Topic: Your opinion: Best Bitcoin Non-Trust Transactions Solution? (Read 2121 times)

Speaking of "TRUST AND SECURITY FOR THE MASSES"

I think the browser implementation is exactly what we need for average people.

please read also here:

https://bitcointalksearch.org/topic/m.1901820

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)

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

Is there an update on this issue?

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.

Why not simply use 2-of-3 multisig?

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

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.

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.

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.

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?

100% perfect description!

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.

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.

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.

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.

Wow. That's pretty clever! Now reputation of the escrow agent matters most, rather than clunky eBay feedback systems. Nicely done!

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://bitcointalksearch.org/topic/280-btc-total-bets-between-micon-and-mrb-are-bfl-asics-real-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.

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.

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…