Transactions chaining ( create/sign ) question

[Andrew Vorobyov]

I think we can overlay Ripple network on top of bitcoin... I need you, developers, to validate my idea.

BTC here will be used as tokens of credit(IOU(i owe you))

For example we have 4 addresses and we want to pass 4 IOUs to through them...

Address #1 moves it to #2, #2 to #3 and #3 to #4.

Question is:

Can we create chain of unsigned transactions to make sure that these tokens finally arrive to #4 and ONLY then sign it so it will move?

[1713473645]

1713473645

[1713473645]

1713473645

[1713473645]

1713473645

[1713473645]

1713473645

[Andrew Vorobyov]

Is it a boycott or what? it's bloody simple question to anybody who working on Bitcoin...

[Gavin Andresen]

Chaining not-yet-signed transactions is impossible because transaction inputs are identified by the previous transaction's hash, and the transaction's hash includes everything about the transaction, including the signatures.

A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.

[Andrew Vorobyov]

A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.

Great idea, Gavin!

So when we will have facilities to spend multi signature transactions without having all of the keys in one wallet?

Can you estimate how much time will it take to develop this?

[blueadept]

There's another way to chain transactions that could be used in an overlay network, based on two schemes from the Contracts wiki page.

Code:

A----B
\   /
 \ /
  C-----D

Imagine a four-node subgraph of a larger network, where A wants to send some BTC to D.  A has an open 2-of-2 transaction, a la Rapidly-adjusted (micro)payments to a pre-determined party to each of B and C, and C has such a transaction to D, and B also has one to C.

With such a network, assuming the transactions paying the 2-of-2 addresses have enough confirmations, value transfer could happen immediately without waiting for additional confirmations of every step.  A could increase the amount it's paying C (or B), and C could increase the amount it's paying to D (or B could increase the amount it's paying to C, and C could increase the amount it's paying to D).  The problem is that this still doesn't account for the fact that A could send extra money to C, and C could just keep it instead of sending it to D.

However, you can add this trick, based on Trading across chains.  A and/or D somehow come up with 256 bits of random data, creating a secret known only to them.  They then take the SHA256 hash of it, and when each of the adjustable transactions is adjusted, it's sent to a script that not only requires the recipient's key to unlock, but also the preimage of the SHA256 hash (meaning, the output script or P2SH script specifies a SHA256 hash that has to equal the hash of a value in the input script redeeming it, like in the contract example).  This means that the transactions can be pre-constructed and sent on to the next party, but until the random preimage is made public, none of those transactions may commit.

There's still an issue in that it's possible that none of the nodes along the chain may be ready to finalize its transaction, so there's no guarantee that any of those nodes would HAVE to make the preimage public; I'm still working on ideas of how to either guarantee that each node along the chain gets a copy of the preimage or how to incentivize nodes to pass the preimage along the chain (probably using risk deposits).  But once that problem is solved, a two-step commit in such a chain should be possible.

[Mike Hearn]

Hmm, I don't think I understand.

If the pre-image is not available then when it becomes so, all the transactions have to be resigned anyway, no? So what does this buy you? C could still keep the funds sent to it without relaying it onwards.

[blueadept]

No, the transactions aren't actually related to each other and don't use each other as inputs. They are more like pre-existing relationships between the nodes, agreements that basically say "I've committed to pay you up to X BTC that I expect you to pass on to other nodes you have relationships with, minus fees."

Between A and C, the initial transaction would be sent to a regular 2-of-2 address. Then they'd wait for a few confirmations and consider the relationship established.

Each time A wants to send money through C, it would sign a transaction with a smaller part back to itself and a larger part to C. The trick is that the destination going to C would change every time, requiring C to use both its key and the preimage to redeem the output.

I hope that's more clear...

[Mike Hearn]

Yes, I know how the rapid adjustment transactions work (I wrote that wiki page after all). What I don't see is what the pre-image gets you. Once it is revealed C could still sit on the money. What forces C to relay the funds to D?

I'm sure there is a valid answer, I just don't understand it right now.

[cbeast]

A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.

Great idea, Gavin!

So when we will have facilities to spend multi signature transactions without having all of the keys in one wallet?

Can you estimate how much time will it take to develop this?

You have asked the $64,000 (literally) question. It will happen, have faith.

[blueadept]

A would wait until each of the adjustable transactions is adjusted before releasing the preimage. Technically, C could still spend the multisignature transaction by signing it, but won't be able to spend the resulting output without the secret.

So A adjusts its transaction to C, C adjusts its transaction to D, and then the preimage is made public allowing C to spend the output of the multisignature transaction. The multisignature transaction may be broadcast before the preimage is known, but C would have no way of spending its output until it is. That might screw A out of the funds but it will lose money for C as well assuming there's a risk deposit.

If that's still not clear, I apologize. I'm posting from my phone. I can get on a PC in a bit when I have more time and illustrate it better/edit it for clarity, maybe provide something closer to an actual spec.

[markm]

Hmm...  If we can actually know the relative resources of the participants then we could set the risk deposit in proportion, to try to make sure that, for example, if C has ten thousand times as much total resources as A, the risk deposit is ten thousand times as much as A stands to lose, so that for C to uses it vast resources to "bully" A by thinkign to iself "hey, A only has so much capital, if I keep making sock-puppets who suck A into traps where the sock-puppet and A both lose, I can eventually fritter away all of A's resources at a cost that is only a trivial fraction of my own resources. How much exactly would it be worth to me to cause A some losses?"

The problem is we would presumably have to assume any possible C we do not have total transarency into the total capital and political capital or alliances and so on of to be a sock-puppet of some guesstimated/imagined potential large spendthrif enemy that might be out there somewhere creating sockpuppets seeking to get that attack-vector C-position in transactions of this type?

-MarkM-

[Gavin Andresen]

A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.

Great idea, Gavin!

So when we will have facilities to spend multi signature transactions without having all of the keys in one wallet?

Can you estimate how much time will it take to develop this?

You have asked the $64,000 (literally) question. It will happen, have faith.

I've been switching back and forth between writing a spec for it ( https://gist.github.com/2839617 ), implementing it ( https://github.com/gavinandresen/bitcoin-git/tree/signrawtx ), writing up a test plan ( https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_Plan ) and testing.

My goal is to get all that done by the end of this week and have it in the 0.7 release.  But lots of things could make it take longer.

[Andrew Vorobyov]

All I can say - I will continue with my donations... Thank you...

[cbeast]

A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.

Great idea, Gavin!

So when we will have facilities to spend multi signature transactions without having all of the keys in one wallet?

Can you estimate how much time will it take to develop this?

You have asked the $64,000 (literally) question. It will happen, have faith.

I've been switching back and forth between writing a spec for it ( https://gist.github.com/2839617 ), implementing it ( https://github.com/gavinandresen/bitcoin-git/tree/signrawtx ), writing up a test plan ( https://secure.bettermeans.com/projects/4180/wiki/Raw_Transaction_RPC_Test_Plan ) and testing.

My goal is to get all that done by the end of this week and have it in the 0.7 release.  But lots of things could make it take longer.

Pardon the topic change. This is huge.