[Bitcoin-development] Quote on BIP 16

[Bitcoin-development] Quote on BIP 16

[Amir Taaki]

Gavin said:
"Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this:  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)

I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable."

How could you have a 70 byte long address without a P2SH scheme? Is this a mistake?

Re: [Bitcoin-development] Quote on BIP 16

[Amir Taaki]

2 compressed pubkeys


----- Original Message -----
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Cc: 
Sent: Sunday, January 29, 2012 4:52 AM
Subject: [Bitcoin-development] Quote on BIP 16

Gavin said:
"Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this:  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
(or possibly even longer)

I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable."

How could you have a 70 byte long address without a P2SH scheme? Is this a mistake?

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Quote on BIP 16

[Luke-Jr]

On Sunday, January 29, 2012 12:10:41 AM Amir Taaki wrote:
> 2 compressed pubkeys

2 compressed pubkeys are 33 bytes each. Add 1 bytes for the N (n-of-m), 1 byte 
for the address version, and finally the 4 byte checksum, you get a total of 
72 bytes. But these are *bytes* - to get an address, you also need to base58 
encode it: this yields a 99 character address.

Re: [Bitcoin-development] Quote on BIP 16

[Gregory Maxwell]

On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> How could you have a 70 byte long address without a P2SH scheme? Is this a mistake?

...  No it's not a mistake.  P2SH _prevents_ needing long addresses.

Lets unpack the acronym "pay to script _hash_".  Hashes only need to
be 128-256 bits in size or so to have acceptable security, so you
don't need something longer than that for paying to a hash.

Note that gavin is saying 70 characters, not bytes.

Without some form of P2SH then only way for you to make a personal
choice of asking people to pay to a two-factor protected account or
two a multiparty trust that manages the finances of an organization
is using some form of "P2S", pay-to-script.

In other words, you'd have to have an address that encodes a full
script specification for the sender to pay to,  instead of just
encoding its hash.  As a result these addresses would be much longer
(and potentially very long).

The minimum size of a two address involving encoded script would be on
that order, but they get bigger quite quickly if you add more options
to the script (actually 70 sounds quite small, it should be more like
100 for a minimum two pubkey script).

In addition to the unworkability of very long addresses as described
by gavin (amusingly I am unable to copy and paste the quoted example
in one go) a P2S solution has several problems which you might
consider more or less important:


(1) They are highly vulnerable to invisible substitution.  E.g. I can
trivially take a P2S address, change one or two characters and get a
script which is redeemable by anyone.  With P2SH you have to do
computation which is exponential in the number of unchanged digits to
get a look alike address.

(2) The sender is fully responsible for fees related to the enlarged
transactions. Even if _you're_ willing to take the txn-processing time
and fee burden of a 30 person joint trust address,  random e-commerce
sites will not be and will randomly reject your addresses.

(3) They create another input vector for non-trivial data which must
be inspected and validated, potentially presenting an attack surface.

(4) They leave the complicated (long) release rules in the transaction
outputs.  When a transaction is mined we can't be sure if it will ever
be redeemed. The outputs are unprunable.   In a future world where
many nodes prune output space is far more important than input space
and it would make sense to require more fees for it because we're
never sure how long it would need to be stored (making it an
attractive target for someone who wants to make Bitcoin unusable by
spamming it with worthless data).  P2SH reduces output sizes to the
absolute minimum without inflating the total data size.

Re: [Bitcoin-development] Quote on BIP 16

[Alan Reiner]

It certainly wouldn't hurt if there was a way to use OP_MULTICHECKSIG 
with hash160 values instead... I doubt that's workable, though.

At the moment, I feel that the copy&paste size problem is much smaller 
than the risk we take implementing such a huge change to the network.  I 
almost feel like, we should have multi-sig in place, thoroughly tested 
and available, as something to fall back on if something goes wrong with 
BIP 13/16/17 after implementation.  After all, I've been promoting the 
idea of considering the "cost" to fixing an erroneous/insecure 
implementation, as consideration for the proposals at hand.

But gmaxwell has expressed some compelling reasons why plain multi-sig 
might be abused, which maybe suggests we don't want it ever considered 
standard...?  I guess I'm not really promoting one thing or another, but 
I feel like copy&pasting is not a big deal (after all, it exists to 
moving large amounts of data around).  Then of course, I use 
home-shift-end all the time, and regular users may not be so adept at 
copying long strings.

-Alan



On 01/29/2012 12:10 AM, Amir Taaki wrote:
> 2 compressed pubkeys
>
>
> ----- Original Message -----
> From: Amir Taaki<zgenjix@yahoo.com>
> To: "bitcoin-development@lists.sourceforge.net"<bitcoin-development@lists.sourceforge.net>
> Cc:
> Sent: Sunday, January 29, 2012 4:52 AM
> Subject: [Bitcoin-development] Quote on BIP 16
>
> Gavin said:
> "Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this:  57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr
> (or possibly even longer)
>
> I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable."
>
> How could you have a 70 byte long address without a P2SH scheme? Is this a mistake?
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Quote on BIP 16

[Gregory Maxwell]

On Sun, Jan 29, 2012 at 12:23 AM, Alan Reiner <etotheipi@gmail.com> wrote:
[snip]
> But gmaxwell has expressed some compelling reasons why plain multi-sig
> might be abused, which maybe suggests we don't want it ever considered
> standard...?  I guess I'm not really promoting one thing or another, but

Be careful not to conflate multisig _addresses_  and P2S with multisig
output scripts in general.

Of the issues I raised only the size of the potentially unprunable
transaction outputs is an argument against multisig outputs which
aren't getting packed up in addresses.

Things like negotiated escrow arrangements can work okay either way.

I think P2SH is still better for these for two reasons: Reasonable
anti-spam behavior by network participant may make it hard to make
large output scripts (see above), but this isn't an issue yet...  and
P2S(H) lets you use a separate escrow-maker tool for clients paying
into escrow without any knowledge or support of escrow transactions in
that client. This uncoupling is important both for general "feature
velocity" as well as providing a uniform feature set across bitcoin
services (e.g. you negotiate paying someone via escrow, you use a tool
to make a mutually agreed escrow configuration, but your funds are in
MTGOX— no issue if P2SH is widely used).

[Bitcoin-development] Fw: Quote on BIP 16

[Amir Taaki]

(oops sorry greg- replied to you by mistake)

That address he gives is 77 characters/bytes (same thing). What I'm asking is how can it be so small. I know that it's encoding a script, but then I started trying to imagine what kind of script and to me it seems that 2 public keys are too large for those 77 characters when encoded.

That is the example quoted on the forums:
57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr


Could it be a mistake?


----- Original Message -----
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Cc: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net>
Sent: Sunday, January 29, 2012 5:19 AM
Subject: Re: [Bitcoin-development] Quote on BIP 16

On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> How could you have a 70 byte long address without a P2SH scheme? Is this a mistake?

...  No it's not a mistake.  P2SH _prevents_ needing long addresses.

Lets unpack the acronym "pay to script _hash_".  Hashes only need to
be 128-256 bits in size or so to have acceptable security, so you
don't need something longer than that for paying to a hash.

Note that gavin is saying 70 characters, not bytes.

Without some form of P2SH then only way for you to make a personal
choice of asking people to pay to a two-factor protected account or
two a multiparty trust that manages the finances of an organization
is using some form of "P2S", pay-to-script.

In other words, you'd have to have an address that encodes a full
script specification for the sender to pay to,  instead of just
encoding its hash.  As a result these addresses would be much longer
(and potentially very long).

The minimum size of a two address involving encoded script would be on
that order, but they get bigger quite quickly if you add more options
to the script (actually 70 sounds quite small, it should be more like
100 for a minimum two pubkey script).

In addition to the unworkability of very long addresses as described
by gavin (amusingly I am unable to copy and paste the quoted example
in one go) a P2S solution has several problems which you might
consider more or less important:


(1) They are highly vulnerable to invisible substitution.  E.g. I can
trivially take a P2S address, change one or two characters and get a
script which is redeemable by anyone.  With P2SH you have to do
computation which is exponential in the number of unchanged digits to
get a look alike address.

(2) The sender is fully responsible for fees related to the enlarged
transactions. Even if _you're_ willing to take the txn-processing time
and fee burden of a 30 person joint trust address,  random e-commerce
sites will not be and will randomly reject your addresses.

(3) They create another input vector for non-trivial data which must
be inspected and validated, potentially presenting an attack surface.

(4) They leave the complicated (long) release rules in the transaction
outputs.  When a transaction is mined we can't be sure if it will ever
be redeemed. The outputs are unprunable.   In a future world where
many nodes prune output space is far more important than input space
and it would make sense to require more fees for it because we're
never sure how long it would need to be stored (making it an
attractive target for someone who wants to make Bitcoin unusable by
spamming it with worthless data).  P2SH reduces output sizes to the
absolute minimum without inflating the total data size.

Re: [Bitcoin-development] Fw: Quote on BIP 16

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Sun, Jan 29, 2012 at 6:19 AM, Amir Taaki <zgenjix@yahoo.com> wrote:

> (oops sorry greg- replied to you by mistake)
>
> That address he gives is 77 characters/bytes (same thing). What I'm asking
> is how can it be so small.


That's an alternative design for multisig addresses that would put a byte
giving the type of transaction and the 20-byte hashes of each of the public
keys involved. They would not have been redeemed using CHECKMULTISIG, but
would use DUP HASH160 CHECKSIG and the arithmetic or logical opcodes to
create the "m of n" condition.

Nobody really liked that solution because it means a new 'type' of bitcoin
address every time we want a new transaction type and long addresses.

Its only advantage is it didn't use CHECKMULTISIG, so there were no
problems with maximum-sigops-per-block.

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1188 bytes --]

Re: [Bitcoin-development] Fw: Quote on BIP 16

[Luke-Jr]

On Sunday, January 29, 2012 9:30:10 AM Gavin Andresen wrote:
> On Sun, Jan 29, 2012 at 6:19 AM, Amir Taaki <zgenjix@yahoo.com> wrote:
> > (oops sorry greg- replied to you by mistake)
> > 
> > That address he gives is 77 characters/bytes (same thing). What I'm
> > asking is how can it be so small.
> 
> That's an alternative design for multisig addresses that would put a byte
> giving the type of transaction and the 20-byte hashes of each of the public
> keys involved. They would not have been redeemed using CHECKMULTISIG, but
> would use DUP HASH160 CHECKSIG and the arithmetic or logical opcodes to
> create the "m of n" condition.
> 
> Nobody really liked that solution because it means a new 'type' of bitcoin
> address every time we want a new transaction type and long addresses.
> 
> Its only advantage is it didn't use CHECKMULTISIG, so there were no
> problems with maximum-sigops-per-block.

In other words, if the max-sigops-per-block were ever approaching a real 
problem, we could just start using these kind of transactions instead hidden 
behind the P2SH... so the one remotely-tangible benefit of BIP 16 over 17 has 
been solved, right? ;)