From: Ruben de Vries <ruben@blocktrail.com>
To: Wladimir <laanwj@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Jeffrey Paul <jp@eeqj.com>
Subject: Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
Date: Fri, 16 Jan 2015 11:16:56 +0100 [thread overview]
Message-ID: <CABETNRsTS=eDqTL5Cj8uYxLPZhWHW=p8CCxCdP7uUAHYujs7gA@mail.gmail.com> (raw)
In-Reply-To: <CA+s+GJCsta-FesGv7zW_i2pEtZM5U20ZqP2V_Oog_LBtQBbe-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Since we only need the sorting for creating the scriptPubKey,
wouldn't it make the most sense to sort it by the way it represented in
that context?
On Thu, Jan 15, 2015 at 2:03 PM, Wladimir <laanwj@gmail.com> wrote:
> On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock <bip@mattwhitlock.name>
> wrote:
> > On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
> >> Internally, pubkeys are DER-encoded integers.
> >
> > I thought pubkeys were represented as raw integers (i.e., they're
> embedded in Script as a push operation whose payload is the raw bytes of
> the big-endian representation of the integer). As far as I know, DER
> encoding is only used for signatures. Am I mistaken?
>
> OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
> DER-encoded signature on the stack.
>
> Possibly you're confused with OP_HASH160 <hash160> OP_EQUALVERIFY as
> used in outputs, which compares the 160-bit hash of the pubkey against
> the given hash (usually taken from a bitcoin address).
>
> It doesn't help understanding to consider either as integers. They are
> binary blob objects with either a fixed format (DER) or a fixed size
> (hashes).
>
> Wladimir
>
--
BlockTrail B.V.
Barbara Strozzilaan 201
1083HN Amsterdam
The Netherlands
Phone: +31 (0)612227277
E-mail: ruben@blocktrail.com
Web: www.blocktrail.com
Github: www.github.com/rubensayshi
BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in
Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01
[-- Attachment #2: Type: text/html, Size: 3392 bytes --]
next prev parent reply other threads:[~2015-01-16 10:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 16:37 [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions Ruben de Vries
2015-01-14 17:39 ` devrandom
2015-01-14 18:00 ` Eric Lombrozo
2015-01-14 18:58 ` Jean-Pierre Rupp
2015-01-14 19:27 ` Jeffrey Paul
2015-01-14 19:58 ` Pavol Rusnak
2015-01-14 23:53 ` Eric Lombrozo
[not found] ` <CALKy-wreXNohc_Pe_DLBS1cXoS-3j8C_F7WsKuU=CYYKF9NB1Q@mail.gmail.com>
2015-01-15 1:09 ` Eric Lombrozo
2015-01-15 1:17 ` Matt Whitlock
2015-01-15 12:33 ` Jean-Pierre Rupp
[not found] ` <CA+s+GJCsta-FesGv7zW_i2pEtZM5U20ZqP2V_Oog_LBtQBbe-w@mail.gmail.com>
2015-01-16 10:16 ` Ruben de Vries [this message]
2015-01-16 16:34 ` Thomas Kerin
2015-01-16 17:09 ` Alan Reiner
2015-01-14 20:32 ` Jeff Garzik
2015-01-15 11:59 ` Jonathan Brown
2015-01-16 18:40 Jean-Pierre Rupp
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='CABETNRsTS=eDqTL5Cj8uYxLPZhWHW=p8CCxCdP7uUAHYujs7gA@mail.gmail.com' \
--to=ruben@blocktrail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=jp@eeqj.com \
--cc=laanwj@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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