Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

bitrated.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#51

Post by darkmighty »

nadaviv wrote: post #2

Hey, I'm the creator. I'd love to hear any feedback/questions/suggestions you have, but specifically on the security model [1] I implemented, design/ux (my design skills are terrible, thank god for Bootstrap for making it look half decent :) and the marketing/texts (I'm not a native English speaker, so any corrections are much appreciated). If you don't know what multisig/m-of-n means, check out the FAQ: https://www.…

I've been thinking about the arbitration problem, what do you think of the following possible implementation of a "3rd party free" arbitration?

Alice desires to buy asset of V value from Bob with bitcoins. Alice sets up a k1xV value address and requires Bob to set up a k2xV one, and they give up control on those addresses for at most time T. Also, Alice and Bob set up a conditional transfer of this value V to a charity (or destroy it) if both don't agree on retrieving the wallets before time T. That way, if the merchant believes he will be punished (e.g. k2 = 2) he shouldn't engage in fraud. Also the merchant should hold the same faith in customers (by setting e.g. k1 = 1 for new customers, k1 = .5 for old ones).

Thoughts?

Note: As a bonus, the merchant could make his transaction history transparent to try to prove he punishes every fraud, and customers can likewise demonstrate some "proof of transaction" showing either they conducted transactions without issue or punished fraudsters.

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#52

Post by simbolit »

drcode wrote: post #22
nadaviv wrote: post #2

Hey, I'm the creator. I'd love to hear any feedback/questions/suggestions you have, but specifically on the security model [1] I implemented, design/ux (my design skills are terrible, thank god for Bootstrap for making it look half decent :) and the marketing/texts (I'm not a native English speaker, so any corrections are much appreciated). If you don't know what multisig/m-of-n means, check out the FAQ: https://www.…

Looks nice, but does this do anything I can't do with my Citibank n-of-m financial transaction arbitration service? (kidding- thanks for another innovation that makes traditional banks look like fossils)

upvote! you had me for a second. i thought "mhhmm.. really? citibank? wow! innovative!" but when i reached the question mark my disbelief became stronger than my gullibility :-)

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#53

Post by Lerc »

I have been pondering the m-of-n aspect. I think there is scope for a service to hold a single key and to give it out upon request only after notifying the key creator and a set amount of time has passed.

An environment where any 2 of three keys work you could have a paper wallet with one key. The service provider holds one, and the originator of the wallet holds the third.

This would allow a protected paper wallet where anyone can remove the money but you get the chance to veto and take the money out first.

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#54

Post by nwh »

Lerc wrote: post #53

I have been pondering the m-of-n aspect. I think there is scope for a service to hold a single key and to give it out upon request only after notifying the key creator and a set amount of time has passed. An environment where any 2 of three keys work you could have a paper wallet with one key. The service provider holds one, and the originator of the wallet holds the third. This would allow a protected paper wallet w…

You can do it without trust using nlocktime.

https://en.bitcoin.it/wiki/NLockTime

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#55

Post by nadaviv »

darkmighty wrote: post #51
nadaviv wrote: post #2

Hey, I'm the creator. I'd love to hear any feedback/questions/suggestions you have, but specifically on the security model [1] I implemented, design/ux (my design skills are terrible, thank god for Bootstrap for making it look half decent :) and the marketing/texts (I'm not a native English speaker, so any corrections are much appreciated). If you don't know what multisig/m-of-n means, check out the FAQ: https://www.…

I've been thinking about the arbitration problem, what do you think of the following possible implementation of a "3rd party free" arbitration? Alice desires to buy asset of V value from Bob with bitcoins. Alice sets up a k1xV value address and requires Bob to set up a k2xV one, and they give up control on those addresses for at most time T. Also, Alice and Bob set up a conditional transfer of this value V to a chari…

Huh! I actually started working on a system that does something very similar, which ended up being morphed into Bitrated after a few people convinced me that it wouldn't work.

This idea has been brought up in the Bitcoin community from time to time [1] [2], usually referred to as mutual assured destruction, risk deposit or nash equilibrium.

I personally really like this idea and think that it could work well with rational players.

The problem is that there is room for abuse - one party could tell the other party "okay, I'm not going to finish that deal with you. we can both either lose everything, or you pay me 70% of the risk deposit and get to keep 30% of it".

In the long run, rational players should always refuse to such offers. If scammers would know that everyone always refuses, they'll quickly get into a loss and stop doing that. The problem is that I'm not sure how people would react in such situations - why not take the 30%?

As to your idea of publishing history - that could work, if that system could somehow know who's a fraudster and who isn't. Its kinda hard to tell by just looking at the blockchain and seeing what happens with the coins, there could be multiple reasons for the funds getting split.

[1] http://nashx.com/HowItWorks (requires trust in the website operator, as he holds the funds. at least it was like that last time I saw it)

[2] https://gist.github.com/etotheipi/2305966

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#56

Post by Lerc »

nwh wrote: post #54
Lerc wrote: post #53

I have been pondering the m-of-n aspect. I think there is scope for a service to hold a single key and to give it out upon request only after notifying the key creator and a set amount of time has passed. An environment where any 2 of three keys work you could have a paper wallet with one key. The service provider holds one, and the originator of the wallet holds the third. This would allow a protected paper wallet w…

You can do it without trust using nlocktime. https://en.bitcoin.it/wiki/NLockTime

That is a different timer isn't it. That lets you make a delayed transaction, It doesn't stop a wallet holder from making an instant transaction.

The service would be to provide a wallet where the holder could not generate an immediate transaction. Any attempt to access would cause the service to contact the owner.

It's possible that nlocktime could allow it so that the service never reveals their private key, It auto approves time delayed transactions and notifies the owner that it has done so.

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#57

Post by michaelt »

nadaviv wrote: post #2

Hey, I'm the creator. I'd love to hear any feedback/questions/suggestions you have, but specifically on the security model [1] I implemented, design/ux (my design skills are terrible, thank god for Bootstrap for making it look half decent :) and the marketing/texts (I'm not a native English speaker, so any corrections are much appreciated). If you don't know what multisig/m-of-n means, check out the FAQ: https://www.…

I'm a bit confused about the part of the FAQ which says "he's requested to enter his public/private key (which is automatically generated) and accept the terms"

This stuff left me confused about all the wallets and keypairs and things going around (not to mention the very idea of private keys other people have access to).

You could make a nice diagram with some arrows showing all the different things and how they're exchanged.

Re: Show HN: Bitrated – Bitcoin m-of-n arbitrated transactions

#60

Post by darkmighty »

nadaviv wrote: post #55
darkmighty wrote: post #51

Earlier quoted context omitted.

I've been thinking about the arbitration problem, what do you think of the following possible implementation of a "3rd party free" arbitration? Alice desires to buy asset of V value from Bob with bitcoins. Alice sets up a k1xV value address and requires Bob to set up a k2xV one, and they give up control on those addresses for at most time T. Also, Alice and Bob set up a conditional transfer of this value V to a chari…

Huh! I actually started working on a system that does something very similar, which ended up being morphed into Bitrated after a few people convinced me that it wouldn't work. This idea has been brought up in the Bitcoin community from time to time [1] [2], usually referred to as mutual assured destruction, risk deposit or nash equilibrium. I personally really like this idea and think that it could work well with rat…

Interesting, let me add that you should let people convince you it won't work without proof, especially for something as reliant on behavior!

I think a reputation system could be built using some kind of peer-to-peer trust system. For example, I'm aware you can prove a certain transaction is yours. Simply by collecting a series of transactions conducted with the merchant and with a series of merchant's trusted peers, the merchant could perhaps decide on the (k1,k2) he might propose; and similarly users may assemble a database of verifiable cases where the transaction backfired (since each user can prove the transaction and the merchant address).

It just bugs me -- one of the great promises of crypto currencies is the elimination of need of trusted 3rd parties -- only to be unable to perform useful real world transactions without them.

The key to enabling this would be devising a system for voluntary transparency, I believe.

Post reply on HN