Bitcoin Forum
December 07, 2016, 10:58:14 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Proposal : standard transactions for security/backup/escrow  (Read 4961 times)
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 19, 2011, 02:30:58 PM
 #21

I want bitcoin to have the possibilities that hashcoin proposes.
Maybe it's too soon, but if there's no risks associated with including the non turing-complete scripts and the nLockTime, the sooner we have it the better. It will be very useful for POS payments.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
1481108294
Hero Member
*
Offline Offline

Posts: 1481108294

View Profile Personal Message (Offline)

Ignore
1481108294
Reply with quote  #2

1481108294
Report to moderator
1481108294
Hero Member
*
Offline Offline

Posts: 1481108294

View Profile Personal Message (Offline)

Ignore
1481108294
Reply with quote  #2

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

Posts: 1481108294

View Profile Personal Message (Offline)

Ignore
1481108294
Reply with quote  #2

1481108294
Report to moderator
1481108294
Hero Member
*
Offline Offline

Posts: 1481108294

View Profile Personal Message (Offline)

Ignore
1481108294
Reply with quote  #2

1481108294
Report to moderator
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
September 19, 2011, 02:42:36 PM
 #22

I want bitcoin to have the possibilities that hashcoin proposes.
Maybe it's too soon, but if there's no risks associated with including the non turing-complete scripts and the nLockTime, the sooner we have it the better. It will be very useful for POS payments.


I don't see the necessity of getting ahead of ourselves.  What hashcoin suggested enables more functionality than just the multi-sig scripts alone.  There's plenty of unique functionality available through standardized multi-sig scripts, and those are going to be plenty valuable to the Bitcoin community as a whole.  My concern is that nLockTime opens up a can of worms w.r.t. security & complexity of the network, so that's not something to just "throw into the client." 

If you believe the nLockTime stuff should be higher priority than the multi-sig scripts, that's a different debate.  It sounds like Gavin has already decided to start standardizing the multi-sig stuff, so I was curious if he ever concluded anything...



Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 19, 2011, 04:08:15 PM
 #23

If nLockTime would not be secure right now, we should wait. But if it is secure, it makes multi-sig scripts more useful.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
September 19, 2011, 07:53:07 PM
 #24

Status of the multisig proposal:  There are two, a stripped-down, simplified one:
  https://gist.github.com/39158239e36f6af69d6f

... and a supports-more-use-cases-but-is-more-complicated one:
  https://gist.github.com/dba89537d352d591eb36


How often do you get the chance to work on a potentially world-changing project?
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 19, 2011, 09:00:22 PM
 #25

Quote
An options contract where the outcome is triggered by a key being broadcast: (Ks AND K1) OR (Kr AND K2) - s gets control of funds if K1 is broadcast, r gets control if K2 is broadcast.

This option would allow trust-less exchange between chains, right?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
September 19, 2011, 11:14:01 PM
 #26

This option would allow trust-less exchange between chains, right?

No. Exchanges between chains require at least more scripting functionality enabled and some require nLockTime and replacement.

Quote
An options contract where the outcome is triggered by a key being broadcast: (Ks AND K1) OR (Kr AND K2) - s gets control of funds if K1 is broadcast, r gets control if K2 is broadcast.

This is misleading as K1 and K2 have to be signatures specific to the transaction and not just secrets which can be revealed.
Someone, please explain how the above construction facilitates the functionality mentioned.

ByteCoin
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
September 19, 2011, 11:41:34 PM
 #27

Quote
An options contract where the outcome is triggered by a key being broadcast: (Ks AND K1) OR (Kr AND K2) - s gets control of funds if K1 is broadcast, r gets control if K2 is broadcast.

This is misleading as K1 and K2 have to be signatures specific to the transaction and not just secrets which can be revealed.
Someone, please explain how the above construction facilitates the functionality mentioned.

ByteCoin


If I were to suggest how to implement an options contract, I wouldn't use key pairs.  Hashes seem more suitable.  Two hashes would be published, one associated with each outcome, and I would assume that the plaintext for only one of the hashes will be revealed when the outcome is known.  So, (Ks AND H1) OR (Kr AND H2)

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 20, 2011, 07:38:04 AM
 #28

This option would allow trust-less exchange between chains, right?
No. Exchanges between chains require at least more scripting functionality enabled and some require nLockTime and replacement.

How not?
Tell me what's wrong with the following example:

chain btc:
3 btc from s to r
 (Ks AND K1) OR (Kr AND K2) - s gets control of funds if K1 is broadcast, r gets control if K2 is broadcast.

chain nmc:
100 nmc from r to s
 (Ks AND K2) OR (Kr AND K1) - r gets control of funds if K1 is broadcast, s gets control if K2 is broadcast.

s knows k1 and r knows k2

If r takes the bitcoins, s can take the namecoins
If s takes back the btc, r can take back the nmc

If s takes the nmc, r can take the btc
If r takes back the nmc, s can take back the btc

What am I missing?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 21, 2011, 06:44:00 AM
 #29

Quote
An options contract where the outcome is triggered by a key being broadcast: (Ks AND K1) OR (Kr AND K2) - s gets control of funds if K1 is broadcast, r gets control if K2 is broadcast.

This is misleading as K1 and K2 have to be signatures specific to the transaction and not just secrets which can be revealed.
Someone, please explain how the above construction facilitates the functionality mentioned.

ByteCoin


If I were to suggest how to implement an options contract, I wouldn't use key pairs.  Hashes seem more suitable.  Two hashes would be published, one associated with each outcome, and I would assume that the plaintext for only one of the hashes will be revealed when the outcome is known.  So, (Ks AND H1) OR (Kr AND H2)

I think K1 and K2 are keys and are also the plaintext of the hash you talk about. If K1 and K2 were public from the beginning, the following sentence makes no sense:

s gets control of funds if K1 is broadcast, r gets control if K2 is broadcast.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
hashcoin
Full Member
***
Offline Offline

Activity: 122


View Profile
September 30, 2011, 07:36:42 PM
 #30

what's a shame is I suspect what's going to happen is once you add multisigs, people will be able to almost-do the schemes I described, but do them in a half-ass way.  For example, with multisigs you could simulate nlocktime with a trusted timestamping third party that announced a batch of public keys and the dates their private keys would be released.
I.e. it would publish a list PK1,PK2,....,PKN and promise to release the corresponding SK1,...,SKN 1-day-at-a-time (or 1-hour or w/e).

Then, instead of nlocktime for time T, you would just require a signature from the sk corresponding to PKT.

More here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.5065

In fact I'll ask this: is there any use of multisigs that wouldn't also benefit from locktime? Note I'm talking only about locktime, NOT the ability to have replaceable TX which seems to be what people are worried has non-trivial semantics.  Again, locktime is something with semantics everyone already understands from existing banking systems: it is just a check dated a bit in the future.  There is no possibility of it introducing an error in the same sense that allowing people to post-date checks does not introduce an error...
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 30, 2011, 07:59:31 PM
 #31

I don't see the danger in lockTime.
But exchange between chains doesn't need it, right? Is the "(Ks AND K1) OR (Kr AND K2)" transaction enough? I would appreciate a simple confirmation.

I understand gavin, he prefers having less, but soon. The more general implementation (groffer's proposal) can substitute it later (v0.6 ??).

Even if it's possible without lockTime (I have to think about that more deeply), your proposal for instant transactions would be better implemented with it.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
September 30, 2011, 08:33:08 PM
 #32

I understand gavin, he prefers having less, but soon. The more general implementation (groffer's proposal) can substitute it later (v0.6 ??).

Yes, I want wallet security and backup as soon as possible, so I want transactions that support that functionality relayed and included in blocks as of the 0.5 release, if possible.

Current state:  (old news for those of you on the bitcoin-development mailing list)
I've made a PULL request for "standard"  (a and b),   (a or b),  (a and b) or c   transactions to eventually support keys split between different devices, wallet backup, and wallet-backup-with-split-keys.
  https://github.com/bitcoin/bitcoin/pull/541


Supporting lockTime or 2-of-3 escrow transactions or more generic 'standard' transaction in the future is certainly possible. Put together a solid pull request that adds support for relaying/including in blocks, with unit tests and a testing plan and, assuming there's general consensus that what you're proposing is safe and secure and is near the top of the "will make bitcoin better" priority list, it will get pulled.


How often do you get the chance to work on a potentially world-changing project?
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
October 01, 2011, 12:42:35 AM
 #33

jtimon, you're conflating signature operations with secret keys.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
October 01, 2011, 08:23:28 AM
 #34

jtimon, you're conflating signature operations with secret keys.

Please, be more specific.
Can the trade between chains be made with that operation or not?
If not, what I'm getting wrong?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
October 01, 2011, 05:04:38 PM
 #35

Public key operations in bitcoin are done by signing and verifying signatures of a hash of the transaction. That hash will be different for the two transactions (so claiming one transaction wouldn't reveal anything useful about the other). It might be possible to make them the same with an OP_CODESEPARATOR and appropriate SIGHASH value, but that's more work than it's worth because you can do the same thing by making the secret a nonce in the scriptSig, and comparing with its hash in scriptPubKey (you'd just have to exchange one-time hashes in a separate secure channel).

However both approaches still suffer from a more fundamental problem. As far as I can tell--and I spent some time working on it--there is no way to design a protocol without introducing new opcodes or enabling transaction replacement that doesn't enable one side to claim both coins if they're dishonest.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
October 01, 2011, 10:17:16 PM
 #36

Note I'm talking only about locktime, NOT the ability to have replaceable TX which seems to be what people are worried has non-trivial semantics.

Could you please outline the contracts which one would be able to construct if one just had nLockTime without transaction replacement?
In particular, there seems to be a lot of general interest in the trust-free cross-chain transactions. Is it possible to do this with the proposed multisignature scripts and the "post-dated cheque" nLockTime you propose.
I believe, the version on the wiki requires replacement.

ByteCoin
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!