Re: [Bitcoin-development] BIP - Hash Locked Transaction
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 -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
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. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
On Fri, Apr 25, 2014 at 8:18 PM, Luke-Jr l...@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 -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
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 -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
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 852baa93672889c1cc0ebe0b886b153410529d6bf404b835 signature.asc Description: Digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd p...@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.) -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
On Fri, Apr 25, 2014 at 01:19:48PM -0700, Gregory Maxwell wrote: On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd p...@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 231ff812c54986461c6f76414390f88e41476a2c2c877304 signature.asc Description: Digital signature -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
On Fri, Apr 25, 2014 at 10:14 PM, Peter Todd p...@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. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
