Proposal : standard transactions for security/backup/escrow

[jtimon]

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.

[1715171805]

1715171805

[1715171805]

1715171805

[1715171805]

1715171805

[etotheipi]

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

[jtimon]

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

[Gavin Andresen]

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

[jtimon]

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?

[ByteCoin]

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.

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]

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)

[jtimon]

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?

[jtimon]

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.

[hashcoin]

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]

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.

[Gavin Andresen]

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.

[maaku]

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

[jtimon]

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?

[maaku]

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.

[ByteCoin]

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