Hacker News Reader

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

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.

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

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.

>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%?

People have a very strong fairness instinct, and will probably refuse such blackmail.

There's a famous experiment where some amount of money is given to one person, and he decides how to split it with a partner (50-50, 100-0, etc.). The partner decides whether to accept the deal or refuse it, in which case the money is lost.

If I remember correctly most people refused offers under 20%, and that's without the anger that someone trying to blackmail you would cause.

How do they give up control on those addresses for at most time T? Does that require trust in a service, or is there a way to do it with script?

You can [1] create a transaction that destroys those coins (spends them on fees, sends them to a charity or really takes them out of circulation) at some time in the future (using nLockTime [2]) in such a way that it could be replaced with another transaction before that time (using a low sequence [3]).

[1] In the future, its not all active yet

[2] https://en.bitcoin.it/wiki/NLockTime https://en.bitcoin.it/wiki/Protocol_specification#tx

[3] http://bitcoin.stackexchange.com/a/2032

Libertarian legal scholar, design nerd and native English speaker here. There's a few basic errors I notice right away like:

>Give your customers a peace of mind.

There should be no 'a' and just be 'give your customers peace of mind'.

The homepage really isn't that great in presentation but the secondary pages are very "squashed":https://www.bitrated.com/faq.html#is-this-an-escrow-

You need to add some spacing/padding around these list items and titles otherwise it looks pretty crappy.

Thanks. I fixed the typo, and I'll be working on some CSS for better typography in the content-heavy pages - they do look somewhat squashed.

Looks like you're using bootstrap. Might want to check out https://wrapbootstrap.com/

I'm glad someone finally made this.

What do you think about potentially offering more complicated schemes in the future? For example, supporting say three arbitrators, requiring two to agree?

You could do this as follows:

Seller: Keys S1 and S2

Buyer: Keys B1 and B2

Arbitrators: Keys A1, A2, A3 (one per arbitrator)

You then do a 4-of-7 multisig transaction.

This generalizes to buyer, seller and N-of-M arbitrators:

Seller gets N keys

Buyer gets N keys

Arbitrators each get one key

Actual transaction is 2N of M + 2N.

This could be a cool idea, but Bitcoin currently artificially limits the total number of public keys to 3, but that limitation will probably be lifted at some point.

Also, in the future, you won't really need hacks like that to make something like that work - Bitcoin has a scripting language that allows you to specify much more complex conditions than m-of-n. You could specify something like `2 of (buyer, seller, (2 of (arb1, arb2, arb3)))`. But currently, the scripting language is limited to a specific white-list of allowed script templates, and doesn't allow doing stuff like that.

Bitcoin does not artificially limit the total number of keys. Transactions with up to 3 keys are considered "standard" by bitcoind, meaning they will be propagated and mined by default. But non-standard 5-of-8 transactions are also valid. If someone relays them and mines them, they will be valid for every node. In practical terms, non-standard transactions mean longer confirmation time, that's it.

It's a bit more complicated than "longer confirmation times" since normal nodes will not relay them. Realistically, production use of non-standard transactions is unwise, but we'll make anything standard that people have a usecaes for and tests for.

... though in this case, you'd really want to use a script like I described instead of inefficiently using multiple keys per player.

Thats a really inefficient way of encoding it.

It would result in a much smaller scriptPubKey to encode something like this instead:

S_pub OP_CHECKSIG OP_SWAP B_pub OP_CHECKSIG OP_ADD OP_DUP OP_DUP OP_VERIFY OP_2 OP_EQUAL OP_NOTIF 0 2 A1_pub A2_pub A3_pub 3 OP_CHECKMULTISIGVERIFY OP_ENDIF

Or something like that— only the 5 pubkeys involved instead of adding extra ones.

I'm aware it's inefficient, I was trying to suggest something that would currently be accepted as a standard transaction. I wasn't aware of the three key limit that's mentioned elsewhere in the thread, though, so my suggestion wouldn't be standard anyway.

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.

Yeah, you're right. I made some changes to the UI to remove some mentions of public/private keys (made that public/private field hidden by default and only shown after clicking "Display advanced options", hidden some stuff behind the "Advanced mode" in the transaction page, etc) but didn't update the FAQ to reflect that.

I'll change the FAQ to be a bit more easy to digest, and yes, some infographic explaining how that works, or possibly even a video, would be a great way to explain that. I'll try and see if I can come up with something.

Weird, I was thinking about this kind of application for the last few days (unfortunately many good domains are squatted, e.g cointract)

I imagined being able to set the arbiter via an email address however, making it a little easier to use, but that obviously has some security implications.

Great execution, very excited to see this part of Bitcoin develop.

btw the about page 404's

> unfortunately many good domains are squatted

This might be partially my fault - I also got bitrator.com and bitrater.com before settling on bitrated :)

I like bitrated. Because it's a bitcoin service where transactions are... arrrrBitrated, matey. Shiver-me-ASICs.

The service is so valuable you could call it a... (•_•) ( •_•)>⌐■-■ (⌐■_■) treasure.

Oops - that testnet link shouldn't be using SSL. Instead of serving he testnet version, it goes to the default ssl server which is the regular version...

I can't edit the comment now, but here's the fixed link: http://testnet.bitrated.com/

AUR: https://aur.archlinux.org/packages/bitrated-git/

Any plans for an API?

Awesome, glad someone is doing this.

Are you going to be offering ways for arbitrators to tie in other social identity sites as a way for arbitrators to present credentials?

Right now, I'm advising them [1] to simply publish their public key in other social profiles they own, but for some Bitcoin-related services (like bitcoin-otc) that have public keys attached to profiles, I'm planning on asking them to sign a message along the lines of "I am shesek from bitcoin-otc, my nickname on bitrated is nadav, and my public key on bitrated is ..." with their bitcoin-otc's key, which'll make it possible to automatically identify them.

[1] https://www.bitrated.com/help/arbitrator-terms.html

i think you're bug bounty (bottom of security page) is a little out of date...

We welcome security audits and offer a bounty of 1 BTC for responsibly disclosing security issues or breaches in our client-server model. If you found a bug, please contact us at security@bitrated.com.

At the time of writing, the BTC/USD exchange rate is ~$110. If this drastically changes (to either side) we'll pay the equivalent BTC of that instead.

Fixed, thanks.

humble suggestion: you should go through the arbitrator's list every so often and clear out the test and dummy accounts

The arbitrarors list is a problem. It seems to suggest that they're all trustworthy, so if your seller just says 'ok lets go with this guy' you might just accept. Then it turns out it was a dummy account created by the seller...

To be useful this would really require a separate service with a reputation system, perhaps a check saying if the arbitrators identity was verified, required pgp etc.

I'm working on that! See my other comment, https://news.ycombinator.com/item?id=6843655

Edit: Also, for now, I'm hoping that it'll take place off the website, possibly over Reddit (which have a pretty active Bitcoin community). I opened an r/bitrated subreddit for possible future use, but it seems like r/bitcoin aren't very excited about this project [1] for now...

[1] http://www.reddit.com/r/Bitcoin/comments/1s0myx/bitrated_bit...

Using well-known arbitrators solve this problem also. I signed up and have quite an online identity that can be verified easily, as did the creator of the hexayurt.

Thanks for the tip; I cleaned them up.

Hey! I saw you talk about this on #bitcoin. Congratulations on the launch! I'm excited to see where you take this.

"especially if you're transecting with an unknown merchant."

misspelled transacting

Thanks for the heads up, I fixed that.