Sage (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2013, 06:39:14 PM |
|
For Bitcoin to replace Paypal and/or become the medium of exchange over the internet we need an efficient solution for non-trust based single transactions.
If I'm sending someone gold bullion coins, I sure as hell want some way to ensure I get my Bitcoins.
A few possible solutions:
1) Escrow Downsides: Clunky, adds friction and expense to the transaction.
2) Kill switch Downsides: Both parties lose if anyone uses the kill switch.
3) 3 or more parties signatures required. Downsides: The other parties could be in on the scam.
4) Some kind of eBay style global feedback registry. Downsides: It could be gamed using multi-accounts. Possibly this problem could be solved factoring in history and volume metrics, making it harder to game.
Ideally the registry would be stored block chain style in a decentralized fashion. Perhaps even built into the current blockchain in the next client updates.
This would allow reputation and some kind of credit to be developed by a Bitcoin buyer/seller over time.
What else? What other solutions can you think of?
Lets start a brainstorm here and solve this problem…
|
|
|
|
jerfelix
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2013, 10:46:49 PM |
|
There could be a "rating convention": After you complete a transaction, you rate on a scale of 1-10 how the transaction went.
You pay the other party in satoshis: 1 to 10.
The votes are public, so analysis of the block chain could determine scamming and ballot stuffing. Analysis of the block chain could also link the rating to the size of the transaction, with some errors.
Generally, one party would send 10 to the other, and the other would return 10 back (for a flawless transaction). Ten 1's aren't the same as one 10. An average rating could be calculated by averaging all tiny transactions.
It's not quite as good as "A+++++++++++++++++ Would do business again", but hey, this is brainstorming, so there are no bad ideas.
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2013, 11:02:25 PM |
|
Cryptographic Escrow Super efficient, escrow agent can't steal funds, almost entirely do-it-yourself when the transaction goes as planned. Possibility of paying for dispute resolution services on an as-needed basis. Software is FREE Anyone can be an agent or a trading partner See it in action right now: https://bitcointalk.org/index.php?topic=135914 - Read thread from start to finish to see how participants learn the system and get comfortable enough with it to use with real bitcoins. They discuss a bet, and I show up in post #23 to explain how my escrow system can help with their bet. They are now using it.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
bg002h
Donator
Legendary
Offline
Activity: 1464
Merit: 1047
I outlived my lifetime membership:)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2013, 01:57:01 AM |
|
Cryptographic Escrow Super efficient, escrow agent can't steal funds, almost entirely do-it-yourself when the transaction goes as planned. Possibility of paying for dispute resolution services on an as-needed basis. Software is FREE Anyone can be an agent or a trading partner See it in action right now: https://bitcointalk.org/index.php?topic=135914 - Read thread from start to finish to see how participants learn the system and get comfortable enough with it to use with real bitcoins. They discuss a bet, and I show up in post #23 to explain how my escrow system can help with their bet. They are now using it. Wow. That's pretty clever! Now reputation of the escrow agent matters most, rather than clunky eBay feedback systems. Nicely done!
|
|
|
|
|
pc
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2013, 02:49:30 PM |
|
For whatever it's worth, I'm currently doing a transaction (as seller) where the funds are in a 2-of-2 multisig address (meaning both my key and the buyer's key are needed to move them). I suppose that the buyer could try to not sign the transaction to pay me after he receives the goods, but I don't know any economic incentive for him to do so. I mean, all it'd do is be mean for the sake of being mean. It's not like he has access to the money anymore. Perhaps not good enough for some people, but for me selling-a-few-random-things-around-the-house level of selling, it's good enough for me.
I just wish that there were a better interface for it. I lead the buyer through the creation of a multisigaddress and signing raw transactions and the like using Bitcoin-Qt's debug console, and it seems like it shouldn't take much to make a nice GUI for it, though there's probably more work than I'm thinking (GUIs always are, especially when trying to explain some complicated concepts like "Are you sure this is the transaction you want to sign?").
I do think that it'd probably work best for "reputations" to be for the escrow or dispute mediation services, so that you do a 2-of-3, and so the vast majority of the time the mediator isn't involved at all, and the mediator makes their reputation by using a clear transparent process to make decisions.
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2013, 04:49:37 PM |
|
My implementation actually does not use multisig at all.
It uses elliptic curve multiplication to derive a single normal keypair for an address whose private key nobody can know until a release of funds has occurred.
The private key is the product of three factors, and each party (payer, payee, escrow agent) knows only 2 of the factors, as well as G*n. n is the factor they don't have, having G*n permits them to compute the bitcoin address without access to the private key. Only when someone has been given the missing factor can they compute the private key and take the funds.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
Ari
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 75
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2013, 10:35:12 PM |
|
My implementation actually does not use multisig at all.
It uses elliptic curve multiplication to derive a single normal keypair for an address whose private key nobody can know until a release of funds has occurred.
The private key is the product of three factors, and each party (payer, payee, escrow agent) knows only 2 of the factors, as well as G*n. n is the factor they don't have, having G*n permits them to compute the bitcoin address without access to the private key. Only when someone has been given the missing factor can they compute the private key and take the funds.
Let me see if I understand this correctly. Escrow agent generates A and B Escrow sends A and G*B to Alice Escrow sends B and G*A to Bob Alice generates P, then sends P to Bob Alice calculates a bitcoin address from (G*B)*A*P Bob calculates a bitcoin address from (G*A)*B*P Alice and Bob comfirm that they both have the same address. The private key to the address is A*B*P. Alice has A and P, but not B. Bob has B and P, but not A. Escrow has A and B, but not P. All the communication need to be encrypted so you don't leak A, B, or P.
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2013, 12:54:28 AM |
|
My implementation actually does not use multisig at all.
It uses elliptic curve multiplication to derive a single normal keypair for an address whose private key nobody can know until a release of funds has occurred.
The private key is the product of three factors, and each party (payer, payee, escrow agent) knows only 2 of the factors, as well as G*n. n is the factor they don't have, having G*n permits them to compute the bitcoin address without access to the private key. Only when someone has been given the missing factor can they compute the private key and take the funds.
Let me see if I understand this correctly. Escrow agent generates A and B Escrow sends A and G*B to Alice Escrow sends B and G*A to Bob Alice generates P, then sends P to Bob Alice calculates a bitcoin address from (G*B)*A*P Bob calculates a bitcoin address from (G*A)*B*P Alice and Bob comfirm that they both have the same address. The private key to the address is A*B*P. Alice has A and P, but not B. Bob has B and P, but not A. Escrow has A and B, but not P. All the communication need to be encrypted so you don't leak A, B, or P. 100% perfect description!
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
Ari
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 75
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2013, 04:45:53 AM |
|
100% perfect description!
There's a slight flaw in the protocol I just described. If neither party verifies G*A or G*B then the escrow agent can send out a bogus escrow invitation which will generate a bitcoin address that neither Alice or Bob will be able to access. To avoid this you could have payer and payee exchange a random number r, then calculate P = GABr, and calculate the bitcoin address from that. or are you already doing something like this?
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2013, 05:34:51 AM |
|
If G*a or G*b were wrong, the "Alice and bob make sure they generated the same Bitcoin address" would fail.
About the only way I see it failing is if escrow agent sent a and G*b to both Alice and Bob under the pretense they were different, and then lost the value for b.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
Ari
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 75
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2013, 06:23:33 AM |
|
If G*a or G*b were wrong, the "Alice and bob make sure they generated the same Bitcoin address" would fail.
About the only way I see it failing is if escrow agent sent a and G*b to both Alice and Bob under the pretense they were different, and then lost the value for b.
I calculate n = ac = bd Send Gc and a to Alice Send Gd and b to Bob Alice calculates Gacp = Gnp Bob calculates Gbdp = Gnp The bitcoin addresses match. Alice then tries to release the escrow by sending Bob a. Bob calculates a*b*p, which is useless. Basically, griefers can abuse the protocol to cause people to lose money. p = Gabr, then bitcoin address from Gabp, solves this by making sure that the bitcoin address won't match.
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2013, 06:39:16 AM |
|
Yes I did think of that abuse as possible, but didn't expect it to be likely. Nevertheless... you're right... it should be protected against.
One remedy is for the party creating the payment invitation to also calculate and send G * the private part he knows - something the other guy should already have - so he can crosscheck it while confirming the bitcoin address.
This is actually quite possible. Each of the strings (einva, einvb, einvp) has room for one pubkey, one privkey, 32 bit hash, and some flags. The "einvp" doesn't use the pubkey field for anything important, I just throw the bitcoin address in there, but that's really a waste of the space. That space might better be used for this purpose. I wanted all the strings to be roughly the same length, so I felt I'd rather waste that space than shorten it. Now we have a perfect use for it.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
HostFat
Staff
Legendary
Offline
Activity: 4256
Merit: 1208
I support freedom of choice
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2013, 05:56:19 PM |
|
I'll wait for the next release with this fix, then I'll make a guide for the italian community ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2013, 06:12:33 PM |
|
Cryptographic Escrow Super efficient, escrow agent can't steal funds, almost entirely do-it-yourself when the transaction goes as planned. Possibility of paying for dispute resolution services on an as-needed basis. Software is FREE Anyone can be an agent or a trading partner See it in action right now: https://bitcointalk.org/index.php?topic=135914 - Read thread from start to finish to see how participants learn the system and get comfortable enough with it to use with real bitcoins. They discuss a bet, and I show up in post #23 to explain how my escrow system can help with their bet. They are now using it. Why not simply use 2-of-3 multisig?
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 04, 2013, 05:04:52 PM |
|
Here is how I anticipate myself doing the fix - I'd like to solicit commentary on it, especially if anyone can find any problem with it.
When I generate the P code (payment confirmation code starting with einvp), I am currently using the second "pubkey" field (which doesn't have any critical function and can be repurposed) to convey the bitcoin address, simply so the receiver of the code has some way to auto-confirm that they are generating the same bitcoin address. This protects against accidental use of the wrong/mismatched code, but doesn't protect against malicious generation of pairs of escrow invitations that appear to match but which can never produce a working private key.
What I am thinking of doing instead would be to use this field to provide a sha256 hash of all of the following, concatenated together:
(Assume the person generating it got escrow invitation part A - simply flip everything if part B is the one generating payment invite):
* Pubkey included in A's escrow invitation + Pubkey derived from private key included in A's escrow invitation + Expected Bitcoin Address or related hash thereof
The first pubkey will have come directly from the escrow agent, and is something the person with escrow invite part B should be able to calculate.
The second pubkey can be calculated from escrow invite part A, and is something the person with part B should already have.
The Bitcoin address can be calculated from both.
The end result is that the person who is validating the payment invitation code based on codes given by others will be the one to cross-check everything and throw up an error if something doesn't check out.
Assuming I make this change, the verify invitations screen ("be a payee" screen) will refuse to verify old invitations based on the new criteria, but I anticipate making the "collect your funds" screen continue to accept them, just throw up a warning if these new checks don't check out. These changes don't alter the first "private keypart" field that the collect funds screen uses so it would continue to work, this way existing invitations remain redeemable after the changes are made, despite a warning.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
HostFat
Staff
Legendary
Offline
Activity: 4256
Merit: 1208
I support freedom of choice
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 31, 2013, 02:06:27 AM Last edit: March 31, 2013, 02:21:50 AM by HostFat |
|
Is there an update on this issue?
|
|
|
|
HostFat
Staff
Legendary
Offline
Activity: 4256
Merit: 1208
I support freedom of choice
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 11, 2013, 08:02:51 AM |
|
|
|
|
|
adraza
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 113
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 21, 2013, 11:43:27 AM |
|
They're not really alternatives; they're implementations ... javascript implementations of the ideas (BIP38; Bitcoin Escrow) put forth by Casascius. I did not come up with these great ideas. please read also here: https://bitcointalk.org/index.php?topic=169957.msg1901820#msg1901820another idea "escrowed" bet I am not a coder so you should do it! (although I think it's just explanatory texts to be changed, no real code changes)
|
Donations here BTC: 14VsPAb5HTzjPjMJBazEZYCA3ikhmmV4L9 LTC: LV5HD3nc3reAW5bmh9z2RLptvUVZZuH4Z6
|
|
|
adraza
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 113
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 21, 2013, 11:47:31 AM |
|
Speaking of "TRUST AND SECURITY FOR THE MASSES"
I think the browser implementation is exactly what we need for average people.
|
Donations here BTC: 14VsPAb5HTzjPjMJBazEZYCA3ikhmmV4L9 LTC: LV5HD3nc3reAW5bmh9z2RLptvUVZZuH4Z6
|
|
|
|