Bitcoin Forum
December 04, 2016, 08:22:45 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Transactions chaining ( create/sign ) question  (Read 1151 times)
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 565



View Profile
May 26, 2012, 10:44:41 AM
 #1

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?


1480839765
Hero Member
*
Offline Offline

Posts: 1480839765

View Profile Personal Message (Offline)

Ignore
1480839765
Reply with quote  #2

1480839765
Report to moderator
1480839765
Hero Member
*
Offline Offline

Posts: 1480839765

View Profile Personal Message (Offline)

Ignore
1480839765
Reply with quote  #2

1480839765
Report to moderator
1480839765
Hero Member
*
Offline Offline

Posts: 1480839765

View Profile Personal Message (Offline)

Ignore
1480839765
Reply with quote  #2

1480839765
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480839765
Hero Member
*
Offline Offline

Posts: 1480839765

View Profile Personal Message (Offline)

Ignore
1480839765
Reply with quote  #2

1480839765
Report to moderator
1480839765
Hero Member
*
Offline Offline

Posts: 1480839765

View Profile Personal Message (Offline)

Ignore
1480839765
Reply with quote  #2

1480839765
Report to moderator
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 565



View Profile
May 30, 2012, 01:01:07 PM
 #2

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

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 30, 2012, 05:23:03 PM
 #3

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.

How often do you get the chance to work on a potentially world-changing project?
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 565



View Profile
May 30, 2012, 05:49:15 PM
 #4

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
Full Member
***
Offline Offline

Activity: 225


View Profile
June 10, 2012, 01:43:19 AM
 #5

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.

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
June 10, 2012, 01:53:11 PM
 #6

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
Full Member
***
Offline Offline

Activity: 225


View Profile
June 10, 2012, 02:51:03 PM
 #7

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...

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
June 10, 2012, 10:59:54 PM
 #8

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
Donator
Legendary
*
Offline Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
June 11, 2012, 12:45:43 AM
 #9

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.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
blueadept
Full Member
***
Offline Offline

Activity: 225


View Profile
June 11, 2012, 12:50:35 AM
 #10

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.

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
markm
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
June 11, 2012, 10:47:53 AM
 #11

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
June 11, 2012, 05:55:40 PM
 #12

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.


How often do you get the chance to work on a potentially world-changing project?
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 565



View Profile
June 11, 2012, 06:01:12 PM
 #13

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

cbeast
Donator
Legendary
*
Offline Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
June 11, 2012, 07:44:11 PM
 #14

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.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!