Re: [Bitcoin-development] Instant / contactless payments

2014-03-10 Thread Alex Kotenko
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

2014-03-10 Thread Jean-Paul Kogelman

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

2014-03-10 Thread Alex Kotenko
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?

2014-03-10 Thread Drak
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?

2014-03-10 Thread Gavin Andresen
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?

2014-03-10 Thread Mike Hearn
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?

2014-03-10 Thread Jeff Garzik
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

2014-03-10 Thread Andreas Schildbach
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

2014-03-10 Thread Alex Kotenko
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?

2014-03-10 Thread Alan Reiner
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?

2014-03-10 Thread Jeff Garzik
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?

2014-03-10 Thread kjj
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?

2014-03-10 Thread Gavin Andresen
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