Re: [Bitcoin-development] Quote on BIP 16
On Sun, Jan 29, 2012 at 12:23 AM, Alan Reiner 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). -- 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
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 > To: > "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 -- 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
On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki 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. -- 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
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. -- 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
2 compressed pubkeys - Original Message - From: Amir Taaki To: "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
[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
