killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 smart property as an alternative to invoicing January 22, 2013, 01:39:56 PM #1 If I get it correctly, the current proposal is to use SSL-signed invoices to improve usability and provide confirmation of purchase. (I.e. so that I can prove that merchant owes me something.)



I propose an alternative to this: it is possible to use smart property/colored coins + decentralized market instead of singed invoices and get similar benefits.



It might sound outlandish, but I'm not saying it's worth implementing it right now. Besides that, I've just implemented a proof-of-concept decentralized market for colored coins based on "atomic coin swapping" (it is called p2ptrade), so I believe this kind of technology is relatively easy to implement. Say, it would take me about a week to implement a functional proof-of-concept.



So here's how it can work:



1. Let's say merchant has 1000 alpaca socks in stock. He will create 1000 alpaca socks vouchers using smart property or colored coins. I recommend colored coins, though. So, basically, one who owns a smart coin-based voucher can get alpaca socks.



2. Merchant sells these voucher tokens on decentralized market, let's call it p2ptrade for simplicity. He doesn't care who buys them as long as they pay. If he is using colored coins, he can get paid in any colored coin-based currency, not just Bitcoins.



3. Optional: These vouchers might be bought by resellers, who can them sell it on same market for a different price or for different currency.



4. End-user buys voucher via p2ptrade. Of course, it might work via highly specialized GUI which might work like app store: he simply searches for a product, reads overview and clicks buy.



5. End-user who is in possession of voucher can order shipment: he will sign message like "Ship alpaca socks to <this> address" with Bitcoin address which currently holds voucher, then he sends voucher to merchant's address to complete the purchase.



6. Merchant now gets this voucher back and it sees user's message (ideally message should be incorporated into blockchain), he should ship socks.



7. User has hard evidence that he have purchased socks, so he can use it against merchant if that fails to deliver the product.



I haven't thoroughly analyze this, but here are some potential advantages compared to signed invoice approach:



1. Merchant needs to sign smart property or color definition, he doesn't need to sign each invoice. This means that he can keep his private key offline, signing a new batch of vouchers once per week, for example.



2. We don't really need SSL. Well, end users need to make sure that voucher indeed come from merchant, but there is plenty of options for such verification. It can be entirely out-of-band, for example. Perhaps a catalog company will endorse vouchers and provide insurance (think like Amazon, eBay), so user only needs to trust that company. It can also work with web-of-trust-like things.



3. It can easily work with multiple currencies via colored coins. Say, merchant sells vouchers for USDcoin, then resellers sell them for GoldCoin, Bitcoin, EURcoin etc. It can also work with ripple-style colored-coin-based currencies.



4. Wide opportunities for reselling (user doesn't care whether he buys voucher directly from merchant or from resellers).



5. You automatically get features like gift cards, catalogs etc.

Chromia : a better dapp platform

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: smart property as an alternative to invoicing January 22, 2013, 03:39:51 PM #2 I think it's an interesting idea, but the use of SSL (actually, PKIX) is really to satisfy one very specific use case, which is to ensure that devices like the Trezor (or phones or any other hardware wallet) can display to the user a human-meaningful identifier rather than an address. So this way a virus on the users computer cannot rewrite an address you are intending to pay to one owned by the botnet controller.



Because of this use case it's really important that everything "just works" and doesn't need any out of band verification. Like, I need to be able to talk to my friend in the morning and he says, "hey Mike, check out bitmit.net, it's awesome", I go there in the afternoon and my device says "Confirm 1.05 BTC to bitmit.net" - no extra work needed.



In your proposal the issue of identity is not really addressed, you say there are plenty of options but for actual widespread deployment it's tough to see much beyond PKIX and perhaps soon DNSSEC. People understand domain names, they aren't perfect but they're "good enough for v1".



After that, the biggest win will be allowing individuals to have identities too. But that's harder. Governments really failed us here, very few issue their citizens with keypairs. And of course, ensuring that whatever the user is using to sign payments is not virus infected. Gadgets like the Trezor are the best solution but I guess the majority of users won't use them, at least not for a long time and maybe never.



That said, I'm all for the creation and tracking of gift card/voucher like things using smart property/coloured coins. I didn't think about the details much though.

killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 Re: smart property as an alternative to invoicing January 22, 2013, 04:31:40 PM #3 Quote from: Mike Hearn on January 22, 2013, 03:39:51 PM I think it's an interesting idea, but the use of SSL (actually, PKIX) is really to satisfy one very specific use case, which is to ensure that devices like the Trezor (or phones or any other hardware wallet) can display to the user a human-meaningful identifier rather than an address. So this way a virus on the users computer cannot rewrite an address you are intending to pay to one owned by the botnet controller.

My proposal addresses this issue, sort of, just in a very different way.



Basically, the difference is that each invoice must be signed by domain owner.



But vouchers can be signed all at once, by anybody who is trusted.



E.g. suppose somebody there is a web site, let's call it bitmutt.com, it finds reputable merchants/vendors, hosts descriptions and so on.



Somebody recommends me bitmutt.com, I go to it, browse product catalog, click on alpaca socks, and it shows up in my bitcoin client as alpaca socks vouchers endorsed by bitmutt.com



So, yes, bitmutt.com, the catalog, needs SSL. But individual merchants do not.



Of course, you don't always need to go through a catalog... Say, your friend might mention that 26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good, so you put this ID into your color-aware client and buy a voucher.



Quote I need to be able to talk to my friend in the morning and he says, "hey Mike, check out bitmit.net, it's awesome",

I would call that out-of-band verification: your friend confirms that bitmit.net is a reliable merchant.



What if there was bitmitt.net which looks exactly like bitmit.net, but doesn't ship goods?



You absolutely need to verify correct spelling before you pay. And your friend is the source of correct spelling, without his help you can't tell which from bitmit and bitmitt is legit. Both look the same!



Quote no extra work needed.

I don't think there is a difference between "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good" and "hey Mike, check out bitmit.net, it's awesome".



So all benefits of SSL boil down to shorter names... Which can be really solved in a different way.



Quote In your proposal the issue of identity is not really addressed

Yes, but the thing is that it doesn't need same kind of identity resolution. In case with vouchers, you don't really care about merchant's identity, you care about endorsements. Is it endorsed by your friend? Is it endorsed by a reputable catalog? Is it endorsed by people on WoT? That matters.



I don't care if I buy from bitmit.com or bitshit.com if their socks are good and they really ship them. Identity is irrelevant.



If I buy something very expensive I'll need to be able to sue the merchant, THEN I'll check his identity.

My proposal addresses this issue, sort of, just in a very different way.Basically, the difference is that each invoice must be signed by domain owner.But vouchers can be signed all at once,who is trusted.E.g. suppose somebody there is a web site, let's call it bitmutt.com, it finds reputable merchants/vendors, hosts descriptions and so on.Somebody recommends me bitmutt.com, I go to it, browse product catalog, click on alpaca socks, and it shows up in my bitcoin client as alpaca socks vouchers endorsed by bitmutt.comSo, yes, bitmutt.com, the catalog, needs SSL. But individual merchants do not.Of course, you don't always need to go through a catalog... Say, your friend might mention that 26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good, so you put this ID into your color-aware client and buy a voucher.I would call that out-of-band verification: your friend confirms that bitmit.net is a reliable merchant.What if there was bitmitt.net which looks exactly like bitmit.net, but doesn't ship goods?You absolutely need to verify correct spelling before you pay. And your friend is the source of correct spelling, without his help you can't tell which from bitmit and bitmitt is legit. Both look the same!I don't think there is a difference between "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good" and "hey Mike, check out bitmit.net, it's awesome".So all benefits of SSL boil down to shorter names... Which can be really solved in a different way.Yes, but the thing is that itsame kind of identity resolution. In case with vouchers, you don't really care about merchant's identity, you care about endorsements. Is it endorsed by your friend? Is it endorsed by a reputable catalog? Is it endorsed by people on WoT? That matters.I don't care if I buy from bitmit.com or bitshit.com if their socks are good and they really ship them. Identity is irrelevant.If I buy something very expensive I'll need to be able to sue the merchant, THEN I'll check his identity. Chromia : a better dapp platform

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: smart property as an alternative to invoicing January 22, 2013, 05:23:12 PM #4 Quote I don't think there is a difference between "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good" and "hey Mike, check out bitmit.net, it's awesome".

The difference is that one is not really communicable out of band. You can't put it on a poster or business card or memorize it, and you can't expect people to actually notice if it doesn't match. Even if people wanted to compare long codes lots of people would compare just the start and end, which means you could easily brute-force an equivalent.



Sure, spelling can be an issue for domain names. Not always though. Eg, Google is a single word and we bought up all confusible domains a long time ago (like most big internet companies).



The point of knowing the domain name is NOT to establish reliability or endorsement of the merchant. I agree that catalogs or a web of trust can be good for that. Using domain names has one purpose, which is to ensure you can read off a confirmation message on a secure display and have some assurance that it is who you are paying, even with a compromised host.



So identity is not irrelevant. It's actually the entire reason for having a payment protocol. The difference is that one is not really communicable out of band. You can't put it on a poster or business card or memorize it, and you can't expect people to actually notice if it doesn't match. Even if people wanted to compare long codes lots of people would compare just the start and end, which means you could easily brute-force an equivalent.Sure, spelling can be an issue for domain names. Not always though. Eg, Google is a single word and we bought up all confusible domains a long time ago (like most big internet companies).The point of knowing the domain name is NOT to establish reliability or endorsement of the merchant. I agree that catalogs or a web of trust can be good for that. Using domain names has one purpose, which is to ensure you can read off a confirmation message on a secure display and have some assurance that it is who you are paying, even with a compromised host.So identity is not irrelevant. It's actually the entire reason for having a payment protocol.

Peter Todd





Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: smart property as an alternative to invoicing January 22, 2013, 05:23:46 PM #5 Quote from: killerstorm on January 22, 2013, 04:31:40 PM What if there was bitmitt.net which looks exactly like bitmit.net, but doesn't ship goods?



You absolutely need to verify correct spelling before you pay. And your friend is the source of correct spelling, without his help you can't tell which from bitmit and bitmitt is legit. Both look the same!



I don't think there is a difference between "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good" and "hey Mike, check out bitmit.net, it's awesome".



Verifying bitmitt.net vs. bitmit.net may or may not be easier than verifying two hex strings are identical, but the former already has a lot of real world research dedicated at solving the problem - the problem exists for regular SSL anyway. By supporting the standard SSL infrastructure we can re-use all that hard work and real world experience, and in addition it means that the risks for a company are the same risks they've already analyzed before with regard to their SSL websites.



Besides, you're friend just isn't going to say "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good", they're going to call the vendor by their human name. That's just life and to think otherwise goes against what people actually do. Good engineering takes real-world human behavior into account and finds ways to deal with it even if the behavior isn't ideal. Verifying bitmitt.net vs. bitmit.net may or may not be easier than verifying two hex strings are identical, but the former already has a lot of real world research dedicated at solving the problem - the problem exists for regular SSL anyway. By supporting the standard SSL infrastructure we can re-use all that hard work and real world experience, and in addition it means that the risks for a company are the same risks they've already analyzed before with regard to their SSL websites.Besides, you're friend just isn't going to say "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good", they're going to call the vendor by their human name. That's just life and to think otherwise goes against what people actually do. Good engineering takes real-world human behavior into account and finds ways to deal with it even if the behavior isn't ideal. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 Re: smart property as an alternative to invoicing January 22, 2013, 05:52:25 PM #6 Quote from: retep on January 22, 2013, 05:23:46 PM Verifying bitmitt.net vs. bitmit.net may or may not be easier than verifying two hex strings are identical, but the former already has a lot of real world research dedicated at solving the problem - the problem exists for regular SSL anyway. By supporting the standard SSL infrastructure we can re-use all that hard work and real world experience, and in addition it means that the risks for a company are the same risks they've already analyzed before with regard to their SSL websites.

I'm afraid you're cargo-culting this. It doesn't matter how much hard work they did if it has no real advantages.



Can you point to a specific case where SSL can save your ass from paying to a scammer?



Quote from: retep on January 22, 2013, 05:23:46 PM Besides, you're friend just isn't going to say "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good", they're going to call the vendor by their human name.

He might copy-paste it via IM program (which likely uses SSL), send it as a text message... Or we can find some way to encoded this ID as something pronounceable. Just like firstbits can deterministically shorten addresses.



I don't want to talk about specifics here... In the end, your friend endorses certain identifier.



Quote from: retep on January 22, 2013, 05:23:46 PM Good engineering takes real-world human behavior into account and finds ways to deal with it even if the behavior isn't ideal.

This is a good point. I believe that use of smart property vouchers is just more flexible w.r.t. problems of identification, and so it would be easier to find a solution which properly takes human behaviour into account.



For example, it works well with 3rd party endorsements and catalogs, and this is exactly how people shop around.



Maybe there is a good way to handle person-to-person verbal recommendations too, I dunno. I'm afraid you're cargo-culting this. It doesn't matter how much hard work they did if it has no real advantages.Can you point to a specific case where SSL can save your ass from paying to a scammer?He might copy-paste it via IM program (which likely uses SSL), send it as a text message... Or we can find some way to encoded this ID as something pronounceable. Just like firstbits can deterministically shorten addresses.I don't want to talk about specifics here... In the end, your friend endorses certain identifier.This is a good point. I believe that use of smart property vouchers is just more flexible w.r.t. problems of identification, and so it would be easier to find a solution which properly takes human behaviour into account.For example, it works well with 3rd party endorsements and catalogs, and this is exactly how people shop around.Maybe there is a good way to handle person-to-person verbal recommendations too, I dunno. Chromia : a better dapp platform

Mike Hearn





Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: smart property as an alternative to invoicing January 22, 2013, 08:11:04 PM #9 To reiterate, the scenario that using PKIX on payment requests solves is that you have a virus on your computer that replaces addresses of merchants with different addresses owned by the botnet controller. Your second factor can verify a payment request and render the correct identity, meaning the only possible attack is to confuse the user into either confirming the wrong domain name (hard) or believing that the merchant doesn't use signed payment requests (easier, unless we're very successful).

killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 Re: smart property as an alternative to invoicing January 22, 2013, 09:40:18 PM #10 Quote from: Mike Hearn on January 22, 2013, 08:11:04 PM To reiterate, the scenario that using PKIX on payment requests solves is that you have a virus on your computer that replaces addresses of merchants with different addresses owned by the botnet controller. Your second factor can verify a payment request and render the correct identity,

OK, let's consider a concrete example:



1. User has pre-existing or out-of-band knowledge that bitmit.net is a reputable merchant. We take this for granted.

2. Goes to bitmit.net site on his computer and makes an order

3. His second factor device shows invoice from bitmit.net, so user can confirm that computer isn't infested.

Now let's consider example with vouchers:



1. User has pre-existing or out-of-band knowledge that "cranky corporate classic company" is a reputable merchant. We take this for granted.

2. Goes to finds items sold by "cranky corporate classic company" and initiates purchase of a voucher

3. His second factor device shows that he is purchasing a voucher issued by "cranky corporate classic company", so user can confirm that computer isn't infested.

I really see no difference, aside that "cranky corporate classic company" looks somewhat funny and we are used to names like "bitmit.net".



Now I guess you would ask: how can we register "cranky corporate classic company" in such a way that it is unambiguous and we can verify that vouchers come from this entity?



Well, that's simple:



1. Company creates a vanity address which starts from 1mctXXXXX... such that no other address mentioned by blockchain so far has same prefix. Perhaps XXXXX should be chosen in such a way that it makes a good name when it is PGP-word-list-encoded.



2. When such address is created company sends transaction to and from this address. Now we have hash and public key mentioned in the blockchain.



3. XXXXX now becomes four word list... We can convert them back to address: "cranky corporate classic company" is encoded as XXXXX, then we scan blockchain for the first address with prefix 1mctXXXXX. We also know public key associated with this address.



4. Voucher color definition is signed by company's private key.



5. Having color definition ID we can fetch color definition, which includes public key it is signed with (we should check the signature). Then we can display that it was signed by "cranky corporate classic company".



The only problem I see is that firstbits lookup requires full blockchain scan, which is sort of expensive. OK, let's consider a concrete example:Now let's consider example with vouchers:I really see no difference, aside that "cranky corporate classic company" looks somewhat funny and we are used to names like "bitmit.net".Now I guess you would ask: how can we register "cranky corporate classic company" in such a way that it is unambiguous and we can verify that vouchers come from this entity?Well, that's simple:1. Company creates a vanity address which starts from 1mctXXXXX... such that no other address mentioned by blockchain so far has same prefix. Perhaps XXXXX should be chosen in such a way that it makes a good name when it is PGP-word-list-encoded.2. When such address is created company sends transaction to and from this address. Now we have hash and public key mentioned in the blockchain.3. XXXXX now becomes four word list... We can convert them back to address: "cranky corporate classic company" is encoded as XXXXX, then we scan blockchain for the first address with prefix 1mctXXXXX. We also know public key associated with this address.4. Voucher color definition is signed by company's private key.5. Having color definition ID we can fetch color definition, which includes public key it is signed with (we should check the signature). Then we can display that it was signed by "cranky corporate classic company".The only problem I see is that firstbits lookup requires full blockchain scan, which is sort of expensive. Chromia : a better dapp platform

killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 Re: smart property as an alternative to invoicing January 22, 2013, 10:00:52 PM #11 Quote from: retep on January 22, 2013, 06:38:47 PM Without SSL there is nothing preventing me from offering some free wifi that silently intercepts websites and replaces Bitcoin addresses with my own.

Yep, but I was considering a scenario where one uses p2ptrade to purchase a voucher. p2ptrade is already trust-free and secure as long as you have a valid ID. And SSL won't help you to find valid ID unless you can get it from a trusted party or you already know it.



I don't know which of bitmitt.net and bitmit.net is valid without getting this name from a reputable source.



Quote None of those solutions work well when you want to tell your friend over the phone.

ID can be made short thanks to firstbits, and it can be encoded using PGP word list so it is pronounceable and memorizable.



Quote In addition making the ID pronounceable only helps if you run the ID through a key derivation function so that it's difficult to generate collisions where most of the "human-comparable data" in the "humanized" representation of the ID matches up. This approach doesn't work for the majority of use-cases because your attacker can spend far, far more effort trying to find a colliding pronounceable ID than the user can in running the key derivation function to check the pronounceable ID.

If it is just 4 distinct words it isn't hard to get it right.



Quote What if I just saw some ad on the subway I vaguely remember for some product that none of my friends know about?

You use google to find product, then find reviews on reputable sites...



Quote It may be how people shop around, but they don't go off and copy-and-paste long cryptographic identities while they're doing that.

They don't need to, browser integration solves that.



Quote People want to be able to use something short and they expect that the honest vendors website is going to be the one at the top of the Google search results.

How is that different from finding product ID in a reputable catalog?



Quote SSL provides this already with pretty decent, if far from perfect, security.

Yes, SSL is better than nothing, but I'm just demonstrating an alternative here. Yep, but I was considering a scenario where one uses p2ptrade to purchase a voucher. p2ptrade is already trust-free and secure as long as you have a valid ID. And SSL won't help you to find valid ID unless you can get it from a trusted party or you already know it.I don't know which of bitmitt.net and bitmit.net is valid without getting this name from a reputable source.ID can be made short thanks to firstbits, and it can be encoded using PGP word list so it is pronounceable and memorizable.If it is just 4 distinct words it isn't hard to get it right.You use google to find product, then find reviews on reputable sites...They don't need to, browser integration solves that.How is that different from finding product ID in a reputable catalog?Yes, SSL is better than nothing, but I'm just demonstrating an alternative here. Chromia : a better dapp platform

killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 Re: smart property as an alternative to invoicing January 22, 2013, 11:40:38 PM #16 Oh, forget about firstbits, it was a bad idea. Public key can be identified by three small numbers: block index, transaction index, input index. I don't think you need more than 4 bytes to encode this.



So invoice or color definition includes 4-byte ID. You can find public key corresponding to that ID in the blockchain.



You can then check that signature on invoice or color definition corresponds to this public key.



Thus nobody can impersonate this short 4-byte ID: attacker has no access to private key, so he can't produce valid signature.



What do I win? Chromia : a better dapp platform

killerstorm



Offline



Activity: 1022

Merit: 1000









LegendaryActivity: 1022Merit: 1000 Re: smart property as an alternative to invoicing January 23, 2013, 05:43:43 PM

Last edit: January 23, 2013, 05:54:36 PM by killerstorm #18 Quote from: jtimon on January 23, 2013, 04:26:52 PM Sorry, I got lost. What relates "cranky corporate classic company" to this 4 Byte ID?



This encoding scheme:



Basically, you make some transactions using your address. Each transaction gets an unique 4-byte ID once it is in blockchain. Each corresponds to an unique combination of PGP words. You just pick combo you like, and it becomes your company's moniker. Of course, you cannot pick exactly the name you want, but you might pick something reasonable.



It is kinda like 1-800-FLOWERS. Each digit is associated with a couple of letters on phone's keyboard, and you can find mnemonic which will help people to memorize your number.



Effectively we are using blockchain as an address book, which is cool.



Quote from: jtimon on January 23, 2013, 04:26:52 PM Whatever it is...Why can't it relate the public key directly without using the 4 Byte ID as a proxy?

4 byte ID is simply a transaction addressing scheme, people don't need to do it, software will do it automatically.



We need to use this addressing to use blockchain as an address book. The alternative is to scan blockchain for the name, which is infinitely more expensive. ( O(N) vs O(1) )



BTW we can probably shrink IDs to 3 bytes (thus three-word names instead of four-word names), but it will work for a limited time, say 4 years or so.



EDIT: Oh, nevermind... There is a 24-bit encoding scheme which will last for about 44 years and is more-or-less reasonable. In 44 years we'll have to change scheme, LOL. So, I, for one, welcome our "cranky corporate absurd" overlords! This encoding scheme: http://en.wikipedia.org/wiki/PGP_word_list Basically, you make some transactions using your address. Each transaction gets an unique 4-byte ID once it is in blockchain. Each corresponds to an unique combination of PGP words. You just pick combo you like, and it becomes your company's moniker. Of course, you cannot pick exactly the name you want, but you might pick something reasonable.It is kinda like 1-800-FLOWERS. Each digit is associated with a couple of letters on phone's keyboard, and you can find mnemonic which will help people to memorize your number.Effectively we are using blockchain as an address book, which is cool.4 byte ID is simply a transaction addressing scheme, people don't need to do it, software will do it automatically.We need to use this addressing to use blockchain as an address book. The alternative is to scan blockchain for the name, which is infinitely more expensive. ( O(N) vs O(1) )BTW we can probably shrink IDs to 3 bytes (thus three-word names instead of four-word names), but it will work for a limited time, say 4 years or so.EDIT: Oh, nevermind... There is a 24-bit encoding scheme which will last for about 44 years and is more-or-less reasonable. In 44 years we'll have to change scheme, LOL. So, I, for one, welcome our "cranky corporate absurd" overlords! Chromia : a better dapp platform