From: Peter Todd <pete@petertodd•org>
To: Gregory Maxwell <gmaxwell@gmail•com>, Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP - Hash Locked Transaction
Date: Fri, 25 Apr 2014 17:14:26 -0400 [thread overview]
Message-ID: <20140425211426.GD8994@savin> (raw)
In-Reply-To: <CAAS2fgQc_UgwYgc0kVso-cL6xqP-2MGg2JoWDHYyAUXhQkyaoA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2014-04-25 21:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 18:49 Tier Nolan
2014-04-25 19:18 ` Luke-Jr
2014-04-25 19:37 ` Tier Nolan
2014-04-25 20:06 ` Alex Mizrahi
2014-04-25 20:14 ` Peter Todd
2014-04-25 20:19 ` Gregory Maxwell
2014-04-25 21:14 ` Peter Todd [this message]
2014-04-25 21:52 ` Tier Nolan
2014-04-26 11:11 ` Jorge Timón
2014-04-26 11:31 ` Tier Nolan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140425211426.GD8994@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
--cc=tier.nolan@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox