[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=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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=aboutlisturlcode=12view=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=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 m...@monetize.io wrote: Only if you view bitcoin as no more than a payment network. On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote: This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org 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=aboutlisturlcode=12view=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=126839071iu=/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
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 jgar...@bitpay.com wrote: This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org 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=aboutlisturlcode=12view=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=126839071iu=/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
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 c1.devran...@niftybox.netwrote:
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 - old implementations that don't understand the new
extended_signature field will drop it during reserialization to set
signature to the empty array, and thus signature should not cover that
[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=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
