BIP - Hash Locked Transaction
10 messages, 25 to 26 Apr 2014. Started by Tier Nolan.
Tier Nolan (4), Peter Todd (2), Luke Dashjr, Alex Mizrahi, Greg Maxwell, Jorge Timón
As part of the atomic cross chain system, outputs need to be hash locked.
https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
A user needs to provide x corresponding to hash(x) in order to spend an output.
Under the protocol, one of the participants is required to provide the secret number in order to spend an output. Once they do that, the other participant can use the secret number to spend an output on the other chain. This provides a mechanism to link the 2 chains together (in addition to lock times). Once the first output is spent, that commits the transfer.
This is half of the scripting operations required to implement the protocol.
The proposal is to make this an adder on to the other standard transactions. It does a check that the hash matches, and then runs the standard transaction as normal.
Adding the prefix to a P2SH transactions wouldn't work, since the template wouldn't match.
A script of this form could be embedded into a P2SH output.
I think that is ok, since embedding the "password" in the hashed script gets all the benefits.
If there is agreement, I can code up the reference implementation as a PR.
This one looks entirely useless (it cannot be made secure), and the assertion that it is necessary for atomic cross-chain transfers seems unfounded and probably wrong...
Luke
On Friday, April 25, 2014 6:49:37 PM Tier Nolan wrote:
Quoted text (32 lines)
> As part of the atomic cross chain system, outputs need to be hash locked. > > https://github.com/TierNolan/bips/blob/bip4x/bip-0045.mediawiki > > https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 > > A user needs to provide x corresponding to hash(x) in order to spend an > output. > > Under the protocol, one of the participants is required to provide the > secret number in order to spend an output. Once they do that, the other > participant can use the secret number to spend an output on the other > chain. This provides a mechanism to link the 2 chains together (in > addition to lock times). Once the first output is spent, that commits the > transfer. > > This is half of the scripting operations required to implement the > protocol. > > The proposal is to make this an adder on to the other standard > transactions. It does a check that the hash matches, and then runs the > standard transaction as normal. > > Adding the prefix to a P2SH transactions wouldn't work, since the template > wouldn't match. > > A script of this form could be embedded into a P2SH output. > > I think that is ok, since embedding the "password" in the hashed script > gets all the benefits. > > If there is agreement, I can code up the reference implementation as a PR.
On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (1 line)
> This one looks entirely useless (it cannot be made secure)
The hash locking isn't to prevent someone else stealing your coin. Once a user broadcasts a transaction with x in it, then everyone has access to x.
It is to release the coin on the other chain. If you spend the output, you automatically give the other participant the password to take your coin on the other chain (completing the trade).
The BIP allows the hash to protect any of other standard transactions (except P2SH, since that is a template match).
For example, it would allow a script of the form
OP_HASH160 [20-byte-password-hash] OP_EQUAL_VERIFY OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
To spend it, you would need to provide the password and also sign the transaction using the private key.
Quoted text (5 lines)
> and the assertion > that it is necessary for atomic cross-chain transfers seems unfounded and > probably wrong... > >
I meant that it is required for the particular protocol.
Quoted text (2 lines)
> Luke >
It is also useful for betting: an oracle will associate a hash with each possible outcome, and when outcome is know, it will reveal a corresponding preimage which will unlock the transaction.
This approach has several advantages over approach with multi-sig script: 1. oracle doesn't need to be involved in each specific transaction 2. resolution is same for everyone who makes a bet on a specific event outcome 3. no need for two-way communication 4. no need for a special protocol: oracle might publish unlocking preimage on a web page, and participants will manually enter it into their clients
On Fri, Apr 25, 2014 at 11:06:37PM +0300, Alex Mizrahi wrote:
Quoted text (11 lines)
> It is also useful for betting: an oracle will associate a hash with each > possible outcome, and when outcome is know, it will reveal a corresponding > preimage which will unlock the transaction. > > This approach has several advantages over approach with multi-sig script: > 1. oracle doesn't need to be involved in each specific transaction > 2. resolution is same for everyone who makes a bet on a specific event > outcome > 3. no need for two-way communication > 4. no need for a special protocol: oracle might publish unlocking preimage > on a web page, and participants will manually enter it into their clients
Actually I did some work looking at this problem a few months ago and other than somewhat larger transactions it looks like implementing oracles by having the oracle reveal ECC secret keys works better in every case. Notably the oracle can prove they really do have the key by signing a challenge message, and with some ECC math the transaction can include keys that have been derived from the oracle keys, blinding what purposes the oracle is being used for from the oracle itself.
On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (7 lines)
> Actually I did some work looking at this problem a few months ago and > other than somewhat larger transactions it looks like implementing > oracles by having the oracle reveal ECC secret keys works better in > every case. Notably the oracle can prove they really do have the key by > signing a challenge message, and with some ECC math the transaction can > include keys that have been derived from the oracle keys, blinding what > purposes the oracle is being used for from the oracle itself.
I think the hash-locked transactions are very useful, and I think Peter agrees (no?)
But I agree with him that that for the oracle case the EC public points are superior. (Also: Reality keys works like this.)
On Fri, Apr 25, 2014 at 01:19:48PM -0700, Gregory Maxwell wrote:
Quoted text (11 lines)
> On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd <pete@petertodd•org> wrote: > > Actually I did some work looking at this problem a few months ago and > > other than somewhat larger transactions it looks like implementing > > oracles by having the oracle reveal ECC secret keys works better in > > every case. Notably the oracle can prove they really do have the key by > > signing a challenge message, and with some ECC math the transaction can > > include keys that have been derived from the oracle keys, blinding what > > purposes the oracle is being used for from the oracle itself. > > I think the hash-locked transactions are very useful, and I think > Peter agrees (no?)
Yup. Revealing EC points is *not* a replacement for the hash-locked case.
Quoted text (2 lines)
> But I agree with him that that for the oracle case the EC public > points are superior. (Also: Reality keys works like this.)
Same again, and on top of that the EC public point method still works better in many circumstances with what are currently non-standard transactions rather than trying to shoe-horn everything into one big CHECKMULTISIG.
Along those lines, rather than doing up yet another format specific type as Tier Nolan is doing with his BIP, why not write a BIP looking at how the IsStandard() rules could be removed? Last year John Dillon proposed it be replaced by a P2SH opcode whitelist(1) and I proposed some extensions(2) to the idea to make sure the whitelist didn't pose transaction mutability issues; very similar to Pieter Wuille's proposed soft-fork to stamp-out mutability.(3)
The key reasons to have IsStandard() right now are the following:
1) Mitigate transaction mutability.
Pieter's soft-fork mitigates mutability well, and can be applied even more easily as an IsStandard() rule.
2) Reduce the potential for scripting bugs to impact the ecosystem.
The scripting system has had a lot more testing since IsStandard() was implemented. Additionally we have a large pool mining non-standard transactions anyway, mostly negating the value of IsStandard() for this purpose.
3) Ensure that after a soft-fork upgrade transactions considered IsStandard() by the the remaining non-upgraded hashing power continue to be valid.
We don't want that hashing power to be able to be tricked into mining invalid blocks. Future soft-forks for transactions will most likely be done by either incrementing the transaction version number, or by redefining one of the OP_NOPx opcodes with new functionality. We just need to ignore transactions with version numbers that we are not familiar with and additionally not include any of the OP_NOPx opcodes in the whitelist.
One last detail is that sigops should be taken into account when calculating fees; Luke-Jr's accept non-standard patch has code to do this already.
1) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02606.html 2) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02611.html 3) https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd <pete@petertodd•org> wrote:
Quoted text (3 lines)
> Along those lines, rather than doing up yet another format specific type > as Tier Nolan is doing with his BIP, why not write a BIP looking at how > the IsStandard() rules could be removed?
Removal of isStandard() would be even better/more flexible.
A whitelist of low risk opcodes seems like a reasonable compromise.
My thoughts behind these two BIPs are that they are a smaller change that adds functionality required for a particular use-case (and some others).
Changing the entire philosophy behind isStandard() is a much bigger change than just adding one new type.
Does it make sense to implement a generic Policy interface (abstract class) which StandardPolicy extends?
Maybe you can then implement a WhitelistPolicy, ReplacebyFeeStandardPolicy, ReplacebyFeeWhitelistPolicy...
This would make it simpler for miners to implement their own policies in general. The following functions (maybe more) could become methods of Policy:
script IsStandard main IsStandardTx main AcceptToMemoryPool
On Sat, Apr 26, 2014 at 12:11 PM, Jorge Timón <jtimon@monetize•io> wrote:
Quoted text (4 lines)
> script IsStandard > main IsStandardTx > main AcceptToMemoryPool >
Accept to memory pool could probably be replaced with an IsStandard(scriptPubKey, scriptSig) method. The only "isStandard" part of the process is the check inputs method (and AcceptToMemoryPool calls IsStandardTx).
The standard script methods at the moment are also used for extracting addresses for wallet management.
The standard script check could be made easier if it just checked for pattern matches.
Is there any objections to this change, other than it doesn't go far enough?