smart property as an alternative to invoicing

[killerstorm]

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.

[Mike Hearn]

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]

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.

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!

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.

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.

[Mike Hearn]

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.

[Peter Todd]

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.

[killerstorm]

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?

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.

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.

[Peter Todd]

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?

Without SSL there is nothing preventing me from offering some free wifi that silently intercepts websites and replaces Bitcoin addresses with my own. With SSL I at least have to get a faked SSL certificate, or hope the user doesn't notice. The former isn't something any random kid in their basement can do, the latter is a problem that is becoming less and less of an issue as UI design and other countermeasures improve. Heck, even the fake SSL certificate problem has countermeasures too, not perfect ones but they can make it pretty hard to pull off the attack.

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.

None of those solutions work well when you want to tell your friend over the phone. People just aren't going to go to the effort. 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.

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

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

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

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. 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. SSL provides this already with pretty decent, if far from perfect, security.

[killerstorm]

The difference is that one is not really communicable out of band.

Oh, if it is the only problem then it's pretty much a solved thing.

There is a plenty of ways to shorten an ID, make it pronounceable and memorizable. For shortening, one could take an approach similar to firstbits: blockchain acts as a disambiguator for short binary fragments.

Then if binary is a problem one might use Bubble Babble or PGP word list encoding.

Perhaps you would like to buy some "topmost Istanbul Pluto vagabond" socks... Four-word phrase gives you 2^32 combinations which is probably enough for product identification.

Merchants might specially look for word combinations which match their products the best, same way people generate vanity Bitcoin addresses.

So... it appears people have a choice: use some funny names for merchants and products, or bend over to our certification authority overlords. What will they choose?

I guess I know the answer, but this is kinda ridiculous: use domain registrars and SSL simply to have pronounceable IDs... Which aren't even as visually/verbally unambiguous as PGP words...

You can't put it on a poster or business card or memorize it,

See above. Also, don't forget about QR codes.

and you can't expect people to actually notice if it doesn't match.

It's possible to make names which are more distinguishable than domain names.

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).

IIRC google.ru (or was it gmail.ru?) was not owned by Google for quite some time. This is a ridiculous solution in any case.

[Mike Hearn]

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]

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.

[killerstorm]

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.

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.

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.

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...

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.

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?

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.

[Gavin Andresen]

The only problem I see is that firstbits lookup requires full blockchain scan, which is sort of expensive.

"sort of expensive" ?  Really expensive and getting more expensive all the time.  And absolutely impossible for a lightweight hardware or mobile-phone wallet, which I think a lot of people will use as their second-factor device.

[marcus_of_augustus]

namecoin

[killerstorm]

"sort of expensive" ?  Really expensive and getting more expensive all the time.  And absolutely impossible for a lightweight hardware or mobile-phone wallet, which I think a lot of people will use as their second-factor device.

Well, full scan is needed only once... It isn't impossible to download 5 GB of data if you're connected to wifi. It just takes some time.

[killerstorm]

namecoin

Namecoin isn't very different from approach I've outlined, you still need to scan whole blockchain... Namecoin chain is certainly shorter than Bitcoin chain, but depending on that isn't cool.

[killerstorm]

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?

[jtimon]

My guts have already decided: I prefer the presold vouchers as invoices concept over SSL invoicing.
But the design is incomplete, so let's focus on the problem to be solved with this approach...

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?

Oh, forget about firstbits, it was a bad idea.

Yes, let's forget that.

namecoin

Namecoin isn't very different from approach I've outlined, you still need to scan whole blockchain... Namecoin chain is certainly shorter than Bitcoin chain, but depending on that isn't cool.

You don't need to scan the whole namecoin chain, only from the end until you find the domain you're looking for, right?
I kind of like this but I suspect it can raise more problems. Can anyone point them out?

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.

Sorry, I got lost. What relates "cranky corporate classic company" to this 4 Byte ID?
Whatever it is...Why can't it relate the public key directly without using the 4 Byte ID as a proxy?

[killerstorm]

Sorry, I got lost. What relates "cranky corporate classic company" to this 4 Byte ID?

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.

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!

[marcus_of_augustus]

Quote from: killerstorm on 23 January 2013, 12:25:15
Quote from: marcus_of_augustus on 23 January 2013, 12:18:49
namecoin

Namecoin isn't very different from approach I've outlined, you still need to scan whole blockchain... Namecoin chain is certainly shorter than Bitcoin chain, but depending on that isn't cool.

You don't need to scan the whole namecoin chain, only from the end until you find the domain you're looking for, right?

This is basically correct and since names expire after 36,000 blocks then you will have to scan at most 36,000 blocks deep to find any name, obviously less on average.

Of course, you could always also hold a local copy of the namecoin db scan that you can trust to look-up and update on a cron or something too.

[StarenseN]

Bump! Genius and very smart indeed.

I'm following this closely.