* [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension @ 2014-06-14 12:00 Lawrence Nahum 2014-06-14 12:57 ` Andreas Schildbach 2014-06-16 12:19 ` Mike Hearn 0 siblings, 2 replies; 47+ messages in thread From: Lawrence Nahum @ 2014-06-14 12:00 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1138 bytes --] Hello, I had the pleasure to meet some of you in Amsterdam and/or to speak on #bitcoin-dev but this is actually my first message to the mailing list - I feel a bit clumsy so apologies in advance if I make any mistake :) Quick introduction/background: my name is Lawrence Nahum and I'm the founder of GreenAddress, a BIP32 multisignature service and instant confirmation platform available in form of web socket APIs and Wallet for mobile, desktop and web. My background is in CS with distributed systems and I've worked most of my career in the City on OTC financial services like confirmation and clearing platforms. This post is to gather feedback, comments and reviews about a BIP70 payment protocol proto buffer extension proposal. https://github.com/greenaddress/bips/blob/bip-payment-request-instant-confirmations/bip-payment-request-instant-confirmations.mediawiki If you are interested in GreenAddress design or for more information on GreenAddress you can find the white paper here http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf and our homepage on https://greenaddress.it Cheers, Lawrence [-- Attachment #2: Type: text/html, Size: 1626 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-14 12:00 [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Lawrence Nahum @ 2014-06-14 12:57 ` Andreas Schildbach 2014-06-15 9:22 ` Lawrence Nahum 2014-06-16 12:19 ` Mike Hearn 1 sibling, 1 reply; 47+ messages in thread From: Andreas Schildbach @ 2014-06-14 12:57 UTC (permalink / raw) To: bitcoin-development Just a quick comment: The supports_instant field seems redundant to me. First, as per your spec, you can derive it from trusted_instant_providers. And second, why do you need it at all? Protobuf is designed so it will simply ignore fields you don't know. So you can just send the instant_* fields in the Payment message without harm. On 06/14/2014 02:00 PM, Lawrence Nahum wrote: > Hello, > > I had the pleasure to meet some of you in Amsterdam and/or to speak on > #bitcoin-dev but this is actually my first message to the mailing list - > I feel a bit clumsy so apologies in advance if I make any mistake :) > > Quick introduction/background: my name is Lawrence Nahum and I'm the > founder of GreenAddress, a BIP32 multisignature service and instant > confirmation platform available in form of web socket APIs and Wallet > for mobile, desktop and web. My background is in CS with distributed > systems and I've worked most of my career in the City on OTC financial > services like confirmation and clearing platforms. > > This post is to gather feedback, comments and reviews about a BIP70 > payment protocol proto buffer extension proposal. > > https://github.com/greenaddress/bips/blob/bip-payment-request-instant-confirmations/bip-payment-request-instant-confirmations.mediawiki > > If you are interested in GreenAddress design or for more information on > GreenAddress you can find the white paper > here http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf > and our homepage on https://greenaddress.it > > Cheers, > Lawrence > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-14 12:57 ` Andreas Schildbach @ 2014-06-15 9:22 ` Lawrence Nahum 2014-06-15 12:46 ` Andreas Schildbach 0 siblings, 1 reply; 47+ messages in thread From: Lawrence Nahum @ 2014-06-15 9:22 UTC (permalink / raw) To: bitcoin-development Andreas Schildbach <andreas <at> schildbach.de> writes: > Just a quick comment: > > The supports_instant field seems redundant to me. First, as per your > spec, you can derive it from trusted_instant_providers. And second, why > do you need it at all? Protobuf is designed so it will simply ignore > fields you don't know. So you can just send the instant_* fields in the > Payment message without harm. Agreed, supports_instant is redundant and can/should/will go. trusted_instant_providers on the other hand I think is needed. Sometimes the providers will charge fees for instant. While the software can ignore the fields, users may not want to pay for instant when the merchant may not accept it or care (even if it would not break the protocol it would still be a waste of fees) Does it make sense? Not all transactions from GreenAddress provide double spend protection, there are additional checks on prevout that are normally not done when spending normally, etc ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-15 9:22 ` Lawrence Nahum @ 2014-06-15 12:46 ` Andreas Schildbach 2014-06-15 14:09 ` Lawrence Nahum 2014-06-18 12:09 ` Lawrence Nahum 0 siblings, 2 replies; 47+ messages in thread From: Andreas Schildbach @ 2014-06-15 12:46 UTC (permalink / raw) To: bitcoin-development Yes I meant only the "supports_instant" is not needed. "trusted_instant_providers" makes sense to me. Generally I like the simplicity of this BIP. Still, I have more questions: What is the use of the Transactions message? Note the Payment message already contains a transactions field that could be signed. Can you briefly describe the whole flow of messages on an example, including the BIP70 messages? Should we allow adding multiple signatures (from different instant providers or maybe while transitioning to another PKI)? On 06/15/2014 11:22 AM, Lawrence Nahum wrote: > Andreas Schildbach <andreas <at> schildbach.de> writes: > >> Just a quick comment: >> >> The supports_instant field seems redundant to me. First, as per your >> spec, you can derive it from trusted_instant_providers. And second, why >> do you need it at all? Protobuf is designed so it will simply ignore >> fields you don't know. So you can just send the instant_* fields in the >> Payment message without harm. > > > > Agreed, supports_instant is redundant and can/should/will go. > > trusted_instant_providers on the other hand I think is needed. > > Sometimes the providers will charge fees for instant. > > While the software can ignore the fields, > users may not want to pay for instant when the merchant may not accept it or > care (even if it would not break the protocol it would still be a waste of > fees) > > Does it make sense? > > Not all transactions from GreenAddress provide double spend protection, there > are additional checks on prevout that are normally not done when spending > normally, etc > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-15 12:46 ` Andreas Schildbach @ 2014-06-15 14:09 ` Lawrence Nahum 2014-06-18 12:09 ` Lawrence Nahum 1 sibling, 0 replies; 47+ messages in thread From: Lawrence Nahum @ 2014-06-15 14:09 UTC (permalink / raw) To: bitcoin-development Andreas Schildbach <andreas <at> schildbach.de> writes: > Generally I like the simplicity of this BIP. Still, I have more questions: > > What is the use of the Transactions message? Note the Payment message > already contains a transactions field that could be signed. Transactions message sole purpose is to allow easy signing of all transactions i don't think you can serialise a single field maybe i missed something, not sure > Can you > briefly describe the whole flow of messages on an example, including the > BIP70 messages? I'll get back to the list with something tomorrow, can be useful in the BIP as an example anyway I guess. > Should we allow adding multiple signatures (from different instant > providers maybe in some different scheme of "instantness" that could be useful, although i wonder if it's possible to keep the BIP simple with such non immediately obvious use cases. > or maybe while transitioning to another PKI)? another PKI, not sure, I understand there are already somewhat weak industry schemes to revoke. I do wonder if there's any better and more "future proof" way. I'll think about it but for now I hope someone with more experience can share some insight. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-15 12:46 ` Andreas Schildbach 2014-06-15 14:09 ` Lawrence Nahum @ 2014-06-18 12:09 ` Lawrence Nahum 2014-06-18 13:25 ` Mike Hearn 2014-06-25 14:01 ` sebastien requiem 1 sibling, 2 replies; 47+ messages in thread From: Lawrence Nahum @ 2014-06-18 12:09 UTC (permalink / raw) To: bitcoin-development Andreas Schildbach <andreas <at> schildbach.de> writes: > > What is the use of the Transactions message? Note the Payment message > already contains a transactions field that could be signed. Can you > briefly describe the whole flow of messages on an example, including the > BIP70 messages? Updated the BIP draft with an example and a few corrections (like the redundant parameter). You can see the diff here https://github.com/greenaddress/bips/commit/636d5819c1be9cc099dca0a47a3148332 522a3d4 Allow me to recap BIP changes in discussion: - making some changes to allow merchants to offer discounts in case of instant ? - allowing multiple signatures ? Did I miss anything? Thoughts on the above from others? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-18 12:09 ` Lawrence Nahum @ 2014-06-18 13:25 ` Mike Hearn 2014-06-18 15:59 ` Daniel Rice 2014-06-25 14:01 ` sebastien requiem 1 sibling, 1 reply; 47+ messages in thread From: Mike Hearn @ 2014-06-18 13:25 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 482 bytes --] > > - allowing multiple signatures ? I'm not sure this is actually important or useful; trusting someone not to double spend is a pretty binary thing. I'm not sure saying "you need to get three independent parties to sign off on this" is worth the hassle, especially because the first signature is obvious (your risk analysis provider or hardware) but the second and third are ..... who? Special purpose services you have to sign up for? Seems like a hassle. But it's up to you. [-- Attachment #2: Type: text/html, Size: 750 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-18 13:25 ` Mike Hearn @ 2014-06-18 15:59 ` Daniel Rice 2014-06-18 16:09 ` Mike Hearn 0 siblings, 1 reply; 47+ messages in thread From: Daniel Rice @ 2014-06-18 15:59 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 2792 bytes --] > I'm not sure this is actually important or useful; trusting someone not to double spend is a pretty binary thing I think that's true if you assume that the instant provider list is based on a by hand created list of accepted instant providers. That's how VISA works now and that's why I was asking for an approach where the trusted_instant_providers list is scalable because that seems very dangerous. Since you can detect when a double spend happens, the entire instant provider list could be automatically generated based on a 3rd party network that shares information between vendors and also monitors double spends. In that scenario, there is no hand written exclusive list of accepted instant providers. There is just a database of past history on all instant providers. That database can be used to give a confidence score for a specific instant provider for a given transaction amount. In this scenario, a new wallet company would be able to earn trust over time. If the list is made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for instant transactions", then new wallet providers have to go around bribing Bitpay and the other large merchant transaction providers to get on their instant provider list. Allowing more than one instant signature on a transaction is supposed to help avoid that scenario. For example, lets say I want to establish my own instant signature. I use a wallet that already has an accepted instant signature, but it also allows me to add my own instant signature. I do this so that I can start establishing trust in my own instant signature while relying on their instant signature. On Wed, Jun 18, 2014 at 6:25 AM, Mike Hearn <mike@plan99•net> wrote: > - allowing multiple signatures ? > > > I'm not sure this is actually important or useful; trusting someone not to > double spend is a pretty binary thing. I'm not sure saying "you need to get > three independent parties to sign off on this" is worth the hassle, > especially because the first signature is obvious (your risk analysis > provider or hardware) but the second and third are ..... who? Special > purpose services you have to sign up for? Seems like a hassle. > > But it's up to you. > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 4026 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-18 15:59 ` Daniel Rice @ 2014-06-18 16:09 ` Mike Hearn 2014-06-19 17:36 ` Daniel Rice 0 siblings, 1 reply; 47+ messages in thread From: Mike Hearn @ 2014-06-18 16:09 UTC (permalink / raw) To: Daniel Rice; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 929 bytes --] > > I think that's true if you assume that the instant provider list is based > on a by hand created list of accepted instant providers. That's how VISA > works now and that's why I was asking for an approach where the > trusted_instant_providers list is scalable because that seems very > dangerous. > Supporting it in the protocol is easy. Building such a thing: that's hard. Decentralised automated reputation systems are complex and subtle. I don't feel strongly about whether the field should be "optional" or "repeated", 100% of implementations in the forseeable future would just look at the first item and ignore the rest. But if later someone did crack this problem it would lead to a simple upgrade path. So perhaps you're right and the protobuf should allow multiple signatures. It means a new sub-message to wrap the pki_type, pki_data and signature fields into one, and then making that repeated. Up to Lawrence. [-- Attachment #2: Type: text/html, Size: 1306 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-18 16:09 ` Mike Hearn @ 2014-06-19 17:36 ` Daniel Rice 0 siblings, 0 replies; 47+ messages in thread From: Daniel Rice @ 2014-06-19 17:36 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 1794 bytes --] > Supporting it in the protocol is easy. Building such a thing: that's hard. Decentralised automated reputation systems are complex and subtle. Bitcoin is valuable as a protocol because it is truly decentralized. The complexity involved in building this system was expansive, but I think we can all agree it was worth the trouble. With this particular topic of instant transactions it seems we have to be very careful about pushing Bitcoin in a centralized direction for the sake of a simple quick solution. Building an automated system to solve the instant transaction problem will be difficult, but also well worth the effort, and exactly like you're saying Mike, I just want to make sure the door is left open protocol wise for a robust solution in the future. On Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn <mike@plan99•net> wrote: > I think that's true if you assume that the instant provider list is based >> on a by hand created list of accepted instant providers. That's how VISA >> works now and that's why I was asking for an approach where the >> trusted_instant_providers list is scalable because that seems very >> dangerous. >> > > Supporting it in the protocol is easy. Building such a thing: that's hard. > Decentralised automated reputation systems are complex and subtle. > > I don't feel strongly about whether the field should be "optional" or > "repeated", 100% of implementations in the forseeable future would just > look at the first item and ignore the rest. But if later someone did crack > this problem it would lead to a simple upgrade path. So perhaps you're > right and the protobuf should allow multiple signatures. It means a new > sub-message to wrap the pki_type, pki_data and signature fields into one, > and then making that repeated. > > Up to Lawrence. > [-- Attachment #2: Type: text/html, Size: 2672 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-18 12:09 ` Lawrence Nahum 2014-06-18 13:25 ` Mike Hearn @ 2014-06-25 14:01 ` sebastien requiem 1 sibling, 0 replies; 47+ messages in thread From: sebastien requiem @ 2014-06-25 14:01 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 826 bytes --] On Wed, Jun 18, 2014 at 2:09 PM, Lawrence Nahum <lawrence@greenaddress•it> wrote: > [snip] > > Allow me to recap BIP changes in discussion: > > - making some changes to allow merchants to offer discounts in case of > instant ? > - allowing multiple signatures ? > > Did I miss anything? Thoughts on the above from others? > Jumping on this thread after reading it all. I am in favor of the discount offered by the merchant. Ideally the merchant could get the amount of the wallet *fee* for instant payment (privacy leak?). That way, the merchant could decide to support the instant payment at 100% (better user experience after all) or at 50% only or at 0%. This would encourage instant payment for merchants and buyers without (re-)creating a non-transparent system. regards, -- sebastien requiem - bendingspoons.com [-- Attachment #2: Type: text/html, Size: 1363 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-14 12:00 [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Lawrence Nahum 2014-06-14 12:57 ` Andreas Schildbach @ 2014-06-16 12:19 ` Mike Hearn 2014-06-16 12:25 ` Mike Hearn ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-16 12:19 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1680 bytes --] Looking good! I think this is much better than the original draft. Agree with Andreas that supports_instant is simply equal to (supported_instant_providers.size() > 1) which makes it redundant. Daniel is right that putting every possible provider in the Payment message might not scale in a world where there are huge numbers of instant-confirmation providers, but I'm hoping that we never have to scale to that size, because if we did that'd rather imply that Bitcoin has become useless for in-person payments without trusted third parties and avoiding that is rather the whole point of the project :) So I'm OK with some theoretical lack of scalability for now. A more scalable approach would be for the user to send the name and signature of their "instant provider" every time and the merchant just chooses whether to ignore it or not, but as Lawrence points out, this is incompatible with the provider charging extra fees for "instantness". But should we care? I'm trying to imagine what the purchasing experience is like with optional paid-for third party anti-double-spend protection. Ultimately it's the merchant who cares about this, not me, so why would I ever pay? It makes no sense for me to pay for double spend protection for the merchant: after all, I'm honest. This is why it doesn't make sense for me to pay miners fees either, it's the *receiver* who cares about confirmations, not the sender. So I wonder if a smarter design is that the user always submits the details of their instantness provider and we just don't allow for optional selection of instantness. I'm not sure that works, UX wise, so is having a less scalable design to support it worthwhile? [-- Attachment #2: Type: text/html, Size: 2003 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 12:19 ` Mike Hearn @ 2014-06-16 12:25 ` Mike Hearn 2014-06-16 15:09 ` Daniel Rice 2014-06-16 15:28 ` Lawrence Nahum 2 siblings, 0 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-16 12:25 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 785 bytes --] Oh yes the other thing we need to decide is how to extend BIP70. Protocol buffers have an extend keyword. But I'm not sure it's what we really want. IMHO a simpler solution is to have a single "living" version of the protobuf (where? in a new git repo?) which has all the fields defined by all the accepted BIPs in a single place. Otherwise the build process and so on for wallet implementors would get unnecessarily complicated for no real reason. Also if you wanted to pick a new number for fields, you'd end up having to read *all* BIPs to figure out what is available. Simpler seems better. If we do that then I suggest just using field number 8 or 9 or whatever rather than 1000. IMHO fields 1000+ should be for private extensions that are unlikely to collide with other users. [-- Attachment #2: Type: text/html, Size: 998 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 12:19 ` Mike Hearn 2014-06-16 12:25 ` Mike Hearn @ 2014-06-16 15:09 ` Daniel Rice 2014-06-16 15:26 ` Lawrence Nahum ` (3 more replies) 2014-06-16 15:28 ` Lawrence Nahum 2 siblings, 4 replies; 47+ messages in thread From: Daniel Rice @ 2014-06-16 15:09 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 3554 bytes --] If you're hoping the instant providers list won't need to scale then you're essentially saying that we need a solution to the double spend problem. That is a good point. Double spends are one of the biggest issues remaining in the protocol. I've seen so many people talk about bad experiences trying to spend Bitcoin at a restaurant and waiting an hour for confirmations. This entire BIP extension is a band aid for double spends. If double spends are not resolved, there will be a million instant providers in the long run and if double spends are resolved then this BIP extension is completely unnecessary. Is solving doublespends off the table? What if we solved doublespends like this: If a node receives 2 transactions that use the same input, they can put both of them into the new block as a proof of double spend, but the bitcoins are not sent to the outputs of either transactions. They are instead treated like a fee and given to the block solver node. This gives miners the needed incentive and tools to end doublespends instead of being forced to favor one transaction over the other. I will write up a BIP if this seems like a practical approach. On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn <mike@plan99•net> wrote: > Looking good! I think this is much better than the original draft. Agree > with Andreas that supports_instant is simply equal to > (supported_instant_providers.size() > 1) which makes it redundant. > > Daniel is right that putting every possible provider in the Payment > message might not scale in a world where there are huge numbers of > instant-confirmation providers, but I'm hoping that we never have to scale > to that size, because if we did that'd rather imply that Bitcoin has become > useless for in-person payments without trusted third parties and avoiding > that is rather the whole point of the project :) So I'm OK with some > theoretical lack of scalability for now. > > A more scalable approach would be for the user to send the name and > signature of their "instant provider" every time and the merchant just > chooses whether to ignore it or not, but as Lawrence points out, this is > incompatible with the provider charging extra fees for "instantness". But > should we care? I'm trying to imagine what the purchasing experience is > like with optional paid-for third party anti-double-spend protection. > Ultimately it's the merchant who cares about this, not me, so why would I > ever pay? It makes no sense for me to pay for double spend protection for > the merchant: after all, I'm honest. This is why it doesn't make sense for > me to pay miners fees either, it's the *receiver* who cares about > confirmations, not the sender. > > So I wonder if a smarter design is that the user always submits the > details of their instantness provider and we just don't allow for optional > selection of instantness. I'm not sure that works, UX wise, so is having a > less scalable design to support it worthwhile? > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 4458 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:09 ` Daniel Rice @ 2014-06-16 15:26 ` Lawrence Nahum 2014-06-16 16:00 ` Daniel Rice 2014-06-16 15:41 ` Paul Goldstein ` (2 subsequent siblings) 3 siblings, 1 reply; 47+ messages in thread From: Lawrence Nahum @ 2014-06-16 15:26 UTC (permalink / raw) To: bitcoin-development Daniel Rice <drice <at> greenmangosystems.com> writes: > If double spends are not resolved, there will be a million instant providers in the long run and if double spends are resolved then this BIP extension is completely unnecessary. I am not sure if double spends can be resolved, at the moment they are not and I highly doubt you will see millions instant providers just like I don't see millions Certificate Authorities and I don't see Million Credit Card networks. Any reason you think people will spread trust instead of consolidating of a bunch of instant transaction providers when time is critical? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:26 ` Lawrence Nahum @ 2014-06-16 16:00 ` Daniel Rice 2014-06-16 16:07 ` Mike Hearn 0 siblings, 1 reply; 47+ messages in thread From: Daniel Rice @ 2014-06-16 16:00 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2226 bytes --] > Any reason you think people will spread trust instead of consolidating of a bunch of instant transaction providers when time is critical? Maybe you're right, but if you are, that's a huge reason not to implement this. We should encourage proliferation of instant providers otherwise we start becoming VISA all over again. That's a future for Bitcoin I'm not excited about: "Use one of these 4 companies, or you need to wait an impractical amount of time before your transaction will go through." Come to think of it, is the payment protocol really the place to put this instant provider signature or should it be in the actual Bitcoin transaction? If we don't believe there is a valid practical solution to doublespends (some people have already emailed me critical feedback on my proposal) then we absolutely need a trust network, but we would also want it to be part of the public ledger for everyone to see. On Mon, Jun 16, 2014 at 8:26 AM, Lawrence Nahum <lawrence@greenaddress•it> wrote: > Daniel Rice <drice <at> greenmangosystems.com> writes: > > > If double spends are not resolved, there will be a million instant > providers in the long run and if double spends are resolved then this BIP > extension is completely unnecessary. > > I am not sure if double spends can be resolved, at the moment they are not > and I highly doubt you will see millions instant providers just like I > don't > see millions Certificate Authorities and I don't see Million Credit Card > networks. > > Any reason you think people will spread trust instead of consolidating of a > bunch of instant transaction providers when time is critical? > > > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3522 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 16:00 ` Daniel Rice @ 2014-06-16 16:07 ` Mike Hearn 0 siblings, 0 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-16 16:07 UTC (permalink / raw) To: Daniel Rice; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 575 bytes --] > > Come to think of it, is the payment protocol really the place to put this > instant provider signature > Yes it's the right place. The original attempt at this concept was in fact called *green addresses* and the idea was you could identify a spend from a trusted wallet by checking which keys were being used to sign. But the problem is, lack of privacy. Everyone can see what wallet provider you use. Also it'd be inefficient to have in the chain. There's no reason for the extra signatures to be there: double spend risk is something only the recipient cares about. [-- Attachment #2: Type: text/html, Size: 935 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:09 ` Daniel Rice 2014-06-16 15:26 ` Lawrence Nahum @ 2014-06-16 15:41 ` Paul Goldstein 2014-06-16 15:48 ` Mike Hearn 2014-06-17 15:58 ` Isidor Zeuner 2014-06-18 2:01 ` Tom Harding 3 siblings, 1 reply; 47+ messages in thread From: Paul Goldstein @ 2014-06-16 15:41 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4911 bytes --] Mike Hearn, why don't we just have all nodes report attempted double spends through the node network. No need to involve the miners at all really, or do your suggestion but also report the double spend attempt. By waiting maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can be more sure that a double spend attack was not tried. Attacker would have to hold back second tx by 10-60 seconds and hope that that second tx (with higher fee) get's into a solved block before the first one. This forced delay time ought to make the attack less successful (but not impossible). Paul G. On Mon, Jun 16, 2014 at 11:09 AM, Daniel Rice <drice@greenmangosystems•com> wrote: > If you're hoping the instant providers list won't need to scale then > you're essentially saying that we need a solution to the double spend > problem. That is a good point. Double spends are one of the biggest issues > remaining in the protocol. I've seen so many people talk about bad > experiences trying to spend Bitcoin at a restaurant and waiting an hour for > confirmations. This entire BIP extension is a band aid for double spends. > If double spends are not resolved, there will be a million instant > providers in the long run and if double spends are resolved then this BIP > extension is completely unnecessary. Is solving doublespends off the table? > > What if we solved doublespends like this: If a node receives 2 > transactions that use the same input, they can put both of them into the > new block as a proof of double spend, but the bitcoins are not sent to the > outputs of either transactions. They are instead treated like a fee and > given to the block solver node. This gives miners the needed incentive and > tools to end doublespends instead of being forced to favor one transaction > over the other. > > I will write up a BIP if this seems like a practical approach. > > > On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn <mike@plan99•net> wrote: > >> Looking good! I think this is much better than the original draft. Agree >> with Andreas that supports_instant is simply equal to >> (supported_instant_providers.size() > 1) which makes it redundant. >> >> Daniel is right that putting every possible provider in the Payment >> message might not scale in a world where there are huge numbers of >> instant-confirmation providers, but I'm hoping that we never have to scale >> to that size, because if we did that'd rather imply that Bitcoin has become >> useless for in-person payments without trusted third parties and avoiding >> that is rather the whole point of the project :) So I'm OK with some >> theoretical lack of scalability for now. >> >> A more scalable approach would be for the user to send the name and >> signature of their "instant provider" every time and the merchant just >> chooses whether to ignore it or not, but as Lawrence points out, this is >> incompatible with the provider charging extra fees for "instantness". But >> should we care? I'm trying to imagine what the purchasing experience is >> like with optional paid-for third party anti-double-spend protection. >> Ultimately it's the merchant who cares about this, not me, so why would I >> ever pay? It makes no sense for me to pay for double spend protection for >> the merchant: after all, I'm honest. This is why it doesn't make sense for >> me to pay miners fees either, it's the *receiver* who cares about >> confirmations, not the sender. >> >> So I wonder if a smarter design is that the user always submits the >> details of their instantness provider and we just don't allow for optional >> selection of instantness. I'm not sure that works, UX wise, so is having a >> less scalable design to support it worthwhile? >> >> >> ------------------------------------------------------------------------------ >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions >> Find What Matters Most in Your Big Data with HPCC Systems >> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. >> Leverages Graph Analysis for Fast Processing & Easy Data Exploration >> http://p.sf.net/sfu/hpccsystems >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 6410 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:41 ` Paul Goldstein @ 2014-06-16 15:48 ` Mike Hearn 2014-06-16 16:30 ` Lawrence Nahum 2014-06-18 1:39 ` Tom Harding 0 siblings, 2 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-16 15:48 UTC (permalink / raw) To: Paul Goldstein; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1385 bytes --] > > Mike Hearn, why don't we just have all nodes report attempted double > spends through the node network. > Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements this exact scheme. It can solve some kinds of double spends (probably), but others - like ones done by corrupt miners (see bitundo) - can't be solved this way. Lawrence's motivation for this BIP is essentially to act as a backup in case the Bitcoin native double spending protections end up being too weak to be useful. It reintroduces a notion of centralised trust as a layer on top of the Bitcoin protocol, but only for cases where the seller/recipient feels it'd be useful. In this way it gives us slack: if someone is able to reliably double spend and the merchants losses due to payment fraud go up, we can fall back to TTPs for a while until someone finds a solution for Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we now have a better intermediary protocol than SWIFT :-) In practice of course this is something payment processors like Bitpay and Coinbase will think about. Individual cafes etc who are just using mobile wallets won't be able to deal with this complexity: if we can't make native Bitcoin work well enough there, we're most likely to just lose that market or watch it become entirely centralised around a handful of payment processing companies. [-- Attachment #2: Type: text/html, Size: 1855 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:48 ` Mike Hearn @ 2014-06-16 16:30 ` Lawrence Nahum 2014-06-16 16:45 ` Mike Hearn 2014-06-18 1:39 ` Tom Harding 1 sibling, 1 reply; 47+ messages in thread From: Lawrence Nahum @ 2014-06-16 16:30 UTC (permalink / raw) To: bitcoin-development Mike Hearn <mike <at> plan99.net> writes: > Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements this exact scheme. It can solve some kinds of double spends (probably), but others - like ones done by corrupt miners (see bitundo) - can't be solved this way. I read the comments on the PR. I mean no disrespect but this patch can't prevent double spends minutes apart and a solution is as good as it's weakest link. It also seems to suffer from potential ddos and otherwise may provide a false sense of security. I wouldn't call it a solution in sight just yet. > Lawrence's motivation for this BIP is essentially to act as a backup in case the Bitcoin native double spending protections end up being too weak to be useful. It reintroduces a notion of centralised trust as a layer on top of the Bitcoin protocol, but only for cases where the seller/recipient feels it'd be useful. In this way it gives us slack: if someone is able to reliably double spend and the merchants losses due to payment fraud go up, we can fall back to TTPs for a while until someone finds a solution for Bitcoin, or we just give up on the Bitcoin experiment, but hey - at least we now have a better intermediary protocol than SWIFT I wouldn't put it just like that. Sure, it's a backup to the double spend solution in case we don't reach one - but also, even if you reach some reasonable compromise I assume it won't be instant and instant confirmation between exchanges can create huge arbitrage opportunities and as such liquidity. It's not really aimed at the merchant but more at service providers and payment processors - or simply, between users that don't know each other in local traders environments/squares, assuming they are ok trusting a known/respected/reputable third party. > In practice of course this is something payment processors like Bitpay and Coinbase will think about. Individual cafes etc who are just using mobile wallets won't be able to deal with this complexity: if we can't make native Bitcoin work well enough there, we're most likely to just lose that market or watch it become entirely centralised around a handful of payment processing companies. What do you expect for e-commerce and escrow to happen? Don't you think the market will naturally converge to a handful of hubs that will helps with refunds and things like that? Or do you expect to just 'trust' all people on online markets and smaller unknown online shops? I mean, the beauty of Bitcoin is that it brings much more transparency and the tools to build such things without huge barriers to entry and without using closed protocols - not that it solves _every_ problem. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 16:30 ` Lawrence Nahum @ 2014-06-16 16:45 ` Mike Hearn 2014-06-16 16:56 ` Lawrence Nahum 0 siblings, 1 reply; 47+ messages in thread From: Mike Hearn @ 2014-06-16 16:45 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1870 bytes --] > > I read the comments on the PR. I mean no disrespect but this patch can't > prevent double spends minutes apart and a solution is as good as it's > weakest link. > Actually Tom is running a page where he shows double spends detected by his node or relayed by mine (there are only two nodes in this little detection network currently), and it does show double spends that occur seconds, minutes or even days apart. Regardless, whether that approach helps or not is off topic for this thread. Let's all hope it does and discuss the details in some other thread, or on the pull request. > instant confirmation between exchanges can create huge arbitrage > opportunities and as such > liquidity. > Yes indeed, if you want to do high frequency trading then every millisecond counts and you probably don't want to rely on watching transactions propagate across the block chain. For inter-exchange traffic this BIP would probably be useful. I've been talking about the consumer case. > What do you expect for e-commerce and escrow to happen? Don't you think the > market will naturally converge to a handful of hubs that will helps with > refunds and things like that? No, I expect there to be many kinds of trades where dispute mediation is unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds the chances of me wanting to charge it back is basically zero. Same for sending between people who know each other, large corporate transactions where the threat of a lawsuit is more useful than mediation, etc. But for transactions where third parties are needed for dispute mediation, yes, I'd expect there to be a handful of well known trusted names for the majority of such transactions, and then a long tail of specialists who only mediate e.g. purchases of rare Aztec artifacts or other things where a generic company might be easily fooled. [-- Attachment #2: Type: text/html, Size: 2543 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 16:45 ` Mike Hearn @ 2014-06-16 16:56 ` Lawrence Nahum 2014-06-16 17:01 ` Mike Hearn 0 siblings, 1 reply; 47+ messages in thread From: Lawrence Nahum @ 2014-06-16 16:56 UTC (permalink / raw) To: bitcoin-development Mike Hearn <mike <at> plan99.net> writes: > Actually Tom is running a page where he shows double spends detected by his node or relayed by mine (there are only two nodes in this little detection network currently), and it does show double spends that occur seconds, minutes or even days apart. I only meant that double spends minutes apart are possible and that by then the sole use of a monitor is too late even if it will tell you. > Regardless, whether that approach helps or not is off topic for this thread. Let's all hope it does and discuss the details in some other thread, or on the pull request. Fair enough. > Yes indeed, if you want to do high frequency trading then every millisecond counts and you probably don't want to rely on watching transactions propagate across the block chain. For inter-exchange traffic this BIP would probably be useful. I've been talking about the consumer case. That's quite different, granted. > No, I expect there to be many kinds of trades where dispute mediation is unnecessary, e.g. when I buy a drink at Starbucks or a burger at McDonalds the chances of me wanting to charge it back is basically zero. Same for sending between people who know each other, large corporate transactions where the threat of a lawsuit is more useful than mediation, etc. I wouldn't assume that if bitcoin alone (i.e. without third parties) can't be used for medium-high value purchases then it's useless. > But for transactions where third parties are needed for dispute mediation, yes, I'd expect there to be a handful of well known trusted names for the majority of such transactions, and then a long tail of specialists who only mediate e.g. purchases of rare Aztec artifacts or other things where a generic company might be easily fooled. Agreed. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 16:56 ` Lawrence Nahum @ 2014-06-16 17:01 ` Mike Hearn 2014-06-16 17:16 ` Lawrence Nahum ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-16 17:01 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 664 bytes --] > > I only meant that double spends minutes apart are possible and that by then > the sole use of a monitor is too late even if it will tell you. > As long as miners stick to Satoshi's first seen rule, which is the default, it's useful: https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 (this is the famous "snack machine" thread from 2010) If they decide to change to something like highest-fee-always-wins, then they (again) centralise things by forcing all instant transactions to pay GreenAddress and its competitors money - much though I like your product Lawrence, let's hope they don't collectively lemming us all off a cliff by doing that ;) [-- Attachment #2: Type: text/html, Size: 1273 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 17:01 ` Mike Hearn @ 2014-06-16 17:16 ` Lawrence Nahum 2014-06-16 18:02 ` Alex Kotenko 2014-06-16 17:44 ` Jorge Timón 2014-06-17 15:58 ` Isidor Zeuner 2 siblings, 1 reply; 47+ messages in thread From: Lawrence Nahum @ 2014-06-16 17:16 UTC (permalink / raw) To: bitcoin-development Mike Hearn <mike <at> plan99.net> writes: > As long as miners stick to Satoshi's first seen rule, which is the default, it's useful: > > > https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 > > > > > (this is the famous "snack machine" thread from 2010) > > If they decide to change to something like highest-fee-always-wins, then they (again) centralise things by forcing all instant transactions to pay GreenAddress and its competitors money - much though I like your product Lawrence, let's hope they don't collectively lemming us all off a cliff by doing that ;) I assume we can't enforce to miners rules about which tx will go in and which won't and therefore whether this will cause more or less double spends. I mean, you can try but I would rather have to option to pick an third party instant provider explicitly than enforce bigger rules on mining which would IMHO lead to implicit centralization. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 17:16 ` Lawrence Nahum @ 2014-06-16 18:02 ` Alex Kotenko 2014-06-16 18:09 ` Mike Hearn 0 siblings, 1 reply; 47+ messages in thread From: Alex Kotenko @ 2014-06-16 18:02 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2949 bytes --] Hi Lawrence/All I'm afraid with this BIP for TTP of instant transactions we will end up in VISA world again. As I see it - it's not about if the TTPs will centralize, it's only when. Simply because if economy of scales makes growth profitable and coming into this market is at least a little expensive - this (centralization, VISA world) will happen, sooner rather than later. And while some may argue that coming to market in Bitcoin world is cheap so the crowd will always have a chance to come in and beat the monopolists - think of one thing. Right now Bitcoin is not seen as money and not regulated accordingly anywhere in the world, thanks God, but how many years away we are from the point when it will start to be regulated that way? And once it is - the monopolies will make sure that rules are restrictive enough to prevent competition, especially in conjunction with economy of scales playing against the small newcomers. The "instant providers list" is susceptible to regulatory influence, and once in place and widespread - it will be a timebomb under Bitcoin. We need to solve the doublespend issue without TTP involvement, or at least without even a slight chance of making this involvement regulateable. Otherwise I think the Bitcoin experiment will fail. Best regards, Alex Kotenko 2014-06-16 18:16 GMT+01:00 Lawrence Nahum <lawrence@greenaddress•it>: > Mike Hearn <mike <at> plan99.net> writes: > > > As long as miners stick to Satoshi's first seen rule, which is the > default, it's useful: > > > > > > https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 > > > > > > > > > > (this is the famous "snack machine" thread from 2010) > > > > If they decide to change to something like highest-fee-always-wins, then > they (again) centralise things by forcing all instant transactions to pay > GreenAddress and its competitors money - much though I like your product > Lawrence, let's hope they don't collectively lemming us all off a cliff by > doing that ;) > > > I assume we can't enforce to miners rules about which tx will go in and > which won't and therefore whether this will cause more or less double > spends. > > > I mean, you can try but I would rather have to option to pick an third > party > instant provider explicitly than enforce bigger rules on mining which > would > IMHO lead to implicit centralization. > > > > > > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 4872 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 18:02 ` Alex Kotenko @ 2014-06-16 18:09 ` Mike Hearn 2014-06-16 20:29 ` Daniel Rice 2014-06-16 20:32 ` Alex Kotenko 0 siblings, 2 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-16 18:09 UTC (permalink / raw) To: Alex Kotenko; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 622 bytes --] I think many of us feel it'd be better if this kind of thing were not needed at all, however, the best way to ensure it doesn't end up being used is to write code, not to try and block alternative approaches. If Bitcoin is robust the market should sort it out. If it's robust for some transactions and not others, that makes for a fun project for a future generation of hackers to sort out. OK, enough philosophy - let's try and keep this thread just for discussion of the BIP itself from now on. If you'd like to continue debating the Future of Bitcoin please change the subject line and break it out into a new thread. [-- Attachment #2: Type: text/html, Size: 716 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 18:09 ` Mike Hearn @ 2014-06-16 20:29 ` Daniel Rice 2014-06-16 20:32 ` Mike Hearn 2014-06-16 21:02 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Daniel Rice 2014-06-16 20:32 ` Alex Kotenko 1 sibling, 2 replies; 47+ messages in thread From: Daniel Rice @ 2014-06-16 20:29 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 2266 bytes --] I'm trying to think through how to encourage the maximum number of instant signature providers and avoid the VISA monopoly. Ideal case would be that people can even be their own instant provider. What if the protocol allowed multiple instant signatures on a transaction? Would it encourage more instant providers? For example, a new instant provider could bootstrap their own trust by paying an already trusted instant provider to co-sign the same transaction. This would be useful in the case that a new company tries to release a new wallet once the trust ring is already established. Nobody will use that wallet because it does not have the trusted history to do instant transactions, but if they can pay a small amount per transaction to a third party to cosign, they can build trust in their own signature till they can eventually have enough trust on their own. This could be how an individual user could grow trust in their own instant signature as well. On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike@plan99•net> wrote: > I think many of us feel it'd be better if this kind of thing were not > needed at all, however, the best way to ensure it doesn't end up being used > is to write code, not to try and block alternative approaches. If Bitcoin > is robust the market should sort it out. If it's robust for some > transactions and not others, that makes for a fun project for a future > generation of hackers to sort out. > > OK, enough philosophy - let's try and keep this thread just for discussion > of the BIP itself from now on. If you'd like to continue debating the > Future of Bitcoin please change the subject line and break it out into a > new thread. > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 2922 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 20:29 ` Daniel Rice @ 2014-06-16 20:32 ` Mike Hearn 2014-06-16 20:37 ` Daniel Rice 2014-06-16 21:02 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Daniel Rice 1 sibling, 1 reply; 47+ messages in thread From: Mike Hearn @ 2014-06-16 20:32 UTC (permalink / raw) To: Daniel Rice; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 779 bytes --] On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice@greenmangosystems•com> wrote: > I'm trying to think through how to encourage the maximum number of instant > signature providers and avoid the VISA monopoly. Ideal case would be that > people can even be their own instant provider. > A provider does not have to be an interactive third party. One reason I suggested using X.509 is so secure hardware devices like the TREZOR could also be instant providers. The hardware would be tamperproof and assert using a secret key embedded in it that the tx came from a genuine, unflashed TREZOR. The the server can know the device won't double spend. In this way you have decentralised anti-double spending. Of course, it's an old solution. MintChip sort of worked a bit like this. [-- Attachment #2: Type: text/html, Size: 1164 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 20:32 ` Mike Hearn @ 2014-06-16 20:37 ` Daniel Rice 2014-06-16 20:46 ` Mike Hearn 2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd 0 siblings, 2 replies; 47+ messages in thread From: Daniel Rice @ 2014-06-16 20:37 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 1309 bytes --] True, that would work, but still how are you going to bootstrap the trust? TREZOR is well known, but in a future where there could be 100 different companies trying to release a similar product to TREZOR it seems like one company could corner the market by being the only one that is an accepted instant provider at most vendors. It seems to encourage monopoly unless there is a standard way to bootstrap trust in your signature. On Mon, Jun 16, 2014 at 1:32 PM, Mike Hearn <mike@plan99•net> wrote: > On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice@greenmangosystems•com > > wrote: > >> I'm trying to think through how to encourage the maximum number of >> instant signature providers and avoid the VISA monopoly. Ideal case would >> be that people can even be their own instant provider. >> > > A provider does not have to be an interactive third party. One reason I > suggested using X.509 is so secure hardware devices like the TREZOR could > also be instant providers. The hardware would be tamperproof and assert > using a secret key embedded in it that the tx came from a genuine, > unflashed TREZOR. The the server can know the device won't double spend. > > In this way you have decentralised anti-double spending. Of course, it's > an old solution. MintChip sort of worked a bit like this. > [-- Attachment #2: Type: text/html, Size: 1989 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 20:37 ` Daniel Rice @ 2014-06-16 20:46 ` Mike Hearn 2014-06-16 20:53 ` Daniel Rice 2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd 1 sibling, 1 reply; 47+ messages in thread From: Mike Hearn @ 2014-06-16 20:46 UTC (permalink / raw) To: Daniel Rice; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 834 bytes --] On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice <drice@greenmangosystems•com> wrote: > True, that would work, but still how are you going to bootstrap the trust? > TREZOR is well known, but in a future where there could be 100 different > companies trying to release a similar product to TREZOR it seems like one > company could corner the market by being the only one that is an accepted > instant provider at most vendors > It's no different to the CA problem. People can only mentally handle a few trust anchors, so for SSL it goes: 1 User -> 2-3 browser makers -> 100's of CAs -> millions of websites The trust starts out narrowly funnelled and grows outwards as things get outsourced. For this it'd go 1 merchant -> 4-5 payment processing engines -> dozens of hardware manufacturers -> hundreds of thousands of devices [-- Attachment #2: Type: text/html, Size: 1330 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 20:46 ` Mike Hearn @ 2014-06-16 20:53 ` Daniel Rice 2014-06-16 20:55 ` Mike Hearn 0 siblings, 1 reply; 47+ messages in thread From: Daniel Rice @ 2014-06-16 20:53 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 1471 bytes --] The trust can be more automated in this case than it can with CAs. The difference is that when a CA does something it shouldn't, like generates an extra cert for a government to use in spoofing a site, nobody knows about it, unless they mess up. Double spends on the network can be monitored and stored for history. Merchants can and will share information on instant provider trust with eachother, so they will essentially be able to build up a credit history on a given instant provider without really knowing who they are. On Mon, Jun 16, 2014 at 1:46 PM, Mike Hearn <mike@plan99•net> wrote: > On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice <drice@greenmangosystems•com > > wrote: > >> True, that would work, but still how are you going to bootstrap the >> trust? TREZOR is well known, but in a future where there could be 100 >> different companies trying to release a similar product to TREZOR it seems >> like one company could corner the market by being the only one that is an >> accepted instant provider at most vendors >> > > It's no different to the CA problem. People can only mentally handle a few > trust anchors, so for SSL it goes: > > 1 User -> 2-3 browser makers -> 100's of CAs -> millions of websites > > The trust starts out narrowly funnelled and grows outwards as things get > outsourced. > > For this it'd go > > 1 merchant -> 4-5 payment processing engines -> dozens of hardware > manufacturers -> hundreds of thousands of devices > > > [-- Attachment #2: Type: text/html, Size: 2257 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 20:53 ` Daniel Rice @ 2014-06-16 20:55 ` Mike Hearn 0 siblings, 0 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-16 20:55 UTC (permalink / raw) To: Daniel Rice; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 167 bytes --] Yes that's true. Though it's off topic, check out http://www.certificate-transparency.org/ .... it's a project to force CA's to publish all certs they make publicly. [-- Attachment #2: Type: text/html, Size: 262 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees 2014-06-16 20:37 ` Daniel Rice 2014-06-16 20:46 ` Mike Hearn @ 2014-06-16 20:50 ` Peter Todd 1 sibling, 0 replies; 47+ messages in thread From: Peter Todd @ 2014-06-16 20:50 UTC (permalink / raw) To: Daniel Rice; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 2814 bytes --] On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote: > True, that would work, but still how are you going to bootstrap the trust? > TREZOR is well known, but in a future where there could be 100 different > companies trying to release a similar product to TREZOR it seems like one > company could corner the market by being the only one that is an accepted > instant provider at most vendors. It seems to encourage monopoly unless > there is a standard way to bootstrap trust in your signature. You can always use fidelity bonds, or as I called it at the time(1), "Trusted identities": Lets suppose Alice has some bitcoins held at bitcoin address A. She wants to establish trust in the "identity" associated with the ECC keypair associated with A, for instance for the purpose of having other users trust her not to attempt to double spend. Since the trust she seeks is financial in nature, she can do this by valuing the identity associated with A, by delibrately throwing away resources. A simple way to do this would of course be to transfer coins to a null address, provably incurring a cost to her. A more socially responsible way would be for her to create a series of transactions that happen to have large, and equal, transaction fees. Bitcoin makes the assumption that no one entity controls more than 50% of the network, so if she makes n of these transactions consecutively, each spending m BTC to transaction fees, there is a high probability that she has given up at least n/2 * m BTC of value. This of course is all public knowledge, recorded in the block chain. It also increases the transaction fees for miners, which will be very important for the network in the future. Now Bob can easily examine the block chain, and upon verifying Alice's trust purchase, can decide to accept a zero-confirmation transaction at face value. If Alice breaks that promise, he simply publishes her signed transaction proving that Alice is a fraudster, and future Bob's will distrust Alice's trusted identity, thus destroying the value needed to create it. In effect, we now have a distributed green address system. Note that the second paragraph is seriously obsolete - better to either use announce-commit sacrifices, or much preferably, simple destruction of coins. (sacrifice to fees encourages mining centralization for obvious reasons) 1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd, http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01005.html Incidentally, my first post to this mailing list! -- 'peter'[:-1]@petertodd.org 000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 20:29 ` Daniel Rice 2014-06-16 20:32 ` Mike Hearn @ 2014-06-16 21:02 ` Daniel Rice 1 sibling, 0 replies; 47+ messages in thread From: Daniel Rice @ 2014-06-16 21:02 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 4080 bytes --] Mike Hearn <mike@plan99•net> wrote: >> A more scalable approach would be for the user to send the name and >> signature of their "instant provider" every time and the merchant just >> chooses whether to ignore it or not, but as Lawrence points out, this is >> incompatible with the provider charging extra fees for "instantness". But >> should we care? I'm trying to imagine what the purchasing experience is like >> with optional paid-for third party anti-double-spend protection. Ultimately >> it's the merchant who cares about this, not me, so why would I ever pay? Lawrence Nahum <lawrence@greenaddress•it> wrote: > I think you are wrong here. > Just because up to date credit cards charged the merchant which in turn > charged you and the ordinary cash payer doesn't mean a newer and better > system can't be transparent from day one. I don't think a whitelist of trust is a practical approach because you are going to want to have varying levels of trust in different instant providers. This would be based on how large their past transaction volume has been. For that reason maybe another approach is an additional negotiation message between the merchant and wallet. Merchant sends payment details -> wallet responds with their instant information requesting if an instant transaction will be accepted for this transaction. Merchant weighs the risk based on historical data about this particular instant provider and the amount of the requested transaction -> Merchant responds yes or no. That approach avoids the scaling issue, but also allows for Lawrence's use case of charging the user a fee only in the case where the instant transaction is supported. On Mon, Jun 16, 2014 at 1:29 PM, Daniel Rice <drice@greenmangosystems•com> wrote: > I'm trying to think through how to encourage the maximum number of instant > signature providers and avoid the VISA monopoly. Ideal case would be that > people can even be their own instant provider. > > What if the protocol allowed multiple instant signatures on a transaction? > Would it encourage more instant providers? For example, a new instant > provider could bootstrap their own trust by paying an already trusted > instant provider to co-sign the same transaction. This would be useful in > the case that a new company tries to release a new wallet once the trust > ring is already established. Nobody will use that wallet because it does > not have the trusted history to do instant transactions, but if they can > pay a small amount per transaction to a third party to cosign, they can > build trust in their own signature till they can eventually have enough > trust on their own. This could be how an individual user could grow trust > in their own instant signature as well. > > > On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <mike@plan99•net> wrote: > >> I think many of us feel it'd be better if this kind of thing were not >> needed at all, however, the best way to ensure it doesn't end up being used >> is to write code, not to try and block alternative approaches. If Bitcoin >> is robust the market should sort it out. If it's robust for some >> transactions and not others, that makes for a fun project for a future >> generation of hackers to sort out. >> >> OK, enough philosophy - let's try and keep this thread just for >> discussion of the BIP itself from now on. If you'd like to continue >> debating the Future of Bitcoin please change the subject line and break it >> out into a new thread. >> >> >> ------------------------------------------------------------------------------ >> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions >> Find What Matters Most in Your Big Data with HPCC Systems >> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. >> Leverages Graph Analysis for Fast Processing & Easy Data Exploration >> http://p.sf.net/sfu/hpccsystems >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > [-- Attachment #2: Type: text/html, Size: 6305 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 18:09 ` Mike Hearn 2014-06-16 20:29 ` Daniel Rice @ 2014-06-16 20:32 ` Alex Kotenko 1 sibling, 0 replies; 47+ messages in thread From: Alex Kotenko @ 2014-06-16 20:32 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum [-- Attachment #1: Type: text/plain, Size: 913 bytes --] True, enough philosophy. Once this BIP will be finalized - we will it's schedule implementation in XBTerminal. This is a solution to the problem we have, probably best one we have to date, so we will use it. 2014-06-16 19:09 GMT+01:00 Mike Hearn <mike@plan99•net>: > I think many of us feel it'd be better if this kind of thing were not > needed at all, however, the best way to ensure it doesn't end up being used > is to write code, not to try and block alternative approaches. If Bitcoin > is robust the market should sort it out. If it's robust for some > transactions and not others, that makes for a fun project for a future > generation of hackers to sort out. > > OK, enough philosophy - let's try and keep this thread just for discussion > of the BIP itself from now on. If you'd like to continue debating the > Future of Bitcoin please change the subject line and break it out into a > new thread. > [-- Attachment #2: Type: text/html, Size: 1390 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 17:01 ` Mike Hearn 2014-06-16 17:16 ` Lawrence Nahum @ 2014-06-16 17:44 ` Jorge Timón 2014-06-17 15:58 ` Isidor Zeuner 2 siblings, 0 replies; 47+ messages in thread From: Jorge Timón @ 2014-06-16 17:44 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Lawrence Nahum On 6/16/14, Mike Hearn <mike@plan99•net> wrote: > If they decide to change to something like highest-fee-always-wins, then > they (again) centralise things by forcing all instant transactions to pay > GreenAddress and its competitors money - much though I like your product > Lawrence, let's hope they don't collectively lemming us all off a cliff by > doing that ;) Replace-by-fee doesn't imply the use of green addresses (there's other solutions to 0 conf transactions in that context, for example, "scorched earth"). And giving up the non-enforceable first-seen default mining policy doesn't mean "giving up on the Bitcoin experiment" either. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 17:01 ` Mike Hearn 2014-06-16 17:16 ` Lawrence Nahum 2014-06-16 17:44 ` Jorge Timón @ 2014-06-17 15:58 ` Isidor Zeuner 2 siblings, 0 replies; 47+ messages in thread From: Isidor Zeuner @ 2014-06-17 15:58 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev, Lawrence Nahum quote: > On 6/16/14, Mike Hearn <mike@plan99•net> wrote: > > If they decide to change to something like highest-fee-always-wins, then > > they (again) centralise things by forcing all instant transactions to pay > > GreenAddress and its competitors money - much though I like your product > > Lawrence, let's hope they don't collectively lemming us all off a cliff by > > doing that ;) > > Replace-by-fee doesn't imply the use of green addresses (there's other > solutions to 0 conf transactions in that context, for example, > "scorched earth"). And giving up the non-enforceable first-seen > default mining policy doesn't mean "giving up on the Bitcoin > experiment" either. > If something means "giving up on the Bitcoin experiment", then for sure it's not one mining policy or another, but the assumption that we should have one uniform mining policy. If we had a community where enough miners had their own opinion about the best mining policy, and expressed it by choosing an appropriate mining pool, then we would have better decentralized mining based on selfish motives of the miners, rather than based on an abstract thought of "centralization is bad, so I will consider how much mining profit from qualitatively interchangable mining pools I'm willing to sacrifice in order to ease my centralization fears". Best regards, Isidor ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:48 ` Mike Hearn 2014-06-16 16:30 ` Lawrence Nahum @ 2014-06-18 1:39 ` Tom Harding 1 sibling, 0 replies; 47+ messages in thread From: Tom Harding @ 2014-06-18 1:39 UTC (permalink / raw) To: bitcoin-development On 6/16/2014 8:48 AM, Mike Hearn wrote: > In practice of course this is something payment processors like Bitpay > and Coinbase will think about. Individual cafes etc who are just using > mobile wallets won't be able to deal with this complexity: if we can't > make native Bitcoin work well enough there, we're most likely to just > lose that market or watch it become entirely centralised around a > handful of payment processing companies. I have trouble seeing how could the real-time anonymous payments market can be cleanly separated from everything else. If trusted third parties become the norm for that market, there will inevitably be a huge overlap effect on other markets that bitcoin can serve best, even today. I don't see how any currency, any cash, can concede this market. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:09 ` Daniel Rice 2014-06-16 15:26 ` Lawrence Nahum 2014-06-16 15:41 ` Paul Goldstein @ 2014-06-17 15:58 ` Isidor Zeuner 2014-06-18 9:15 ` Mike Hearn 2014-06-18 20:47 ` Natanael 2014-06-18 2:01 ` Tom Harding 3 siblings, 2 replies; 47+ messages in thread From: Isidor Zeuner @ 2014-06-17 15:58 UTC (permalink / raw) To: Paul Goldstein; +Cc: Bitcoin Dev quote: > Mike Hearn, why don't we just have all nodes report attempted double spends > through the node network. No need to involve the miners at all really, or > do your suggestion but also report the double spend attempt. By waiting > maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can > be more sure that a double spend attack was not tried. Attacker would have > to hold back second tx by 10-60 seconds and hope that that second tx (with > higher fee) get's into a solved block before the first one. This forced > delay time ought to make the attack less successful (but not impossible). > What prevents the following steps from happening: 1. attacker sends first transaction, paying to the merchant 2. merchant waits 10-60 seconds 3. merchant confirms the payment as received 4. attacker sees merchant's confirmation 5. attacker sends double spend The security improvement seems to be pretty much exactly the chance that during the 10-60 seconds, a block is solved. Am I missing something? Regarding "reporting double spends", this would only help if it comes with some kind of penalty for the double spend. Now what if the double spend was not done on malicious motives? Maybe someone posted a transaction which does not confirm for some reason, and wants to recover his funds? Should we regard transactions which do not confirm as forever lost, in order to get to an "every double spend is a misbehaviour" policy? Best regards, Isidor ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-17 15:58 ` Isidor Zeuner @ 2014-06-18 9:15 ` Mike Hearn 2014-06-18 20:47 ` Natanael 1 sibling, 0 replies; 47+ messages in thread From: Mike Hearn @ 2014-06-18 9:15 UTC (permalink / raw) To: Isidor Zeuner; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 626 bytes --] Please, let's talk about other anti-double spend things on a separate thread. On Tue, Jun 17, 2014 at 5:58 PM, Isidor Zeuner <cryptocurrencies@quidecco•de > wrote: > What prevents the following steps from happening: > I linked to Satoshi's post on this earlier, he explains why it works there, assuming people follow the original protocol rules. Your analysis holds as long as network abandons the original Bitcoin design. Obviously, we hope people won't do that. If everyone decides not to do things how Satoshi laid out then things will break, although whether we have a failure of "Bitcoin" at that point is debatable. [-- Attachment #2: Type: text/html, Size: 999 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-17 15:58 ` Isidor Zeuner 2014-06-18 9:15 ` Mike Hearn @ 2014-06-18 20:47 ` Natanael 1 sibling, 0 replies; 47+ messages in thread From: Natanael @ 2014-06-18 20:47 UTC (permalink / raw) To: Isidor Zeuner; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2472 bytes --] Den 17 jun 2014 17:59 skrev "Isidor Zeuner" <cryptocurrencies@quidecco•de>: > > quote: > > Mike Hearn, why don't we just have all nodes report attempted double spends > > through the node network. No need to involve the miners at all really, or > > do your suggestion but also report the double spend attempt. By waiting > > maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can > > be more sure that a double spend attack was not tried. Attacker would have > > to hold back second tx by 10-60 seconds and hope that that second tx (with > > higher fee) get's into a solved block before the first one. This forced > > delay time ought to make the attack less successful (but not impossible). > > > > What prevents the following steps from happening: > > 1. attacker sends first transaction, paying to the merchant > > 2. merchant waits 10-60 seconds > > 3. merchant confirms the payment as received > > 4. attacker sees merchant's confirmation > > 5. attacker sends double spend > > The security improvement seems to be pretty much exactly the chance > that during the 10-60 seconds, a block is solved. Am I missing > something? > > Regarding "reporting double spends", this would only help if it comes > with some kind of penalty for the double spend. Now what if the double > spend was not done on malicious motives? Maybe someone posted a > transaction which does not confirm for some reason, and wants to > recover his funds? Should we regard transactions which do not confirm > as forever lost, in order to get to an "every double spend is a > misbehaviour" policy? > > Best regards, > > Isidor With 2-of-2 multisignature notaries, the doublespend (the set of conflicting transactions) would be published and propagated together as evidence of the notary being malicious. This is trivial and self-evident self-contained proof. But there should be no direct penalty IMHO in the Bitcoin protocol itself. If a transaction would have to be replaced honestly because of being wrong or simply not confirming, then I think there should be some means of showing the second transaction is "legitimate". Don't ask me how exactly it would work in practice, but one method could be through showing the original recipients have signed off on it (showing they agree it should be reversed). If you can't get the original recipient to sign, then you're stuck with either not replacing it or the notary trying to prove the replacing transaction was legitimate. [-- Attachment #2: Type: text/html, Size: 3023 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:09 ` Daniel Rice ` (2 preceding siblings ...) 2014-06-17 15:58 ` Isidor Zeuner @ 2014-06-18 2:01 ` Tom Harding 3 siblings, 0 replies; 47+ messages in thread From: Tom Harding @ 2014-06-18 2:01 UTC (permalink / raw) To: bitcoin-development On 6/16/2014 8:09 AM, Daniel Rice wrote: > What if we solved doublespends like this: If a node receives 2 > transactions that use the same input, they can put both of them into > the new block as a proof of double spend, but the bitcoins are not > sent to the outputs of either transactions. They are instead treated > like a fee and given to the block solver node. This gives miners the > needed incentive and tools to end doublespends instead of being forced > to favor one transaction over the other. Before considering a hard fork with unpredictable effects on the uncertainty window, it would be interesting to look at a soft fork that would directly target the goal of reducing the uncertainty window, like treating locally-detected double-spends aged > T as invalid (see earlier message "A statistical consensus rule for reducing 0-conf double-spend risk"). If anything is worth a soft fork, wouldn't reducing the double-spend uncertainty window by an order of magnitude be in the running? Reducing the reasons that transactions don't get relayed, which actually seems to have a shot of happening pretty soon, would also make this kind of thing work better. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 12:19 ` Mike Hearn 2014-06-16 12:25 ` Mike Hearn 2014-06-16 15:09 ` Daniel Rice @ 2014-06-16 15:28 ` Lawrence Nahum 2014-06-16 15:43 ` Mike Hearn 2 siblings, 1 reply; 47+ messages in thread From: Lawrence Nahum @ 2014-06-16 15:28 UTC (permalink / raw) To: bitcoin-development Mike Hearn <mike <at> plan99.net> writes: [snip] > Daniel is right that putting every possible provider in the Payment message might not scale in a world where there are huge numbers of instant- confirmation providers, but I'm hoping that we never have to scale to that size, because if we did that'd rather imply that Bitcoin has become useless for in-person payments without trusted third parties and avoiding that is rather the whole point of the project :) So I'm OK with some theoretical lack of scalability for now. Hard to say for now. I like the current simplicity but if someone can come up with some use case for other options we should discuss and investigate them. I don't see more than a bunch of accepted payment methods anywhere I ever been in my life, I don't see merchants trusting more than a handful of third parties. > A more scalable approach would be for the user to send the name and signature of their "instant provider" every time and the merchant just chooses whether to ignore it or not, but as Lawrence points out, this is incompatible with the provider charging extra fees for "instantness". But should we care? I'm trying to imagine what the purchasing experience is like with optional paid-for third party anti-double-spend protection. Ultimately it's the merchant who cares about this, not me, so why would I ever pay? I think you are wrong here. Just because up to date credit cards charged the merchant which in turn charged you and the ordinary cash payer doesn't mean a newer and better system can't be transparent from day one. Ultimately you care because the alternative is to wait. > It makes no sense for me to pay for double spend protection for the merchant: after all, I'm honest. It's quite simple, in a low amounts world people will probably accept zero confs, just like occasionally people can walk out with a bag of crisps without paying from a Pret in London. Guards would cost more than what they'd save from thefts. With higher amounts they will either not accept bitcoin unless instant confirmed or they will make you wait if that's even feasible (unlikely in a supermarket or petrol station but perfectly fine at the restaurant maybe). > This is why it doesn't make sense for me to pay miners fees either, it's the receiver who cares about confirmations, not the sender. You care too: time and money, or just money if you want to use the old simplification. > So I wonder if a smarter design is that the user always submits the details of their instantness provider and we just don't allow for optional selection of instantness. I'm not sure that works, UX wise, so is having a less scalable design to support it worthwhile? We would not support that I think. Explicit is better than implicit. We will charge for instant confirmation and wouldn't want the user charged unless pre-agreed, especially if then they also have to wait because the instant tx was not recognized as such. Yeah we can charge the merchant that can then in turn charge you, we may as well charge you and be transparent about it but also have deals with merchant where they pay fixed amounts per month for unlimited tx and make it free for their users. Perhaps just like today people ask you which card you are going to use and they may not accept Amex or Diners the same will go for instant and they, the merchants, will just pick the instant provider from a touch screen before allowing the payment in. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:28 ` Lawrence Nahum @ 2014-06-16 15:43 ` Mike Hearn 2014-06-16 17:05 ` Lawrence Nahum 0 siblings, 1 reply; 47+ messages in thread From: Mike Hearn @ 2014-06-16 15:43 UTC (permalink / raw) To: Lawrence Nahum; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2168 bytes --] > > I don't see more than a bunch of accepted payment methods anywhere I > ever been in my life, I don't see merchants trusting more than a handful of > third parties. > Sure. I buy this. Although the credit card market is a great example of what we *don't* want: a stagnant duopoly of trusted third parties who rampantly abuse their position. So I'd hope we see either (a) nobody really caring about this BIP because Bitcoin gives good enough double spend protection or (b) lots of anti-double-spend providers (hundreds seems fine). > Ultimately you care because the alternative is to wait. > No, I will never wait. Neither me nor the merchant wants to me to be pointlessly hanging around for an hour. The alternative is to pay by credit card or cash. Outside of experiments there is no such thing as a shop that only accepts only Bitcoin and will require me to wait for a block because I didn't use a TTP to guarantee anti-double spends. So this seems like a fundamental problem to me: having the ability to say, "here is a proof I won't double spend" is fine, but it doesn't achieve anything if the merchant would have sold me the goods in return for a normal Bitcoin tx anyway, which in practice they always will because this system starts out from zero users and would have to work upwards. I *especially* will never use this system if I have to pay for it - I'd much rather just put my money into a wallet that can't generate these proofs and pay the sticker price. Maybe what this BIP needs is an extra field that lets the merchant say, I will give you a discount of X satoshis if you give me a no-double-spends proof. In other words invert it: the sticker price is what normal Bitcoin transactions cost, and then your wallet shows you the regular BIP70 price minus the discount plus the third parties fee as what you finally pay. I compare it to the sticker price the merchant is asking and if it's lower I'm happy, and if it's higher my wallet would automatically avoid using the TTP because I don't want to ever pay more, only less. The market would then figure out if the fees the TTP charges are worth the lower losses due to double spending fraud. [-- Attachment #2: Type: text/html, Size: 2744 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension 2014-06-16 15:43 ` Mike Hearn @ 2014-06-16 17:05 ` Lawrence Nahum 0 siblings, 0 replies; 47+ messages in thread From: Lawrence Nahum @ 2014-06-16 17:05 UTC (permalink / raw) To: bitcoin-development Mike Hearn <mike <at> plan99.net> writes: > Sure. I buy this. Although the credit card market is a great example of what we don't want: a stagnant duopoly of trusted third parties who rampantly abuse their position. So I'd hope we see either (a) nobody really caring about this BIP because Bitcoin gives good enough double spend protection or (b) lots of anti-double-spend providers (hundreds seems fine). Maybe hundreds, maybe less. I can imagine there would/could be local ones. It's not the same as credit cards though: it's an open protocol with explicit intent from all parties and no forced fees for normal transactions - just for instant ones. > No, I will never wait. Neither me nor the merchant wants to me to be pointlessly hanging around for an hour. The alternative is to pay by credit card or cash. Outside of experiments there is no such thing as a shop that only accepts only Bitcoin and will require me to wait for a block because I didn't use a TTP to guarantee anti-double spends. I tend to agree but _today_ people are trying to use bitcoin and are waiting and waiting .. > So this seems like a fundamental problem to me: having the ability to say, "here is a proof I won't double spend" is fine, but it doesn't achieve anything if the merchant would have sold me the goods in return for a normal Bitcoin tx anyway, which in practice they always will because this system starts out from zero users and would have to work upwards. I especially will never use this system if I have to pay for it - I'd much rather just put my money into a wallet that can't generate these proofs and pay the sticker price. This is a cultural thing. In some places if you pay by cards you pay extra. I think it may be good to support both models but I like better the transparent one even if I'm going to admit that the least transparent one may be more attractive as it fools consumers. > Maybe what this BIP needs is an extra field that lets the merchant say, I will give you a discount of X satoshis if you give me a no-double-spends proof. In other words invert it: the sticker price is what normal Bitcoin transactions cost, and then your wallet shows you the regular BIP70 price minus the discount plus the third parties fee as what you finally pay. I compare it to the sticker price the merchant is asking and if it's lower I'm happy, and if it's higher my wallet would automatically avoid using the TTP because I don't want to ever pay more, only less. > The market would then figure out if the fees the TTP charges are worth the lower losses due to double spending fraud. I think this is worth discussing further. Would love also more input from other people on this. ^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>]
* Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees [not found] <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net> @ 2014-06-17 20:40 ` Goss, Brian C., M.D. 2014-06-17 22:28 ` Mark Friedenbach 0 siblings, 1 reply; 47+ messages in thread From: Goss, Brian C., M.D. @ 2014-06-17 20:40 UTC (permalink / raw) To: <bitcoin-development@lists•sourceforge.net> Can two signed transactions using the same output as an input (ie, a double spend) be used to trigger a third transaction? It would be nice if I could sign a tx that would pay m bitcoins to an arbitrary address if and only if someone could present proof that I signed more than 1 transaction using the same output. Thus, a merchant could trust that I would not attempt a double spend for a purchase of n < m bitcoins. Can this type of transaction be expressed in Bitcoin's scripting language? Chaum had a similar feature in Digicash way back when...a double spend would let the second merchant compute the identity of the double spender and serve as proof of double spending. It didn't automate punishment though! My apologies if this has been discussed previously. ----------------------------- > > Message: 2 > Date: Mon, 16 Jun 2014 16:50:41 -0400 > From: Peter Todd <pete@petertodd•org> > Subject: Re: [Bitcoin-development] Fidelity bonds for decentralized > instant confirmation guarantees > To: Daniel Rice <drice@greenmangosystems•com> > Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>, Lawrence > Nahum <lawrence@greenaddress•it> > Message-ID: <20140616205041.GA21784@savin> > Content-Type: text/plain; charset="us-ascii" > >> On Mon, Jun 16, 2014 at 01:37:52PM -0700, Daniel Rice wrote: >> True, that would work, but still how are you going to bootstrap the trust? >> TREZOR is well known, but in a future where there could be 100 different >> companies trying to release a similar product to TREZOR it seems like one >> company could corner the market by being the only one that is an accepted >> instant provider at most vendors. It seems to encourage monopoly unless >> there is a standard way to bootstrap trust in your signature. > > You can always use fidelity bonds, or as I called it at the time(1), > "Trusted identities": > > Lets suppose Alice has some bitcoins held at bitcoin address A. She > wants to establish trust in the "identity" associated with the ECC > keypair associated with A, for instance for the purpose of having other > users trust her not to attempt to double spend. Since the trust she > seeks is financial in nature, she can do this by valuing the identity > associated with A, by delibrately throwing away resources. A simple way > to do this would of course be to transfer coins to a null address, > provably incurring a cost to her. > > A more socially responsible way would be for her to create a series of > transactions that happen to have large, and equal, transaction fees. > Bitcoin makes the assumption that no one entity controls more than 50% > of the network, so if she makes n of these transactions consecutively, > each spending m BTC to transaction fees, there is a high probability > that she has given up at least n/2 * m BTC of value. This of course is > all public knowledge, recorded in the block chain. It also increases the > transaction fees for miners, which will be very important for the > network in the future. > > Now Bob can easily examine the block chain, and upon verifying Alice's > trust purchase, can decide to accept a zero-confirmation transaction at > face value. If Alice breaks that promise, he simply publishes her signed > transaction proving that Alice is a fraudster, and future Bob's will > distrust Alice's trusted identity, thus destroying the value needed to > create it. > > In effect, we now have a distributed green address system. > > Note that the second paragraph is seriously obsolete - better to either > use announce-commit sacrifices, or much preferably, simple destruction > of coins. (sacrifice to fees encourages mining centralization for > obvious reasons) > > 1) "[Bitcoin-development] Trusted identities", Apr 26th 2012, Peter Todd, > http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg01005.html > > Incidentally, my first post to this mailing list! > > -- > 'peter'[:-1]@petertodd.org > 000000000000000058ca7ee3a40438ea5a96e499910638352468c6d69abdb226 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 685 bytes > Desc: Digital signature > > ------------------------------ > > > > End of Bitcoin-development Digest, Vol 37, Issue 27 > *************************************************** ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees 2014-06-17 20:40 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Goss, Brian C., M.D. @ 2014-06-17 22:28 ` Mark Friedenbach 0 siblings, 0 replies; 47+ messages in thread From: Mark Friedenbach @ 2014-06-17 22:28 UTC (permalink / raw) To: bitcoin-development Not with current script, but there are mechanisms by which you can do a digital signature where signing two pieces of information reveals the ECDSA k parameter, thereby allowing anyone to recover the private key and steal the coins. Practically speaking, these are not very safe systems to use. For example, imagine accidentally loading up the same wallet on two machines or the wallet software crashing after signing and sending the transaction, and the user recreates & sends on recovery. It also invalidates reasonably legitimate use cases for repeating addresses (in the absence of other solutions), and its not really possible to prevent people from sending multiple coins to the same address (which could then be stolen). On 06/17/2014 01:40 PM, Goss, Brian C., M.D. wrote: > Can two signed transactions using the same output as an input (ie, a > double spend) be used to trigger a third transaction? > > It would be nice if I could sign a tx that would pay m bitcoins to an > arbitrary address if and only if someone could present proof that I > signed more than 1 transaction using the same output. Thus, a > merchant could trust that I would not attempt a double spend for a > purchase of n < m bitcoins. > > Can this type of transaction be expressed in Bitcoin's scripting > language? > > Chaum had a similar feature in Digicash way back when...a double > spend would let the second merchant compute the identity of the > double spender and serve as proof of double spending. It didn't > automate punishment though! > > My apologies if this has been discussed previously. > ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2014-06-25 14:02 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-14 12:00 [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Lawrence Nahum
2014-06-14 12:57 ` Andreas Schildbach
2014-06-15 9:22 ` Lawrence Nahum
2014-06-15 12:46 ` Andreas Schildbach
2014-06-15 14:09 ` Lawrence Nahum
2014-06-18 12:09 ` Lawrence Nahum
2014-06-18 13:25 ` Mike Hearn
2014-06-18 15:59 ` Daniel Rice
2014-06-18 16:09 ` Mike Hearn
2014-06-19 17:36 ` Daniel Rice
2014-06-25 14:01 ` sebastien requiem
2014-06-16 12:19 ` Mike Hearn
2014-06-16 12:25 ` Mike Hearn
2014-06-16 15:09 ` Daniel Rice
2014-06-16 15:26 ` Lawrence Nahum
2014-06-16 16:00 ` Daniel Rice
2014-06-16 16:07 ` Mike Hearn
2014-06-16 15:41 ` Paul Goldstein
2014-06-16 15:48 ` Mike Hearn
2014-06-16 16:30 ` Lawrence Nahum
2014-06-16 16:45 ` Mike Hearn
2014-06-16 16:56 ` Lawrence Nahum
2014-06-16 17:01 ` Mike Hearn
2014-06-16 17:16 ` Lawrence Nahum
2014-06-16 18:02 ` Alex Kotenko
2014-06-16 18:09 ` Mike Hearn
2014-06-16 20:29 ` Daniel Rice
2014-06-16 20:32 ` Mike Hearn
2014-06-16 20:37 ` Daniel Rice
2014-06-16 20:46 ` Mike Hearn
2014-06-16 20:53 ` Daniel Rice
2014-06-16 20:55 ` Mike Hearn
2014-06-16 20:50 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Peter Todd
2014-06-16 21:02 ` [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension Daniel Rice
2014-06-16 20:32 ` Alex Kotenko
2014-06-16 17:44 ` Jorge Timón
2014-06-17 15:58 ` Isidor Zeuner
2014-06-18 1:39 ` Tom Harding
2014-06-17 15:58 ` Isidor Zeuner
2014-06-18 9:15 ` Mike Hearn
2014-06-18 20:47 ` Natanael
2014-06-18 2:01 ` Tom Harding
2014-06-16 15:28 ` Lawrence Nahum
2014-06-16 15:43 ` Mike Hearn
2014-06-16 17:05 ` Lawrence Nahum
[not found] <mailman.212267.1402952308.2171.bitcoin-development@lists.sourceforge.net>
2014-06-17 20:40 ` [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees Goss, Brian C., M.D.
2014-06-17 22:28 ` Mark Friedenbach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox