My stats are a little rusty, but as far as I see, it doesn't, it goes up.

Hashing is Bernoulli trial, either you beat the target or you don't. That gives mining a geometric distribution, and so the variance (in number of hashes required) is (1-p)/p². The re-targeting algorithm tries to keep the hashrate directly proportional to 1/p, so the variance in time quadratically increases with the hashrate. Right?

I guess the phenomenon above was a much higher variance in hashrate because of people turning their computers off at night, whereas now the variance is greatly reduced due to increased numbers and because miners tend to keep the gear running 24/7.

See also https://en.bitcoin.it/wiki/BIP_0015

It basically comes down to Satoshi's over-reliance on OpenSSL. The whole thing is a hack around the function BN_bn2mpi() (which converts a bignum to a sequence of bytes) so that only the 3 most significant bytes of the number are stored and the rest discarded.

EDIT: After re-reading, I seem to be answering a different question to the one asked. I thought the question was asking why the the 'bits' field was an encoding of the target rather than simply an encoding of the number of fractional bits.

Regardless, I think this highlights some shortcomings in the payment protocol as it stands. It's been designed with a focus on merchants and as such is overly limited in its use for different use-cases. At its heart, it provides a mechanism for building a specific type of transaction between two parties without the users having to mess around with raw transactions. If you think a little bigger, you can cover the case of arbitrary transaction building and signing between multiple (not just 2) parties which subsumes the use-cases already catered for.

The current idea is that the merchant specifies which outputs the user should pay to and expects the transaction to be returned complete and signed.

The idea I've just come up with is that a general transaction (not just outputs) is passed around being build over a number of exchanges without the client software needing to know anything about how the exchange should happen. Signatures are not necessarily required, so arbitrary transactions can be built between multiple clients and a single server, allowing users to review the final transaction before authorizing it.

The thing that gets passed around is a transaction and some details about how the client should further build the transaction - what it should add to the transaction or if it should sign it. Wrap this as before with other useful details like the url, pki-sign etc.


Now, in the standard use-case, originally the merchant creates the outputs he wants and wraps them in a PaymentDetails object and signs it, creating a PaymentRequest.
He sends it to the user who's client interprets this to mean 'I should add some inputs to pay for those outputs, (and maybe add an output for my change), sign it, and then send it back to the url given'. This interpretation is all implicit and built in and thus is limiting.

With the TxBuilder approach the interpretation is explicit.
The merchant takes the outputs he wants as before and creates a transaction. He wants the user to provide inputs who's value matches his outputs, so he specifies the 'inputsValue' and he wants the transaction to be signed, so he specifies this too. He doesn't care about additional outputs (maybe he cares about not creating a huge transaction, so limits outputs to 1 - whatever).
The user's client can read the build details and determine that it wants him to provide input of a certain value, is free to add outputs how he pleases and should sign the result.

My solution to Sergio's use case is also possible now:
Merchant creates a Tx with the output for his payment (maybe not with his change output yet). He specifies the value that the inputs should total and specifies that the transaction should NOT be signed.

The user's client can easily determine what is required and inform the user of the details if need be (as no signature is needed, there is little harm either way). The user agrees and the client fills in the inputs, adds a change output for itself and sends the transaction back.
The merchant can then add his fee payment input and change output. He specifies 0 inputs or outputs are to be added, and specifies to sign the transaction with SIGHASH_ALL.

The users client can then display the details of the final transaction and ask if the user agrees to sign. If so, it returns the almost completed transaction to the merchant who signs it himself (or of course he signs it in the previous step and gives up his ability to refuse the transaction).

The merchant can finally issue an acknowledgement as before so that the user knows that the exchange is complete and its status.


EDIT: @Sergio, sorry for hijacking

Agreed


You've kind of missed the point. The problem Sergio is addressing is that the merchant needs to include an output for his change after paying the fee, and the payee needs to have an output for his own change. Thus you end up with 3 outputs. The merchant does not know what the change address is for the payee, so cannot create a transaction with all the outputs without asking the payee. SIGHASH_SINGLE can help because it allows you to add outputs but is crippled because you don't have a choice as to which output you are signing, in particular this isn't helpful if your funds are spread about a lot and have to use multiple inputs because now the input and output indices cannot possibly match.

Your solution assumes that the merchant has an unspent output with the exact amount needed for the fee. If instead he needs to use multiple inputs, then he can't use SIGHASH_SINGLE. If he does indeed have the exact amount in 1 unspent output, then there is no need to provide his payment first, he can simply add it after.

Also the merchant shouldn't already sign it because then he loses the power to reject the payment. The payee can take the fee amount off the amount owed and only pay the difference. The transaction will be valid but with a smaller (no fee) and the payee can broadcast it themselves.


I think the solution is simply have the payee provide the merchant with a partial transaction with all his details included (but not signed obviously!). It has each of his inputs and includes a single output for his own change so that the difference in value is the exact value of the thing he is purchasing. The merchant then can add the output for the actual payment, inputs to pay for the fee and another output for his own change. He sends this back to the payee who signs it and sends to the merchant who finally chooses whether to accept or decline. If he accepts he can sign it himself and broadcast.

What you're missing is that paying to 160-bit script hash is an addition that wasn't part of the original client. Originally you paid directly to the full public keys.

Greg's point is this:

At the minimum difficulty, the average number of hashes required to find a block is 2³². The nonce field is 32 bits (surprise!) , so on average, each candidate block will have exactly 1 nonce to make it under the target.

The current difficulty is 8,974,296, which means that on average 8,974,296 times more hashes are required to find a block than at the minimum difficulty, so for each block there is a 1 in 8,974,296 chance of there existing a nonce making it under the target.  Put another way, we have to try all 2³² nonces for 8,974,296 different blocks on average to find a valid block.

This number is about 2²³, so we only need to have 23 or so more bits other than the nonce that we can change in order to find a valid block.

Yes and yes.

The points on an elliptic curve can be added (via the construction you describe) and similarly can be subtracted as you've worked out. By repeated addition, you get multiplication of a point by an integer.
The curve that is used in Bitcoin has the property that from a single point G, (for generator point) by repeatedly adding it to itself you get every point (with integer coordinates) on the elliptic curve.

In elliptic curve cryptography a private key, k, is simply an integer, and the public key is the point you get by adding G to itself k times. Given a general point on the curve, there is no known way to get back to the number k without simply trying every one until you get lucky.

The recovery of the Sony keys was because of a flaw in their implementation of the signing algorithm. The algorithm requires a random number which should be different every time something is signed. Sony used the same number every time and this allowed the private key to be recovered (though of course it took a long time before anyone realized that they were always using the same number). The signature is dependent on the random number, so repeatedly signing the same message should give a different signature every time.

Step 1: delete your bash history
Step 2: don't try to roll your own security tools

There's a lot of shoulds, cans and coulds but no how.

Also, I know that Hashcash is your baby and you're rightly proud of it, but Bitcoin isn't Hashcash and your insistence on crowbarring its terminology into your posts make them all the more difficult to read.

Bitcoin condoms - so you don't end up hard-forking your family.
or
Fork safely.

 

The client will relay invs to its other peers for every new block it receives. If it's syncing, then it receives a lot of new blocks and so you get a lot of invs.

Is your local node syncing at the time?

There is a new field in the version message you send which tells the other peer not to send you inv's like this.

To receive block headers, you need to ask with a 'getheaders' message, it doesn't follow the 'getblocks' -> receive 'inv' -> 'getdata' -> receive block  message sequence.

Seems like a nice way to artificially reduce the network hashing rate / temporarily split the network.
I use a number of nodes to send 2 transactions spending the same input to the network, but I make sure to send them as close as possible to the same time. Thus, the rest of the network see that there is a double spend, but there isn't a strong consensus as to which order the transactions arrived, so half the network mine a fork with one transaction and the other half mine a fork with the other. At some point in the future, one side decides it must have been wrong and one of the forks wins. Up until that time, each fork has been competing possibly with many reorgs.

That's for a single double spend. Now think about a collection of nodes which continuously pump out double spends. Each split halves the hashing power if perfectly timed, it doesn't take much to bring the network to its knees.

With the same inputs, the total value of the transaction is the same. Changing the fees means that the total value must be redistributed in a different way to before. Thus some outputs must get less if the fees are to get more.
I'm assuming he doesn't mean to allow adding or removing outputs.

So if I have a reasonable proportion of hashing power, I can stop mining blocks and trigger this mechanism. Then the network will happily accept lower difficulty blocks which I can mine very fast, possibly putting my effective hashing power over 51% if other miners still try to produce blocks at the full difficulty.

Alternatively, when the hashing power drops and this is triggered, some nodes will be pumping out blocks with minimum difficulty and others at some other higher difficulty. Do we stick to the largest proof-of-work chain or simply switch to longest chain as the main chain? All you end up with is a bunch of competing chains and many reorgs. This effectively prevents users from making transactions until the chaos has subsided because they can't be sure they won't be undone. Thus the result is largely the same as if the rules hadn't been changed - you have to wait much longer for your transactions to get into a block, and because of the reduced frequency of blocks, there is more competition for the space and higher uncertainty of your transaction not making the cut.

It's an interesting idea, but you've made too many assumptions on the actions of a 51% attacker. Why is it required that they do not include most transactions into their chain? Their competing chain could include every transaction in the honest chain except one (unspending their own coins) and defeat this protection. A 51% attacker cannot spend coins which are not his, all he can do unspend recently spent coins, in particular his own, allowing double spending. If he only ever changes his own transactions, then these canary transactions will never die and no alarm will sound.

Well it depends how lazy you are . If you share the downloads between the peers without connecting to more peers, then no problem. If you purposely connect to as many peers as there are checkpoints, then it's not the same, especially if you don't bother to disconnect from most of them after you've finished downloading.