Pages:
Author

Topic: Proposal : standard transactions for security/backup/escrow (Read 5423 times)

sr. member
Activity: 416
Merit: 277
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
legendary
Activity: 905
Merit: 1012
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.
legendary
Activity: 1372
Merit: 1002
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?
legendary
Activity: 905
Merit: 1012
jtimon, you're conflating signature operations with secret keys.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
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.

legendary
Activity: 1372
Merit: 1002
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.
full member
Activity: 372
Merit: 114
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...
legendary
Activity: 1372
Merit: 1002
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.
legendary
Activity: 1372
Merit: 1002
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?
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
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)
sr. member
Activity: 416
Merit: 277
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
legendary
Activity: 1372
Merit: 1002
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?
legendary
Activity: 1652
Merit: 2301
Chief Scientist
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

legendary
Activity: 1372
Merit: 1002
If nLockTime would not be secure right now, we should wait. But if it is secure, it makes multi-sig scripts more useful.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
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...


legendary
Activity: 1372
Merit: 1002
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.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
Gavin, what is the status of the new standard transactions?  Did anyone actually authoritatvely decide on how the new transactions will look in the blockchain (specifically, the OP_CODE structure of the transactions)?  Any decision on the how they will be serialized (for the purpose of handing out addresses)? 

I recognize that you are probably working on the updated client, but I wanted to know if you reached any conclusions, since this thread seems to have been left dangling a month ago...
full member
Activity: 372
Merit: 114
Note that many of the escrow use cases also need nLockTime to be useful (NOT replaceable TX/sequence numbers, just a TX that won't even be accepted into a memory pool until a given time/block).  I would strongly urge you to enable nLockTime.  Here are two use cases:

https://bitcointalksearch.org/topic/instant-tx-for-established-business-relationships-need-replacementsnlocktime-25786
https://bitcointalksearch.org/topic/trust-free-crypto-currency-exchange-with-time-conditional-scripts-22581

In one of them I mentioned using replaceable TX, not sure why, but they aren't needed.

Multi-signed TX and locktime is all that is needed for instant secure offline transactions with future-settled payment.

The "untrusted exchange" use case just needs one more thing: multiple uses of OP_HASHEQUALVERIFY.  I know you said not to beg for arbitrary additions in this thread, but I figure it's worth a shot since OP_HASHEQUALVERIFY is already used/allowed, but just once in accordance with IsStandard.  Untrusted exchange can be done if you allow 2 more HASHEQUALVERIFY in a TX... I hope you'll agree allowing a script to couple more HASHEQUALVERIFYs is not dangerous.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
Please also enable the non-address versions. Like:
2 KeyA KeyB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG

Those are "Proposal 1" -- enabling all the 'plain-old' OP_CHECKMULTISIG transactions.

groffer reports finding a bug in CHECKMULTISIG (pops too many items off the stack), which makes me wonder if it would be better to avoid it. For small n, using CHECKSIG multiple times is straightforward and doesn't make the transactions much larger.

The (a and b) OR c transaction with public keys instead of addresses isn't in the proposal, but for consistency's sake I agree it should be.
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
So part of the discussion is about the length of acceptable keys, which would help drive the format for these multi-sig addresses.     Casascius... you mentioned in another thread that you actually type some addresses in by hand.  What is the reason for this?  So far, I have never needed to do it myself, and was wondering if you have special requirements, or if we anticipate a common scenario that people would be copying by hand (i.e. typing).  If so, then perhaps it's not ideal to push the multisig approach with long addresses.  It's okay if it's done occasionally, but if there's a common scenario that most users would run into semi-frequently, we probably should focus on keeping them short.

I use paper bitcoin wallets and multiple computers, including one dedicated to transacting in BTC, and a different one for interacting with financial websites (including bitcoin exchanges) which browses no other websites, so I minimize the risk of having my bitcoins lost or stolen and my accounts compromised.  Although that seems somewhat heretical, the more people have their bitcoins stolen without seeing it coming, the more it makes sense.

I have a serious amount invested in bitcoins, am aware that skilled adversaries are after them, and don't want to risk it.  All my bitcoins are offline pretty much all the time.

When I take bitcoins offline, I break them into denominations so if I just need to buy something small, I can import a "twenty" or whatever, and leave the remainder of my stash safe.
Pages:
Jump to: