Ruben de Vries [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-01-14 to 2015-02-13
💬 Posted a total of 3 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:30:30

- reply

📅 Original date posted:2015-02-13
📝 Original message:The idea is more like BIP44/45 to have a 'standard' that software can
comply by and express they do
so that it makes a step towards compatibility between (wallet) software.
On Fri, Feb 13, 2015 at 8:53 AM, Peter Todd <pete at petertodd.org> wrote:
> On Thu, Feb 12, 2015 at 10:13:33PM +0000, Luke Dashjr wrote:
> > Where is the Specification section?? Does this support arbitrary
> scripts, or
> > only the simplest CHECKMULTISIG case?
>
> 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.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000013cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1
>
--
BlockTrail B.V.
Barbara Strozzilaan 201
1083HN Amsterdam
The Netherlands
Phone: +31 (0)612227277
E-mail: ruben at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150213/a64f7cc8/attachment.html>

2023-06-07 15:28:32

- reply

📅 Original date posted:2015-01-16
📝 Original message: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 at gmail.com> wrote:
> On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock <bip at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150116/6dcebfd8/attachment.html>

2023-06-07 15:28:29

- reply

📅 Original date posted:2015-01-14
📝 Original message:For p2sh multisig TXs the order of the public keys affect the hash and
there doesn't seem to be an agreed upon way of sorting the public keys.
If there would be a standard (recommended) way of sorting the public keys
that would make it easier for services that implement some form of multisig
to be compatible with each other without much hassle and making it possible
to import keys from one service to another.
I'm not suggesting forcing the order, just setting a standard to recommend,
there doesn't seem to be much reason for (new) services to not follow that
recommendation.
Ryan from BitPay broad this up before (
https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in bitcore
they've implemented lexicographical sorting on the hex of the public key.
In a short search I can't find any other library that has a sorting
function, let alone using it by default, so bitcore is currently my only
reference.
Ruben de Vries
CTO, BlockTrail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150114/9114f30a/attachment.html>