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

61–70 of 74 posts

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

#61

Post by atweiden »

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.…

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

Any plans for an API?

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

#62

Post by nadaviv »

michaelt wrote: post #57
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…

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.

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

#63

Post by nwh »

Lerc wrote: post #56
nwh wrote: post #54

Earlier quoted context omitted.

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 aut…

You can do a trick where you make a transaction from a private key with a nLockTime set in the future, then not broadcast it until that date, and destroy the original private hey. Then the only option is to wait until the time or block number set.

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

#64

Post by DennisP »

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…

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?

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

#65

Post by oleganza »

nadaviv wrote: post #47
ryan-c wrote: post #44

Earlier quoted context omitted.

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: Se…

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…

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.

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

#66

Post by nadaviv »

DennisP wrote: post #64
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…

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

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

#67

Post by nullc »

ryan-c wrote: post #44
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 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: Se…

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.

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

#68

Post by nullc »

oleganza wrote: post #65
nadaviv wrote: post #47

Earlier quoted context omitted.

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…

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.

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

#69

Post by Anderkent »

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…

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

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

#70

Post by ryan-c »

nullc wrote: post #67
ryan-c wrote: post #44

Earlier quoted context omitted.

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: Se…

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.
Post reply on HN