[Bitcoin-development] Payment Protocol Hash Comments
From BIP70: If pki_type is "x509+sha256", then the Payment message is hashed using the SHA256 algorithm to produce the message digest that is signed. If pki_type is "x509+sha1", then the SHA1 algorithm is used. A couple minor comments; - I think it meant to say the field to be hashed is 'PaymentRequest' not 'Payment' message -- probably got renamed at some point and this is an old reference calling it by its original name. - Could be a bit more explicit about the hashing, e.g. 'copy the PaymentRequest, set the signature field to the empty string, serialize to a byte[] and hash. - SHA1 is retiring, any particular reason to even have it in there at all? - Should there any way for the end-user to see details like the pki_type and the certificate chain, like browser do? Thanks, Jeremy -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
Another example use-case to back up devrandom's point is using a twitter handle as the "merchant name". In that example, a 3rd party service hosts and signs the PaymentRequest, but when someone opens that PaymentRequest in their wallet, they should know that they are paying the specified twitter user. On Sat, Mar 1, 2014 at 12:07 PM, Dev Random wrote: > This looks like a good solution of the delegation use case for > medium/large businesses. > > I'm wondering about the small business case. A small business or an > individual might not have the technical expertise to perform the > delegation signature. Normally the X509 keys are squirreled away on the > merchant's web server and are not accessible through ordinary means. > And actually, the merchant might not even have a standalone web > presence. > > Do you think it makes sense to have another scheme where a merchant can > be name spaced under the payment processor? This would require just one > additional field - the merchant identifier. In effect, the PP would > certify that "PP / merchant-id" generated this invoice directly on the > PP system. > > On Fri, 2014-02-28 at 12:46 +0100, Mike Hearn wrote: > > Now we're starting to see the first companies deploy BIP70, we're > > encountering a need for identity delegation. This need was long > > foreseen by the way: it's not in BIP70 because, well, we had to draw > > the line for v1 somewhere, and this is an issue that mostly affects > > payment processors. But I figured I'd start a thread anyway because > > people keep asking me about it :) > > > > > > Objective > > > > > > Identity delegation means that a payment request can be signed by > > someone who is not holding the certified private key. The most obvious > > use case for this is payment processors like BitPay and Coinbase who > > currently have to sign payment requests as themselves. Other use cases > > might involve untrusted sales agents who want to be able to accept > > payment as their employer, but cannot be trusted with a long-term > > valuable secret, e.g. because they take their phone into areas with > > high crime rates. > > > > > > The lack of this is ok for v1 but not great, because: > > > > > > 1) It requires the name of the *actual* recipient to be put in the > > memo field, otherwise you don't have the nice receipt-like properties. > > The memo field is just plain text though, it doesn't have any > > exploitable structure. > > > > > > 2) It gives a confusing UI, the user thinks they're paying e.g. > > Overstock but their wallet UI tells them they're paying Coinbase > > > > > > 3) Whilst these payment processors currently verify merchants so the > > security risk is low, in future a lighter-weight model or competing > > sites that allow open signups would give a weak security situation: a > > hacker who compromised your computer could sign up for some popular > > payment processor under a false identity (or no identity), and wait > > until you use your hacked computer to make a payment to someone else > > using the same payment processor. They could then do an identity swap > > of the real payment request for one of their own, and your Trezor > > would still look the same. Avoiding this is a major motivation for the > > entire system! > > > > > > Also it just looks more professional if the name you see in the wallet > > UI is correct. > > > > > > Proposed implementation > > > > > > We can fix this with a simple extension: > > > > > > enum KeyType { > > SECP256K1 = 1 > > } > > > > > > message ExtensionCert { > > required bytes signature = 1; > > required bytes public_key = 2; > > required KeyType key_type = 3; > > required uint32 expiry_time = 4; > > optional string memo = 5; > > } > > > > > > // modification > > message X509Certificates { > > repeated bytes certificate = 1; > > repeated ExtensionCert extended_certs = 2; > > } > > > > > > message PaymentRequest { > > // new field > > optional bytes extended_signature = 6; > > } > > > > > > This allow us to define a so-called extended certificate, which is > > conceptually the same as an X.509 certificate except simpler and > > Bitcoin specific. To create one, you just format a ExtensionCert > > message with an ECDSA public key from the payment processor (PP), set > > signature to an empty array and then sign it using your SSL private > > key. Obviously the resulting (most likely RSA) signature then goes > > into the signature field of the ExtensionCert. The memo field could > > optionally indicate the purpose of this cert, like "Delegation to > > BitPay" but I don't think it'd ever appear in the UI, rather, it > > should be there for debugging purposes. > > > > > > The new ExtensionCert can then be provided back to the PP who adds it > > to the X509Certificates message. In the PaymentRequest, there are now > > two signature fields (this is for backwards compatibility). Because of > > how the mechanism is designed they should not interfere with each > > other - o
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
Only if you view bitcoin as no more than a payment network. On Mar 1, 2014 10:24 AM, "Jeff Garzik" wrote: > This is wandering far off-topic for this mailing list. > > On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes wrote: > >> > You can make the same argument against Bitcoin itself you know... > >> > > >> > A Bitmessage-like network would be trivial to front-run via a sybil > >> > attack. It's the fundemental problem with marketplaces - the data > >> > they're trying to publish has to be public. > >> > >> I don't see the Bitcoin analogy... > >> Anyway, I still don't think the seller cares, if he sells at the price > >> he was asking, what would he care about "front running" those parallel > >> networks. > >> I've seen many street markets without "public information" and they > >> work just well. > > > > The spot price for ammonia fertilizer, refined gasoline at terminals, > > and price of tea in china are not 'public information', yet these are > > some of the largest traded commodities in the world, far exceeding > > the drop in the bucket that all cryptocoin transactions make. > > > > I'd further argue that the *actual* price of corn (cash bid price at > > elevators and ethanol plants) is not public information either. There > > is a great deal of money traded in collecting and then distributing the > > 'cleared price' information. Have a look at > > > http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1 > > > > > >> >> I don't think this will be a tragedy, because like we discussed on > >> >> IRC, I don't think the primary goal of markets is price discovery, > but > >> >> trade itself. > >> >> > >> >> About historic data, the actual trades are always public, and some > >> >> kind of "archivers" could collect and maintain old orders for > historic > >> >> bid and asks, etc. > >> > > >> > And again, how do you know that record is honest? Fact is without > >> > proof-of-publication you just don't. > >> > >> Well, the trades that appeared in the chain actually occurred. > >> Buying to yourself at fake prices? Be careful, the miner could just > >> separate the order and fill it himself. Or anyone paying a higher fee, > >> for that matter. > > > > You just made my long-term strategic argument for investing in my own > > mining hardware so I can be sure to trade reliably. > > > >> Again, you haven't addressed why the seller cares more about "accurate > >> historic market data" than just his own fees and sell. > >> > >> > You mean a reverse nLockTime that makes a transaction invalid after a > >> > certain amount of time - that's dangerous in a reorg unfortunately as > it > >> > can make transactions permenantly invalid. > > > > People who take money from buyers and sellers care most about 'accurate > > historic market data'. I just want to exchange my corn for e85, > fertilizer, > > and electricity, and audit the code that runs accounting for the > exchange. > > > > I really don't give a shit if there is 'accurate historic market data' as > > long as **MY** personal trade data is accurate and I got a good enough > price, > > and I know who I'm dealing with. > > > > I know someone smarter than me and with more money, market leverage, and > > political connections **WILL** game the system and distort the market > data > > history so they can take more money from buyers and sellers without > actually > > doing some usefull market function. > > > > As long as use buyers and sellers can see the code, and have a good eye > for > > knowing when someone's pushing the market around, we can just put our > orders > > in and relieve some speculators of their money. > > > > Just get me working code for cross-chain trades, and we'll work on the > > accurate historic data problem later. > > > > > > > Troy Benjegerdes 'da hozer' > ho...@hozed.org > > 7 elements earth::water::air::fire::mind::spirit::soul > grid.coop > > > > Never pick a fight with someone who buys ink by the barrel, > > nor try buy a hacker who makes money by the megahash > > > > > > > -- > > Flow-based real-time traffic analytics software. Cisco certified tool. > > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > > Customize your own dashboards, set traffic alerts and generate reports. > > Network behavioral analysis & security monitoring. All-in-one tool. > > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > ___ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > --
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
This is not bitcoin-philosophy, it's bitcoin-development. Existential philosophy belongs on IRC or the forums. On Sat, Mar 1, 2014 at 1:28 PM, Mark Friedenbach wrote: > Only if you view bitcoin as no more than a payment network. > > On Mar 1, 2014 10:24 AM, "Jeff Garzik" wrote: >> >> This is wandering far off-topic for this mailing list. >> >> On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes wrote: >> >> > You can make the same argument against Bitcoin itself you know... >> >> > >> >> > A Bitmessage-like network would be trivial to front-run via a sybil >> >> > attack. It's the fundemental problem with marketplaces - the data >> >> > they're trying to publish has to be public. >> >> >> >> I don't see the Bitcoin analogy... >> >> Anyway, I still don't think the seller cares, if he sells at the price >> >> he was asking, what would he care about "front running" those parallel >> >> networks. >> >> I've seen many street markets without "public information" and they >> >> work just well. >> > >> > The spot price for ammonia fertilizer, refined gasoline at terminals, >> > and price of tea in china are not 'public information', yet these are >> > some of the largest traded commodities in the world, far exceeding >> > the drop in the bucket that all cryptocoin transactions make. >> > >> > I'd further argue that the *actual* price of corn (cash bid price at >> > elevators and ethanol plants) is not public information either. There >> > is a great deal of money traded in collecting and then distributing the >> > 'cleared price' information. Have a look at >> > >> > http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1 >> > >> > >> >> >> I don't think this will be a tragedy, because like we discussed on >> >> >> IRC, I don't think the primary goal of markets is price discovery, >> >> >> but >> >> >> trade itself. >> >> >> >> >> >> About historic data, the actual trades are always public, and some >> >> >> kind of "archivers" could collect and maintain old orders for >> >> >> historic >> >> >> bid and asks, etc. >> >> > >> >> > And again, how do you know that record is honest? Fact is without >> >> > proof-of-publication you just don't. >> >> >> >> Well, the trades that appeared in the chain actually occurred. >> >> Buying to yourself at fake prices? Be careful, the miner could just >> >> separate the order and fill it himself. Or anyone paying a higher fee, >> >> for that matter. >> > >> > You just made my long-term strategic argument for investing in my own >> > mining hardware so I can be sure to trade reliably. >> > >> >> Again, you haven't addressed why the seller cares more about "accurate >> >> historic market data" than just his own fees and sell. >> >> >> >> > You mean a reverse nLockTime that makes a transaction invalid after a >> >> > certain amount of time - that's dangerous in a reorg unfortunately as >> >> > it >> >> > can make transactions permenantly invalid. >> > >> > People who take money from buyers and sellers care most about 'accurate >> > historic market data'. I just want to exchange my corn for e85, >> > fertilizer, >> > and electricity, and audit the code that runs accounting for the >> > exchange. >> > >> > I really don't give a shit if there is 'accurate historic market data' >> > as >> > long as **MY** personal trade data is accurate and I got a good enough >> > price, >> > and I know who I'm dealing with. >> > >> > I know someone smarter than me and with more money, market leverage, and >> > political connections **WILL** game the system and distort the market >> > data >> > history so they can take more money from buyers and sellers without >> > actually >> > doing some usefull market function. >> > >> > As long as use buyers and sellers can see the code, and have a good eye >> > for >> > knowing when someone's pushing the market around, we can just put our >> > orders >> > in and relieve some speculators of their money. >> > >> > Just get me working code for cross-chain trades, and we'll work on the >> > accurate historic data problem later. >> > >> > >> > >> > Troy Benjegerdes 'da hozer' >> > ho...@hozed.org >> > 7 elements earth::water::air::fire::mind::spirit::soul >> > grid.coop >> > >> > Never pick a fight with someone who buys ink by the barrel, >> > nor try buy a hacker who makes money by the megahash >> > >> > >> > >> > -- >> > Flow-based real-time traffic analytics software. Cisco certified tool. >> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer >> > Customize your own dashboards, set traffic alerts and generate reports. >> > Network behavioral analysis & security monitoring. All-in-one tool. >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk >> > ___ >> > Bitc
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes wrote: >> > You can make the same argument against Bitcoin itself you know... >> > >> > A Bitmessage-like network would be trivial to front-run via a sybil >> > attack. It's the fundemental problem with marketplaces - the data >> > they're trying to publish has to be public. >> >> I don't see the Bitcoin analogy... >> Anyway, I still don't think the seller cares, if he sells at the price >> he was asking, what would he care about "front running" those parallel >> networks. >> I've seen many street markets without "public information" and they >> work just well. > > The spot price for ammonia fertilizer, refined gasoline at terminals, > and price of tea in china are not 'public information', yet these are > some of the largest traded commodities in the world, far exceeding > the drop in the bucket that all cryptocoin transactions make. > > I'd further argue that the *actual* price of corn (cash bid price at > elevators and ethanol plants) is not public information either. There > is a great deal of money traded in collecting and then distributing the > 'cleared price' information. Have a look at > http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1 > > >> >> I don't think this will be a tragedy, because like we discussed on >> >> IRC, I don't think the primary goal of markets is price discovery, but >> >> trade itself. >> >> >> >> About historic data, the actual trades are always public, and some >> >> kind of "archivers" could collect and maintain old orders for historic >> >> bid and asks, etc. >> > >> > And again, how do you know that record is honest? Fact is without >> > proof-of-publication you just don't. >> >> Well, the trades that appeared in the chain actually occurred. >> Buying to yourself at fake prices? Be careful, the miner could just >> separate the order and fill it himself. Or anyone paying a higher fee, >> for that matter. > > You just made my long-term strategic argument for investing in my own > mining hardware so I can be sure to trade reliably. > >> Again, you haven't addressed why the seller cares more about "accurate >> historic market data" than just his own fees and sell. >> >> > You mean a reverse nLockTime that makes a transaction invalid after a >> > certain amount of time - that's dangerous in a reorg unfortunately as it >> > can make transactions permenantly invalid. > > People who take money from buyers and sellers care most about 'accurate > historic market data'. I just want to exchange my corn for e85, fertilizer, > and electricity, and audit the code that runs accounting for the exchange. > > I really don't give a shit if there is 'accurate historic market data' as > long as **MY** personal trade data is accurate and I got a good enough price, > and I know who I'm dealing with. > > I know someone smarter than me and with more money, market leverage, and > political connections **WILL** game the system and distort the market data > history so they can take more money from buyers and sellers without actually > doing some usefull market function. > > As long as use buyers and sellers can see the code, and have a good eye for > knowing when someone's pushing the market around, we can just put our orders > in and relieve some speculators of their money. > > Just get me working code for cross-chain trades, and we'll work on the > accurate historic data problem later. > > > Troy Benjegerdes 'da hozer' ho...@hozed.org > 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop > > Never pick a fight with someone who buys ink by the barrel, > nor try buy a hacker who makes money by the megahash > > > -- > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doub
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
> > You can make the same argument against Bitcoin itself you know... > > > > A Bitmessage-like network would be trivial to front-run via a sybil > > attack. It's the fundemental problem with marketplaces - the data > > they're trying to publish has to be public. > > I don't see the Bitcoin analogy... > Anyway, I still don't think the seller cares, if he sells at the price > he was asking, what would he care about "front running" those parallel > networks. > I've seen many street markets without "public information" and they > work just well. The spot price for ammonia fertilizer, refined gasoline at terminals, and price of tea in china are not 'public information', yet these are some of the largest traded commodities in the world, far exceeding the drop in the bucket that all cryptocoin transactions make. I'd further argue that the *actual* price of corn (cash bid price at elevators and ethanol plants) is not public information either. There is a great deal of money traded in collecting and then distributing the 'cleared price' information. Have a look at http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1 > >> I don't think this will be a tragedy, because like we discussed on > >> IRC, I don't think the primary goal of markets is price discovery, but > >> trade itself. > >> > >> About historic data, the actual trades are always public, and some > >> kind of "archivers" could collect and maintain old orders for historic > >> bid and asks, etc. > > > > And again, how do you know that record is honest? Fact is without > > proof-of-publication you just don't. > > Well, the trades that appeared in the chain actually occurred. > Buying to yourself at fake prices? Be careful, the miner could just > separate the order and fill it himself. Or anyone paying a higher fee, > for that matter. You just made my long-term strategic argument for investing in my own mining hardware so I can be sure to trade reliably. > Again, you haven't addressed why the seller cares more about "accurate > historic market data" than just his own fees and sell. > > > You mean a reverse nLockTime that makes a transaction invalid after a > > certain amount of time - that's dangerous in a reorg unfortunately as it > > can make transactions permenantly invalid. People who take money from buyers and sellers care most about 'accurate historic market data'. I just want to exchange my corn for e85, fertilizer, and electricity, and audit the code that runs accounting for the exchange. I really don't give a shit if there is 'accurate historic market data' as long as **MY** personal trade data is accurate and I got a good enough price, and I know who I'm dealing with. I know someone smarter than me and with more money, market leverage, and political connections **WILL** game the system and distort the market data history so they can take more money from buyers and sellers without actually doing some usefull market function. As long as use buyers and sellers can see the code, and have a good eye for knowing when someone's pushing the market around, we can just put our orders in and relieve some speculators of their money. Just get me working code for cross-chain trades, and we'll work on the accurate historic data problem later. Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Making the H in HD keychains useful
I've been trying to find ways to make HD keychain wallets (BIP0032) really usable from an application development perspective. I think we all know a number of solid use cases and possible applications for the D in HD, but nobody seems to have really found a way to make use of the H in a way that is actually manageable from a usability standpoint. After pondering it a bit more, I think I've stumbled upon at least a couple issues that seem to give hints as to how we can change this. Hierarchical organizations do not generally tend to be designed up front, cast in stone. In the real world, hierarchies tend to evolve organically, growing new branches as entities differentiate themselves to different purposes. Organizations grow over time. Sometimes branches merge, sometimes branches die. This means that for HD keychains to be truly useful, they too need to be sufficiently flexible to adapt to the needs of a growing and evolving organization. It needs to be simple to create and move branches around as the need for them arises without having to plan the structure a priori. A significant problem I'm runnign into in trying to build applications around the BIP0032 standard is the lack of a clear separation between signing keys and hierarchical nodes. That's to say, a child of a node can either be used as a signing key or as a parent for new branches to the tree. From a usability standpoint, what this means is that one must be very careful in how one allocates keys from the very beginning - if one mixes signing keys with new branching nodes in the same generation, the whole thing becomes a horrendous mess. Moreover, it is impossible to generally distinguish these two fundamentally different types of objects (at least from a use model perspective) just from the extended key representation, something that is certain to create significant confusion as we try to design applications that can share these types of objects. An organization might begin as a single individual who just wants to generate signing keys for him/herself. Later on, this individual might bring on another individual or two and create new branches for them. With the current HD keychain structure, unless this individual made sure to set aside these new branches from the start, the individual is now forced to mix the new branches in at the same level of the hierarchy as the signing keys. Instead, it should be possible to branch off any node without having to worry at all about whether or not that node has been used to generate signing keys at all. A possible workaround to this issue is to always allocate a specific child for hierarchical derivation and the rest of the children for signing keys. Then to create subbranches, the specific child would be used as the new parent, effectively alternating generations between signing keys and organizational nodes. However, this solution seems pretty ugly. A better solution, IMO, is to only use BIP0032 for organizational hierarchy and have a different mechanism for generating a sequence of signing keys from a given node. This different mechanism could be used standalone by those not needing the full set of hierarchical features. For those who do want to use the hierarchical features, it could be seeded by the keys in the BIP0032 hierarchy. These individual signing keys would NEVER be represented in the same format as the organizational hierarchy nodes, thus ensuring applications can share these structures without risk of confusion. Until we make this clear distinction between organizational hierarchy (which parallels real-world organizations) and signing keys (which are merely cryptographic primitives, preferably never even shown directly to most endusers), I think we'll fail to find good ways to make the H in HD keychains useful. -Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development