I think child-pays-for-parent would solve the problem without a hard fork. I didn´t know it was already coded. If you decide to integrate it, I will review the code looking at DoS attacks.

The extensions proposed to the Payment protocol are interesting, but child-pays-for-parent is much simpler for the fee problem.

One of the ideas in the Bitcoin Payment Messages (https://gist.github.com/gavinandresen/4120476) is that the merchant could pay for the fees of a transaction.

The idea of merchant-pays-fee could be solved by extending the transaction verification system. A new SIGHASH_MULTI flag is added. This flags takes a two argument, which is the output index to start from (outIndex) and the number of outputs to sign (numOuts).

This is what it does:

-   The output of txCopy is resized to the size to 2
-   All other txCopy outputs aside from the output at outIndex and the one at outIndex+1 are removed completely.
-   All other txCopy inputs aside from the current input are set to have an nSequence index of zero.

Think of this as "sign a subset of the outputs-- I don't care where the other outputs go".

When this flag is combined with SIGHASH_ANYONECANPAY, then the sender can:

Create a transaction with many inputs i(0),i(1),(i)2.. i(n-1).
For i(0).. i(n-1) the users sign them with SIGHASH_ANYONECANPAY | SIGHASH_MULTI (0,2)

Then the user puts two outputs: one for the merchant and another for change. He puts no fees.

When the merchant wants to add fees, he adds another input m(n) and a single output for the fee change.

To extend this protocol to allow a merchant to mix multiple transactions together and add a single fee tx, then another flag SIG_MULTIHASH could be used that specifies the HASH of the output script  (OutputHashStart), and the number of outputs. (numOuts)

Then clients would search for the outputs to hash when OP_CHECKSIG is executed.

The merchant can then combine tx(1) ... tx(n) into TX by only appending the transactions and adding a new input and a new output.

The only problem I see with the proposal is that if a transaction can be sliced to form valid transactions, then the algorithm that detects double-spends should be modified to discard a transaction tx y another transaction TX is received and contains tx in it.

Best regards, Sergio.

If I want the output script to look like: <pubKey> OP_CHECKSIG

By looking at the code I see no way if doing it.

Is there a way?

Thanks, Sergio.

Check out my old post: http://bitslog.wordpress.com/2011/12/31/mining-for-science/
(section Mining for Algorithm Discovery)

I discuss an "almost"  Turing complete mining idea.

Best regards, Sergio.

Eureka! 

Dear Grau,
 I failed to exploit the supposed "problem". I cannot create a JSON test that differentiates the two implementations. 

I apologize for the inconvenience.

Nevertheless the subject of the thread, which was not to talk about any particular problem, remains useful: how to handle the notification and collaboration between parties when a flaw is discovered in an implementation that is not the reference one but affects the rest.

Best regards.
 Sergio.

Yes Grau, you're right. That's why I didn't make public the problem details. But honestly, the problem is there in the Bitsofproof code, I'm quite sure.
The fact that BisofProof is still in Beta (but won't be in Beta forever) is the reason that I'm asking people: how should we handle a problem with one (but not all) of the client implementations.

I think that, for the community good, as fast as a bug that can cause possible network split is discovered, all users must be notified. I mean all (including users that do not use this client). This does not mean that the bug must be exposed. But if people know their clients can bee "knocked out" of the best chain, they can put additional protective measures to periodically check if they were.

Related to the test cases Grau posted, I'm quite sure they do not check the problem I spotted.
Those test cases do not test the result of each opcode, only they test if the script verification fails or not.
That's completely wrong, or at least it's incomplete.
If you want to check if OP_ADD1 works, you should check that before executing the opcode and afterward the stack have some known values. Now the script test cases only check that the result is TRUE or anything else.

Gavin or donor coders should try to build more detailed test cases for each script arithmetic opcode, to avoid screwing up things in future versions and to help other implementers to verify their codes.

Grau: my impression is that your code is good, as is Mike Hearn's code. The problem is not on your code, but in the lack of a "Bitcoin Bible" manual to specify the hidden and often forgotten rules of the protocol.

Would you allow me to post the problem here?

Since I have audited the security of the main client for a while and I'm getting bored, I turned to look at to the alternate clients (e.g. Bitcoinj Bitsofproof, etc.).

In the past both in Bitcoinj and Bitsofproof I detected incompatibilities between the Satoshi code rules and their implementations, so their clients could be "forked out" of the best chain by specially crafted blocks/transactions.

They were reported to the project maintainers and they have been fixed long ago.

Today I found another incompatibility between the rules of  Bitsofproof and the rules of Satoshi client. I will report today to Grau. Bitsofproof is still in BETA, but looks very promising.

But the point is: Should all the Bitcoin community (apart from the alternate client project maintainer) be notified of the possibility of a network split? If we get to a point where 40% of the network is running client 1 and another 40% is running client 2, then a "bug" in client 2 is also a problem for all users (not only the ones using client 2). Attacks that affect a large part of the network also undermine the credibility of the network as a whole.

So eventually in the future there should be a "higher level" list of problems/vulnerabilities of the Bitcoin network (independent of the client app), that could probably be maintained by the Bitcoin Foundation.

Best regards,
 Sergio.

+1

Excelent idea. But if we are going to hardfork,  it´s time to rethink how the hash of the tx  is computes for signature verification. 
First, we should ban OP_CODESEPARATOR.

But I think the right way to do SIGHASH_WITHINPUTVALUE it is to put the amount outside the script, in another field, and stop embeding things in the input script.

Let
 
Tx' = Tx with all script inputs cleared

TxHash(Tx) = H ( H(Tx') | n | [ amount ] )

Where H() is a double SHA-256 hash. n is the input being verified and amount is the optionally amount.

The advantage of this scheme is that H(Tx) can be cached for the whole transaction, and the second application of H() is very fast. This prevents by design the vulnerability CVE-2013-2292 and it would allow to permit transactions over 100 Kbytes to be standard again.

I wish he would just sends us some words... I wonder if he will be grateful or annoyed at my posts. I hope he is well enough not to worry.

Please point me out where it seems that, maybe my English was not precise enough to express it.


I've never thought about this kind of confiscation. But it would be terribly non-equitative, brutal, and not useful, since maybe there is other people holding as much as that coins, but in hundreds of small transaction outputs.

How Satoshi mining pattern disappears...

I will make it simple. If I did not uncovered this data set yesterday, some else would have done it, surrounded by much worse descriptive words. What I did is not ingenious. Is the most evident method of data mining. The data was there at plain sight.

I put all my effort in my blog post to calm the market showing the truth: that Satoshi or whoever mined them had not used the coins to distort the market, and I succeed, since the BTC price increased afterwards.

Can you imagine how yellow journalism would have handled this information to discredit the coin ?

So please stop blaming me for having uncovered Satoshi or whoever fortune: it was already uncovered.

Please take into account that X-Axis is not time, but block number.

Here is the same data, but with the Time in the X-Axis.

I estimate the PC is rebooted every 100 hours or 4 days.

I think this is for backing up wallets, but I'm unsure..

No, I didn't mean so. These are probably different machines, My apologize. Deltas of 1 may be threads of the same PC.
 

There has been 231828 blocks solved (without counting orphans) which is roughly equal to 2^18. So we can statistically expect a block with 18 more prefixed zeros than the expected difficultly. Block 125552 has only 12 more prefix zeros than the expected (67 vs 56) so statistically it has no meaning at all.

 That's why I'm not hysterically warning you.

Whenever I edit a published post, I add the word "Edit:" or I strike the words that must be removed.

Could you stop this fruitless competition ?

What you see are different THREADS of the same PC. Possibly two or four threads were running concurrently.
Each thread has it own ExtraNonce, but all threads are started almost at the same time.

Do you mean that I should remove that sentence from the post?
If you or Gavin ask me to do it, then I'll do it.