Bitcoin Forum
November 22, 2017, 05:25:15 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Your opinion: Best Bitcoin Non-Trust Transactions Solution?  (Read 2034 times)
Sage
Hero Member
*****
Offline Offline

Activity: 632


View Profile
January 31, 2013, 06:39:14 PM
 #1

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…
1511371515
Hero Member
*
Offline Offline

Posts: 1511371515

View Profile Personal Message (Offline)

Ignore
1511371515
Reply with quote  #2

1511371515
Report to moderator
1511371515
Hero Member
*
Offline Offline

Posts: 1511371515

View Profile Personal Message (Offline)

Ignore
1511371515
Reply with quote  #2

1511371515
Report to moderator
1511371515
Hero Member
*
Offline Offline

Posts: 1511371515

View Profile Personal Message (Offline)

Ignore
1511371515
Reply with quote  #2

1511371515
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511371515
Hero Member
*
Offline Offline

Posts: 1511371515

View Profile Personal Message (Offline)

Ignore
1511371515
Reply with quote  #2

1511371515
Report to moderator
1511371515
Hero Member
*
Offline Offline

Posts: 1511371515

View Profile Personal Message (Offline)

Ignore
1511371515
Reply with quote  #2

1511371515
Report to moderator
jerfelix
Sr. Member
****
Offline Offline

Activity: 266


View Profile
January 31, 2013, 10:46:49 PM
 #2

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 Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
January 31, 2013, 11:02:25 PM
 #3

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 Offline

Activity: 1358


I outlived my lifetime membership:)


View Profile WWW
February 01, 2013, 01:57:01 AM
 #4

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!

Hardfork aren't that hard.
1GCDzqmX2Cf513E8NeThNHxiYEivU1Chhe
Mike Hearn
Legendary
*
Offline Offline

Activity: 1526


View Profile
February 01, 2013, 01:10:50 PM
 #5

Mikes solution is an implementation of this:

  https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

It's definitely an important step for the community to set this up, but it'll take a lot of work.
pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
February 01, 2013, 02:49:30 PM
 #6

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 Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 01, 2013, 04:49:37 PM
 #7

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
**
Offline Offline

Activity: 75


View Profile
February 01, 2013, 10:35:12 PM
 #8

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 Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 02, 2013, 12:54:28 AM
 #9

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
**
Offline Offline

Activity: 75


View Profile
February 02, 2013, 04:45:53 AM
 #10

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 Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 02, 2013, 05:34:51 AM
 #11

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
**
Offline Offline

Activity: 75


View Profile
February 02, 2013, 06:23:33 AM
 #12

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 Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 02, 2013, 06:39:16 AM
 #13

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 Offline

Activity: 2632


I support freedom of choice


View Profile WWW
February 02, 2013, 05:56:19 PM
 #14

I'll wait for the next release with this fix, then I'll make a guide for the italian community Smiley

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
jl2012
Legendary
*
Offline Offline

Activity: 1722


View Profile
February 02, 2013, 06:12:33 PM
 #15

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
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1358


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
February 04, 2013, 05:04:52 PM
 #16

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 Offline

Activity: 2632


I support freedom of choice


View Profile WWW
March 31, 2013, 02:06:27 AM
 #17

Is there an update on this issue?

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
HostFat
Staff
Legendary
*
Offline Offline

Activity: 2632


I support freedom of choice


View Profile WWW
April 11, 2013, 08:02:51 AM
 #18

Two alternatives from mannkind

http://www.bit2factor.org/
Code: https://github.com/mannkind/bit2factor.org
http://www.bitescrow.org/
Code: https://github.com/mannkind/bitescrow.org

NON DO ASSISTENZA PRIVATA - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
adraza
Member
**
Offline Offline

Activity: 113


View Profile
April 21, 2013, 11:43:27 AM
 #19

They're not really alternatives; they're implementations  Smiley

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

another 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
**
Offline Offline

Activity: 113


View Profile
April 21, 2013, 11:47:31 AM
 #20

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
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!