Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2014-09-17 Thread Vezalke
Alan Reiner  gmail.com> writes:

> 
> 
> 
> On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen 
gmail.com> wrote:When I say "pass around" I'm not thinking of users copying
and pasting, that would be a terrible user experience; all of that
communication needs to happen automatically behind the scenes. Lets tackle
that after we've got the simpler customer-pays-merchant flow working nicely
(funded-escrow-pays-merchant is a subset of that, anyway).
> 
> 
> 
> 
> I think that the "pass around" method needs to happen in addition to the
methods of transparent protocols that occur behind the scenes.  For one,
there's a lot of CONOPs that need to be worked out by getting knowledgeable
people using it, and providing feedback about how it could/should/will be
used and how it could be improved.  The pass-around method is simpler to
implement and still usable by the types of users that will be using it in
the beginning -- experts.  Also, I see that for very large, important
multi-sig tx/contracts/escrow, the "manual" method might be preferred --
much the same way many people prefer manual-transmission cars even though
automatics are "easier" -- some people/organizations will want the control.   
> 
> I'm all for protocols that enable higher-level access to this
functionality, I'm just saying there should be lower-level access, too.
> 
> 
> 
> 
> 
> 
> 
> 
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development  lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
Another online space wagering stage has been propelled and targets Bitcoin,
Litecoin and Dogecoin fans from everywhere throughout the world. 

Presented in August, Crypto-Games.net is a straightforward space machine
diversion that might be immediately played in any web program with the
utilization of cryptocurrencies, making it one of the first few wagering
destinations that are intended for Slot machine betting. 

As indicated by its site, it emphasizes a four-reel space machine with one
pay line that acknowledges wagers measuring from 50 Credits to a greatest of
9,999 Credits, where playing with most extreme wager yields a gigantic big
stake of 4,999,500 Credits. 

Then, the store exchange routines for this opening machine amusement have
been created to be productive with the stores taking online 2 to 10 minutes
to be transformed and the withdrawals just 6 to 60 minutes without any
transaction charges. Moreover, a QR code has as of now been added to suit
versatile bettors utilizing their cell phones and tablets. 

Also, the administrators have taken the additional mile to guarantee
reasonableness by depending on the random.org API to deliver genuine
arbitrariness that supplements the diversion's reasonable calculation. 

The https://www.crypto-games.net opening diversion, on the other hand,
cautions players to observe their remarkable ID number to abstain from
losing access to their account. This is essential on the grounds that
Crypto-Games does not oblige any type of record enlistment; rather, it
composes into cookies, which are erased following 14 days. 

Besides, it has taken off new extra arrangements for Crypto bettors aside
from the 25% house edge that are up for gets through the referral system.





--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-23 Thread Elden Tyrell
On 2012-12-21 17:05:21 +, Stephen Pair said:
> Also, identity is one thing, an elaborate trust based identity 
> verification system (like CA's) is a whole other thing.

Your distinction between "identity" and "trust-based identity" is one 
of the most important insights to emerge from this thread.  Thank you 
for pointing this out.

> the first task at hand is to implement secure, private messaging... 
> it's easy to do and you don't need to solve the PKI problem.



--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-22 Thread Mark Friedenbach
I hope that this input does not come too late; I haven't had time to review
the proposal until now.

For alt-chains that have time-varying value (Freicoin[1], currently), it is
necessary in some applications to include a "reference height" in the
invoice. Since the bitcoin protocol does not assume a universally
agreed-upon time source, Freicoin (and presumably other
yet-to-be-implemented time-varying chains) uses blocktime as the clock for
time-value calculations: outputs lose 2**-20 of their value with each
passing block. The reference height for an invoice is the blocktime at
which amount values are specified and the reference point for time-varying
calculations. As a concrete example, an invoice for payment of 50 frc today
could be satisfied by 49.99313402 frc tomorrow.

To implement this, we would require an optional "uint64 refheight" field in
the invoice structure. "refheight" or "nRefHeight" is what we call this
value internally, but "blocktime" or "blockheight" would work as well.

Github is currently down, so I apologize if a suitable field has already
been added.

Cheers,
Mark Friedenbach

[1] http://freico.in/ "Freicoin: a P2P digital currency delivering freedom
from usury."


On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen wrote:

> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
>
> Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
> suggestions and brainstorming.
>
> This document is online at https://gist.github.com/4120476
>
> If you respond to this message, please be considerate of people who
> subscribe to the digest version of this mailing list and trim your
> response.
>
>
> Invoices, Payments and Receipts for Bitcoin Transactions
> 
>
> This document proposes protocol buffer-based formats for signed,
> authenticated "invoices" and "receipts" -- requests for payment, and
> proof-of-payment.
>
> Separate documents propose an extension to the Bitcoin URI syntax and
> new MIME types to support them.
>
> Motivation
> ==
>
> The idea of a "payment protocol" to improve on Bitcoin addresses has
> been around for over a year. Users have been asking for some features
> in this proposal (like the ability to provide a refund address so
> overpayments or refunds can be returned to customers without the need
> to ask them for their address) for two or three years, and have
> started to work around shortcomings in the Bitcoin payment process
> with creative (but inefficient) uses of transactions.
>
> The key features of this proposal are:
>
> + Requests for payment (Invoices) are tied to authenticated identities
> using the only widely-deployed identity authentication system we have
> right now (X.509 certificates signed by root certificate authorities)
> + Invoices include a user-friendly description of what the payment is for
> + Payments include where refunds should be sent
> + At the end of the payment process, the customer holds a
> cryptographically signed Receipt that can be used as proof-of-payment
> if there is any dispute with the merchant.
>
>
> Specification
> =
>
> Invoice/SignedInvoice
> -
>
> An Invoice is a request for payment from a merchant to a customer:
>
> ::
>
> message Output {
> optional uint64 amount = 1;
> required bytes script = 2;
> }
>
> amount: Number of satoshis (0.0001 BTC) to be paid. If not given
> or zero, then the customer will be asked how much to pay.
>
> script: a "TxOut" script to which the customer should direct payment.
> This will normally be one of the standard Bitcoin transaction script
> (e.g. pubkey OP_CHECKSIG).
>
> ::
>
> message Invoice {
> repeated bytes x509chain = 1;
> repeated Output outputs = 2;
> required uint64 time = 3;
> optional uint64 expires = 4;
> optional bool single_use = 5 [default = true];
> optional string memo = 6;
> optional string receiptURI = 7;
> optional bytes merchant_data = 8;
> }
>
> outputs: one or more outputs where Bitcoins are to be sent.
>
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
>
> time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was
> created.
>
> expires: Unix timestamp after which the Invoice should be considered
> invalid. If not given, the Invoice may be re-used until the earliest
> certificate expiration date in the X509chain.
>
> single_use: If true, this Invoice should be used for only one payment.
> If false, it may be added to the user's address book and used
> repeatedly until it expires (e.g. for donations or a recurring
> payment).
>
> memo: UTF-

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-21 Thread Stephen Pair
The more I think about this topic, the more I think the first task at hand
is to implement secure, private messaging...the nature of any messages
(payment requests or otherwise) sent between wallets is such that it needs
to be secured.  And the great thing is that it's easy to do and you don't
need to solve the PKI problem.  Have the wallet maintain one or more ECC
key pairs for the purposes of signing and encrypting messages.  Allow these
to be shared between wallets, or exported/imported, etc.  You can punt on
the whole topic of verifying the others' public keys using PKI (I mean,
people use bitcoin addresses today without the use of any formal or
explicit PKI to verify them...people will make do without it for
communications keys just fine...and they can always use PGP or other PKI if
they feel the need...most people would just pick up the phone to verify a
friend's public key)...this also doesn't preclude the use of X.509 for the
merchant/customer scenario...

For a payment protocol, you could do something like this: use https & ssl
certificates/CAs as one method of obtaining an ECC public key...pki_type
could be "https" and pki_bytes could be a url for the https location to
download the ECC public key.  The software would reject (or warn) if the
SSL certificate isn't considered valid by the normal CA validation process.
 The wallet would not necessarily need to permanently store ECC public keys
obtained in this manner.  This approach doesn't require people to obtain
new certificates just for bitcoin.

In fact, there would be very little difference to the proposed payments
protocol if this approach were taken...instead of using X.509 directly for
signing and encrypting messages, you are using it for signing and
encrypting the ECC public key exchange.  And this allows people that don't
have web servers or SSL certificates to exchange their ECC public keys by
other means and be able to use this payment protocol as well as any others
that one could imagine.  So, I actually think this is a better way of
keeping PKI out of the scope of the proposal.

Payment requests are just one kind of messaging between wallets.  I've also
mentioned the "cheques" feature.  I'm sure there are many more
possibilities.  Having a uniform method of securing messages sent between
wallets (that doesn't depend on external tools) would be a great step
forward IMO.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-20 Thread Stephen Pair
On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn  wrote:

> > you may find yourself in a situation needing to parse a protobuf
> > message in a web browser
> Nothing stops you converting them into whatever form you want on the
> server side. If you don't care about the signature checking then it's
> no problem to use a server. If you do then you'd need to ship all the
> code for verifying signatures that to the client anyway, at which
> point a small protobuf parser is hardly a deal killer.


No, it's not a killer...just a hassle.  JSON is convenient and ubiquitous
and there is something to be said for that (and I wanted to point out that
the JOSE objection was invalid).  Protobufs are nice and efficient, but who
cares.  You're talking about direct communications rather than something
that will be bounced around every node in the mesh network.  I don't really
care much either way, it's not worth debating.  I'm just thankful no one is
arguing for XML or IIOP.  :)

> ...like what about the casual user that wants to create a payment request
> to
> > send to their friend over email
>
> They can send an unsigned payment request. Note that if you mail it as
> an attachment from a competent, up to date email provider then the
> attachment isn't really unsigned. The whole thing is covered by the
> emails DKIM signature which is applied transparently by the ESP. If
> the signature fails to verify then the mail client can show that or
> treat the mail differently (as Gmail does). This is easy to use for
> the end user - they don't have to think about cryptography or PKI. As
> long as their email account is secure then they can send signed mails
> asserting to their identity.
>

This leaves too much to chance for my taste.  Forget email, what about
jabber, ICQ, skype, IRC?  Email is just one communications medium, there
are many others for which there would be no assurance that the payment
request hasn't been tampered with.  You could at a minimum allow a person
to create a normal ECC key, but have it used as an identity in
communications rather than a payment address.  You store it in a separate
file in ~/.bitcoin/id  ...you don't have to solve the whole set of PKI
problems, people could exchange identities using any secure channel they
are comfortable with (email + phone verification of a short hash id would
be sufficient).  In another scenario, an id could be made available over
https, using the normal SSL certificate and CA infrastructure to verify
authenticity.  This way all messages could be signed and/or encrypted
without the user having to go out of their way to use external tools or
infrastructure that is often not very user friendly.  You also need
encryption for the "cheque" feature...asking people to use GPG would be too
much of a burden (and email DKIM doesn't offer encryption).

>>> wandering off topic >>>
Indeed, "cheques" could become the dominant method of person to person
payments...first, you would obtain someone's id, which you might already
have on file (rather than obtaining a bitcoin address), then you would
generate a "cheque" for the amount desired and send it to them...the
recipient then has full control over what address they want to sweep the
funds to as well as whether they'd like to include a miner fee to speed the
confirmation along. Despite the fact that you may send many payments to the
same identity, the only thing showing up on the p2p network and the block
chain is the one time use address for the cheque and the recipient's wallet
address.  This means the recipient has much more control over the address
policy used (compared with simply giving out a bitcoin address that may be
reused).
<<<

> Refund addresses...this is not going to be as useful as people might
> > think...most refunds that bitpay needs to process happen days or even
> months
> > after the initial purchase
>
> Useful feedback, thanks. Still, there may be other types of merchants
> for whom it's useful, and many users won't change their wallet. It
> certainly simplifies things if you can present the refund address and
> give a one-click option to use it. If the user wants to use a
> different address, then they can go onto the slow/complicated path.
>
> This current spec deliberately punts on the topic of identifying end
> users. It's a difficult problem.
>

I know, but as I was responding, I began to realize this is a mistake.
 It's worthwhile to tackle that problem first...if done right, it would pay
huge dividends.  Also, identity is one thing, an elaborate trust based
identity verification system (like CA's) is a whole other thing.  I think
the former is pretty simple actually...and it's all that's really needed
for the time being (as I alluded, a bitcoin identity could be communicated
or verified using the existing X.509/CA infrastructure if desired...you
could also use the PGP infrastructure).


> > I like the use of merchant_data...this means that you no longer will
> need a
> > unique bitcoin address for every in

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-20 Thread Mike Hearn
Thanks for the thoughts. For those who don't know, Stephen works for BitPay.

> My first observation is that the proposal is too heavily oriented around a
> merchant/customer interaction.

The term "merchant" is just being used to mean the entity requesting
the payment. I'm hopeful that in future mobile wallets will be
creating these messages where today they'd make URLs and QRcodes. So
it's definitely intended for person to person payments too.

> you may find yourself in a situation needing to parse a protobuf
> message in a web browser

Nothing stops you converting them into whatever form you want on the
server side. If you don't care about the signature checking then it's
no problem to use a server. If you do then you'd need to ship all the
code for verifying signatures that to the client anyway, at which
point a small protobuf parser is hardly a deal killer.

> ...like what about the casual user that wants to create a payment request to
> send to their friend over email

They can send an unsigned payment request. Note that if you mail it as
an attachment from a competent, up to date email provider then the
attachment isn't really unsigned. The whole thing is covered by the
emails DKIM signature which is applied transparently by the ESP. If
the signature fails to verify then the mail client can show that or
treat the mail differently (as Gmail does). This is easy to use for
the end user - they don't have to think about cryptography or PKI. As
long as their email account is secure then they can send signed mails
asserting to their identity.

> Refund addresses...this is not going to be as useful as people might
> think...most refunds that bitpay needs to process happen days or even months
> after the initial purchase

Useful feedback, thanks. Still, there may be other types of merchants
for whom it's useful, and many users won't change their wallet. It
certainly simplifies things if you can present the refund address and
give a one-click option to use it. If the user wants to use a
different address, then they can go onto the slow/complicated path.

This current spec deliberately punts on the topic of identifying end
users. It's a difficult problem. Whereas many merchants have SSL
certs, most end users don't have published keys in any useful form. By
far the easiest way for 99% of people to generate a signed message is
to send email that's signed by DKIM (from gmail, hotmail, yahoo, other
providers etc). Then it's all transparent and behind the scenes. Their
identity is their email address.

So for BitPays scenario, you could require an email to be sent by the
end user containing new instructions. Your MTA can show you whether
the mail is correctly DKIM signed or not when deciding whether to
follow the instructions.

> But, if the recipient never cashes the check, the sender could pull those
> funds back after a certain period of time.

Yeah, I like the term "check"/"cheque" for that concept of a reversible payment.

> I like the use of merchant_data...this means that you no longer will need a
> unique bitcoin address for every invoice.

It's still a good idea to use one for privacy reasons. The merchant
data is there so you can stuff whatever state you want into it. So
it's like cookies. You don't have to keep state on the server side.
Just encrypt/sign it, put it in the invoice, and when you get a
payment message back there's no need to do database lookups or
anything, you can just do some crypto and know who is submitting it.

> Generally speaking, I'm not a fan of embedding things like that

What's wrong with it? Isn't your proposal more complex? I don't see
why it's better than just embedding it.

> The Receipt should be signed...it could be used as proof of payment by
> wallets.

There's no Receipt message, a SignedPaymentRequest + transactions that
pay to the requested outputs are together the proof of payment.

Re a new URI scheme. Interesting idea, thanks for the suggestion. It
seemed like it'd be easier for merchants to integrate if a single
linked worked for all wallet implementations/versions. But I guess we
could do both schemes, even.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-20 Thread Stephen Pair
Here are my (mostly half baked) thoughts on the payments protocol proposal.

My first observation is that the proposal is too heavily oriented around a
merchant/customer interaction.  I think it's equally important to consider
the person to person scenarios.  It would be very cool if people could
send/receive payments by copying and pasting stuff on facebook or email
(you can kind of do it now, but it's not safe unless you go to
extraordinary lengths using PGP signatures and the like).

Protobufs vs JSON: Protobufs are fine, although I will mention that the
serialization/JOSE arguments are irrelevant...you only need that if you
need a reliable way of signing an in memory object structure...in this case
you would be signing a serialized form of the object...the recipient
doesn't have to be able to reproduce the serialized form, they only need to
verify the signature on the already serialized bytes...I see protobufs as a
good serialization format for storage, while JSON being more practical for
communications in a web oriented environment...with protobufs & a web
wallet, you may find yourself in a situation needing to parse a protobuf
message in a web browser...the protobuf parsing and serializing code is
just going to add bloat to the web page...personally, I probably would have
gone with JSON, but hey, I'm not writing the code.

X.509 - nasty, but maybe ok ...as long as you can add root CAs to your
Bitcoin client or explicitly trust a certificate, I don't see that it poses
any privacy issues...but there are some other things to think about here
...like what about the casual user that wants to create a payment request
to send to their friend over email (wrapped in a clear text block similar
to PGP...it could also be sent as a file attachment)?  Are you now
requiring them to go and setup a certificate?  Btw, I really like the use
of a payment request in this manner because you have a signed payment
request that can be verified against an address book of known identities.
 This could be much safer than simply emailing an unsigned bitcoin address
around.

Refund addresses...this is not going to be as useful as people might
think...most refunds that bitpay needs to process happen days or even
months after the initial purchase...in that span of time, people can change
wallets, rendering such a refund address useless...so, as I think about the
situation, we would still need to contact the buyer to confirm a refund
address anyway.  What we really need is to verify the identity of the
person we're potentially sending the refund to...we need a way of
determining that the person we're sending the refund to is the same person
that paid the original invoice.  Bitcoin addresses are identities, but they
are too low level.  HD wallets come to mind...the top level or intermediate
levels of a deterministic hierarchy could be used for identity
purposes...but it also seems like it might be conflating payments and
identity (which for many reasons you might want to keep separate).  What if
bitcoin clients could manage one or more identities used for the purpose of
communications?  You could have a bitcoin identity file that could be used
by multiple wallets.  These identities would be used for signing messages
and verifying the authenticity of communications...when sending a payment,
instead of a refund address, you would include one of these identities
which could later be used to confirm a refund address.  In fact, the refund
would be processed by the buyer generating another payment request message
signed by the identity used in the original payment.

People would understand that their identities are important for
communications and they would keep those even when changing to new wallets
and such (identities could be stored in ~/.bitcoin/id or something
(encrypted of course)).

There are some other interesting possibilities if messaging and identities
are done right...for example, I could add "check" feature (analogous to
paper checks).  It would work like this...you create a transaction that
spends to a newly generated address...you put that transaction, along with
the private key into an encrypted container (sent to the identity of the
person you want to pay).  The recipient can open it and their wallet would
go ahead and generate and broadcast a transaction moving the funds into
their wallet (optionally including a fee).  But, if the recipient never
cashes the check, the sender could pull those funds back after a certain
period of time.  This also eliminates the possibility of accidentally
sending the funds to the wrong address (or an old address) and the bitcoins
being forever lost...the recipient can sweep the transaction into any
wallet of their choice.

As I'm writing this, I'm beginning to wonder if the identity management
problem is unavoidable.  Maybe that needs to be dealt with first.  It would
enable so many other interesting possibilities.

I like the use of merchant_data...this means that you no longer will nee

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-17 Thread Gavin Andresen
On Mon, Dec 17, 2012 at 6:23 AM, Melvin Carvalho
wrote:

> If the decision has already been made, then let's go with that
>
>
The decision has already been made.

-- 
--
Gavin Andresen
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-17 Thread Melvin Carvalho
On 17 December 2012 10:19, Mike Hearn  wrote:

> Can we please drop the binary vs text issue? We have been around it
> millions of times already. There are no compelling arguments to use
> text here and several obvious problems with it. If you think you've
> found a good argument to use JSON, please research protocol buffers
> more thoroughly and see if it changes your mind.
>

Hi Mike, thanks you for the pointer.  I have read up on Protocol Buffers.

If the decision has already been made, then let's go with that, but if not
perhaps I can offer some comments.

Looking at:

http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

And -- "Canonically, Protocol Buffers are serialized into a binary wire
format which is compact, forwards-compatible, backwards-compatible, but not
self-describing"

I can see there are advantages in this approach in that you can send
messages quickly and with low bandwidth.  However the non self describing
data means that it's significantly harder to convert from one format to
another.  Also references are important, and can be achieved in JSON.

Yet in my opinion there is great advantage to growing the bitcoin ecosystem
to interoperate with the whole net, kind of creating a complete web
economy.  The way to do this is to foster interoperability.  Having looked
at and worked with standards for the past 5-10 years that is the great
challenge.  Every system works in an island, and few talk to any others.
However, a market based economy grows exponentially more valuable with
extra liquidity.

Inventing yet another format may lead to balkanization.  If history is a
judge, the chances are high.  A self describing JSON format, however is
much more likely to interop.

I can understand the hesitation with JOSE.  However, if you get a moment,
please look at :

http://payswarm.com/specs/source/web-keys/

This should provide some of the tools that you need.

As I said above, if the matter is closed, that's fine and thanks for taking
the time to read.

Can I at least propose to make it mandatory for the binary format to have a
translation script to a self describing JSON format and back again.  I
would love to see the bitcoin ecosystem become a major part of the
infrastructure of the web itself (leading to even nice things like a proper
web of trust), as well as an awesome P2P system in its own right.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-17 Thread Gary Rowe
I've been following this thread closely, and Mike is correct here -
protocol buffers is definitely the way to go.


On 17 December 2012 09:19, Mike Hearn  wrote:

> Can we please drop the binary vs text issue? We have been around it
> millions of times already. There are no compelling arguments to use
> text here and several obvious problems with it. If you think you've
> found a good argument to use JSON, please research protocol buffers
> more thoroughly and see if it changes your mind.
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-17 Thread Mike Hearn
Can we please drop the binary vs text issue? We have been around it
millions of times already. There are no compelling arguments to use
text here and several obvious problems with it. If you think you've
found a good argument to use JSON, please research protocol buffers
more thoroughly and see if it changes your mind.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-17 Thread Melvin Carvalho
On 17 December 2012 03:18, Jeff Garzik  wrote:

> On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
>  wrote:
> > On 3 December 2012 20:35, Mike Koss  wrote:
> >> It would also be really nice to migrate to textual representations of
> data
> >> structures as opposed to binary ones.  The most successful internet
> >> standards are based on text, making them that much more accessible for
> >> developers to deal with them.   JSON would be my preferred candidate.
> >>
> >> Why don't we sign the text representation of a (utf8) JSON, rather than
> >> some complex encoding standard of JSON?  That way the signatures are
> simple
> >> - and you need only retain the original textual representation of a
> message
> >> to validate the signature (as well as the decoded version, if you don't
> want
> >> to alway re-parse the message when writing programs that use it).
>
> > Binary formats can be challenging to deal with and convert to other
> formats.
> > The experiences in the PKI world of ASN.1 have not been great, in terms
> of
> > interop.  It tends to create islands and silos.  This is probably one of
> the
> > reasons why X.509 and GPG are fragmented and why we dont really have a
> > widely deployed web of trust on the net.  Another reason is simply lack
> of
> > developer resources to make tools.  In that respect I think JSON offers
> > significant advantages, though I am interested in the security issues
> > raised.
>
> I thought this had already been covered up-thread?
>
> When creating something that must be hashed and/or compared, the data
> structure must be created and reproduced precisely, byte-for-byte.
> JSON offers significant -disadvantages- in this regard.  With JSON,
> you would therefore require an additional middle layer, between JSON
> and application, ensuring that all fields are output in the same
> order, all whitespace is not only perfectly preserved -- but reliably
> generates identical whitespace output for identical inputs, given two
> separate JSON implementations.
>

Apologies if I am a bit late to the thread.  I bumped into someone that
suggested I take a look at it.  Will try and catch up!

You raise a good point.

Is there no good canonicalization algorithm / library for JSON?

I think that provided that each JSON object has an identifier,
canonicalization of JSON is not that hard.

Then when you hash or sign the canonical form they can be compared reliably.


>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgar...@exmulti.com
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-16 Thread Jeff Garzik
On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho
 wrote:
> On 3 December 2012 20:35, Mike Koss  wrote:
>> It would also be really nice to migrate to textual representations of data
>> structures as opposed to binary ones.  The most successful internet
>> standards are based on text, making them that much more accessible for
>> developers to deal with them.   JSON would be my preferred candidate.
>>
>> Why don't we sign the text representation of a (utf8) JSON, rather than
>> some complex encoding standard of JSON?  That way the signatures are simple
>> - and you need only retain the original textual representation of a message
>> to validate the signature (as well as the decoded version, if you don't want
>> to alway re-parse the message when writing programs that use it).

> Binary formats can be challenging to deal with and convert to other formats.
> The experiences in the PKI world of ASN.1 have not been great, in terms of
> interop.  It tends to create islands and silos.  This is probably one of the
> reasons why X.509 and GPG are fragmented and why we dont really have a
> widely deployed web of trust on the net.  Another reason is simply lack of
> developer resources to make tools.  In that respect I think JSON offers
> significant advantages, though I am interested in the security issues
> raised.

I thought this had already been covered up-thread?

When creating something that must be hashed and/or compared, the data
structure must be created and reproduced precisely, byte-for-byte.
JSON offers significant -disadvantages- in this regard.  With JSON,
you would therefore require an additional middle layer, between JSON
and application, ensuring that all fields are output in the same
order, all whitespace is not only perfectly preserved -- but reliably
generates identical whitespace output for identical inputs, given two
separate JSON implementations.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-16 Thread Melvin Carvalho
On 3 December 2012 20:35, Mike Koss  wrote:

> The thing that bugged me most about the original spec was the sole
> reliance on X.509 - glad to see you've made that optional.  I think many
> people will balk at deferring our identity trust to the existing CA's.  I
> think it's a fine bootstrap method, but I'd really like to see another
> option that allows for out-of-band trust (based on ECDSA, probably).
>
> It would also be really nice to migrate to textual representations of data
> structures as opposed to binary ones.  The most successful internet
> standards are based on text, making them that much more accessible for
> developers to deal with them.   JSON would be my preferred candidate.
>
> Why don't we sign the text representation of a (utf8) JSON, rather than
> some complex encoding standard of JSON?  That way the signatures are simple
> - and you need only retain the original textual representation of a message
> to validate the signature (as well as the decoded version, if you don't
> want to alway re-parse the message when writing programs that use it).
>

Binary formats can be challenging to deal with and convert to other
formats.  The experiences in the PKI world of ASN.1 have not been great, in
terms of interop.  It tends to create islands and silos.  This is probably
one of the reasons why X.509 and GPG are fragmented and why we dont really
have a widely deployed web of trust on the net.  Another reason is simply
lack of developer resources to make tools.  In that respect I think JSON
offers significant advantages, though I am interested in the security
issues raised.


>
> On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen 
> wrote:
>
>> Spec updated: https://gist.github.com/4120476
>>
>> Changes are:
>>
>> Version numbers:  a couple of people asked privately about adding
>> version numbers to the messages. In general, Protocol Buffers don't
>> need version numbers if later versions add only optional fields.
>>
>> And best-practice is to know what version of something you're
>> expecting BEFORE you start parsing that something.
>>
>> So, if a bitcoin client is getting Invoice messages via email or from
>> a web server, the version will be specified as part of the MIME type;
>> for example:
>>Content-Type: application/x-bitcoin-invoice; version=1
>> The version= syntax is part of the MIME standard.
>>
>> Following that best-practice of knowing what you're parsing before you
>> parse it, I added an invoice_version field to the SignedInvoice
>> message. It is now:
>>
>> message SignedInvoice {
>> required bytes pki_data = 1;
>> required string pki_type = 2 [default = "x509"];
>> required bytes serialized_invoice = 3;
>> required uint32 invoice_version = 4 [default = 1];
>> required bytes signature = 5;
>> }
>>
>>
>> Handling of receiptURI errors:
>>
>> Following discussion here, I changed the spec to say:
>>
>> "Clients may handle errors communicating with the receiptURI server
>> however they like, but should assume that if they cannot communicate
>> at all with the server then the Payment should either be retried later
>> or immediately rejected."
>>
>> and under Receipt added:
>>
>> "The Bitcoin client must be prepared to handle the case of an evil
>> merchant that returns accepted=false but broadcasts the transactions
>> anyway."
>>
>>
>> I also added a TODO "Test Vectors" section with base64-encoded
>> examples of everything.
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> --
>> Keep yourself connected to Go Parallel:
>> INSIGHTS What's next for parallel hardware, programming and related areas?
>> Interviews and blogs by thought leaders keep you ahead of the curve.
>> http://goparallel.sourceforge.net
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> Mike Koss
> CTO, CoinLab
> (425) 246-7701 (m)
>
> A Bitcoin Primer  - What you
> need to know about Bitcoins.
>
>
>
> --
> Keep yourself connected to Go Parallel:
> BUILD Helping you discover the best ways to construct your parallel
> projects.
> http://goparallel.sourceforge.net
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d__

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-07 Thread Mike Hearn
> yeah... I had similar thoughts on what to do if some Outputs specify an
> amount and others don't. I'm still waffling on whether or not I like
> allowing repeated Outputs; a single Output would make the spec a fair bit
> simpler

Yes, but at the cost of privacy. Generators of payment requests always
have the option of just adding a single output and being done with it.
But in future they'll probably want to keep their income in unlinkable
chunks of a size that's up to them, and multi-outputs are needed for
this (the idea being, the users wallet tries to keep a
close-as-possible match between the requested outputs and their own).

OK, let's punt on tipping for now.

> If a bitcoin client accepts unsigned payment requests (a couple of people
> have asked if that would be possible so I think that is desired), then it
> doesn't have the payer's identity-- all it has is the Outputs that will be
> paid.

I see. If I were to implement a wallet I'd just display nothing
(except the size of the request). Showing an address doesn't really
help the user in any way.

> I still like the idea of only including the root CAs who have jumped through
> the hoops needed to get the "allowed to issue EV certs" blessing.

The hoops only actually apply for EV certs though, they aren't
required to do that verification for DV certs.

The main reason to use the browser root CAs is that merchants are
guaranteed to be able to re-use their existing certs. Otherwise they
might have to buy new ones, which would be annoying.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-07 Thread Gavin Andresen
On Fri, Dec 7, 2012 at 6:01 AM, Mike Hearn  wrote:

> Yet more comments (I guess at some point we need to stick a fork in it
> - or at least move on to implementing a prototype version).
>

Yes, my next step is prototyping.

Note that this is not a BIP yet:  I want to have a working implementation
before making this an Official BIP.


> Maybe don't require the payment URI to be HTTPS.


Changed:
   receipt_url: Secure (usually https) location where...

Though it's not strictly necessary, it'd be nice to have defined
> behavior for if you want to pay more than the requested amount, for a
> tip.


yeah... I had similar thoughts on what to do if some Outputs specify an
amount and others don't. I'm still waffling on whether or not I like
allowing repeated Outputs; a single Output would make the spec a fair bit
simpler, and if a merchant wants to split up a payment for some reason they
could just generate another transaction.

I want to move on to actually implementing this before creating complicated
rules. Maybe the best way to tip a waitress is to get two separate
PaymentRequests, one for the restaurant and one that goes directly to the
waitress (depends on whether or not the restaurant needs or wants to know
how much their employees are getting tipped, I suppose).  Maybe it would be
best to have a separate "gratuity" Output in the PaymentRequest. That's the
kind of detail I think doesn't need to be worked out right now, I'd rather
restaurants tell us what they need/want.


> "Display the proposed Outputs in as human-friendly a form as possible"
>  ??? Surely you'd just display the total amount requested? I don't
> think it ever makes sense to try and display outputs to the user
> directly.
>

This is the case of getting an UNSIGNED payment request; I've changed the
wording a little to make that more clear.

If a bitcoin client accepts unsigned payment requests (a couple of people
have asked if that would be possible so I think that is desired), then it
doesn't have the payer's identity-- all it has is the Outputs that will be
paid.



> Re: the UI TODO - agreed but let's take it out of the BIP...


Not a BIP yet

serialized_paymentrequest -> serialized_payment_request?


Done.


> The question of root CAs still needs resolution.  I stick with
> my recommendation to support all CAs that browsers support.


I still like the idea of only including the root CAs who have jumped
through the hoops needed to get the "allowed to issue EV certs" blessing.
 I'm not suggesting that all bitcoin merchants must get EV certs, but I am
suggesting that they must get a certificate from one of the most reputable
certificate authorities, and the ability to issue EV certificates is, I
think, a good proxy for that.

But, again:  Not a BIP yet.  Lets get something implemented and then hammer
out details (implementing always turns up edge cases you forgot when
spec'ing).


-- 
--
Gavin Andresen
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-07 Thread Mike Hearn
Yet more comments (I guess at some point we need to stick a fork in it
- or at least move on to implementing a prototype version).

Maybe don't require the payment URI to be HTTPS. If you want to pay a
Tor hidden service then HTTPS just adds unnecessary complexity. Just
recommend to merchants that they use an encrypted connection and leave
it at that.

Though it's not strictly necessary, it'd be nice to have defined
behavior for if you want to pay more than the requested amount, for a
tip. Perhaps rather than "zero value outputs will be ignored" say, "if
some outputs have value and others don't, the user will be given the
option of overpaying and the extra money will be split evenly between
the zero valued outputs". That way a waitress can have the phone add a
zero-valued output to her own wallet and that would prompt the wallet
software to display some convenient UI for adding on 10% or whatever.

receiptURI -> receipt_url ? technically it has to be resolvable so
"uri" isn't quite right.

"Display the proposed Outputs in as human-friendly a form as possible"
 ??? Surely you'd just display the total amount requested? I don't
think it ever makes sense to try and display outputs to the user
directly.

Re: the UI TODO - agreed but let's take it out of the BIP and maybe
make it an alternative document. Or just replace it with a
recommendation that "the user interface should be designed to ensure
users understand the difference between an unsigned and signed payment
request, for best practices see "

serialized_paymentrequest -> serialized_payment_request? Otherwise
languages that use CamelCase will look odd 
setSerializedPaymentrequest()

The question of root CAs still needs resolution. I stick with my
recommendation to support all CAs that browsers support. Obviously,
it's better for a merchant to obtain an EV cert than a domain
verification cert - the UI can reflect the higher level of
verification.

I doubt there's a need to specify a max number of certs in a chain.
But if you want to, go for something high, like 256. There's no point
in trying to put DoS mitigations into something like this, for the
same reason HTML doesn't impose a maximum page size. It's in the
message builders interest to ensure it gets read by all users.
Crashing their clients doesn't achieve anything as long as the crash
isn't exploitable.




On Fri, Dec 7, 2012 at 11:45 AM, Mike Hearn  wrote:
>> OK. I want to keep the signature field required, though, so how about:
>>
>> signature: digital signature over a protocol buffer serialized variation of
>> the SignedPaymentRequest message where signature is a zero-byte array and
>> fields are serialized in numerical order (all current protocol buffer
>> implementations serialize fields in numerical order), using the public key
>> in pki_data.
>
> Looks good to me.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-07 Thread Mike Hearn
> OK. I want to keep the signature field required, though, so how about:
>
> signature: digital signature over a protocol buffer serialized variation of
> the SignedPaymentRequest message where signature is a zero-byte array and
> fields are serialized in numerical order (all current protocol buffer
> implementations serialize fields in numerical order), using the public key
> in pki_data.

Looks good to me.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-06 Thread Gavin Andresen
On Thu, Dec 6, 2012 at 12:55 PM, Mike Hearn  wrote:

> Re: the newest spec. Rather than make the signature over the
> "concatenation of", why not just make it a signature over the
> serialized protobuf minus the signature field (as I did in my demo
> code). Otherwise it seems like we'd need more code than really
> necessary. We can state explicitly tags must be ordered if you want,
> even though all implementations should do that already.


OK. I want to keep the signature field required, though, so how about:

signature: digital signature over a protocol buffer serialized variation of
the SignedPaymentRequest message where signature is a zero-byte array and
fields are serialized in numerical order (all current protocol buffer
implementations serialize fields in numerical order), using the public key
in pki_data.

-- 
--
Gavin Andresen
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-06 Thread Alan Reiner
On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen wrote:

> When I say "pass around" I'm not thinking of users copying and pasting,
> that would be a terrible user experience; all of that communication needs
> to happen automatically behind the scenes. Lets tackle that after we've got
> the simpler customer-pays-merchant flow working nicely
> (funded-escrow-pays-merchant is a subset of that, anyway).



I think that the "pass around" method needs to happen in addition to the
methods of transparent protocols that occur behind the scenes.  For one,
there's a lot of CONOPs that need to be worked out by getting knowledgeable
people using it, and providing feedback about how it could/should/will be
used and how it could be improved.  The pass-around method is simpler to
implement and still usable by the types of users that will be using it in
the beginning -- experts.  Also, I see that for very large, important
multi-sig tx/contracts/escrow, the "manual" method might be preferred --
much the same way many people prefer manual-transmission cars even though
automatics are "easier" -- some people/organizations will want the control.


I'm all for protocols that enable higher-level access to this
functionality, I'm just saying there should be lower-level access, too.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-06 Thread Mike Hearn
Re: the newest spec. Rather than make the signature over the
"concatenation of", why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must be ordered if you want,
even though all implementations should do that already.

> Thumbnail sketch:  escrow service or participant sends around an
> EscrowProposal, gets EscrowProposalACK's with public keys to use, then sends
> all participants an EscrowEstablished message with the final multisig script
> or address.

Yeah, that sounds reasonable. Not that we should really design it now,
but let's use the term "mediation" rather than "escrow", which has
connotations of depositing funds with the escrow service.

I think it's best to see the existing payment messages as structures
that'll get filled out with more features over time. So rather than
have a separate EscrowProposal message, you would integrate it with
payment requests. Older clients that don't understand mediation would
just ignore the extra data they don't recognize.

message PaymentRequest {
   

  // One per mediator acceptable to the seller.
  repeated MediationProposal mediation_data = 10;
}

message MediationProposal {
  required SignedMediatorIdentity identity = 2;

  // Opaque bytes that the mediator can be asked to turn into a human
readable description
  // of how disputes will be mediated. The merchant sets this to
describe whatever policy it
  // is willing to go along with, so policies may be arbitrarily complicated.
  required bytes policy = 3;
}

message SignedMediatorIdentity {
  required MediatorIdentity identity = 1;
  // If the identity data is signed ...
  optional string pki_type = 2;
  optional bytes pki_data = 3;
  optional bytes pki_signature = 4;
}

message MediatorIdentity {
  // Name of the mediator to be displayed to the user.
  required string friendly_name = 1;
  // PNG image that can be used to represent the mediator to the user.
  optional bytes logo = 2;
  // Some text shown to the user under the name explaining the
mediators policies, why they should be chosen, etc.
  optional string blurb = 3;

  // An HTTP URL where a mediator can be reached to do things like
prove ownership of pubkeys, initiate the protocols, etc.
  required string contact_url = 4;
}

... etc 

So the user experience would be that when a payment request is received:

- older clients ignore the mediation_data field and do a direct
payment as normal
- newer clients ask the user to pick a mediator (if they want to) and
if mediation is requested, the PaymentRequest is then discarded and
the next step of the mediation protocol begins.

The old request has to be discarded because the outputs would have
been written on the assumption of no mediation being in use (for
backwards compatibility).

Anyway, though I'm awfully guilty, let's not get off track. Just that
this is how I imagined new payment features being done - as new
extensions to the payment protocol, which would be a living document
amended by BIPs.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-06 Thread Gavin Andresen
Spec updated yet again:
  https://gist.github.com/4120476

Renamed to PaymentRequest/PaymentACK.

Added a 'network' field ("main" or "test") to PaymentRequest so testnet and
main network (and alterna-chain) payment requests don't get confused.

Updated description of PaymentRequest.outputs:

outputs: one or more outputs where Bitcoins are to be sent. If the sum of
outputs.amount is zero, the customer will be asked how much to pay, and the
bitcoin client may choose any or all of the Outputs (if there are more than
one) for payment. If the sum of outputs.amount is non-zero, then the
customer will be asked to pay the sum, and the payment shall be split among
the Outputs with non-zero amounts (if there are more than one; Outputs with
zero amounts shall be ignored).
-

RE: escrow/multisig:

Setting up a multi-person escrow will, I think, need it's own set of
messages. I think we should leave that for a future spec.

Thumbnail sketch:  escrow service or participant sends around an
EscrowProposal, gets EscrowProposalACK's with public keys to use, then
sends all participants an EscrowEstablished message with the final multisig
script or address.  Escrow gets funded by any/all of the participants, and
then gets spent using the SignedPaymentRequest/Payment/PaymentACK
protocol-- participants will pass around a SignedPaymentRequest and a
partially-signed Payment message for all to approve.

When I say "pass around" I'm not thinking of users copying and pasting,
that would be a terrible user experience; all of that communication needs
to happen automatically behind the scenes. Lets tackle that after we've got
the simpler customer-pays-merchant flow working nicely
(funded-escrow-pays-merchant is a subset of that, anyway).

-- 
--
Gavin Andresen
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-06 Thread Mike Hearn
Escrow/multisig is complicated enough to wait for another day. But
certainly having a payment protocol is an important step towards it
On 6 Dec 2012 07:32, "Andreas Petersson"  wrote:

> During/before the Payment Request there should be a method to exchange
> the public keys to be able to generate a common multisig address.
> Should this be handled in a different protocol, or be included in this
> spec?
> Or is there a method for the customer to verify that the specified BIP16
> Output contains his address and the one from an escrow service?
>
> --
> Andreas
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-05 Thread Andreas Petersson
During/before the Payment Request there should be a method to exchange 
the public keys to be able to generate a common multisig address.
Should this be handled in a different protocol, or be included in this 
spec?
Or is there a method for the customer to verify that the specified BIP16 
Output contains his address and the one from an escrow service?

--
Andreas

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-05 Thread Gavin Andresen
I've had some push-back on the names of the proposed messages-- e.g.
"Invoice" in the accounting world means "I've already given you a
product or service, here is what you owe, payment terms, what forms of
payment are accepted, etc."

I think there might also be confusion about why we're defining our own
Invoice when there are at least three or four other existing standard
for electronic invoices.

So unless there is strong objection I'm going to change the names of
the messages:

Invoice -->  PaymentRequest
Payment : ok as-is
Receipt --> PaymentACK  (payment acknowledgement)

On Tue, Dec 4, 2012 at 12:06 PM, Mike Hearn  wrote:
> Does it make sense to have this spec not include the details of
> bootstrapping? It's not complicated 

BIP 0001 says:  "If in doubt, split your BIP into several well-focussed ones."

I think it makes sense to keep the URI extension separate from the
binary message format.

> We should define a simple mechanism for extending the protocol now...
>
> message Invoice {
>   extensions 1000 to max;
> }

Ok.

-- 
--
Gavin Andresen

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-04 Thread Mike Hearn
> So, if a bitcoin client is getting Invoice messages via email or from
> a web server, the version will be specified as part of the MIME type;
> for example:
>Content-Type: application/x-bitcoin-invoice; version=1
> The version= syntax is part of the MIME standard.

I think that's OK. However, you should only be getting the version you
expect because when you request an invoice, your client should be
telling the merchant what protocol version you implement.

Does it make sense to have this spec not include the details of
bootstrapping? It's not complicated - we extend the URI spec in a
backwards compatible way:

   
bitcoin:1AbCdEfG?value=10.0&label=Pay%20for%20Foo&invoice=https://merchant.com/inv/aB425az

When a compatible client sees the invoice param, it ignores the rest
of the URI and downloads the URL
https://merchant.com/inv/aB425az?ver=1.0

A server on merchant.com sees that the client expects a version 1.0
invoice and vends it. If ver=2.0 or whatever, it knows it can use 2.0
features. If extensions are supported, add new query params.

We should define a simple mechanism for extending the protocol now, so
people who want to make proprietary extensions don't conflict. The
simplest is to just say, if you want to add new fields to an Invoice
message, please update a wiki page with the tag numbers you're going
to use, and start from number X. Protobufs have a simple way to
formalize this in the language:

   https://developers.google.com/protocol-buffers/docs/proto#extensions

message Invoice {
  extensions 1000 to max;
}

The point of this is to allow you to define new parts of the messages
in separate .proto files. It's only a minor convenience but it means
if you want to use, say, two extensions that weren't yet folded into
the main spec, you can more easily do so without having to do a manual
merge of the message definitions together.

For instance, if you wanted to extend the protocol to support
specification of recurring billing, you could make a file called
recurring-invoices.proto containing:

message Recurrences {
  required uint32 every_seconds = 1;
  optional uint32 start_time = 2;
}

extend Invoice {
  optional Recurrences recurrences = 1005;
}

then you update the wiki page to claim tag number 1005 and apps can
easily use your new features. If/when the feature gets standardized
via a BIP, the core .proto definition can be extended to include these
messages and the extensions can go away.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Jeff Garzik
On Mon, Dec 3, 2012 at 5:26 PM, Roy Badami  wrote:
> On Mon, Dec 03, 2012 at 10:28:13PM +0100, Mike Hearn wrote:
>> Witness the absurd design of SMTP that means you can't
>> start a paragraph with the word From because that's a new-message
>> marker!
>
> Actually that has absolutely nothing to do with SMTP.  It's down to
> the file format of the standard BSD UNIX mailbox (which uses lines
> beginning with 'From ' to delimit messages).

His point (pun intended) stands.  SMTP uses "." terminator, which also
causes annoying confusion.

You shouldn't need to escape and unescape data that is not being
interpreted in any way.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Roy Badami
On Mon, Dec 03, 2012 at 05:34:12PM -0500, Jeff Garzik wrote:
> You shouldn't need to escape and unescape data that is not being
> interpreted in any way.

Funilly enough pretty much all low-level links that make up the
Internet use either bit-stuffing or byte-stuffing to escape a
particular bit sequence or byte that terminates an HDLC frame.

I'm not particularly agreeing or disagreeing with you on the
suitability for the case at hand, but as an absolute your statement
doesn't hold water.  The use of a terminator for a variable-length
data structure rather than a length prefix is a design desicion that
has little-to-nothing to do with the debate of text-versus-binary.

Anyone remember Holerith constants?

roy

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Roy Badami
On Mon, Dec 03, 2012 at 10:28:13PM +0100, Mike Hearn wrote:
> Witness the absurd design of SMTP that means you can't
> start a paragraph with the word From because that's a new-message
> marker!

Actually that has absolutely nothing to do with SMTP.  It's down to
the file format of the standard BSD UNIX mailbox (which uses lines
beginning with 'From ' to delimit messages).

roy

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Gregory Maxwell
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn  wrote:
> 4) A longer term reason - in time, people may choose to not broadcast
> transactions at all in some cases. I think how network speed will be
> funded post-inflation is still an open question. Assuming the simplest
> arrangement where users pay fees, getting transactions into the chain
> has a cost. In cases where you trust the sender to not double spend on
> you, you may keep a fee-less transaction around "in your pocket". Then
> when it's your turn to pay, you use some unconfirmed transactions to
> do so.

This brings up an additional point.  If we're mutually trusting
parties (or secured by some kind of external mechanism), and you've
given me a payment which I haven't broadcast for confirmation— and
later we make another transactions I should be able to offer you the
original unconfirmed txn and ask if you'd instead be willing to write
a replacement that combines both payments.

--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Mike Hearn
> It would also be really nice to migrate to textual representations of data
> structures as opposed to binary ones.  The most successful internet
> standards are based on text.

There are lots of successful binary protocols: TCP, IP, PNG, JPEG,
MP3, DNS, SSH, SSL, the Bitcoin protocol itself. What's more some
other protocols that are text based have suffered serious problems due
to that choice. Witness the absurd design of SMTP that means you can't
start a paragraph with the word From because that's a new-message
marker! Or the fact that file attachments grow by 33% when you send
them. Or the various exploits that can exist in web servers thanks to
header splitting attacks.

Trying to represent something binary as text doesn't make any sense.
If you look at these data structures they consist of keys, signatures,
hashes, certificates and other fundamentally binary things. You'd just
end up base64 encoding everything anyway, at which point all you've
done is design an inefficient binary protocol that masquerades as
text. The disadvantages of both with the advantages of neither.

Protocol buffers have a text form that you can print to and parse
from, if you so wish, though I only normally see people use that
support for debug prints and sometimes because they want to load
hand-written config files directly into protobuf generated objects.

--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Gavin Andresen
On Mon, Dec 3, 2012 at 2:35 PM, Mike Koss  wrote:
> Why don't we sign the text representation of a (utf8) JSON, rather than some
> complex encoding standard of JSON?

Because the results from standard JSON parsers are undefined if I give
you an "envelope" JSON that has repeated keys.

For example:

{
  "pki_data" : "...hex-or-base64-encoded certificate chain...",
  "signature" : "hex-or-base64-encoded-signature-bytes",
  "message" : "string-encoded-utf8-JSON",
  "message" : "another string-encoded-utf8-JSON",
  "signature" : "more hex-or-base64-encoded-signature-bytes",
  "pki_data" : "...another certificate chain...",
}

The JSON spec doesn't say what you'll get when you decode that mess.
Maybe the first instance of each field, maybe the last, maybe one
picked at random...

The JOSE (Javascript Signing and Encryption) spec says "Thou Shalt Use
A JSON Parser That Treats Multi-defined-keys As An Error."

I expect that most developers will be lazy and will just use whatever
JSON parser is convenient, no matter how much the spec/documentation
warns them not to. And that makes me nervous, because I can imagine
attackers taking advantage of mismatches between (say) the JSON
parsing software used by some back-end server process and a front-end
JavaScript web wallet UI.

-- 
--
Gavin Andresen

--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Mike Koss
The thing that bugged me most about the original spec was the sole reliance
on X.509 - glad to see you've made that optional.  I think many people will
balk at deferring our identity trust to the existing CA's.  I think it's a
fine bootstrap method, but I'd really like to see another option that
allows for out-of-band trust (based on ECDSA, probably).

It would also be really nice to migrate to textual representations of data
structures as opposed to binary ones.  The most successful internet
standards are based on text, making them that much more accessible for
developers to deal with them.   JSON would be my preferred candidate.

Why don't we sign the text representation of a (utf8) JSON, rather than
some complex encoding standard of JSON?  That way the signatures are simple
- and you need only retain the original textual representation of a message
to validate the signature (as well as the decoded version, if you don't
want to alway re-parse the message when writing programs that use it).

On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen wrote:

> Spec updated: https://gist.github.com/4120476
>
> Changes are:
>
> Version numbers:  a couple of people asked privately about adding
> version numbers to the messages. In general, Protocol Buffers don't
> need version numbers if later versions add only optional fields.
>
> And best-practice is to know what version of something you're
> expecting BEFORE you start parsing that something.
>
> So, if a bitcoin client is getting Invoice messages via email or from
> a web server, the version will be specified as part of the MIME type;
> for example:
>Content-Type: application/x-bitcoin-invoice; version=1
> The version= syntax is part of the MIME standard.
>
> Following that best-practice of knowing what you're parsing before you
> parse it, I added an invoice_version field to the SignedInvoice
> message. It is now:
>
> message SignedInvoice {
> required bytes pki_data = 1;
> required string pki_type = 2 [default = "x509"];
> required bytes serialized_invoice = 3;
> required uint32 invoice_version = 4 [default = 1];
> required bytes signature = 5;
> }
>
>
> Handling of receiptURI errors:
>
> Following discussion here, I changed the spec to say:
>
> "Clients may handle errors communicating with the receiptURI server
> however they like, but should assume that if they cannot communicate
> at all with the server then the Payment should either be retried later
> or immediately rejected."
>
> and under Receipt added:
>
> "The Bitcoin client must be prepared to handle the case of an evil
> merchant that returns accepted=false but broadcasts the transactions
> anyway."
>
>
> I also added a TODO "Test Vectors" section with base64-encoded
> examples of everything.
>
> --
> --
> Gavin Andresen
>
>
> --
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)

A Bitcoin Primer  - What you need
to know about Bitcoins.
--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-01 Thread Gavin Andresen
Spec updated: https://gist.github.com/4120476

Changes are:

Version numbers:  a couple of people asked privately about adding
version numbers to the messages. In general, Protocol Buffers don't
need version numbers if later versions add only optional fields.

And best-practice is to know what version of something you're
expecting BEFORE you start parsing that something.

So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
   Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.

Following that best-practice of knowing what you're parsing before you
parse it, I added an invoice_version field to the SignedInvoice
message. It is now:

message SignedInvoice {
required bytes pki_data = 1;
required string pki_type = 2 [default = "x509"];
required bytes serialized_invoice = 3;
required uint32 invoice_version = 4 [default = 1];
required bytes signature = 5;
}


Handling of receiptURI errors:

Following discussion here, I changed the spec to say:

"Clients may handle errors communicating with the receiptURI server
however they like, but should assume that if they cannot communicate
at all with the server then the Payment should either be retried later
or immediately rejected."

and under Receipt added:

"The Bitcoin client must be prepared to handle the case of an evil
merchant that returns accepted=false but broadcasts the transactions
anyway."


I also added a TODO "Test Vectors" section with base64-encoded
examples of everything.

-- 
--
Gavin Andresen

--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-29 Thread Roy Badami
On Thu, Nov 29, 2012 at 06:31:24PM +0100, Mike Hearn wrote:
> > I'd still like to understand the rationale for having the merchant
> > broadcast the transaction
> 
> There are several reasons for this:

[snip]

All good reasons, thanks for the explanation.

Though I still like my idea of a ValidatePurchase message that allows
a buyer to ask a merchant "would you accept this payment?" without
actually supplying a signed transaction.  Make it optional if you care
about minimising the number of round trips, e.g. for fast NFC
payments.

Having such a message reduces the extent to which you need to trust
the merchant not to spend a transaction that they've rejected.  (And
in the non-Internet connected case this is particularly useful since
the client won't have the ability to broadcast a pay-to-self
transaction.)

roy



--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-29 Thread Mike Hearn
> I'd still like to understand the rationale for having the merchant
> broadcast the transaction

There are several reasons for this:

1) P2P network sockets are a limited resource and bringing up
connections to the network, whilst somewhat fast today, is not
guaranteed to be fast in future. Passing transactions to the merchant
for broadcast reduces the load on the P2P nodes because lots of thin
clients aren't any longer connecting and disconnecting when sending.
They only need to talk to the network when the user has received
money.

2) Some users may not have network connectivity at all. For example,
this happens quite often whilst traveling at Bitcoin conferences ;)
The solution, which Andreas and I prototyped in Berlin together, is
for the buyer to communicate only with the seller which can be done
over Bluetooth or WiFi Direct or some other mobile radio protocol.
Again, send only, but for the common case where you load up your
wallet before setting out and then buy things, it works OK.

4) A longer term reason - in time, people may choose to not broadcast
transactions at all in some cases. I think how network speed will be
funded post-inflation is still an open question. Assuming the simplest
arrangement where users pay fees, getting transactions into the chain
has a cost. In cases where you trust the sender to not double spend on
you, you may keep a fee-less transaction around "in your pocket". Then
when it's your turn to pay, you use some unconfirmed transactions to
do so. People pass around longer and longer chains of un-broadcast
transactions until a payment crosses a trust boundary, at which point
the receiver adds on their own transaction that spends back to himself
but with a fee, and broadcasts them all together as a unit. In this
way only people who genuinely need to fear double spends pay for
security.

--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-29 Thread Gavin Andresen
On Thu, Nov 29, 2012 at 12:07 PM, Roy Badami  wrote:
> I'd still like to understand the rationale for having the merchant
> broadcast the transaction - it seems to add complexity and create edge
> cases.

Mike Hearn has experimented with in-person payments using
bluetooth/NFC on a phone, where the merchant has full Internet
connectivity but the phone might only be able to connect to the
merchant via a Bluetooth/NFC paymentURI.

I think I agree with you, though: if the device DOES have
bitcoin-p2p-network-connectivity, then expecting the client to
broadcast the transaction might be cleaner.

However, if a connection to the paymentURI is made and the transaction
data has been sent, clients have to deal with the case where the
merchant also broadcasts the transaction, no matter what the spec says
and even if the merchant sends an "accepted : false" response.


-- 
--
Gavin Andresen

--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-29 Thread Roy Badami
I'd still like to understand the rationale for having the merchant
broadcast the transaction - it seems to add complexity and create edge
cases.

How about this as an alternative proposal:

The buyer's client prepares the transaction and computes its txid.  It
then sends a ValidatePurchase message to the merchant containing the
proposed Outputs and a copy of the merchant_data along with the txid.

Assuming the proposed payment is accepted as valid by the merchant,
the buyer's client simply broadcasts the pre-prepared transaction in
the normal way, and it is the merchant's responsibility to watch for
this transaction to arrive over the p2p network/blockchain to complete
the purchase.  (So if the merchant rejects the purchase at the
ValidatePurchase stage, they never get to see the transaction that the
buyer prepared, and there's therefore no need for a send-to-self to
cancel it.)

An optional RequestReceipt message (perhaps containing the
merchant_data and txid) can be sent by the client after the
transaction has been broadcast - but by making this explicitly
optional it forces the merchant to rely on seeing the bitcoin
transaction to 'commit' the payment and not on the RequestReceipt
message.

As far as I can see this proposal has no edge cases where the buyer
and merchant have differing ideas as to whether the transaction has
'comitted' - or at least, no more edge cases than the standard bitcoin
protocol has.

roy

--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-29 Thread Gavin Andresen
RE: Roy Badami's comments on edge cases around submitting a Payment
message to a merchant and then not receiving a timely response:

I agree, it is messy.

I'm hesitant to try to specify One True Way of handling it in the
spec; I've got a feeling that this might be a place where different
implementations might try different things, with the best
implementation winning.

For example, if some future nifty-keen Bitcoin client is re-using an
old Invoice to send a monthly subscription payment and they can't
contact the paymentURI, then the right thing is probably for it to
retry once a day for three or four days and if they all fail then give
up and tell the user that the service is no longer in business (or
changed their paymentURI without leaving behind a redirect).

If it has a single-use Invoice created a minute or two ago, the right
logic might be:
  + If the paymentURI is completely non-responsive, just error and
tell the user "payment failed"
  + If connected to the paymentURI and payment sent, but disconnected
before receiving a response, then try to send-to-self the coins to
cancel payment.

Again, I'm not at all sure that is the best way to handle it;
implementors have the right incentives to give their users the best
user experience, so I feel comfortable leaving the spec fuzzy for now.

-- 
--
Gavin Andresen

--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-29 Thread slush
Hi,

not sure if you already noticed, but I and my friends are actively working
on bitcoin hardware wallet. This should be pocket size device with
something like 256kB flash and 80 MHz CPU, talking with the computer over
USB. User will prepare transaction on the machine, send it to the device,
device shows target address on the display and user confirms it by pressing
the button.

We're trying to make bitcoin payments safe even on hacked computer. For
this reason we're also implementing SPV so device don't need to trust
computer with any kind of information. The biggest existing problem is that
user cannot be sure that the address displayed on computer screen is
correct and he's confirming valid address.

I don't have any solution for this problem yet. I just appreciate an
activity in payment protocol area, because it can (with some care) solve
this problem and my appeal si to keep all this simple. I'd be very happy
with simple payment protocol which can be implemented even on devices like
I'm working on, so device with few widely used certificates stored in the
memory will be able to display origin of the invoice and confirm its
validity.

slush


On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd  wrote:

> After doing more thinking, what about letting a spend sign more
> information associated with the transaction, such as a transaction ID
> provided by the merchant? This seems to solve a lot of the problems being
> put forward, with much less complexity.
>
> --
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts
> and peers. http://goparallel.sourceforge.net
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Watson Ladd
After doing more thinking, what about letting a spend sign more information
associated with the transaction, such as a transaction ID provided by the
merchant? This seems to solve a lot of the problems being put forward, with
much less complexity.
--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Roy Badami
> If a Receipt is not received for any reason (timeout, error) and
> Payment.transactions has not been broadcast by the merchant on the
> Bitcoin p2p network, then the Bitcoin client should assume that the
> payment failed, inform the customer that the payment failed, and
> return coins involved in the transaction to the customer's wallet.

I'm not sure I understand the rationale for this.  In the above
scenario the buyer has no way to determine whether the merchant still
has a copy of the transaction that they could broadcast in future.
Maybe there is simply a systems problem at the merchant which has
temporarily delayed the transaction broadcast. Or maybe a dishonest
merchant deliberately engineered this situation in an attempt to
mislead the buyer as to the status of their payment.

Either way, having the buyer think the coins have been returned to
their wallet - only to disappear from their wallet again at some later
time - would seriously damage user confidence in Bitcoin IMHO.

It seems to me that the first thing the buyer should do given the
protocol as it stands is simply resend the Payment message - if there
was a temporary problem then resending the payment message (with the
same signed transation) might resolve the sitution.

If after several retries the status of the transaction is still
undefined then it's really not clear what to do, but it seems
desireable to have the client take steps so that it can return to a
state of certainly about its wallet balance as quickly as possible.
Two things I can imagine that the buyer might want their client to do
at this point are:

 * broadcast the transaction itself, so they are sure the payment
   transaction will make it into the blockchain without any further
   action on their part, or

 * invalidate the transaction by immediately broadcasting a
   pay-to-self transaction that spends one or more of the same outputs
   that the payment transaction spends (and treat the funds as part of
   the unconfirmed balance until this pay-to-self transaction
   confirms).  This ensures the merchant can't subsequently use a
   transaction which the buyer thinks has failed

It seems to me it would be simpler and cleaner if the buyer just
always broadcasted the transaction on the p2p network, regardless of
whether the Invoice includes a receiptURI.  If a receiptURI is
included, the buyer's client would also include the transaction in the
Purchase message.  The merchant then tries to broadcast the
transaction as well (unless their bitcoind has already seen it, which
may well be the common case).  This approach seems to me to have fewer
nasty edge cases.s

roy


--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Gavin Andresen
RE: Changing SignedInvoice's invoice field to 'bytes serialized_invoice':

Good Idea, I agree it will avoid potential issues. I think it then
makes sense to pull the pki_type and pki_data into SignedInvoice, too,
and specify that the signature is on the SHA256-HMAC of pki_type,
pki_data, and serialized_invoice (being careful to combine them in a
way that is secure).

RE: Changing Payment to include just merchant_data and not the entire Invoice:

Agreed, good idea.


RE: Mr. Stanish's suggestion to punt all of this and wait for a Grand
Unified Solution:

No, we have problems that need a solution right now. And, having
written one (I was the lead author of the ISO/IEC 14772-1
international standard) I'm very pessimistic about your chances for
anything like IFEX to actually be adopted.

-- 
--
Gavin Andresen

--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Peter Todd
On Wed, Nov 28, 2012 at 11:43:19AM +0100, Mike Hearn wrote:
> Peter is correct that there are a few degrees of freedom in protobuf
> serialization, though far fewer than with JSON.

FWIW I re-read the specs again and turns out my memory was wrong. (I
last looked at this about four months ago) Duplicated fields are handled
in a defined manner, with the last field seen in the serialization being
the one whose value is used. Again, repeated fields are treated as
elements of a list, preserving order.

It does raise the interesting question do the implementations that don't
preserve order of unknown fields, preserve the order of multiple unknown
fields, either repeated or not?

> I'd like to think upstream would be open to resolving these
> ambiguities.

I gotta admit, I suspect they won't be that open. Protocol buffers was
designed because Google needed a fast serialization method suitable for
many different internal projects. Needing round-trip idempotence seems
like a rare requirement to me, especially for internal use.

> Re-serialization of an Invoice message in the Payment message is a
> potential source of mistakes. There's no need to ever concatenate
> these messages and alternative implementations that don't order
> serialized fields by tag number are missing an important optimization,
> so they could be fixed. The main issue is treatment of unknown fields.
> If/when the Invoice message is extended with other fields that are
> round-tripped through an old client, the data may get lost. JSON
> doesn't help resolve that either, of course. There are a few
> solutions:

Well, actually you can take advantage of the message concatination
ability of protocol buffers to extend a message by simply appending the
new fields to the existing thus either defining new fields, or
overriding old values as required. If you want to de-duplicate though
you run into the problem all over again.

On the other hand JSON handles this case fine too provided that your
JSON implementation supports dictionary objects with arbitrary fields.
Just use the object as is and the unknown fields will be re-serialized
properly at the other end. Some implementations will have to be careful
to handle collisions with existing keys in the namespace. (consider in
Python what would happen if you mapped your object to a class instance,
and the serialization included the key "__init__")

That said, JSON is quite problematic with numbers. For instance, you
have to be careful to keep integers represented as pure integers below
what Javascript can handle, the maximum integer exactly representable in
a double float, or the JSON won't be parsable in Javascript even if many
other languages handle it fine. Protocol buffers is at least pretty
explicit about what size integers are.

> 1) Change the type of the Invoice field in Payment to be "bytes" and
> set it to be the hash of the originally received binary Invoice
> message. Downside, requires merchants to track all outstanding
> invoices.
> 2) Ask protobufs upstream to modify the spec/implementations so
> ordering of unknown fields is specified. The Python implementation
> could be extended to support them so Python implementors don't end up
> with accidental message downgrades.
> 3) Language of the spec could be changed to explicitly state that the
> received Invoice may not be binary-identical to the one that was sent,
> in the case of a client that incorrectly downgrades the message. Thus
> you'd be expected to check what the Invoice was using merchant_data
> which is opaque and could just be, eg, a database key on your own end.
> 4) Instead of submitting the entire Invoice back to the merchant, just
> the merchant_data could be in the Payment message.
> 
> Of the four options I prefer the last. What is the use case for
> resubmitting the entire invoice anyway? Even if protobufs are improved

Note that I think the SignedInvoice message itself is broken, because
protobuf implementations have no reason to guarantee that they can give
you the serialized bytes of the Invoice sub-message. It's a quite
specific use-case that isn't needed for pretty much anything but crypto.
FWIW I took a quick look at the official API's, C++, Java and Python,
and as far as I can tell none of them support accessing the binary
serialization of a message field other than by re-serializing the
message.

Really the invoice field should be declared as bytes serialized_invoice,
as inconvenient as that is to work with.

> so handling of round-tripping new messages through old [Python]
> clients is more rigorous, some implementors will probably convert the
> protobuf objects into some internal forms for whatever reason (or
> serialize them to a database, etc) and they're very likely to mess up
> the handling of unknown fields when they do it.

Since the Payment message includes an *untrusted* Invoice that the
vendor needs to authenticate the whole invoice no matter what on Payment
reception. In many cases that implies they have to

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Walter Stanish
> RE: the ifex-project and other electronic invoicing standards:  Thanks
> for the pointers, Walter! I'm all for adopting the best ideas that
> have come before, as long as we end up with something useful and small
> enough to convince ourselves it is as secure as we can make it.

Fair enough, although I would posit:
 0. You can't get more secure than not doing it at all.
 1. Small is sometimes beautiful, but sometimes just the 999th
crippled and half-featured attempt at a nontrivial problem space
(...linked heavily to implementation-time assumptions and/or specific
peer systems, and by its very nature destined for the dustbin of time?
Well, maybe. Eventually, we all are.)
 2. X.509 is not small (or beautiful, unless one is some weird new
kind of centralized cryptographic trust fetishist, of some sort you
might see with furrowed brows, boozing at midday sporting key & anchor
tattoos in old convention polo-shirts, mumbling to themselves about
the employee-motivation benefits of single sign-on...)

> looked at the ifex spec, and quickly got lost. It would help me if you
> could write up what our motivating use cases would look like if
> implemented on top of ifex.

Yes. Understandable. Thoughts around an IFEX protocol proposal, unlike
the other proposals, are still drafty (err...as a coastal verandah?)
and not the clearest. However, we have much research and progress has
been achieved in the odd year-or-so since beginning.  The fundamental
concerns of such a protocol (regarding the establishment of neutral,
open and technically-viable proposals for internet-wide
currency/commodity, market and financial endpoint identification) have
already been reasonably met.

This has opened the door to the potential for faster progress on the
IFEX protocol itself ("a mechanism for the identification,
negotiation, description, execution and management of financial
transactions over their lifetime"), like, right about now. Which is
kind of the same zone of potential functionality (at least in a naive,
linguistic comparison sense) that people are talking about here.
Because of the hope to garner more interest from the Bitcoin community
with this post (do read on!), I spent a bunch of hours today cleaning
up and converting the IFEX Protocol's current breezy-draft form back
from the wiki formatting it had been lazing and grazing (and growing,
albeit slowly) in for the greater part of the year and moving to
Github (forks and issues very much encouraged) over here:
https://github.com/globalcitizen/ifex-protocol
  (Discussion list at http://group.ifex-project.org/ actually has
quite a few members at present, despite appearances to the contrary)

> implemented on top of ifex.

Re: "implemented on top of ifex", this is kind of opposite to how IFEX works.

IFEX's idea is to provide a flexible yet stable protocol that lets
individual (potential, ongoing, or completed) transactions on
arbitrary (legacy, conventional, emerging, or future) settlement
systems (in arbitrary currencies/commodities) to be described and
facilitated (executed, routed, monitored, etc.) in real time, by
describing accurately the objective properties of each of those
systems and components.

So, for example, an end user, requiring a transfer of  of 
currency/commodity from 'point a' to 'point b' would find routes to
achieve that, evaluate them in terms of monetary and temporal
overheads against their own trust and risk models plus any legal,
privacy or other requirements in order to select and effect the most
appropriate manner of settlement.

In short, IFEX sees Bitcoin as having such-and-such properties,
matches that to a need to transfer some funds, and effects the
transfer, monitoring and/or reporting on its state in a normalized
fashion throughout its lifetime.

I'll try again to describe the motivating use case:
==
Recognising that Bitcoin is not the only emerging financial community
or settlement system facing real world business integration
challenges, and recognising the significant complexity of these in
common situations (multi-hop transactions, arbitrary currency
transactions, foreign exchange automation, liquidity guarantee
challenges, settlement latency negotiation, invoicing periods,
commercial payment or shipping terms, sovereign (exchange rate
fluctuation) and other forms of risk management, potentially
simultaneous multi-level fee, tax and discount requirements,
product/service coding, line items, complex tax calculations
(particularly in the US, and which may be based on both buyer and
seller geolocation), legal requirements to include various metadata,
etc.), instead of investing valuable developer time on internal
implementation (and subsequent maintenance) of a tightly-scoped
(==crippled?) business-level protocol extension to Bitcoin that can be
perhaps fairly characterised as unlikely to quickly evolve to meet
many of these real world requirements, and with as yet unclear real
world demand for such from the Bitcoin community, w

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Mike Hearn
The current spec is ambiguous in the case of what to do if the invoice
contains one output of a fixed amount and one or more outputs of an
unspecified amount. Should the user be prompted once per output? That
seems suboptimal. Prompted once for a value that's then randomly
distributed between all open-value outputs? It seems this ability of
the protocol is somewhat more complex than it appears. The ability to
have open outputs is nice for tips though.

You could consider moving pki_type and pki_data into a separate
message and making both fields required, then making the pki message
optional. Otherwise you can have pki_type set but no data or
vice-versa. It doesn't make much difference in the end, just slightly
improves the automatic sanity checks produced by the proto compiler.

w.r.t SIGHASH_ANYONECANPAY. I think it's best not to use this
routinely as it relaxes the signature checks in ways that may open
non-obvious holes when combined with other features. I thought we
pretty much had consensus on recursively calculating fees including
dependents in the memory pool?

Peter is correct that there are a few degrees of freedom in protobuf
serialization, though far fewer than with JSON. I'd like to think
upstream would be open to resolving these ambiguities.
Re-serialization of an Invoice message in the Payment message is a
potential source of mistakes. There's no need to ever concatenate
these messages and alternative implementations that don't order
serialized fields by tag number are missing an important optimization,
so they could be fixed. The main issue is treatment of unknown fields.
If/when the Invoice message is extended with other fields that are
round-tripped through an old client, the data may get lost. JSON
doesn't help resolve that either, of course. There are a few
solutions:

1) Change the type of the Invoice field in Payment to be "bytes" and
set it to be the hash of the originally received binary Invoice
message. Downside, requires merchants to track all outstanding
invoices.
2) Ask protobufs upstream to modify the spec/implementations so
ordering of unknown fields is specified. The Python implementation
could be extended to support them so Python implementors don't end up
with accidental message downgrades.
3) Language of the spec could be changed to explicitly state that the
received Invoice may not be binary-identical to the one that was sent,
in the case of a client that incorrectly downgrades the message. Thus
you'd be expected to check what the Invoice was using merchant_data
which is opaque and could just be, eg, a database key on your own end.
4) Instead of submitting the entire Invoice back to the merchant, just
the merchant_data could be in the Payment message.

Of the four options I prefer the last. What is the use case for
resubmitting the entire invoice anyway? Even if protobufs are improved
so handling of round-tripping new messages through old [Python]
clients is more rigorous, some implementors will probably convert the
protobuf objects into some internal forms for whatever reason (or
serialize them to a database, etc) and they're very likely to mess up
the handling of unknown fields when they do it.

--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-28 Thread Peter Todd
On Mon, Nov 26, 2012 at 05:37:31PM -0500, Gavin Andresen wrote:
> Why not JSON?
> -
> 
> Invoice, Payment and Receipt messages could all be JSON-encoded. And
> the Javascript Object Signing and Encryption (JOSE) working group at
> the IETF has a draft specification for signing JSON data.
> 
> But the spec is non-trivial. Signing JSON data is troublesome because
> JSON can encode the same data in multiple ways (whitespace is
> insignificant, characters in strings can be represented escaped or
> un-escaped, etc.), and the standards committee identified at least one
> security-related issue that will require special JSON parsers for
> handling JSON-Web-Signed (JWS) data (duplicate keys must be rejected
> by the parser, which is more strict than the JSON spec requires).
> 
> A binary message format has none of those complicating issues. Which
> encoding format to pick is largely a matter of taste, but Protocol
> Buffers is a simple, robust, multi-programming-language,
> well-documented, easy-to-work-with, extensible format.

I'm not sure this is actually as much of an advantage as you'd expect. I
looked into Google Protocol buffers a while back for a timestamping
project and unfortunately there are many ways in which the actual binary
encoding of a message can differ even if the meaning of the message is
the same, just like JSON.

First of all while the order in which fields are encoded *should* be
written sequentially, parsers are also required to accept the fields in
any order. There is also a repeated fields feature where the
fields can either be serialized as one packed key-list pair, or multiple
key-value(s) pairs; in the latter case the payloads are concatenated.

The general case of how to handle a duplicated field that isn't supposed
to be repeated seems to be undefined in the standard. Yet at the same
time the standard mentions creating messages by concatenating two
messages together. Presumably parsers treat that case as an error, but I
wouldn't be surprised if that isn't always true.

Implementations differ as well. The current Java and C++ implementations
write unknown fields in arbitrary order after the sequentially-ordered
known fields, while on the other hand the Python implementation simply
drops unknown fields entirely. As far as I know no implementation
preserves order for unknown fields.

Finally, while not a Protocol Buffers specific problem, UTF8 encoded
text isn't guaranteed to survive a UTF8-UTFx-UTF8 round trip.  Multiple
code point sequences can be semanticly identical so you can expect some
software to convert one to the other. Similarly lots of languages
internally store unicode strings by converting to something like UTF16.
One solution is to use one of the normalization forms such as NFKD - an
idempotent transformation - although I wouldn't be surprised if
normalization itself is complex enough that implementation bugs exist,
not to mention the fact that the normalization forms have undergone
different versions.

I think the best way(1) to handle (most) the above by simply treating the
binary message as immutable and never re-serializing a deserialized
message, but if you're willing to do that just using JSON isn't
unreasonable either.


1) Of course I went off an created Yet Another Binary Serialization for
my project, but I'm young and foolish...

-- 
'peter'[:-1]@petertodd.org


signature.asc
Description: Digital signature
--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Gavin Andresen
Spec updated: https://gist.github.com/4120476

Notable changes are:

+ Removed SignedReceipt

+ Replaced Invoice.x509chain with a "pki_type" and "pki_data" to make
using other identity systems cleaner.

+ Added a "Why not an existing electronic invoice standard?" section
to the design notes

-- 
--
Gavin Andresen

--
Keep yourself connected to Go Parallel: 
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Mike Hearn
> That hash would then be reported via some secure channel outside of bitcoin's
> domain.

OK, I see. I guess that could be a reasonable fallback for the case
where you have a secure channel.

> I don't understand what the relevance of multi-factor is to invoices?

Yes, exactly. It's about paying who you think you're paying (when you
confirm on a second uncompromised device).

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Andy Parkins
On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote:

> That's pretty much what we have today - in future other schemes can be
> proposed as extensions. Protocol buffers are easily extended, they
> ignore unknown fields. Then you'd wait and see what the invoice
> request looked like and produce an invoice with the right security
> bits.

That's good; I've not done anything with protocol buffers, so wasn't aware it 
was that simple.

> > In particular two additional identification types:
> >  - GnuPG (obviously)
> 
> It's not obvious to me, incidentally. The web of trust has been
> dead-on-arrival since it was first proposed, and for good reasons.
> SSL/X.509, for better or worse, has significant usage.

Sorry, I meant "obviously" in the sense that "obviously that's the other one 
that everyone will want".  The web-of-trust as a universal identity mechanism 
is, I agree, not useful.  However, as a localised, smaller-scale identity 
verification system it's used by every GnuPG user.  You become your own 
certificate authority.  For example, I've set up my whole family with GnuPG; 
I've set them up to trust me to authenticate (and I doubt any of them has ever 
added anyone else).  Then I take on the responsibility of signing all my 
family/friends keys and they don't need to worry about it.

There's no reason that a small group of companies wouldn't do exactly the same 
sort of thing.

> Your case of a small business is a perfect example of people who won't
> be using GPG. If they don't want to buy an SSL cert, they can just as

Bear in mind, I was using that example as an example of a hash protected in a 
GPG envelope, not a GPG-signed invoice.  People who've already got their GPG 
system in place will appreciate being able to leverage it.

> well put a reference number in the memo field or a "Hey Bob, here is
> the bill we discussed". The payer does not get the multi-factor auth

How can they put a hash of an invoice inside the invoice?  In my "hash mode" 
invoices, it would be a random number (or possibly specifying the hash 
algorithm) then the SignedInvoice would simply be the original invoice + hash.  
That hash would then be reported via some secure channel outside of bitcoin's 
domain.

> protection so if their computer has a virus, they may be hosed. But
> that's good incentive for sellers to get verified. Some CA authorities
> do it for free these days.

I don't understand what the relevance of multi-factor is to invoices?  The 
payment is performed via normal bitcoin mechanisms isn't it -- multi-factor or 
not?  This invoice system has one primary job: to ensure that the target of 
the payment is who the payer thinks it is -- that's not affected by multi-
factor methods of protecting my wallet.



Andy

-- 
Dr Andy Parkins
andypark...@gmail.com

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Mike Hearn
> Personally, I'd like to see fewer implicit ties to X509.  With X509 as one
> option.

That's pretty much what we have today - in future other schemes can be
proposed as extensions. Protocol buffers are easily extended, they
ignore unknown fields. Then you'd wait and see what the invoice
request looked like and produce an invoice with the right security
bits.

> In particular two additional identification types:
>
>  - GnuPG (obviously)

It's not obvious to me, incidentally. The web of trust has been
dead-on-arrival since it was first proposed, and for good reasons.
SSL/X.509, for better or worse, has significant usage.

Your case of a small business is a perfect example of people who won't
be using GPG. If they don't want to buy an SSL cert, they can just as
well put a reference number in the memo field or a "Hey Bob, here is
the bill we discussed". The payer does not get the multi-factor auth
protection so if their computer has a virus, they may be hosed. But
that's good incentive for sellers to get verified. Some CA authorities
do it for free these days.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Andy Parkins
On Monday 26 November 2012 22:37:31 Gavin Andresen wrote:

> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.

Personally, I'd like to see fewer implicit ties to X509.  With X509 as one 
option.  For example, I'd much prefer to see a doorway to the future left open 
like this:

message Invoice {
repeated bytes issuerIdentityType;
repeated bytes issuerIdentityBytes;

or similar, instead of "x509chain".

In particular two additional identification types:

 - GnuPG (obviously)
 - Hash based

The hash-based system would be there as a method of leveraging an existing 
trusted connection, without needing to get into the nitty-gritty of 
certificates.  For example, I am paying for something on a web site; I 
presumably already have a secure connection that I trust to that site.  That 
site can issue me an invoice (which is to be sent to the bitcoin client) _and_ 
a hash of the certificate on the same page.

I trust that hash because I received it over a secure connection from a 
trusted source.  When my bitcoin client pops up with the received invoice, it 
shows me the hash of the invoice, and I can be sure that it is from the web 
site I thought it was from.

Imagine I'm a (very) small business, I have two or three customers.  I want to 
email one of my customers an invoice.  I don't want to have to get an X509 
certificate, and I don't necessarily know how.  However, I can ring my 
customer up and say "I've generated an invoice with my bitcoin client, it is 
hashed A7DE-521X-9977.  Write that down and confirm it when you get my 
invoice".  Alternatively, I might attach a file called
invoice-A7DE-521X-9977.bitinv to a signed GnuPG email.  The receipient can 
easily confirm I sent it because the filename must match the contents and 
GnuPG protects against tampering.




Andy

-- 
Dr Andy Parkins
andypark...@gmail.com

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Gavin Andresen
One more thought:

RE: "Receipt" verus "Acceptance" :

I believe "Receipt" is the right term-- it means "I got your payment",
NOT "your payment has cleared."  E.g. if I hand a merchant a paper
check they'll hand me a receipt, but the check could still bounce.
That's the analogy here-- a merchant might give you a receipt, but if
the transaction is rejected by the network for whatever reason (Finney
attack maybe) you cannot expect to go to court with your
invoice/receipt and claim you made a valid payment.


-- 
--
Gavin Andresen

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Gavin Andresen
RE: SignedReceipt:  I agree it is superfluous.  I'll remove it from the spec.

RE: "it is controversial use of the host key to use it for digital
signing of documents"  :  The idea of embedding a x509 certificate
chain comes from the IETF's JSON Object Signing and Encryption working
group "JWS" specification, so I can't be TOO controversial.

RE: the ifex-project and other electronic invoicing standards:  Thanks
for the pointers, Walter! I'm all for adopting the best ideas that
have come before, as long as we end up with something useful and small
enough to convince ourselves it is as secure as we can make it. I
looked at the ifex spec, and quickly got lost. It would help me if you
could write up what our motivating use cases would look like if
implemented on top of ifex.

RE: jgarzik's suggestion to allow txids in the Payment: that worries
me, because it is trivial to create several different variations of
the same transaction (same inputs to same outputs) with different
txids (re-signing inputs uses a different signature nonce, which
changes the signature/txid, for example).

RE: using self-signed certificates:  as Mike said, I assume Bitcoin
clients will have some way of managing root certificates, so experts
could add trusted self-signed certs.

-- 
--
Gavin Andresen

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Michael Gronager
> No, the point of using X509 certs is to get a verified identity (a
> domain name) on the receipt, this is needed for multi-factor
> authentication. You can't do that without some kind of third party
> asserting to an identity.


Agree that you need a third party to verify identity. But the verification 
policy of sites is the job for a payment provider not a payment technology. So 
if you would like verification of the site you could just sign the memo using 
standard S/MIME - why mix it with the payment protocol?

Further, it is controversial use of the host key to use it for digital signing 
of documents, and not even within the policy of a host certificate as far as I 
recall.

The problem you are trying to tackle is that we don't have an ID solution on 
the internet today for this purpose. Certificates for signing messages are 
distributed freely and insecurely only based on temporarily having an email 
from within an organization, and the host certificates are meant for SSL 
handshakes. Funnily, any CA can issue digital certificates for email signing 
for any domain, even though they don't own them, and without notifying the 
owner. DANE actually solves this, but until then using the host certificates is 
unintended use, it is cryptographically a nice solution, but legally and 
standard-wise a hack.

/M
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Mike Hearn
> Further, the inclusion of x509 is not really needed in the spec - you don't 
> need to sign the invoice with an x509, you can use the payment key.

No, the point of using X509 certs is to get a verified identity (a
domain name) on the receipt, this is needed for multi-factor
authentication. You can't do that without some kind of third party
asserting to an identity.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Michael Gronager
> 
> If a merchant/payment processor is willing to take the risk of zero or
> low confirmation transactions (because they are insured against it,
> for example), they were allowed to reply "accepted" immediately, and
> this would be a permanent proof of payment, even if the actual Bitcoin
> transaction that backs it gets reverted.

I guess that moves the discussion from developers to lawyers ;) Even though you 
send a signed receipt, if you can proof you didn't get the money, you will 
never be expected to deliver the goods. (and you can even write that in the the 
receipt ...)

So the SignedReceipt is legally not worth the bits it is composed of, hence I 
don't see the point in supporting it.

If you are selling atoms you can usually wait for N confirmations (even though 
you start shipping I guess you can recall a parcel within 144 blocks). If you 
are selling bits (like access to a site), you can revoke that access once you 
discover the transaction did not go through. So I can't find a use case where a 
Signed Receipt in the proposed form is advantageous.

/M
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Pieter Wuille
On Tue, Nov 27, 2012 at 11:42:01AM +0100, Michael Gronager wrote:
> > 
> > The SignedReceipt message is useful in the sense that it shows
> > confirmation by the merchant, but if you don't get one, you can still
> > prove you paid the invoice. So from this perspective perhaps
> > SignedReceipt should be renamed to Acceptance or something like that,
> > and then the spec should call out that a signed invoice plus accepted
> > Bitcoin transactions is mathematically a proof of purchase.
> 
> Which is why I find the "SignedReceipt" somewhat superfluous. If you 
> implement a payment system, like bit-pay/wallet you are likely to double that 
> through some sort of e-mail receipt anyway.

Gavin's proposal differs in this from my original proposal, where I
exactly *didn't* want to couple the receipt with the acceptance of
the Bitcoin transaction.

If a merchant/payment processor is willing to take the risk of zero or
low confirmation transactions (because they are insured against it,
for example), they were allowed to reply "accepted" immediately, and
this would be a permanent proof of payment, even if the actual Bitcoin
transaction that backs it gets reverted.

For that reason, I also had a separate "pending" state, which means the
receiver isn't willing to just accept the current state as irrevocably
paid. In this case, the sender was allowed to retry until the receipt
sayd "accepted" or "rejected".

The whole point was to avoid that customers/merchants would have to
deal with the uncertainty involved in Bitcoin transaction. At some
point, someone is going to accept the transaction (whether that is at
0 or at 120 confirmations), and acceptance will at the higher level
be considered a boolean anyway - not some "probably, unless reorg".

-- 
Pieter


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Michael Gronager
> 
> The SignedReceipt message is useful in the sense that it shows
> confirmation by the merchant, but if you don't get one, you can still
> prove you paid the invoice. So from this perspective perhaps
> SignedReceipt should be renamed to Acceptance or something like that,
> and then the spec should call out that a signed invoice plus accepted
> Bitcoin transactions is mathematically a proof of purchase.

Which is why I find the "SignedReceipt" somewhat superfluous. If you implement 
a payment system, like bit-pay/wallet you are likely to double that through 
some sort of e-mail receipt anyway.

Further, the inclusion of x509 is not really needed in the spec - you don't 
need to sign the invoice with an x509, you can use the payment key. The proof 
would still be equally binding, and valid also for non holders of x509 (server) 
certificates (like normal people).
Finally, host certificates does not normally keep in their "purpose" S/MIME 
Signing. So you are bending the intended use of the x509 certificate anyway.

/M

> 
> --
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Mike Hearn
On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager  wrote:
> * What if the SignedReceipt is not received AND the transactions IS posted on 
> the p2p.

I think this is a problem with confusing terminology rather then the
spec itself.

The original formulation had a receipt being something generated
purely by the buyer. The signed Invoice message  + the Bitcoin
transactions paying to the outputs + the merkle branches showing
acceptance by the network *is* the receipt.

The SignedReceipt message is useful in the sense that it shows
confirmation by the merchant, but if you don't get one, you can still
prove you paid the invoice. So from this perspective perhaps
SignedReceipt should be renamed to Acceptance or something like that,
and then the spec should call out that a signed invoice plus accepted
Bitcoin transactions is mathematically a proof of purchase.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Michael Gronager
Short comments:

* What if the SignedReceipt is not received AND the transactions IS posted on 
the p2p. Then you have payed for the goods, but you don't have a receipt. This 
could happen both from malice or system failures.
** Suggestion - sign the invoice with the key to which to send the transaction, 
the proof of payment, equivalent to a signed receipt is then in the blockchain.

This scheme would work both with or without x509, if you want to include x509, 
the message in the invoice could simply be signed by the x509 certificate as 
well.

PRO: Any user can send signed invoices, not only those with a x509 cert.
PRO: No limbo situation with no SignedReceipt
CON: This disables the use of anything but payment to key/address incl multisig 
etc.

However, the wast majority of use will anyway be payment to key/address.

Support of general pay to script could be supported through the payment scheme 
proposed earlier by Mike: No non-fee payments are accepted, except in a group - 
i.e. it is up to the merchant to generate the final transaction incl the fees, 
and that one could be to a general script. This also keeps the support of pay 
to general script needed for a client to a minimum.

Cheers,

Michael



--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-27 Thread Mike Hearn
Luke-Jr - common subset of what operating systems ship is fine for me
as long as people do due diligence around mobile OS' here. It seems
easier to me to just grab a list from a popular browser, on the
grounds that SSL is mostly used by them so nobody is going to buy an
SSL cert rejected by IE/Firefox/Chrome/etc. But intersecting OS lists
is effectively the same.

For my own clients I'd just ship my own copy of the canonical CA certs
regardless, because integrating with each operating systems
proprietary crypto APIs is a lot of work vs just loading a pem file
into OpenSSL. If there are a lot of people who want to use the OS cert
management UIs then I guess that can be a point wallet clients compete
on.

> Removing that and adding a opaque string called domain name, or
> identityName would be sufficient to move the conversation forward
> without the x.509 baggage.

But it would result in implementations that do not meet the requirements.

Yes, X.509 has problems. It's in the proposal because we can get the
effect we want (verifiable domain names in the UI) in about 50 lines
of code, today, with the id-verified keys people actually have already
bought.

As Gavin says, we can add optional fields later to extend the protocol
in a backwards compatible way.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Walter Stanish
>> We are not establishing an IETF working group, which is an option that
>> was explored prior to the Paris meeting and has been sidelined at
>> present for depth-of-bureaucracy by the backing commercial entities.
>> Rather, we are establishing a top-level IANA registry group. This is
>> not anticipated by the IETF old-guard working with us to be either (a)
>> controversial or (b) possible to block.
>
> My last note in this sub-thread.

Mine too!

> There are no IANA registry groups, there is no such thing, and no way
> to form one.

Reading between the lines, I believe this phrase, which is not my own
but that of experienced IETF staff, refers to the groups visible at
http://www.iana.org/protocols/ (which you yourself cited). Whether it
is formally used or not is unknown to me.

> The IETF can ask the IANA to form a registry but these
> things take lots of support and take a long time,

Expert opinion estimates six weeks, and by current estimates, we
should have an arrival circa February.

> and these are only
> created through standards track RFC. ICANN runs the IANA and there is
> no such framework that you elude to. Review
> http://www.iana.org/protocols/

I would like to suggest that perhaps exactly this sort of banter is an
excellent illustration for the Bitcoin community of what we have been
up against in this (conceivable simple an public benefit oriented)
endeavour. If you also look at the fact that the ISO4217 registry (to
take currency/commodity codes as just one example) there is apparently
not even a public list of requirements for codepoint issue.  This sort
of thing is *exactly* why the internet community appears to
desperately need an open registry - allowing public internet bodies
(IANA) to function to support innovation and interconnectivity for all
sectors of the internet's various financial communities so that
anyone, including innovators, can obtain interoperability via simple,
hassle-free paths, without encountering self-important bureaucrats.

We anticipate victory circa February.

- Walter

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Rick Wesson
>
> We are not establishing an IETF working group, which is an option that
> was explored prior to the Paris meeting and has been sidelined at
> present for depth-of-bureaucracy by the backing commercial entities.
> Rather, we are establishing a top-level IANA registry group. This is
> not anticipated by the IETF old-guard working with us to be either (a)
> controversial or (b) possible to block.

My last note in this sub-thread.

There are no IANA registry groups, there is no such thing, and no way
to form one. The IETF can ask the IANA to form a registry but these
things take lots of support and take a long time, and these are only
created through standards track RFC. ICANN runs the IANA and there is
no such framework that you elude to. Review
http://www.iana.org/protocols/

If you are applying for a gTLD, good luck with that.


-rick

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Walter Stanish
>> We are currently working with IETF staff, with open offers of support
>> from multiple well funded commercial bodies, to transition these
>> proposals through to IANA management.
>
> I hate to inform you that you have been mislead. The IETF and the IANA
> do not operate as you outlined above. Having spent too many years
> within ICANN/IETF/IANA I can assure you are mistaken.
> Your drafts are expired and it appears that there is no support for a
> "finance" working group in the IETF.

We are not establishing an IETF working group, which is an option that
was explored prior to the Paris meeting and has been sidelined at
present for depth-of-bureaucracy by the backing commercial entities.
Rather, we are establishing a top-level IANA registry group. This is
not anticipated by the IETF old-guard working with us to be either (a)
controversial or (b) possible to block.

- Walter

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Rick Wesson
On Mon, Nov 26, 2012 at 7:16 PM, Walter Stanish  wrote:
>>> X-ISO4217-A3
>>
>> I see that draft-stanish-x-iso4217-a3 is not standards track, is there
>> a reason for this?
>
> Of the three currently published proposals, all are essentially IANA
> registry proposals.
>
> We are currently working with IETF staff, with open offers of support
> from multiple well funded commercial bodies, to transition these
> proposals through to IANA management.

I hate to inform you that you have been mislead. The IETF and the IANA
do not operate as you outlined above. Having spent too many years
within ICANN/IETF/IANA I can assure you are mistaken.
Your drafts are expired and it appears that there is no support for a
"finance" working group in the IETF.


-rick

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Walter Stanish
>> X-ISO4217-A3
>
> I see that draft-stanish-x-iso4217-a3 is not standards track, is there
> a reason for this?

Of the three currently published proposals, all are essentially IANA
registry proposals.

We are currently working with IETF staff, with open offers of support
from multiple well funded commercial bodies, to transition these
proposals through to IANA management.

It appears that the Independent Stream Editor path will be used to
transition these through to IANA, at which time the proposals
themselves will be converted to Informational status.

(As far as I understand right now, Within the IETF, Standards Track
has special meaning and entails relatively large degrees of
bureaucracy that are not within the current contributors' resources.
It is also worth pointing out that many popular protocols implemented
on the majority of systems (IIRC, such as IMAP) never reach formal
standardization for this reason. It should be noted that in these
cases, this does not make the protocols any less attractive as
potential components for system implementation.)

> It also doesn't appear to address ~any of the the targeted items here.
> Is there another draft I should be looking for which has more overlap
> with the discussion here?

As outlined in the previous post:
  - Internet Financial EXchange (IFEX). A proposal under development
that facilitates the negotiation of financial transactions between
internet-based financial endpoints. (The area we would love your
input) http://www.ifex-project.org/our-proposals/ifex

As well as the information linked to above, significant but not
particularly well grounded discussions have occurred regarding the
IFEX-based paradigm for settlement versus some other proposed
paradigms, in particular Ripple (as it appeared some months ago),
which can be read here:
https://groups.google.com/forum/?fromgroups#!topic/rippleusers/v4bEBZZVEsA[1-25]

Kind regards and with the hopes of combining our efforts as a joint
proposal that can benefit other currencies/commodities and settlement
systems as well as Bitcoin,
Walter Stanish
Skype:walter.stanish

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gregory Maxwell
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish  wrote:
> X-ISO4217-A3

I see that draft-stanish-x-iso4217-a3 is not standards track, is there
a reason for this?

It also doesn't appear to address ~any of the the targeted items here.
Is there another draft I should be looking for which has more overlap
with the discussion here?

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Walter Stanish
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."

I agree this is a very pertinent subject, and with a bit of looking
around it is clear that there is a requirement here for emerging
financial ecosystems of many types, certainly not just for the Bitcoin
community, which until now seems to have been getting along just about
OK despite the current levels of complexity.

That said, I have a number of serious concerns with the proposal.

1. Undue Broadening of Scope: From an architectural perspective, if
one accepts the unix mantra of "do one thing and do it well" as
reasonable and time-proven doctrine, given that Bitcoin is already
trying to be both a commodity and a distributed consensus-based
settlement system, does it really make sense to attempt to tack-on
business-level functions?

2. X.509: I have read (somewhere or other, recently) that it is
generally considered bad form to mandate specific cryptographic
systems in new protocols where open support is possible. Given the
recent issues with X.509, the security nightmare that already exists
with the volume of (sometimes cracked, sometimes
government-compromised?) issuers, and the complexity of the scheme, it
seems a little strange to singularly mandate X.509, despite its
widespread use at present.  There are also a swathe of potential
issues around DNS interdependence, information leakage within
certificates themselves and/or their DNS-interpretation by clients,
etc. I would consider suggesting open support with initial support for
GPG, as it is apparently preferred as a simple and further
decentralized solution by the majority of the open source and
cryptographic software development community.

3. Failure to Review Existing Work: I would urge anyone to be wary of
adopting any proposal that does not inform itself through reference to
existing protocols in the same area.  In this area there are a few
protocols in current use (chiefly in Europe) such as those listed at
http://en.wikipedia.org/wiki/Invoice#Electronic_invoices as well as
various hosted platforms such as http://xero.co.nz/ (chiefly
Australia/New Zealand). Often, existing work shows its age with
after-the-fact alterations that sit poorly with initial assumptions:
exactly the kind of situation one can walk in to developing against a
proposal before adequately researching the area.

4. Complexity of Metadata: Physical and digital invoicing for
businesses operating at scale often requires delivery terms, product
classification codes, locale-specific taxation (often at multiple
levels), various fees and discounts (sometimes fulfillment-speed
linked with multiple tiers/thresholds), and other features that I am
skeptical are ever going to be made fully available within a business
protocol tacked on to a hybrid digital currency/settlement system
(like Bitcoin) as a secondary concern.

5. Non-BTC Currencies/Currency-like Commodities: No approach to
non-BTC currencies appears to have been made, which makes the
"invoice" of limited utility for almost all businesses, save those
willing to accept all of the 'capital risk' (exchange rate fluctuation
risk) inherent in a BTC-based fulfilment process with a potential term
long enough to justify an invoicing process. (Does this narrow scope
actually cover any existing business?)

6. DNS: As already mentioned with regards to X.509: a huge red flag as
an area of potential vulnerability, or at least information leakage.

I must now admit that in raising the above I am definitely biased.  My
employer (Payward, Inc.) and other organizations (OpenCoin, Inc.,
etc.) have been working with the Internet Engineering Task Force
(IETF) on tabling some open proposals within this area under the
auspices of the Internet Financial Exchange Project
(http://ifex-project.org/).  Our hope is to facilitate the requisite
standardisation within internet-connected systems to deal with what is
perhaps fairly characterised as a relatively heterogeneous outlook on
the rise of cryptographic (and other alternate) currencies and
commodities, and emerging settlement infrastructures.

Whilst the current Bitcoin proposal is admirable for correctly raising
the area as one of immediate concern, I hope that the above points out
some of the perhaps as-yet unconsidered complexities and draws in to
question whether Bitcoin is in fact the appropriate place to implement
a solution, given the hassles that will entail.  After all, wouldn't
Bitcoin developer time would be better spent improving the core of
bitcoin (ie. distributed settlement system and commodity) rather than
adding new features?

I would invite parties within the Bitcoin community with an interest
in non directly settlement-linked financial transaction negotiation
and reporting features to con

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gavin
Supporting DNSSEC/DANE in the future when they are widely deployed is a great 
idea.

Note that the x509chain field is 'repeated', and any repeated field may have 
zero entries. So I would suggest supporting other PKI systems in the future by 
adding optional new fields (for maximum compatibility or security merchants 
might want to include both a x509chain AND 

--
Gavin Andresen


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Rick Wesson
On Mon, Nov 26, 2012 at 4:26 PM, Mike Hearn  wrote:
>> Perhaps we should agree to talk about everything _except_ that first?
>
> Yeah, alternatives to X.509 chains don't interest me right now except
> in the sense that they should be cleanly implementable with future
> extensions.
>
> So if you care about DANE or DNSSEC or custom PKI infrastructures or
> whatever, rather than proposing them as replacements here (DOA), just
> figure out how you would extend the protocol in Gavins mail in a
> future extension. If you can't see a clean way to do it then let's
> discuss that. If you can think of a way to do it then let's table it.
> Better replacements can come in later BIPs.

The only part that has an x509 cert associated is in the invoice message.

message Invoice {
//repeated bytes x509chain = 1;
optional string domainName =1;
repeated Output outputs = 2;
required uint64 time = 3;
optional uint64 expires = 4;
optional bool single_use = 5 [default = true];
optional string memo = 6;
optional string receiptURI = 7;
optional bytes merchant_data = 8;
}

Removing that and adding a opaque string called domain name, or
identityName would be sufficient to move the conversation forward
without the x.509 baggage.

-rick

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Tuesday, November 27, 2012 12:16:07 AM Gregory Maxwell wrote:
> On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr  wrote:
> > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> >> Would you find it acceptable if something supported a static whitelist
> >> plus a OS provided list minus a user configured blacklist and the
> >> ability for sophisticated users to disable the whitelist?
> > 
> > How is this whitelist any different from the list of CAs included by
> > default with every OS?
> 
> Because the list is not identical (and of course, couldn't be without
> centralizing control of all OSes :P ) meaning that the software has to
> be setup in a way where false-positive authentication failures are a
> common thing (terrible for user security) or merchants have to waste a
> bunch of time, probably unsuccessfully, figuring out what certs work
> sufficiently 'everwhere' and likely end up handing over extortion
> level fees to the most well established CAs that happen to be included
> on the oldest and most obscure things.

There is a common subset of CAs which are included in all OSs.
That's the "whitelist equivalent". We or someone else could even setup a list 
of these common CAs for merchants if that is needed.

The fees CAs charge for certs is a flaw in the CA model in general, I don't 
see that it's important for us to solve it.


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Rick Wesson
On Mon, Nov 26, 2012 at 4:31 PM, Luke-Jr  wrote:
> On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
>> Another nifty thing is that it can associate a cert to a domain and a
>> payment address, if one were to put said address in the DNS :)
>>
>> Now I am sure the majority of the bitcoin user-base desires anonymity,
>> but as a merchant I would like to be knowable and wouldn't mind it if
>> my identity and those of my transactions were "known" and associated
>> both with my domains and x.509 cert. In most commercial transactions
>> (which include many of those that leverage invoices) identity is
>> important, at least for the merchant.
>
> Anonymity isn't a feature we claim to have, nor a goal of the project for the
> most part. Using a single Bitcoin address has many problems besides non-
> anonymity: your customers are denied basic privacy and there is no good way to
> guarantee the user who says he paid you really did (since transaction ids are
> public record, anyone can claim they sent it).
>
> In short, it is for the most part considered a rule to always use a unique
> address per transaction or at least per customer.

putting payment addresses in the DNS does not require that only a
single address be used. This is an assumption and a possible use case,
but there is no requirement that payment addresses must be 1:1
associated.

-rick

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
> Another nifty thing is that it can associate a cert to a domain and a
> payment address, if one were to put said address in the DNS :)
> 
> Now I am sure the majority of the bitcoin user-base desires anonymity,
> but as a merchant I would like to be knowable and wouldn't mind it if
> my identity and those of my transactions were "known" and associated
> both with my domains and x.509 cert. In most commercial transactions
> (which include many of those that leverage invoices) identity is
> important, at least for the merchant.

Anonymity isn't a feature we claim to have, nor a goal of the project for the 
most part. Using a single Bitcoin address has many problems besides non-
anonymity: your customers are denied basic privacy and there is no good way to 
guarantee the user who says he paid you really did (since transaction ids are 
public record, anyone can claim they sent it).

In short, it is for the most part considered a rule to always use a unique 
address per transaction or at least per customer.

Luke

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Mike Hearn
> Perhaps we should agree to talk about everything _except_ that first?

Yeah, alternatives to X.509 chains don't interest me right now except
in the sense that they should be cleanly implementable with future
extensions.

So if you care about DANE or DNSSEC or custom PKI infrastructures or
whatever, rather than proposing them as replacements here (DOA), just
figure out how you would extend the protocol in Gavins mail in a
future extension. If you can't see a clean way to do it then let's
discuss that. If you can think of a way to do it then let's table it.
Better replacements can come in later BIPs.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gregory Maxwell
On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr  wrote:
> On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
>> Obviously the state of the world with browsers is not that good... but
>> in our own UAs we can do better and get closer to that.
>
> This effectively centralizes Bitcoin (at least in the eyes of many) and even
> if each competing client had their own list, you'd be back to the original
> "problem" of not being sure your CA is on all lists.

Thats the CA model generally. It _is_ a distributed-centralized model
in practice.

>> Would you find it acceptable if something supported a static whitelist
>> plus a OS provided list minus a user configured blacklist and the
>> ability for sophisticated users to disable the whitelist?
>
> How is this whitelist any different from the list of CAs included by default
> with every OS?

Because the list is not identical (and of course, couldn't be without
centralizing control of all OSes :P ) meaning that the software has to
be setup in a way where false-positive authentication failures are a
common thing (terrible for user security) or merchants have to waste a
bunch of time, probably unsuccessfully, figuring out what certs work
sufficiently 'everwhere' and likely end up handing over extortion
level fees to the most well established CAs that happen to be included
on the oldest and most obscure things.

Taking— say— the intersection of Chrome, Webkit, and Firefox's CA list
as of the first of the year every year and putting the result on a
whitelist would be a possible nothing-up-my-sleeve approach which is
not as limited as having some users subject to the WinXP cert list,
which IIRC is very limited (but not in a way that improves security!).

Jeff wrote:
> Self-signed certs are quite common, because it is easier, while being
> more secure than http://

Uhh.  Really?   Well, I agree with you that they should be (I
unsuccessfully lobbied browser vendors to make self-signed https on
http URLs JustWork and simply hide all user visible evidence of
security), but the really nasty warnings on those sites undermines the
security of the sites _and_ of other HTTPS sites because it conditions
users to click ignore-ignore-ignore. I don't think they are all that
common.

One thing which I think will be hard for us in this discussion is
being sensitive to the (quite justified!) concerns that the current CA
system is absolute rubbish, both terrible for security, usability, and
an unreasonable barrier to entry relative to the provided security—
without allowing the discussion to be usurped by everyone's pet
replacement, which there are a great many of with varying feasibility
and security.

Perhaps we should agree to talk about everything _except_ that first?

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Rick Wesson
I hope you all take a moment to see what DANE leverages with DNSSEC
and SelfSigned x.509 certs. DANE provides the capability for any
entity to associate a self signed certificate with a domain name. This
capability removes the critical path of whitelists and/or Root CA
certs.

Another nifty thing is that it can associate a cert to a domain and a
payment address, if one were to put said address in the DNS :)

Now I am sure the majority of the bitcoin user-base desires anonymity,
but as a merchant I would like to be knowable and wouldn't mind it if
my identity and those of my transactions were "known" and associated
both with my domains and x.509 cert. In most commercial transactions
(which include many of those that leverage invoices) identity is
important, at least for the merchant.

-rick


On Mon, Nov 26, 2012 at 3:52 PM, Jeff Garzik  wrote:
> On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen  
> wrote:
>> This is the next big "lets all agree to do things the same way" thing
>> I think we should tackle. I'm particularly looking for feedback from
>> other bitcoin client developers, even if it is just a quick "looks
>> reasonable, if everybody else is going to do it then I will
>> (eventually) too..."
>
> Comments:
>
> 1) Payment message should include ability to specify the transaction
> _or_ a transaction id sent via normal means over the network.
>
> 2) I think a significant bitcoin userbase will want to operate outside
> the full root-CA chain.  Just look at https:// websites now.
> Self-signed certs are quite common, because it is easier, while being
> more secure than http://
>
> So some provision for self-signed certs, a use case in wide use
> elsewhere, or equivalent thereof, seems reasonable.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgar...@exmulti.com
>
> --
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Rick Wesson
X.509 has some problems we have recent experience with. I'd prefer to
leverage something like DANE which looks to help with assertions
around certificates and creates an option around the CAs and x.509
roots.

-rick


On Mon, Nov 26, 2012 at 2:37 PM, Gavin Andresen  wrote:
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."
>
> Thanks to Pieter Wuille and Mike Hearn for lots of feedback and
> suggestions and brainstorming.
>
> This document is online at https://gist.github.com/4120476
>
> If you respond to this message, please be considerate of people who
> subscribe to the digest version of this mailing list and trim your
> response.
>
>
> Invoices, Payments and Receipts for Bitcoin Transactions
> 
>
> This document proposes protocol buffer-based formats for signed,
> authenticated "invoices" and "receipts" -- requests for payment, and
> proof-of-payment.
>
> Separate documents propose an extension to the Bitcoin URI syntax and
> new MIME types to support them.
>
> Motivation
> ==
>
> The idea of a "payment protocol" to improve on Bitcoin addresses has
> been around for over a year. Users have been asking for some features
> in this proposal (like the ability to provide a refund address so
> overpayments or refunds can be returned to customers without the need
> to ask them for their address) for two or three years, and have
> started to work around shortcomings in the Bitcoin payment process
> with creative (but inefficient) uses of transactions.
>
> The key features of this proposal are:
>
> + Requests for payment (Invoices) are tied to authenticated identities
> using the only widely-deployed identity authentication system we have
> right now (X.509 certificates signed by root certificate authorities)
> + Invoices include a user-friendly description of what the payment is for
> + Payments include where refunds should be sent
> + At the end of the payment process, the customer holds a
> cryptographically signed Receipt that can be used as proof-of-payment
> if there is any dispute with the merchant.
>
>
> Specification
> =
>
> Invoice/SignedInvoice
> -
>
> An Invoice is a request for payment from a merchant to a customer:
>
> ::
>
> message Output {
> optional uint64 amount = 1;
> required bytes script = 2;
> }
>
> amount: Number of satoshis (0.0001 BTC) to be paid. If not given
> or zero, then the customer will be asked how much to pay.
>
> script: a "TxOut" script to which the customer should direct payment.
> This will normally be one of the standard Bitcoin transaction script
> (e.g. pubkey OP_CHECKSIG).
>
> ::
>
> message Invoice {
> repeated bytes x509chain = 1;
> repeated Output outputs = 2;
> required uint64 time = 3;
> optional uint64 expires = 4;
> optional bool single_use = 5 [default = true];
> optional string memo = 6;
> optional string receiptURI = 7;
> optional bytes merchant_data = 8;
> }
>
> outputs: one or more outputs where Bitcoins are to be sent.
>
> x509chain: one or more DER-encoded X.509 certificates that identifies
> the merchant. See the "Certificates" section below for details.
>
> time: Unix timestamp (seconds since 1-Jan-1970) when the Invoice was created.
>
> expires: Unix timestamp after which the Invoice should be considered
> invalid. If not given, the Invoice may be re-used until the earliest
> certificate expiration date in the X509chain.
>
> single_use: If true, this Invoice should be used for only one payment.
> If false, it may be added to the user's address book and used
> repeatedly until it expires (e.g. for donations or a recurring
> payment).
>
> memo: UTF-8 encoded, plain-text (no formatting) note that should be
> displayed to the customer, explaining what this Invoice is for.
>
> receiptURI: Secure (https) URI where a Payment message (see below) may
> be sent to obtain a SignedReceipt as proof-of-payment.
>
> merchant_data : Arbitrary data ignored by the client that may be used
> by the merchant to identify the Invoice.
>
> ::
>
> message SignedInvoice {
> required Invoice invoice = 1;
> required bytes signature = 2;
> }
>
> A SignedInvoice is an Invoice signed using the private key
> corresponding to the public key in the first certificate in the
> x509chain and the HMAC SHA-256 algorithm.
>
> When a Bitcoin client receives a SignedInvoice, it must authorize
> payment by doing the following:
>
> 1. Validate the x509chain certificate chain up to it's list of root
> certificate authorities
> 2. Validate that the time on the customer's system is before Invoice.expires
> 3. Display the "Common Name" (CN) s

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Jeff Garzik
On Mon, Nov 26, 2012 at 5:37 PM, Gavin Andresen  wrote:
> This is the next big "lets all agree to do things the same way" thing
> I think we should tackle. I'm particularly looking for feedback from
> other bitcoin client developers, even if it is just a quick "looks
> reasonable, if everybody else is going to do it then I will
> (eventually) too..."

Comments:

1) Payment message should include ability to specify the transaction
_or_ a transaction id sent via normal means over the network.

2) I think a significant bitcoin userbase will want to operate outside
the full root-CA chain.  Just look at https:// websites now.
Self-signed certs are quite common, because it is easier, while being
more secure than http://

So some provision for self-signed certs, a use case in wide use
elsewhere, or equivalent thereof, seems reasonable.

-- 
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> Obviously the state of the world with browsers is not that good... but
> in our own UAs we can do better and get closer to that.

This effectively centralizes Bitcoin (at least in the eyes of many) and even 
if each competing client had their own list, you'd be back to the original 
"problem" of not being sure your CA is on all lists.

> Would you find it acceptable if something supported a static whitelist
> plus a OS provided list minus a user configured blacklist and the
> ability for sophisticated users to disable the whitelist?

How is this whitelist any different from the list of CAs included by default 
with every OS?

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gregory Maxwell
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr  wrote:
> On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
>> They could be included as well of course, but from a seller
>> perspective the most important thing is consistency. You have to be
>> able to predict what CAs the user has, otherwise your invoice would
>> appear in the UI as unverified and is subject to manipulation by
>> viruses, etc.
>
> That's expected behaviour - except it's mainly be manipulated by *users*, not
> viruses (which can just as easily manipulate whatever custom cert store we
> use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no
> matter who Joe is or what connections he has.
>
>> So using the OS cert store would effectively restrict merchants to the
>> intersection of what ships in all the operating systems their users
>> use, which could be unnecessarily restrictive. As far as I know, every
>> browser has its own cert store for that reason.
>
> Browsers with this bug are not relevant IMO.


This is messy.   It's important to people to know that their cert will
be accepted by ~everyone because non-acceptance looks like malice.  If
the cert system is actually to provide value then false positives need
to be low enough that people can start calling in law enforcement,
computer investigators, etc.. every time a cert failure happens.
Otherwise there is little incentive for an attacker to not _try_.

Obviously the state of the world with browsers is not that good... but
in our own UAs we can do better and get closer to that.

Would you find it acceptable if something supported a static whitelist
plus a OS provided list minus a user configured blacklist and the
ability for sophisticated users to disable the whitelist?

This way people could trust that if their cert is signed via one on
the whitelist they'll work for ALL normal users.. and the UI can have
very strong behavior that protects people (e.g. no 'click here to
disable all security because tldr' button)... but advanced users who
can deal with sorting out failure can still have complete control
including OS based control.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Mike Hearn
> That's expected behaviour - except it's mainly be manipulated by *users*, not
> viruses (which can just as easily manipulate whatever custom cert store we
> use).

The point of using signed invoices as virus protection isn't to change
what the user sees on the infected host. The point is the invoice can
be relayed to a second device that isn't also compromised which then
independently renders a payment confirmation screen (like your mobile
phone), and it has an identifier in it that's useful to people, like
bitmit.net instead of an address.

If it was just showing you a Bitcoin address, that doesn't mean
anything to you so a virus on your PC could wait until you want to
make a large payment somewhere and swap out the address in use. You'd
never know it was the wrong address and you'd happily confirm on your
second device.

For this to work, the seller has to be able to predict what certs you
have in all your devices. If it's up to the OS vendors then it's hard
to know and in practice all that'll happen is somebody will compile a
list of CAs that are "known good" (ie, present in all deployed mobile
and desktop OS') and that'll be the minimal cert list. No different to
if it was hard-coded in the spec.

> If I don't trust Joe's certs, I don't want Bitcoin overriding that no
> matter who Joe is or what connections he has.

Nothing says your wallet software can't provide cert management UI
like browsers do.

In practice I have a feeling that cert management UI is one of the
least used parts of a browser. I've used browsers for years and the
only time I've ever had to go into those screens was to manage
installation/removal of self signed certs used by various
organizations. I never manually revoked a root authority. When it was
necessary due to breaches (Comodo/DigiNotar) the browser makers
revoked them for me.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
> They could be included as well of course, but from a seller
> perspective the most important thing is consistency. You have to be
> able to predict what CAs the user has, otherwise your invoice would
> appear in the UI as unverified and is subject to manipulation by
> viruses, etc.

That's expected behaviour - except it's mainly be manipulated by *users*, not 
viruses (which can just as easily manipulate whatever custom cert store we 
use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no 
matter who Joe is or what connections he has.

> So using the OS cert store would effectively restrict merchants to the
> intersection of what ships in all the operating systems their users
> use, which could be unnecessarily restrictive. As far as I know, every
> browser has its own cert store for that reason.

Browsers with this bug are not relevant IMO.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Mike Hearn
They could be included as well of course, but from a seller
perspective the most important thing is consistency. You have to be
able to predict what CAs the user has, otherwise your invoice would
appear in the UI as unverified and is subject to manipulation by
viruses, etc.

So using the OS cert store would effectively restrict merchants to the
intersection of what ships in all the operating systems their users
use, which could be unnecessarily restrictive. As far as I know, every
browser has its own cert store for that reason.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:02:14 PM Mike Hearn wrote:
> Minor caveat, IMHO we should support all CAs used by the popular
> browsers.

I would prefer using the user-accepted certs at the operating system level...

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Mike Hearn
Obviously this LGTM :)

Minor caveat, IMHO we should support all CAs used by the popular
browsers. This ensures no merchant ever finds that their SSL cert they
already own is OK for the web but not for Bitcoin. I don't see a need
to be stricter here, given all it achieves is signing some data in a
way linked with a domain name.

X.509 is pretty baroque indeed, for our use cases it'd not be hard to
do better. In particular, the inability to delegate properly rather
defeats the benefits of chained certificates. For the payment
processor case what you really want to do is take your keys, then
issue a new cert that is specific to signing Bitcoin transactions and
give that to the payment processor secure in the knowledge that they
cannot MITM your secure connections. Unfortunately X.509 wasn't
designed for the web and thus certificates you buy are marked such
that they are not allowed to sign for other certs (due to lack of real
namespace support).

This leads to the idea of redefining the cert chain part of the
protocol like this:

  repeated bytes x509_chain = 1;

becomes

  message Certificate {
enum Type {
  X509 = 1;
}
required Type type = 1;
required bytes data = 2;
  }

  repeated Certificate cert_chain = 1;

Then if later we want to introduce our own minimal certificate formats
which include features we want, we can add new enum types to do so.

Note that if an old client encounters an invoice with a cert type it
doesn't recognize, it will abort parsing of the message entirely. So
the request to download the invoice should probably include a protocol
version number of some kind so the server knows when it's safe to use
new invoice features.

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development