* [Bitcoin-development] Quote on BIP 16 @ 2012-01-29 4:52 Amir Taaki 2012-01-29 5:10 ` Amir Taaki 2012-01-29 5:19 ` Gregory Maxwell 0 siblings, 2 replies; 9+ messages in thread From: Amir Taaki @ 2012-01-29 4:52 UTC (permalink / raw) To: bitcoin-development 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Quote on BIP 16 2012-01-29 4:52 [Bitcoin-development] Quote on BIP 16 Amir Taaki @ 2012-01-29 5:10 ` Amir Taaki 2012-01-29 5:15 ` Luke-Jr 2012-01-29 5:23 ` Alan Reiner 2012-01-29 5:19 ` Gregory Maxwell 1 sibling, 2 replies; 9+ messages in thread From: Amir Taaki @ 2012-01-29 5:10 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Quote on BIP 16 2012-01-29 5:10 ` Amir Taaki @ 2012-01-29 5:15 ` Luke-Jr 2012-01-29 5:23 ` Alan Reiner 1 sibling, 0 replies; 9+ messages in thread From: Luke-Jr @ 2012-01-29 5:15 UTC (permalink / raw) To: bitcoin-development, Amir Taaki 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Quote on BIP 16 2012-01-29 5:10 ` Amir Taaki 2012-01-29 5:15 ` Luke-Jr @ 2012-01-29 5:23 ` Alan Reiner 2012-01-29 8:14 ` Gregory Maxwell 1 sibling, 1 reply; 9+ messages in thread From: Alan Reiner @ 2012-01-29 5:23 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Quote on BIP 16 2012-01-29 5:23 ` Alan Reiner @ 2012-01-29 8:14 ` Gregory Maxwell 0 siblings, 0 replies; 9+ messages in thread From: Gregory Maxwell @ 2012-01-29 8:14 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development 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). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Quote on BIP 16 2012-01-29 4:52 [Bitcoin-development] Quote on BIP 16 Amir Taaki 2012-01-29 5:10 ` Amir Taaki @ 2012-01-29 5:19 ` Gregory Maxwell [not found] ` <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com> 1 sibling, 1 reply; 9+ messages in thread From: Gregory Maxwell @ 2012-01-29 5:19 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com>]
* [Bitcoin-development] Fw: Quote on BIP 16 [not found] ` <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com> @ 2012-01-29 11:19 ` Amir Taaki 2012-01-29 14:30 ` Gavin Andresen 0 siblings, 1 reply; 9+ messages in thread From: Amir Taaki @ 2012-01-29 11:19 UTC (permalink / raw) To: bitcoin-development (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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Fw: Quote on BIP 16 2012-01-29 11:19 ` [Bitcoin-development] Fw: " Amir Taaki @ 2012-01-29 14:30 ` Gavin Andresen 2012-01-29 14:40 ` Luke-Jr 0 siblings, 1 reply; 9+ messages in thread From: Gavin Andresen @ 2012-01-29 14:30 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Fw: Quote on BIP 16 2012-01-29 14:30 ` Gavin Andresen @ 2012-01-29 14:40 ` Luke-Jr 0 siblings, 0 replies; 9+ messages in thread From: Luke-Jr @ 2012-01-29 14:40 UTC (permalink / raw) To: bitcoin-development 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? ;) ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-01-29 14:40 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-29 4:52 [Bitcoin-development] Quote on BIP 16 Amir Taaki
2012-01-29 5:10 ` Amir Taaki
2012-01-29 5:15 ` Luke-Jr
2012-01-29 5:23 ` Alan Reiner
2012-01-29 8:14 ` Gregory Maxwell
2012-01-29 5:19 ` Gregory Maxwell
[not found] ` <1327835941.47827.YahooMailNeo@web121006.mail.ne1.yahoo.com>
2012-01-29 11:19 ` [Bitcoin-development] Fw: " Amir Taaki
2012-01-29 14:30 ` Gavin Andresen
2012-01-29 14:40 ` Luke-Jr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox