Bitcoin Forum
December 05, 2016, 08:42:01 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Refereed Transactions  (Read 4633 times)
gim
Member
**
Offline Offline

Activity: 90


View Profile
April 30, 2011, 09:29:45 PM
 #1

Would the current script system allow conditional transactions requiring a signed certificate from a third party referee?
Probably it is not possible, for the same reasons that have been disscussed in this thread http://bitcointalk.org/index.php?topic=1786.0.

Though, it would allow very interesting uses of bitcoins...

Let's say A (Alice) is interested in some fancy item (lets say a fancynickname@freenode account) currently accorded to B (Bob) by C (Freenode).
So Alice would like to buy Bob account for 1BTC, but she is reluctant to send him the coin because she don't trust him. He might not give up his account even though he has received payment.
Of course Bob is also reluctant to give up his account before he received payment.

Now, let's say Freenode (who owns a GPG Key) agrees to sign account transfer certificates.
Alice would like to send Bob 1BTC conditional to the issue of such a certificate (within some deadline...).

And it would be so nice if such trades could be done!
A and B can trade without knowing each other, and both only need to trust the referee C.

Any thoughts?
1480970521
Hero Member
*
Offline Offline

Posts: 1480970521

View Profile Personal Message (Offline)

Ignore
1480970521
Reply with quote  #2

1480970521
Report to moderator
1480970521
Hero Member
*
Offline Offline

Posts: 1480970521

View Profile Personal Message (Offline)

Ignore
1480970521
Reply with quote  #2

1480970521
Report to moderator
1480970521
Hero Member
*
Offline Offline

Posts: 1480970521

View Profile Personal Message (Offline)

Ignore
1480970521
Reply with quote  #2

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

Activity: 90


View Profile
April 30, 2011, 09:44:04 PM
 #2

Of course from a UI point of view it can be very simple. Alice just asks Freenode's website what she should put in the "condition" field in her "bitcoin send" window.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 1988



View Profile
April 30, 2011, 10:10:31 PM
 #3

And it would be so nice if such trades could be done!
A can trade with B without knowing each other, and both only need to trust the referee C.

ClearCoin escrow has worked good enough for my purposes:
  http://www.clearcoin.com/

gim
Member
**
Offline Offline

Activity: 90


View Profile
April 30, 2011, 10:25:02 PM
 #4

ClearCoin escrow has worked good enough for my purposes:
  http://www.clearcoin.com/

Yeah! ClearCoin is a kind of referee and could become a trusted certificate issuer.
But there are also many potential referees that would refuse to handle the coins themselves.
xc
Jr. Member
*
Offline Offline

Activity: 40


View Profile
April 30, 2011, 10:29:47 PM
 #5

Satoshi created the transaction scripting system exactly for purposes like this.

"The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.  If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later." -Satoshi

http://bitcointalk.org/index.php?topic=195.msg1611#msg1611

He said he was working on it for two-party escrows, but now that he's gone it might be something for the current developers to consider prioritizing.

Being able to so directly manipulate currency at the programmatic level allows for a full realization of the promises of smart contracts.  Contract enforcement through code without violence.  Decentralized, voluntary arbitration.  Realized Cryptoanarchy.  Imagine how much easier it would be to conduct business in such an environment.  It's not mentioned often here, but Bitcoin, in addition to dramatically altering the monetary system, really could revolutionize the entire system of commerce law.

1Ff7AUN7bQkqfSjLaMLi54tWLnWTqvrhwA
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 30, 2011, 10:51:41 PM
 #6

It's possible, though I think you need some out-of-band system to get the escrow agent to sign your transaction.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gim
Member
**
Offline Offline

Activity: 90


View Profile
April 30, 2011, 11:28:24 PM
 #7

He said he was working on it for two-party escrows, but now that he's gone it might be something for the current developers to consider prioritizing.

Right, it would be great if all those features could be added quickly. As satoshi said, when new implementations of the bitcoin client will be around, things will quickly be set in stone. If things are not moving right now, I fear that the script system will never be used, and will remain an embryo.
That's why I'd like to see some movement.

Look at smtp, it has so much defaults and it seems nothing can be done... nobody has switched to [better]mail.
If bitcoin ever begin to go mainline (is it?), who will dare to switch to [better]coin ? Won't it be too late?
gim
Member
**
Offline Offline

Activity: 90


View Profile
April 30, 2011, 11:30:50 PM
 #8

It's possible, though I think you need some out-of-band system to get the escrow agent to sign your transaction.

Do you have a script example? How do you deal with the deadline?
Which OP_s have to be activated in the client?

Sorry, lots of questions Smiley
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
May 01, 2011, 12:24:32 AM
 #9

You can do it really simply with a script like this:
Code:
[2] <escrow's pubkey> <sender's pubkey> <recipient's pubkey> [3] OP_CHECKMULTISIG
The escrow and one party, or both parties, must cooperate to send the coin. The escrow needs to enforce the deadline, though. I don't think there's any way to have a secure deadline within transactions.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
May 01, 2011, 12:43:11 AM
 #10

I don't think there's any way to have a secure deadline within transactions.
This is the bit where I tout the usefulness of OP_BLOCKNUMBER in spite of the modest complications a safe implementation would entail.  Wink most recently discussed here http://bitcointalk.org/index.php?topic=6439.0

Much as I think that the scripting is the best bit of Satoshi's work, I'm doubtful it will ever be revived.
The fact that a bitcoin is increasingly valuable with scripting disabled means that scripting is not essential. Enabling scripting, although I'm a big fan, would break the rule that a successful product should do one thing well.

ByteCoin
just_someguy
Full Member
***
Offline Offline

Activity: 125


View Profile
May 01, 2011, 01:02:08 AM
 #11

Do you mean push the current block count onto the stack? That would be handy.
What are the problems with doing that? I don't see that its been discussed.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
May 01, 2011, 01:27:28 AM
 #12

Do you mean push the current block count onto the stack? That would be handy.
What are the problems with doing that? I don't see that its been discussed.

In the event of a block chain reorganization, in the absence of a double spending attack, all the transactions on the shorter branch can expect to be incorporated into the longer chain. The only "money" that's lost is the rewards for finding blocks on the shorter branch - the coinbase transactions. There's a reason why coinbase takes such a long time to mature, it's because it's subject to being disappeared in the event of a reorg. We assume that reorgs can't take place at a depth of 120 blocks so coinbase matures after that time.
The problem comes with OP_BLOCKNUMBER transactions which are involved in a reorg where they get incorporated into a block which changes the functionality of the script because of the different block number. Any transactions spending coins depending on OP_BLOCKNUMBER transactions may also get invalidated and that's bad. So to be safe there would have to be some scheme that provides as much assurance as is provided with coinbase maturing for 120 blocks. I guess that coinbase matures at a rate of 5BTC every 12 blocks so perhaps OP_BLOCKNUMBER transactions shouldn't mature until max(120,ceil(value_in_bitcoins/5*12)) blocks have passed to provide similar assurances.

It's not a great solution as OP_BLOCKNUMBER transactions are treated differently to any others.

ByteCoin  
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
May 01, 2011, 01:35:38 AM
 #13

I wouldn't oppose OP_BLOCKNUMBER if transactions using it matured like that.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gim
Member
**
Offline Offline

Activity: 90


View Profile
May 01, 2011, 01:35:02 PM
 #14

You can do it really simply with a script like this:
Code:
[2] <escrow's pubkey> <sender's pubkey> <recipient's pubkey> [3] OP_CHECKMULTISIG
The escrow and one party, or both parties, must cooperate to send the coin. The escrow needs to enforce the deadline, though. I don't think there's any way to have a secure deadline within transactions.

Interesting! Strange that this ownership is symmetric in sender/recipient/escrow.

I was thinking that the referee should be left apart from the actual bitcoin transaction and would only sign a "<B> gave <A> his account prior to <date>" certificate. But maybe it's a good way to deal with the deadline problem? (Referee would be trusted to handle the deadline correctly.)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 01, 2011, 02:35:41 PM
 #15

Any script opcodes that import state from outside can be used to fork the block chain. It's not sufficient to have OP_BLOCKNUMBER only be spendable after N blocks as somebody can write a script that is valid up until a certain time and then becomes invalid, allowing arbitrary forking of the chain even in the absence of naturally occurring re-orgs.

Transactions that "mature" after a certain time are possible with nLockTime, although without replacement it's not that useful. Also scripting isn't really disabled. You just have to get your new script into the whitelist and then convince some miners to upgrade. All clients will understand that new script type afterwards.
gim
Member
**
Offline Offline

Activity: 90


View Profile
May 01, 2011, 03:25:56 PM
 #16

Any script opcodes that import state from outside can be used to fork the block chain.

I'm not really sure your argument is valid or possibly I don't understand.
Bob would put the data in the chain when he provide the scriptSig (he forged using the certificated) to redeem his due.
He is supposed to do that before the deadline, and bitcoins are frozen until then. What fork could that induce?
gim
Member
**
Offline Offline

Activity: 90


View Profile
May 01, 2011, 03:36:32 PM
 #17

He is supposed to do that before the deadline, and bitcoins are frozen until then. What fork could that induce?

I mean.. the only real issue i see is the timestamping vs chain reorg problem.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
May 01, 2011, 08:04:51 PM
 #18

Any script opcodes that import state from outside can be used to fork the block chain. It's not sufficient to have OP_BLOCKNUMBER only be spendable after N blocks as somebody can write a script that is valid up until a certain time and then becomes invalid, allowing arbitrary forking of the chain even in the absence of naturally occurring re-orgs.

You're right -- it is impossible to do safely. The attacker could do something like:
Code:
OP_BLOCKNUMBER [120000] OP_LESSTHAN

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
gim
Member
**
Offline Offline

Activity: 90


View Profile
May 01, 2011, 09:22:17 PM
 #19

Dunno about OP_BLOCKNUMBER, but if this instruction returns the number of the block in which the script (or even the scriptSig) is meant to be included into, i can't see the problem... except for chain reorganisation.
Of course, it should not return the current block number as in "today's last blocknumber" in the case it is verified later.

I'd like to know if I'm missing something.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
May 01, 2011, 09:35:16 PM
 #20

The block in which the script is meant to be included into can't be known by people verifying the transaction.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1] 2 »  All
  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!