From: Satoshi Nakamoto <[email protected]>
Date: Wed, Mar 9, 2011 at 5:15 PM
To: Mike Hearn <[email protected]>
Subject: Re: Open sourced my Java SPV impl
>I hope you are doing well. I finally got all the lawyers happy enough
>to release BitCoinJ under the Google name using the Apache 2 license:
>
>It's incomplete - notably it doesn't properly handle block chain
>splits yet - but the rest is coming. I put a lot of work into
>documentation and comments so hopefully it'll open up BitCoin to a new
>audience who weren't able to understand/build the current code. Over
>the next month or two I'll be finishing off some of the bigger missing
>pieces for a full client-mode implementation.
That's great news! Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too.
>I know you are busy right now but I'm hoping you can find time to
>answer a few questions I had.
I'm happy to answer any questions.
>As part of doing full SPV I'm thinking of adding a getmerklebranch
>message to the protocol. This would return a set of {blockhash,
>branch} pairs
That's a CMerkleTx
>given tx hashes, so allowing verification of a broadcast
>transaction before it was incorporated into a block without storing
>the full chain. Does that approach sound good to you?
I don't understand. A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work. Linking back to an as-yet unsolved block proves nothing.
Network nodes are able to verify 0-conf txes because they have the complete tx index, so they can:
1) verify signatures against dependencies.
2) say that they haven't seen another spend yet, because they know about every tx in existence.
Are you talking about CMerkleTxes for the tx's dependencies? That would get part 1), but not part 2).
If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw.
>Also, I've been thinking of exploring different transaction types
>lately, eg by removing the IsStandard() checks for the testnet.
Very good idea. That should definitely be allowed on -testnet.
>It's
>clear you put a lot of thought into transactions beyond simply moving
>coins around up front, but unfortunately none of it was in the paper
>or documented in the code. Escrow, multi-pay and so on are all
>interesting but I was wondering if you could compile a list of ideas
>for things we can do with the scripting language at some point.
>
>Finally, the code that allows for transaction replacement has been
>disabled but the comment doesn't say why. Is this just to reduce the
>attack surface/complexity or is there a deeper reason?
Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.
See these threads:
http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119
http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
>I haven't fully
>understood why sequence numbers are a property of the tx inputs rather
>than the tx itself.
It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.
The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.
One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.