Re: [Bitcoin-development] Instant / contactless payments
2014-03-08 8:52 GMT+00:00 Jan Vornberger j...@uos.de: On Thu, Mar 06, 2014 at 02:39:52PM +, Alex Kotenko wrote: Not sure if you've seen it, but here is how we do NFC right now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. Very interesting, thanks for sharing! Are the two devices on the same wifi network in the demo? In my experience transaction propagation through the Bitcoin network takes a couple of seconds longer on average, so I'm surprised it's that fast here. No, devices on this video are not on the same network, and even if they would - I cannot control what remote hosts my phone would connect to, so transaction may anyway travel around the globe before coming to the POS even if they would be on one LAN. As for transaction times - I'd say it varies. From my extensive testing most of transactions usually come through within 2-5 seconds, but roughly one in ten transactions may take more time, sometimes much more time. You probably share this view, but I just wanted to repeat, that from my experiments, I think that sending the transaction only over the Bitcoin network should be a rarely-used fallback. It usually takes a little longer than you would like for a POS solution and every so often you don't get the transaction at all until the next block. And then what do you do? Maybe you would need to ask the customer to pay again, to get things done now, and put the previous transaction in some kind of refund mode, where - when you finally get it - you send it back somewhere. But it's really a problematic corner case - but yet it will happen occasionally with network-only propagation. Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. In the context of this discussion, I would also like to share a video of a prototype system: https://www.youtube.com/watch?v=mguRpvf3aMc Here shown is the (currently no longer working) Bridgewalker client, but it is also fully compatible with Andreas' wallet. The client picks up the payment details via NFC (as a Bitcoin URI - could and should be updated to use payment protocol) and transmits a copy of the transaction via Bluetooth (using the simple convention first implemented by Andreas). One optimization I did in the Bridgewalker client is, that it already opens the Bluetooth connection when presenting the user with the confirmation dialog. This results in a little additional speed-up, as the connection is already warmed up, when the user confirms. All code of this prototype is open source, as is the Bridgewalker client. Yes, I've seen this demonstration, I think it was on reddit about two month ago. Looks interesting, but by that time most of my client software was already done, so I couldn't really use this. From my testing, I can say that NFC for getting the payment details + Bluetooth for transmitting the transaction back works well. I'm a bit skeptical about using NFC also for the back-channel, but maybe for cases where there is no additional user confirmation it could work. NFC as back channel definitely will not work . Mike proposed something like a threshold to define minimal amount available for spending without confirmation, but I don't see this thing becoming widely used any time soon, and before that we will need to have confirm button tap. One problem with Bluetooth I see is, that it seems to be mostly turned off by users and many seem to perceive it as insecure, to have it active, as a result of earlier Bluetooth hacks. So I'm not sure if that will turn out to be a problem for usability when rolled-out in practice. Yes, this is a problem, I think bluetooth is offline on many devices, and keeping it on all the time will harm security (if not real security, then at least perceived by users) and also harm battery life, which will be seen as huge problem by the users. Would be great to be able to control BT state automatically from within the wallet app with user permission given once on installation time, but not sure if it's possible in Android. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Just to add some more numbers, in Canada, the maximum is $50 and I've used it for transactions of $5, even less. I use it every day to pay for breakfast and it works through my wallet, even with multiple NFC enabled cards in there (though not overlapping). The experience is quite smooth; simply tap my wallet on the POS and a few seconds later it's approved. jp On Mar 10, 2014, at 9:04 AM, Mike Hearn m...@plan99.net wrote: I just did my first contactless nfc payment with a MasterCard. It worked very well and was quite delightful - definitely want to be doing more of these in future. A bit more competitive intelligence - turns out that the experience isn't quite so good after all. After trying a few more times to use contactless payments, I found it has a ~75% failure rate based on my usage. By far the biggest problem is also the most predictable - it's very common here for merchants to require minimum payment sizes before they'll accept credit cards, often quite high, like 20 CHF or more. But the PIN-less mode only works for payments below a certain threshold, I haven't quite figured out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF. So there turns out to be an incredibly thin price range in which the simple touch-to-pay system actually works. Most of the time, either they: a) Reject cards entirely because the payment is too small b) Don't have the right hardware, or the hardware just mysteriously fails to work. c) Require a PIN because the payment is too large I'm sure Bitcoin can do better than this. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
It heavily depends on where you use it. Here in UK any card payments are often limited to minimum of £5 in small shops that have heavy transaction fees burden and low margins. Big networks with more resources often let you pay as little as you want by card, and they more often have NFC enabled POS devices. So it's not an NFC or POS limit, but a business decision for these small merchants. Bitcoin can address this issue for sure, but this doesn't concern NFC. 2014-03-10 16:14 GMT+00:00 Jean-Paul Kogelman jeanpaulkogel...@me.com: Just to add some more numbers, in Canada, the maximum is $50 and I've used it for transactions of $5, even less. I use it every day to pay for breakfast and it works through my wallet, even with multiple NFC enabled cards in there (though not overlapping). The experience is quite smooth; simply tap my wallet on the POS and a few seconds later it's approved. jp On Mar 10, 2014, at 9:04 AM, Mike Hearn m...@plan99.net wrote: I just did my first contactless nfc payment with a MasterCard. It worked very well and was quite delightful - definitely want to be doing more of these in future. A bit more competitive intelligence - turns out that the experience isn't quite so good after all. After trying a few more times to use contactless payments, I found it has a ~75% failure rate based on my usage. By far the biggest problem is also the most predictable - it's very common here for merchants to require minimum payment sizes before they'll accept credit cards, often quite high, like 20 CHF or more. But the PIN-less mode only works for payments below a certain threshold, I haven't quite figured out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF. So there turns out to be an incredibly thin price range in which the simple touch-to-pay system actually works. Most of the time, either they: a) Reject cards entirely because the payment is too small b) Don't have the right hardware, or the hardware just mysteriously fails to work. c) Require a PIN because the payment is too large I'm sure Bitcoin can do better than this. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Multisign payment protocol?
I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
No, this doesn't make any sense. Multisig outputs are a tool you use to build helpful features, not a feature in and of themselves. By all means create a nice protocol, implementation and BIP for something like: - Creation of multi-user money pools for managing an organisations funds - Dispute mediated transactions - Watchdog services that provide a third party risk analysis of transactions - Micropayment channels (actually me and Matt already did this, sans BIP) but trying to do just multisig won't work well. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
Payment protocol currently supports payments to multi-sig addresses. In general, almost all wallet software sucks RE multisig. Just try any of these actions in Bitcoin-Qt or another wallet: * obtain a public key you control, given a bitcoin address * easily share public keys * easily share partially signed transactions * build a P2SH multisig address from public keys, reliably. Right now, participants have no idea about pubkey order, leading various N possible P2SH addresses, given a list of public keys. Reproducing the P2SH address is harder than it should be. * track partially controlled balance (balance of coins of which you may sign at least 1 of N) * support for remote oracles and services that provide 1-of-N signatures etc. On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
On 03/10/2014 04:09 PM, Alex Kotenko wrote: Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. Just a small clarification here. Bitcoin Wallet supports the customer side of the protocol since 2011, without any Labs enabling! This means you've got an install base of half a million devices that you can interoperate with. Sure, a lot of users will have Bluetooth switched off. The UI flow to enable it while paying is pretty smooth though. The merchant side used to have the Labs enabling but this is gone since a few weeks. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Instant / contactless payments
Ah, I see, so it's only payee who has to enable it, payer side is on by default. Then fine, situation is better than I thought. We'll look at implementing BIP70 asap. Best regards, Alex Kotenko 2014-03-10 19:28 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/10/2014 04:09 PM, Alex Kotenko wrote: Yes, I'm certain about that we need to switch to BIP70 asap. As I said earlier - support among the wallets is the biggest problem here really. Only Andreas' Wallet supports it right now AFAIK, and even in there it's only as LABS feature, so will be turned off for most of users. Just a small clarification here. Bitcoin Wallet supports the customer side of the protocol since 2011, without any Labs enabling! This means you've got an install base of half a million devices that you can interoperate with. Sure, a lot of users will have Bluetooth switched off. The UI flow to enable it while paying is pretty smooth though. The merchant side used to have the Labs enabling but this is gone since a few weeks. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
As far as I'm concerned, the way forward is to scrap BIP 10 and build up something new that is flexible and extensible. Also, my understanding is that there may be room in the payment protocol for this stuff though I'm not sure if it is really adapted well to all the steps: exchanging public keys, creating multi-sig/P2SH addresses, proposing multi-sig spends, bundling meta-data needed for lite/offline nodes, aggregating signatures, and any other details. When I start multisig integration into Armory (very soon!) I'll write a list of requirements for the new format/process and post it here for a wider discussion. Certainly, if the payment protocol can already handle all this, that would be awesome. -Alan On 03/10/2014 08:04 PM, kjj wrote: I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org mailto:d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig http://coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their
Re: [Bitcoin-development] Multisign payment protocol?
All of that only melds with the payment protocol under an extremely expansive definition of payment. The payment protocol is really geared towards a direct one-to-one relationship. We can make the payment protocol do all this, if you squeeze and push and try reall hard; it is mainly a question of protocol design and intended usage: is PP intended to be, ultimately, an expansive, universal protocol for gossiping with other parties about bitcoin transactions in a not-flood-fill manner? On Mon, Mar 10, 2014 at 8:09 PM, Alan Reiner etothe...@gmail.com wrote: As far as I'm concerned, the way forward is to scrap BIP 10 and build up something new that is flexible and extensible. Also, my understanding is that there may be room in the payment protocol for this stuff though I'm not sure if it is really adapted well to all the steps: exchanging public keys, creating multi-sig/P2SH addresses, proposing multi-sig spends, bundling meta-data needed for lite/offline nodes, aggregating signatures, and any other details. When I start multisig integration into Armory (very soon!) I'll write a list of requirements for the new format/process and post it here for a wider discussion. Certainly, if the payment protocol can already handle all this, that would be awesome. -Alan On 03/10/2014 08:04 PM, kjj wrote: I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list
Re: [Bitcoin-development] Multisign payment protocol?
I was trying to use bip10 for multisig and coinjoin, but there was a problem with it. I'll have to look back at my notes, but I thought I sent you a message about it. And then real life swallowed my bitcoin time... I think the bottom line was that it would be useful in the generic case with just one minor change. If there is interest, and it sounds like there just may be, I can dust off my notes and see where I left it. Probably should do it soon before someone implements it in PB or XML. Alan Reiner wrote: Then of course I tried to do this with BIP 10 https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the time. So I continue to use BIP 10 even though it's pretty crappy. I wanted it to be useful for multisig, too, but it has some deficiencies there (it was done when Armory was extremely young and OP_EVAL was still on the table). However, with all this activity, we should start thinking about that and discussing it. Otherwise, I'll just do my own thing again and probably end up with something that fits my own needs, but not anyone else's. Really though, multisig shouldn't require all the same app to work. -Alan On 03/10/2014 01:49 PM, Gavin Andresen wrote: In my experience, best process for standardizing something is: 1) Somebody has a great idea 2) They implement it 3) Everybody agrees, Great idea! and they copy it. 4) Idea gets refined by the people copying it. 5) It gets standardized. Mutisig wallets are at step 2 right now. BIP is step 5, in my humble opinion... On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org mailto:d...@zikula.org wrote: I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig http://coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list
Re: [Bitcoin-development] Multisign payment protocol?
Multisig is orthogonal to the payment protocol (but payment protocol is needed first). There need to be protocols for: a) Establishing multisig wallets of various sorts. See: https://moqups.com/gavinandresen/no8mzUDB/ https://moqups.com/gavinandresen/no8mzUDB/p:ab18547e0 ... etc. for a UI mock-up. There needs to be some protocol so all participants in a multisig wallet contribute keys (actually, we should just assume everybody uses BIP32 HD public keys so we get privacy from the start). Multi-person shared wallets, escrows, and wallet protection service wallets (which might be protected with two-factor authentication) are different use cases and probably use slightly different protocols (and will probably need different BIPs eventually). b) Gathering signatures for a multisig spend. Here is where the payment protocol is useful; the PaymentRequest message should be passed around so all participants know what is being paid for, and maybe a partially-signed Payment message is where the signatures are gathered (or maybe the signatures are sent separately and one of the participants creates and submits the Payment and gets the PaymentACK... to be designed). See: https://moqups.com/gavinandresen/no8mzUDB/p:a7e81be96 https://moqups.com/gavinandresen/no8mzUDB/p:af7339204 ... for UI mock-up for the multi-person-spend case. And maybe a protocol for I don't want to be part of this multisig any more / I lost control of my private key don't trust me in this multisig any more. On Mon, Mar 10, 2014 at 8:14 PM, Jeff Garzik jgar...@bitpay.com wrote: All of that only melds with the payment protocol under an extremely expansive definition of payment. The payment protocol is really geared towards a direct one-to-one relationship -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
