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
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;
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
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo
