From: Thomas Kerin <me@thomaskerin•io>
To: bitcoin-development@lists•sourceforge.net,
Gregory Maxwell <gmaxwell@gmail•com>
Subject: Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
Date: Fri, 22 May 2015 18:28:02 +0100 [thread overview]
Message-ID: <555F6722.7000103@thomaskerin.io> (raw)
In-Reply-To: <54DE8C1C.60804@thomaskerin.io>
[-- Attachment #1: Type: text/plain, Size: 3684 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I wonder are there any other blockers or modifications that need to be
made for this to be merged?
Latest version of the document:
https://github.com/afk11/bips/blob/213e8a27a3a2eaaf44f79221a9f9f888af002801/bip-0067.mediawiki
On 13/02/15 23:43, Thomas Kerin wrote:
>
> On 12/02/15 22:13, Luke Dashjr wrote:
>> Where is the Specification section?? Does this support arbitrary
scripts, or
>> only the simplest CHECKMULTISIG case?
>
> The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.
>
> You're right, we're missing a Specification. I have tweaked the
document to cover this now.
>
>
>
> On 13/02/15 07:53, Peter Todd wrote:
>> It might be enough to rewrite this BIP to basically say "all pubkeys
executed by all CHECKMULTISIG opcodes will be in the following canonical
order", followed by some explanatory examples of how to apply this
simple rule. OTOH we don't yet have a standard way of even talking about
arbitrary scripts, so it may very well turn out to be the case that the
above rule is too restrictive in many cases - I certainly would not want
to do a soft-fork to enforce this, or even make it an IsStandard() rule.
>
> It would be interesting, but I agree it should not be brought into
these validation rules - just a convention for people to follow for now.
I think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons.
>
>
> --
> Thomas Kerin
> -------------------------
> My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQJ8BAEBCgBmBQJVX2ciXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVlOwP/1w/Omr/6jGyi7spqW22HQ7P
4+lNNzcsWp5/pv8e6YelUOSYiHuh/KxRoFfWL+wF+PNS2EtjRxSsXxg/R2nMft7B
JQLNmIG6zTzVg/lhVObeSslXaia7repZxZ1S4nyEcs8rDVt7kkNnNguFOeONF95O
3usCnrch+QbQacIt9StySAz155u1SuHeSmGmA/fRGLfArndXDdN0fYwE1KGyv5wm
LqZ1PQfmYaCc0TUKRvpDRuc/+KF7q1fDMzuP9mZ3WiPdvTDKCXSRxYfbQYJdxplg
AC0CFiOne+DXgiBdTOIcs9pcp1/6SyZs75Bkpv71AxBCmTlRTuYpsfH7O3VuZBGP
FrN/4BMYnzMbGnNmvZwerUKH59MmzZTAzLSwZlpvj7ZxRks6KOp1CHInFWQlHAXJ
O5c5McvqSdQ0rPHLcQ4DwB00Q1els18NRULjxdsTfLrT32birIXn3M1Hn/Q9d8Sa
N+Y/cfXkojf4rJt75+XwjLyHECwS378ZFC8lfs1m/B3VSQxTtTZWA8905a1IRv/F
nPQ2eaxBrFjm4OatE5lx+I/xmVAQuybG54UdcZGaKVXJbMg3sOslcYg7eA77pmR5
7jRoRU+q7GhiRsUmxSkD+57FfhaMzX7iUl4xe3YK14KUS/pONuv0USC9to8a62kA
gz9kb4pJMEhTtZNv7z9C
=iq37
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/html, Size: 5468 bytes --]
prev parent reply other threads:[~2015-05-22 17:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 21:42 Thomas Kerin
2015-02-12 22:13 ` Luke Dashjr
2015-02-13 7:53 ` Peter Todd
2015-02-13 9:01 ` Ruben de Vries
2015-05-24 0:44 ` Eric Lombrozo
2015-02-13 23:43 ` Thomas Kerin
2015-05-22 17:28 ` Thomas Kerin [this message]
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=555F6722.7000103@thomaskerin.io \
--to=me@thomaskerin$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@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