1) "Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
for pruned nodes)" - 2013-06-06 - Peter Todd <pete@petertodd.org> -
bitcoin-development email list


All instances of =3D should simply be =.

Ok, I wrote some code to do it and was making sure I hadn't missed some obvious-to-you-but-not-me issue before creating a pull request.
I'll create a patch and send you privately instead - you may find it useful even if you've already done most of the work already.

Is there a subtle issue with recursive fee calculation that's prevented it being implemented?

Also, you're going to need a better example than "listreceivedbyaddress" because all of its functionality is already provided in the transactions tab.

Yes, this is interesting. You just reminded me - I had a thought some time ago that it might be possible to create trusted oracles using some kind of secure 2-party computation, such that the oracle doesn't know what it is that he knows, and therefore cannot lie convincingly. I guess it's very similar underneath to your garbled circuit blacklisting idea - have you already considered this?


This goes the other way too. If I receive a PaymentACK saying the payment was rejected, it would be nice to have proof that the merchant won't still broadcast my payment anyway.

Yes, I agree it's a solution looking for a problem, but we're brainstorming 

But the SPV client has no guarantee that he's been given all transactions relevant to him. If you can trust a remote peer, then you can be sure that you have been given everything.

What might be better is for a trusted service running a full node to expose a 'getbalance <scriptPubkey>' command which looks up the scriptPubkey in the UTXO set and returns the total value of all unspent outputs to that scriptPubkey. This would mean that the transaction downloads could be from untrusted peers (like now) and then confirmation that you've received everything is done by querying a trusted node for the final balance and comparing it to your calculated balance.

This has illustrated an issue however.

When the transactions are being added to the block. Each time one is added, it's dependants are added to the queue. When we've exhausted all the transactions which link directly off the main chain, we're left with these dependant transactions which always have zero priority. If they also have zero fee, then the ordering fails to choose one over another.

Thus the ordering of the priority queue ends up being determined by the order that the transactions were added to it.

When Mr 8's 500BTC transaction is added to the block, it has a very high priority, meaning that it's added early and its dependants are added to the queue first. Once the priority>0 transactions are all added, his next transaction is at the front of the queue. This again puts the next one in the queue early. It wouldn't even matter if the other transactions were of low value and huge. They'd be first in the queue. You could use this to fill the entire block with one transaction with zero fee, simply by making it depend on a high priority transaction (which also has zero fee).


One solution is to amend the ordering. It currently only depends on the priority value and the fee/kB, so it fails to distinguish when they are both equal, falling back to insertion order. If the third element (the tx pointer) of the TxPriority object was used for comparison too, then the zero fee, zero priority transactions would be ordered by where they are in RAM - which is at least not predictable. This does have the downside (?) that it is no longer deterministic. To do that you'd want to order by hash - but that could get expensive.


EDIT: thinking a bit more, ordering by pointer doesn't really work either because the allocation strategy in std::map is (I'm guessing) likely to be to allocate a chunk of memory enough for multiple elements, so the chain of transactions coming in one after another will end up in a chunk of contiguous memory, and we end up falling back to insertion order again.

The transaction is not really "simplified". Instead, a new transaction is created with the other inputs blanked out.
See here, from step 6.

Ok, I think I solved the mystery.

Firstly, BTC Guild are almost certainly running 2 bitcoind instances, one of which has 'blockprioritysize' set to maximum, meaning that fee/kB is essentially ignored.

Secondly, a few blocks before (234941) was solved by BTC Guild, only a few seconds after the previous block. Because of the short time period, there were very few transactions left in the memory pool which linked directly off the main chain. Instead it was filled with very low priority transactions and chains of transactions (zero priority). This block cleared out most of the low priority transactions, thus all that was left was this guy's chain.

Fast forward a few blocks and BTC Guild solved another block (234946), and again in only a few seconds. This time there were no low priority transactions left, only zero priority transaction chains. So that is what got included in the block.

Ah sorry, I didn't look hard enough. Back to the drawing board I guess.

I also just realized that blockchain.info displays the transactions in a block from last to first (except the coinbase tx). Confused the hell out of me trying to follow the chain and seeing inputs from transactions which seemingly didn't exist yet.

These transactions aren't in the same block. The chain of transactions was broadcast at the same time, but each transaction appeared in consecutive blocks.

The first transaction which links off a confirmed transaction has high priority so gets into the block, and the rest of the chain has zero priority, so doesn't get into the block.



The priority is calculated before the transactions are selected to go into the block. The view is NOT updated while this is happening - in fact, the view is not of the memory pool at all, it is of the previous block. For any chain of transactions in the memory pool, only the first (the one linking off the blockchain) has its nConf calculated.

FYI this is already done at a very similar type of exchange for the same reason.

You've come up with ElGamal encryption independently. Pretty impressive .

Heh, good point!

Short answer: No.
Longer answer: 'ConnectInputs()' doesn't exist anymore in the code. It never explicitly checked for duplicates because it was a check of a single transaction, so it couldn't know about the other transactions in the block. However, if the transactions are duplicate then updating the UTXO set will fail (presumably what it meant). If a true collision of different transactions this isn't true (as far as I can see).
The same is true now, the code has just moved to CheckInputs and UpdateCoins.

It's really just the same rule. You can't have 2 live transactions (those with unspent outputs) with the same hash. See https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2105.

Yes. Though you have to deal with the case where the transaction isn't in the blockchain separately.


Basically from the view of the reference client, there is no need for the identifier to be unique forever. The only need for looking up transactions is to get their unspent outputs. Once the outputs are spent, they never need to be looked up again, so the identifier can be reused.

I don't know what you mean by 'out' transaction exactly, but if you spend some coins and have some change left over, you'll end up with a transaction where you're both spending and receiving.

Thus there'll be some overlap between the transactions shown by listunspent and transactions which spent some of your coins ('out' transactions?).

I suspect you're using a regular bitcoind to call your customized server. The vanilla client doesn't know about your new calls and so doesn't convert the values.

If you run your modified Qt client and open the debug console, you'll notice the command works just fine.

Deepceleron, thanks for taking the time to explain, though the convergence of the geometric to exponential distribution wasn't the issue I had. However, dealing with the exponential distribution made finding my error much simpler.

My issue was the conversion from dealing with number of hashes to dealing with time.
My incorrect reasoning was that 1/p is the mean number of hashes, which we choose to be 10 minutes worth of hashes at the current hashrate, R, so  1/p = 600R, then 1/p² is 600²R² and concluding that this is the variance in time, which therefore goes up with the square of the hashrate .

Anyway, I worked out the error: Transforming the exponential CDF for the number of hashes required into the CDF of time required using  1/p = 600R  gives an exponential distribution with a mean of 10 minutes, in particular the hashrate cancels itself out, and so the variance is constant, no matter the hashrate.

I was hoping you'd explain why the difference is unobservable.

Anyway, if anyone has the time to do it, it might be interesting to see a chart of the cumulative distributions of the solution times during e.g. January and April, superimposed to see if the bell shape has noticeably widened with the increase in hashing power.