[Bitcoin-development] BIP - Hash Locked Transaction

[Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1687 bytes --]

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Luke-Jr]

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

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr <luke@dashjr.org> wrote:

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



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



> Luke
>

[-- Attachment #2: Type: text/html, Size: 1946 bytes --]

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Alex Mizrahi]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 846 bytes --]

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

On Fri, Apr 25, 2014 at 11:06:37PM +0300, Alex Mizrahi wrote:
> 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.

-- 
'peter'[:-1]@petertodd.org
0000000000000000852baa93672889c1cc0ebe0b886b153410529d6bf404b835

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Gregory Maxwell]

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?)

But I agree with him that that for the oracle case the EC public
points are superior. (Also: Reality keys works like this.)

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3280 bytes --]

On Fri, Apr 25, 2014 at 01:19:48PM -0700, Gregory Maxwell wrote:
> 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.

> 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

-- 
'peter'[:-1]@petertodd.org
0000000000000000231ff812c54986461c6f76414390f88e41476a2c2c877304

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd <pete@petertodd.org> wrote:

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

[-- Attachment #2: Type: text/html, Size: 1025 bytes --]

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Jorge Timón]

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

Re: [Bitcoin-development] BIP - Hash Locked Transaction

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On Sat, Apr 26, 2014 at 12:11 PM, Jorge Timón <jtimon@monetize.io> wrote:

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

[-- Attachment #2: Type: text/html, Size: 1036 bytes --]