When I looked into the coinbase of BTC, I found there were three outputs in it.
one for miners to get reward of BTC.
ont for commitment.
but the last one, I don't know what it is.
Related
I'm trying to understand an illustrative example of how Lamport's algorithm is applied. In the course that I'm taking, we were presented with two representations of the clocks within three [distant] processes, one with the lamport alogrithm applied and the other without.
Without the Lamport algorithm:
With the lamport algorithm applied:
My question is concerning the validity of the change that was applied to the third entry of the table pertaining to the process P1. Shouldn't it be, as the Lamport algorithm instructs, max(2, 2) + 1, which is 3 not 4?
When I asked some of my classmates regarding this issue, one of them informed me that the third entry of the table of P1 represents a "local" event that happened within P1, and so when message A is arrived, the entry is updated to max(2, 3) + 1, which is 4. However, if that was the case, shouldn't the receipt of the message be represented in a new entry of its own, instead of being put in the same entry that represents the local event that happened within P1?
Upon further investigation, I found, in the same material of the course, a figure that was taken from Tannenbaum's Distributed Systems: Principles and Paradigms, in which the new values of an entry that corresponds to the receipt of a message is updated by adding 1 to the max of the entry before it in the same table and the timestamp of the received message, as shown below, which is quite different from what was performed in the first illustration.
I'm unsure if the problem relates to a faulty understanding that I have regarding the algorithm, or to the possibility that the two illustrations are using different conventions with respect to what the entries represent.
validity of the change that was applied to the third entry of the table pertaining to the process P1
In classical lamport algorithm, there is no need to increase local counter before taking max. If you do that, that still works, but seems like an useless operation. In the second example, all events are still properly ordered. In general, as long as counters go up, the algorithm works.
Another way of looking at correctness is trying to rebuild the total order manually. The hard requirement is that if an event A happens before an event B, then in the total order A will be placed before B. In both picture 2 and 3, everything is good.
Let's look into picture 2. Event (X) from second cell in P0 happens before the event (Y) of third cell of P1. To make sure X does come before Y in the total order it is required that the time of Y to be larger than X's. And it is. It doesn't matter if the time difference is 1 or 2 or 100.
in which the new values of an entry that corresponds to the receipt of a message is updated by adding 1 to the max of the entry before it in the same table and the timestamp of the received message, as shown below, which is quite different from what was performed in the first illustration
It's actually pretty much the same logic, with exception of incrementing local counter before taking max. Generally speaking, every process has its own clock and every event increases that clock by one. The only exception is when a clock of a different process is already in front, then taking max is required to make sure all events have correct total order. So, in the third picture, P2 adjusts clock (taking max) as P3 is way ahead. Same for P1 adjust.
I looked through the Squareup.com API v2 for a method to retrieve a transaction using the receipt number on the printed receipt (It is 4 characters) but I found nothing documented for this method.
Is this possible?
I know I can get the transaction details using transaction ID but that's not what I want.
No, you cannot query the API by receipt number at this time.
If you needed to look up by receipt number, you could keep a separate store of the receipts indexed by the receipt code, but that might be more trouble than it is worth.
The 4-digit receipt ID you are referring to is the same as the first four characters of the selected tender ID for the transaction. You could accomplish this by retrieving all transactions for the given location and searching the first four characters. You may need additional details, such as the payment total to guarantee against duplicates.
I'm trying to Replace By Fee (RBF) an unconfirmed transaction due to low fee which was set more than a week ago (5c5dcb0b21dc6142d789899f5efb31b2deb9366644f83d6dfa6e580f9a8697f0).
To do the replacement, I'm using coinb.in. However, when I fill in my address (1SfmVjR5itYMgFY7jD5meLg8efmmtKfXV) and hit 'Load', the tool shows a zero balance. I know it's not correct, as the transaction is not confirmed yet and as I can check the balance in BlockCypher.
Can anyone explain me what I'm doing wrong?
Should I insert the Input to my wallet manually on coinb.in? If so, where can I find the 'Script'? It doesn't seem right...
There is no "unspent transaction output" at your Address currently so that Coinb.in shows a zero balance.
You can get a raw transaction with here.
After you get it, you can modify the amount of BTC for output with Coinb.in, sign it with your private key and broadcast it.
Hope this is helpful for you.
I am looking for a way to get only 'new' transactions from specific account item. I.e. only transactions that was posted to account after I made previous transactions fetch/search.
For example I have the following scenario:
I have add item to consumer. Lets say consumer have 1 account item named 'BankAccount1'.
I fetch/search ALL transactions for some BankAccount1 and store transactions locally.
Now I need a way to get only new transactions on periodic basis. I.e. only transactions that was posted to 'BankAccount1' after previous fetch/search call. Is it possible to do this or I need to get all transactions every time and just skip transactions with Id which already present locally? If transaction Id is unique and incremental (did they?) maybe its possible to save last fetched transaction Id, and on next time get only transactions with Id > prevFetchId (what API to use if its possible)?
p.s.
I am using container based approach REST API.
As per your question, I can infer that you are going to store transactions locally in your DB. In that case Yodlee recommend to use Procedural Data Extracts, using which you can keep your DB in sync with Yodlee Cloud. You can find more details about it here.
Yodlee recommends you to pass date range in the executeUserSearchRequest API to get the transactions for any specific duration,as getting only new transactions may cause some issues. This is why Yodlee recommends to have few days of overlap, this will help you in not missing any transaction.
Transaction ID would be unique but it may not be incremental.
Lets say I have a website that sells widgets. I would like to do something similar to a tag cloud tracking best sellers. However, due to constantly aquiring and selling new widgets, I would like the sales to decay on a weekly time scale.
I'm having problems puzzling out how store and manipulate this data and have it decay properly over time so that something that was an ultra hot item 2 months ago but has since tapered off doesn't show on top of the list over the current best sellers. What would be the logic and database design for this?
Part 1: You have to have tables storing the data that you want to report on. Date/time sold is obviously key. If you need to work in decay factors, that raises the question: for how long is the data good and/or relevant? At what point in time as the "value" of the data decayed so much that you no longer care about it? When this point is reached for any given entry in the database, what do you do--keep it there but ensure it gets factored out of all subsequent computations? Or do you archive it--copy it to a "history" table and delete it from your main "sales" table? This is relevant, as it has to be factored into your decay formula (as well as your capacity planning, annual reporting requirements, and who knows what all else.)
Part 2: How much thought has been given to the decay formula that you want to use? There's no end of detail you can work into this. Options and factors to wade through include but are not limited to:
Simple age-based. Everything before the cutoff date counts as 1; everything after counts as 0. Sum and you're done.
What's the cutoff date? Precisly 14 days ago, to the minute? Midnight as of two Saturdays ago from (now)?
Does the cutoff date depend on the item that was sold? If some items are hot but some are not, does that affect things? What if you want to emphasize some things (the expensive/hard to sell ones) over others (the fluff you'd sell anyway)?
Simple age-based decays are trivial, but can be insufficient. Time to go nuclear.
Perhaps you want some kind of half-life, Dr. Freeman?
Everything sold is "worth" X, where the value of X is either always the same or varies on the item sold. And the value of X can decay over time.
Perhaps the value of X decreased by one-half every week. Or ever day. Or every month. Or (again) it may vary depending on the item.
If you do half-lifes, the value of X may never reach zero, and you're stuck tracking it forever (which is why I wrote "part 1" first). At some point, you probably need some kind of cut-off, some point after which you just don't care. X has decreased to one-tenth the intial value? Three months have passed? Either/or but the "range" depends on the inherent valud of the item?
My real point here is that how you calculate your decay rate is far more important than how you store it in the database. So long as the data's there that the formalu needs to do it's calculations, you should be good. And if you only need the last month's data to do this, you should perhaps move everything older to some kind of archive table.
you could just count the sales for the last month/week/whatever, and sort your items according to that.
if you want you can always add the total amonut of sold items into your formula.
You might have a table which contains the definitions of the pointing criterion (most sales, most this, most that, etc.), then for a given period, store in another table the attribution of points for each of the criterion defined in the criterion table. Obviously, a historical table will be used to store the score for each sellers for a given period or promotion, call it whatever you want.
Does it help a little?