[Bitcoin-development] Payment protocol thoughts
I've been thinking about the requirements for a payment protocol
lately. It seems we have consensus that we need one of these. Pieter
has a gist on the topic here: https://gist.github.com/1237788
IMHO we'll want to move away from "send X BTC to address Y" and more
towards "upload to me transactions that send X BTC to outputs
A,BF,G". In this context by output I mean the obvious
interpretation of script+value.
The reasons are privacy and security. Privacy: you don't want people
to find out if you have an unexpectedly large balance (from the block
chain). Example worst case scenarios
- in a hypothetical Bitcoin-using country, as most people receive
income exactly once a month from their employer, you could potentially
find out other peoples salaries. Drama ensues.
- business partners could find out their counterparty has an
unexpectedly good financial position, messing up negotiations
Security:
- some of the outputs could be in a hot wallet, others in cold
wallets, helping you maintain correct balances between them in real
time
- the outputs can be multi-sig scripts
Wallets would then craft a series of transactions to try and somewhat
balance the size of inputs vs outputs. Because they are separate
transactions and all the keys are fresh, there's no way to link them
together into a single payment, especially not if they're broadcast in
random order with some jitter.
The upside of this is better privacy. The downside is obviously more
transactions and therefore more overhead. In theory the sum of tx
outputs would end up converging to a reasonable "coin size" for the
recipients, eg, businesses might be happy to receive a lot of money in
a single output, individuals less, children or very poor people maybe
much less.
Let's call payment requests invoices. Here is a brainstorm on other
features that may be desirable. I'm not suggesting they're all in v1,
just that we think about them a bit to ensure we don't paint ourselves
into a corner.
- Optional list of {signature, certificate} pairs. SSL certs can be
embedded into the payment request file itself so they can be checked
instantly for wallets that want to show a verified identity, but you
can also provide other certificates issued outside the regular SSL CA
system. For example maybe MtGox issues you a "trusted vendor"
certificate. Maybe the better business bureau issues you a cert, etc.
- Optional expiry time (from sipas gist) so outputs that were never
sent to can be recycled
- Upload target (URI), where to send the created transactions
- Optional message and branding image/icon that a wallet can display
to make the transaction history a bit prettier
- Opaque token that the wallet is supposed to copy into the payment.
The merchant can use to link invoice with payment. It's technically
redundant, the output set would identify the invoice too, as could a
token in the upload target URL, but it may be simpler for some
merchant implementations
- Ability to specify payment amount[s] in terms of other currencies.
If the amount is specified statically it can just be recorded in the
wallet for informational purposes. If there's a URL provided also, it
is an endpoint where quotes can be obtained. This allows merchants to
make long-lived invoices which are protected against FX volatility.
Downside: complicates wallets. Upsides: invoices can be kept around
for longer.
- Web/human-usable URL for the order so users can, eg, send messages
to the merchant specific to an order, post a review of the merchant,
etc
- Support for setting up 2-of-3 dispute mediation. Invoices should be
able to name a list of acceptable mediators and the wallet software
can intersect this with a list of mediators acceptable to the user, to
find one that works best. The whole mechanism by which merchants and
users agree on mediators isn't designed yet but we can at least think
about it now. It may be there's a simple design everyone agrees on
already.
- Support for requesting recurring payments. Eg, I should be able to
provide N sets of M outputs, one set for each payment with a payment
schedule. Wallets can then ensure they run at the appropriate times to
keep up the subscription.
- Suggested tip/service charge. Wallet would give a simple UI to
adjust this up/down by X percentage points
- Request to sign inputs with SIGHASH_ANYONECANPAY, allowing the
payment to be a pledge for an assurance contract
- Ability to specify minimum confirmation level of coins that will be
spent. Some merchants may be OK with you immediately re-spending
unconfirmed coins. Other merchants will care more and might want you
to take on the burden of getting your transactions into the chain.
On the payment upload side:
- An optional signature under a stable user key that lets users
optionally link their payments across merchants. In this way a user
can build cross-market reputation which may help them in future, by
relaxing confirmation requirements or reducing the chance of being
asked to enter di
Re: [Bitcoin-development] Payment protocol thoughts
I agree we need a payment protocol, but instead of thinking of all of the things we might possibly want I would like to solve a few boring problems that we have right now. Absolutely critical: + Bitcoin addresses by themselves are insecure against man-in-the-middle attacks. We need a payment protocol so if you get a donation link for "Bitcoin Foundation" in an email message and click on it you can be reasonably certain that your coins will actually go to the Foundation and not some hacker at your ISP that modified the email message. + After sending payment I should have a receipt that proves I followed the payee's instructions, so if the payee says they never received the funds I can prove that it wasn't my fault. + Protocol for gathering signatures from multiple devices (extension/variation of the basic payment protocol, I think). Not absolutely necessary, but I think v1 should have it anyway: + Where-to-send-refund information included with payments, so overpayments/refunds can be handled efficiently and displayed intelligently in the customer's wallet. Everything else I think can wait. -- -- Gavin Andresen -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
There are tons of scenarios, some discussed here on this list previously, which would benefit from out of band messages and notes. This is small, but an interesting tidbit from BTC Foundation payments; roughly 3-5% of our initial members double-spent. WOW, that's terrible. I presume that's because they use web wallets without double-click prevention. But, seriously! A tiny UI issue that's a big deal in an irrevocable payment system. On Tue, Oct 2, 2012 at 10:43 AM, Gavin Andresen wrote: > I agree we need a payment protocol, but instead of thinking of all of the > things we might possibly want I would like to solve a few boring problems > that we have right now. > > Absolutely critical: > > + Bitcoin addresses by themselves are insecure against man-in-the-middle > attacks. We need a payment protocol so if you get a donation link for > "Bitcoin Foundation" in an email message and click on it you can be > reasonably certain that your coins will actually go to the Foundation and > not some hacker at your ISP that modified the email message. > > I'm trying but can't think of a lightweight solution to this off the top of my head. Not that that proves much. > + After sending payment I should have a receipt that proves I followed the > payee's instructions, so if the payee says they never received the funds I > can prove that it wasn't my fault. > > + Protocol for gathering signatures from multiple devices > (extension/variation of the basic payment protocol, I think). > > With the foundation trying to operate without bank accounts, I think it comes into clarity for me just how innovative and incredibly awesome this would be for financial controls for companies. Imagine the bookkeeper inputting payments, and the owner (or 2 of 3 owners) approving them. I can even imagine large member groups having 2/3 or majority spend rules. When we talk about stuff like this, I come back around to thinking there should be many different GUIs -- this use case is more business-y, it's stuff like this that I always think about the bitcoin testing project helping provide -- a standard backend that a bookkeeping GUI could go on top of.. > Not absolutely necessary, but I think v1 should have it anyway: > > + Where-to-send-refund information included with payments, so > overpayments/refunds can be handled efficiently and displayed intelligently > in the customer's wallet. > > > Everything else I think can wait. > > -- > -- > Gavin Andresen > > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes wrote: > This is small, but an interesting tidbit from BTC Foundation payments; > roughly 3-5% of our initial members double-spent. WOW, that's terrible. To be specific, do you mean a) paid twice or b) sent BF coins, then sent the same coins elsewhere ? Double-spend is a specific technical term -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
I meant sent twice, a. No double-spends that I'm aware of. Sorry for the loose verbiage! Peter On Tue, Oct 2, 2012 at 11:07 AM, Jeff Garzik wrote: > On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes wrote: > > This is small, but an interesting tidbit from BTC Foundation payments; > > roughly 3-5% of our initial members double-spent. WOW, that's terrible. > > To be specific, do you mean > > a) paid twice > or > b) sent BF coins, then sent the same coins elsewhere > ? > > Double-spend is a specific technical term > > -- > Jeff Garzik > exMULTI, Inc. > jgar...@exmulti.com > -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
I think it's worth pondering the different things we may want in future, even if that future is quite far out, just to ensure we have a robust design that won't box us in later. Brainstorming feature ideas now doesn't commit anyone to implementing them, but it may help improve the final v1 design. > + Bitcoin addresses by themselves are insecure against man-in-the-middle > attacks. A simple way to solve this problem is just use the SSL identity of the server that is taking part in the protocol, but it's not much harder to embed a signature + cert chain into the invoice itself. And once you're doing that, allowing several different sigs/cert chains is pretty easy. It means you keep the design open to cases where SSL may not be appropriate. Eg, you could create invoices signed by your web-of-trust identity, or some non-SSL Bitcoin specific verification system. None of those things have to actually be implemented, but by considering them now we can make the protocol more future prooof. > + After sending payment I should have a receipt that proves I followed the > payee's instructions, so if the payee says they never received the funds I > can prove that it wasn't my fault. A signed invoice + the blockchain transactions does this, BUT with a major caveat: if you have not set up dispute mediation, there is nobody to prove faultlessness to. So I'm not sure this would be very useful. Supporting real dispute mediation seems more practical, but also more work. > + Protocol for gathering signatures from multiple devices > (extension/variation of the basic payment protocol, I think). This would be nice, I think invoices could be wrapped by another protocol that handles it. I'm not sure it needs to be a part of the core payment protocol. There are lots of different ways to implement this and I'm not sure there's agreement on what it should look like - somebody needs to build a "proprietary" implementation first. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment protocol thoughts
On Tue, Oct 2, 2012 at 6:44 PM, Mike Hearn wrote: > A simple way to solve this problem is just use the SSL identity of the > server that is taking part in the protocol, but it's not much harder SSL itself (as opposed to using the certs as you suggest) is not non-reputablable, so it's not enough for the below concerns > A signed invoice + the blockchain transactions does this, BUT with a > major caveat: if you have not set up dispute mediation, there is > nobody to prove faultlessness to. To their prospective customer base. "I can prove to the public that you ripped me off" is protective, even if there isn't formal direct remedy available. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Testing Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/10/2012 17:52, Peter Vessenes wrote: > I'm a big proponent of a testing project. I am very happy to hear this, however, your actual words are slightly evasive. I do not expect you to be up to speed on this. Gavin started a project called 'the bitcoin testing project' This project solicited donations, about 80 coins last time I checked. However these 80 odd coins were donated to 'the bitcoin testing project' This would seem to be an official bitcoin (both protocol and client) testing project. I signed up to work on this, and organise as much as i could of this. for various reasons I did not manage to do the testing I wanted to on 0.7 i over committed myself. Are the donations solicited for the 'bitcoin testing project) funds going to be given to 'the foundation'? Does the foundation support 'the bitcoin testing project'? does the foundation have any involvement with 'the bitcoin testing project'? > > I think if one could self organize that Gavin and team wanted to > bless we could put up some BTC as bounties or funding. We won't > have our heads around the foundation budget for a few more weeks, > but self-organization is often slower than budgeting. :) Im ready to go, more or less. Please check out the links in my previous emails. I have over 400 testcases (8 platforms * 50 release tests) - Also I am not sure what you mean by bless, I take it that is a euphemism for pay? I have tried my hardest to get bettermeans to work, but it doesnt. It does show quite a lot of work that I have done though. If you were to say to me, 'steve, by monday we need end to end, requirements based testing' It would be done. (I have already spent over 4 months on this) Leaderless leadership is something I am having a hard time with, bettermeans is excellent at this. But I have found very little in regards to voting and polling that integrates with the project in an effortless way like bettermeans. I understand that the budget from the foundation is something that needs to be worked on and organised. I offer my services in this area (qa only). I would be happy to submit my cv and refs for this, if required. I am now feeling frustrated and useless. has my last 4 months of work been for nothing? it feels like it. I know I bang on about processes but they are sorted, you can only attract talent like Arklan if he has a process to follow. i feel like a broken record. tl;dr version 1 - Will donations to the 'bitcoin testing project' as started by gavin going to be given to the foundation? 2 - Is the work bill hees and myself going to be binned? 3 - I feel like I have the knowledge and drive to push this, but I cant do it on my own. 4 - Is bill or I entitled to any of the cash raised for 'the bitcoin testing project' 5 - Do I have to join the foundation to have a say in how the project (testing) is done? 6 - sorry for being so mercenary, but am I going to receive any coin for work I have done? 7 - It really probably is the time for a bitcoin-test list to appear. Is there anything I can do to make this happen? > > This is just my opinion, but I would like very, very much to move > the current specification into unit tests so that anyone could > validate their alternate bitcoin implementation. This is a lot of > work, some of which has been done, much of which hasn't. have a look at the stuff in bettermeans. I personally think we can go a step further and publish guidelines (similar to RFC's and all the tests that we would do against a ref client) But I dont want to waste any more time on stuff that is going to be ignored, life is short. > > So, my two cents, plus an offer to bring it up at our next > budgeting meeting. I accept that offer. and I really appreciate it. I have some more questions I would like you to ask in regards to QA. (Gavin and I skyped about this a while ago and we didnt really come to a resolution, weworked out the problems though ;) ) I have an exceptionally detailed qa process (based off the game certification process) - but I have gone on about this at length in previous messages. I thank you for your email and your involvement with this, but do you think we are closer to getting stuff tested? call my bluff... Not one person has asked for login details to my proposals - and i even have a bugzilla version now. I need to sleep. sorry if i rambled. nite nite, steve > > Peter > > > On Mon, Oct 1, 2012 at 7:28 AM, steve wrote: > > On 01/10/2012 14:52, Arklan Uth Oslin wrote: Hi guys. So, as I mentioned on the bitcointalk.org forums thread about the foundation, I want to get involved in the QA side of bitcoin development. I've done functional testing in the video game industry for years. > > Nice one, I worked in games for quite a few years. (before getting > into finance then pentesting) there are about 6 keen testers now. > maybe we should get a bitcoin-test mailing list, where we can > discus
Re: [Bitcoin-development] Bitcoin Testing Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2012 03:02, Gregory Maxwell wrote: > On Tue, Oct 2, 2012 at 9:15 PM, steve wrote: >> Im ready to go, more or less. Please check out the links in my >> previous emails. I have over 400 testcases (8 platforms * 50 >> release tests) - Also I am not sure what you mean by bless, I >> take it that is a euphemism for pay? > > Perhaps a bit bluntly here— but since you seem to be rather boldly > insisting on getting paid: that is not what i was getting at, nor what i meant at all.I am sorry it came across this way. Im a bit drunk. (yeah that old excuse) I was only trying to make an example of the quandary that exists, in what happens to the current donations. There are far more deserving people who have a claim on that coin rather than I. I have stated on more than on occasion (written in public and verbal with gavin) that I would be willing to work for free. But I would love to be able to ditch the day job. (however i see that more as services than mining/testing) rereading what i wrote yeah, fair play i can see how you read my mail like that. it wasnt meant to :/ i feel a bit of a turnip. the tone is not what i meant. it does read pretty mercenary. > > With all of this testing where can I find the issues you've > uncovered? Searching on your name/email in the issue tracker > reports nothing, likewise I can't find anything in my email (beyond > abstract discussion of testing). > This is a different issue. But I see why you have raised it and I would like to address it. I personally believe you should earn bitcoins for writing testcases, executing testcases, passing or failing test cases. in that order (failing a testcase normally generates a new one therefore encouraging indepth and recorded testing.). QA should not be judged based solely on bug reports - this is unfair and will result in race to report bugs. I have worked on a few projects that have tried it. This is one reason we need workflow and testcase software, so we can measure and compensate people for their work. As I have stated in previous emails I should have, but for various excuses did not manage to run a single testcase for 0.7. but I did setup a frame work, and I know some people did do some good work on 0.7 I believe these people should be compensated from the (limited) funds the project received... something needs to happen with those coins. I am sorry you find my emails abstract (and therefore meaningless?) this is a really confusing time. i dont know if i am doing right from wrong. I am trying to lead, without leading... i have always preferred benevolent dictator. I know a number of bitcoin businesses that are really keen to work with the project, but I have no authority, noone seems to. Someone should be able to say, nice one, thanks for the vm's. maybe use $200 worth of coin to get a technet licence, that gives 10 installs of each ms OS. slipstreaming in the service packs means you can have whatever era pc you want (and the vps providers will allow various configuration of vm's...) then even if you do it by hand you can still do 6 or 7 at once... as for bug reports, give me 1 week from now (168hrs), lets see what i can do. (priority, protocol, daemon, qt ref?) but still process is more important... I still think that writing and doing testcases should get more coin than bug reports. but from what I have read, the big bounties will be paid by the foundation. im not sure if that is true or where i read it. (protocol level bugs) it feels like I am wasting peoples time,and I should get back in my box. so I will. contact me off list if you want to have a look at the various workflow stuff i have done. cheers, steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQa6pAAAoJEFvEB9dQFvtQ0H8H/jUjvzmsp61w1bmDnHR+KmF4 LNu7WwVLrTvrT8AHSNh3mClWvMM3muJJA7NMb2WthAgVe3jtrGimfreAlstDsObL XNEcGvU6WN1YosH0MkN7hyDl8jnrDFoiH1P5qsMecuZIxwq7Z0vCOHEJ9DPmZilW R+G8OmoGcpaeWs9VqXR6zR7Uyz69KaDAQpMRE1GTu3zQP9HSSolciy3ESeJRR9Sd yO7EcCGdQot80rOG/VIZ0wkOmzGGm1thzYzayD6Zn2eW4Hw+ME1en9ksIbXJFpSv IdgThEm7p5UuBo0jFkbX4Awrf9hfusZSEGWfhZqdASqqkSBnYqLmWF1sLprDRF8= =Iv87 -END PGP SIGNATURE- -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Testing Project
And, finally, when I say "Ditto to above" I mean "I have no idea", not "nope". Double oops. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
