Pages:
Author

Topic: [coinb.in] Open Source, Multi Signature, HD Wallet, SegWit/Bech32 and more! - page 18. (Read 74774 times)

full member
Activity: 144
Merit: 100

You've mentioned that the sellers maybe put at a disadvantage here because the buyer may not sign the transaction, well, there are many tried and tested sites where this type of system works. Such as; localbitcoins, bitmit, coingig or even all those .onion sites - but these sites require you to fully trust them, as they expect the coins to be deposited in their wallet and the buyer presses a "release button", as opposed to a multisig address, where no single person can steal them or claim they've been hacked, etc etc..


Exactly: here we are trying to avoid the need for trusted third parties policing the transactions. And often they rely on a separate trust metrics for assessing the participants: for example, Bitcoin.de has a system of mutual ratings among users based on the number of successful settlements, and each user's rating is visible to all other users. But this requires a centralized database and someone to maintain it, and we don't want that.

Anyway, unless I've miss understood your suggestion, it is not possible to do as payments can not be "cancelled".

However (please correct me if I'm wrong), I guess it's possible to make a transaction that will pay part of the amount sent to the script hash to one address (the Seller) and part to another (the Buyer). If the Buyer reneged on his agreement and refused to sign and broadcast the transaction after receiving the goods, he would have to forfeit the bond.

there are a number of ways you could arrange a multisig contract to address what you call bond forfeiture.  Just to be sure, in its basic form, if the multisig address requires more signatures than are available to sign the tx, then funds will remain locked, yes.  So there is extra burden on all parties to be sure keys are safe & available on time.... or, depending on the details & complexity of agreement - additional signer keys could be used, shared, split or other tricks to build in failsafes.

here is an example of an exchange implementation using Outkast's multisig [thanks again - much fun]
http://isx.io

your question 'is it possible to implement this protocol with p2sh primitives?" - p2sh could be html javascripted just like this one if thats what you mean.

See also:
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0017.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki
http://bitcoin.stackexchange.com/questions/2749/what-is-an-explanation-of-the-p2sh-voting-in-laymans-terms

em
newbie
Activity: 4
Merit: 0

You've mentioned that the sellers maybe put at a disadvantage here because the buyer may not sign the transaction, well, there are many tried and tested sites where this type of system works. Such as; localbitcoins, bitmit, coingig or even all those .onion sites - but these sites require you to fully trust them, as they expect the coins to be deposited in their wallet and the buyer presses a "release button", as opposed to a multisig address, where no single person can steal them or claim they've been hacked, etc etc..


Exactly: here we are trying to avoid the need for trusted third parties policing the transactions. And often they rely on a separate trust metrics for assessing the participants: for example, Bitcoin.de has a system of mutual ratings among users based on the number of successful settlements, and each user's rating is visible to all other users. But this requires a centralized database and someone to maintain it, and we don't want that.

Anyway, unless I've miss understood your suggestion, it is not possible to do as payments can not be "cancelled".

However (please correct me if I'm wrong), I guess it's possible to make a transaction that will pay part of the amount sent to the script hash to one address (the Seller) and part to another (the Buyer). If the Buyer reneged on his agreement and refused to sign and broadcast the transaction after receiving the goods, he would have to forfeit the bond.
hero member
Activity: 714
Merit: 601
I would be cool if someone could make an easy android app to arrange and start a poker match.
So everyone will be able to play poker everywhere with just their smartphone and empty pockets Smiley

Nice idea... final project could be pretty awesome.
hero member
Activity: 714
Merit: 601
Maybe I'm missing something, but I think that with this method the Seller is at a disadvantage here, because the Buyer might renege on his promise and not sign the transaction after receiving the goods (e.g., unless the Seller ship an extra amount of goods). True, a mediator could break the tie if two signatures over three were sufficient to release the payment, but it would be much better if recourse to trusted third parties could be minimized.
A scheme that might work better would run as follows:

- After reaching a verbal agreement, Buyer issues a "Conditional payment" for Seller (which at this stage s/he may cancel at any time)
- Seller accepts the payment by "posting a bond" of, say, X% of the amount.  The payment's status becomes "Committed", and Buyer can't cancel it anymore.
- Seller ships the goods
- Buyer receives the goods, and "releases the payment": the initial amount is paid to Seller, and at the same time the bond is paid back to Buyer.

Is it possible to implement this protocol with p2sh primitives?

Hey,

Thanks for the feedback.

You've mentioned that the sellers maybe put at a disadvantage here because the buyer may not sign the transaction, well, there are many tried and tested sites where this type of system works. Such as; localbitcoins, bitmit, coingig or even all those .onion sites and the mediators do just fine - but these sites require you to fully trust them, as they expect the coins to be deposited in their wallet and the buyer presses a "release button", as opposed to a multisig address, where no single person can steal them or claim they've been hacked, etc etc..

I also suspect many highly trusted sellers would just accept payment directly anyway.

Anyway, unless I've miss understood your suggestion, it is not possible to do as payments can not be "cancelled".

All the best
em
newbie
Activity: 4
Merit: 0
Maybe I'm missing something, but I think that with this method the Seller is at a disadvantage here, because the Buyer might renege on his promise and not sign the transaction after receiving the goods (e.g., unless the Seller ship an extra amount of goods). True, a mediator could break the tie if two signatures over three were sufficient to release the payment, but it would be much better if recourse to trusted third parties could be minimized.
A scheme that might work better would run as follows:

- After reaching a verbal agreement, Buyer issues a "Conditional payment" for Seller (which at this stage Buyer may cancel at any time)
- Seller accepts the payment by "posting a bond" of, say, X% of the amount.  The payment's status becomes "Committed", and Buyer can't cancel it anymore.
- Seller ships the goods
- Buyer receives the goods, and "releases the payment": the initial amount is paid to Seller, and at the same time the bond is paid back to Buyer.

Is it possible to implement this protocol with p2sh primitives?
staff
Activity: 4214
Merit: 1203
I support freedom of choice
I would be cool if someone could make an easy android app to arrange and start a poker match.
So everyone will be able to play poker everywhere with just their smartphone and empty pockets Smiley
hero member
Activity: 714
Merit: 601
I just have to say - It's amazing what you guys are doing...

Thank You!

Thanks Smiley

This is an awesome project, very glad I saw this thread.
+1 million!

Great stuff outkast - i will use this EVERY day from now on



Thanks Smiley
hero member
Activity: 605
Merit: 500
I just have to say - It's amazing what you guys are doing...

Thank You!
hero member
Activity: 714
Merit: 601
Just ran through a test transaction, this works great! Kudos again. My shitty laptop apparently can't sign transactions, the script crashes, but I've tested it successfully on another machine, works a treat. 3cac39fc4aefc65aaa5419a60ab52aebc01d3c55f178a8ebe274650916cf38d6

Good to hear it worked.
sr. member
Activity: 412
Merit: 266
Just ran through a test transaction, this works great! Kudos again. My shitty laptop apparently can't sign transactions, the script crashes, but I've tested it successfully on another machine, works a treat. 3cac39fc4aefc65aaa5419a60ab52aebc01d3c55f178a8ebe274650916cf38d6

full member
Activity: 144
Merit: 100
This is an awesome project, very glad I saw this thread.
+1 million!

Great stuff outkast - i will use this EVERY day from now on

sr. member
Activity: 412
Merit: 266
This is an awesome project, very glad I saw this thread. I'm working on implementing multisig into Bitwasp, and currently support for multisig sucks in the clients. I was hoping someone would come up with a stateless signing tool. Looking forward to your marketplace, I haven't seen another open source one before Smiley
newbie
Activity: 32
Merit: 0
hero member
Activity: 714
Merit: 601
@ktorn I've been looking into it, its a little trickier than I first thought but should have it resolved over the next couple of days.
No worries, take your time.

Fixed Cheesy you can now send back to a multisig address.

One of my test cases http://blockchain.info/tx/832679f95685a8178bc7128dd3450fc29d0552a3ee6bcc3f1254f48d0ba4e0c4
newbie
Activity: 32
Merit: 0
@ktorn I've been looking into it, its a little trickier than I first thought but should have it resolved over the next couple of days.
No worries, take your time.
sr. member
Activity: 278
Merit: 251
ABISprotocol on Gist
OutCast3k:

thank you, you are a good entity

much thanks

very excellent

etc
hero member
Activity: 714
Merit: 601
Just a small update.

If anyone is running my script offline, I've fixed a lot of bugs so i'd suggest getting an update from github.

latest bitcoin-qt client seems only generate address from compressed public key.
so all my addresses are associated with compressed publickey (prefix with 02/03, not 04).
and when compressed publickeys are used, their private keys also in different format, (prfix with K/L instead of 5)

@btcmsia I will look into this, but will have to get back to you before I promise anything. You can always generate a pubkey from the new keys tab, https://coinb.in/multisig/#newKeys You could also use bitaddress.org or brainwallet.org to generate keys pretty quickly.

Now that P2SH output support that we talked about earlier would be the icing on the cake Wink
Should I nudge the bitcoinjs folks about the issue or do you want to have a go at it?

@ktorn I've been looking into it, its a little trickier than I first thought but should have it resolved over the next couple of days.

Many thanks to everyone who has been testing Cheesy
newbie
Activity: 2
Merit: 0
Unfortunately, you can't use an address in replace of a pubkey.

An address is a one way hash of a pubkey. Its not possible to use an address because it cant be used to generate a pubkey, and its the pubkeys (which is included in the redeem scripts) that are needed to validate the signatures in a transaction when you release/send the coins from your mutlsig address.

I'm talking about compressed public key, not address.

latest bitcoin-qt client seems only generate address from compressed public key.
so all my addresses are associated with compressed publickey (prefix with 02/03, not 04).
and when compressed publickeys are used, their private keys also in different format, (prfix with K/L instead of 5)

there will be a compatible issue if your apps only support uncompressed pkey.
newbie
Activity: 32
Merit: 0
I'll look into supporting the ability to send back to a multisig address later today, it shouldn't be that big of a deal. I don't think you'll get a response from the bitcoinjs guys.

Yeah, I've noticed that their github repo hasn't be touched in a while. Ping me when you patch the code and I'll give it a test on this side.
hero member
Activity: 714
Merit: 601
This issue has now been fixed Smiley the order that signatures are added no longer matters.

I've just tested it twice, switching the order of the signing keys between tests, and both transactions were successful.
Your fix works! Smiley

Now that P2SH output support that we talked about earlier would be the icing on the cake Wink
Should I nudge the bitcoinjs folks about the issue or do you want to have a go at it?

I'll look into supporting the ability to send back to a multisig address later today, it shouldn't be that big of a deal. I don't think you'll get a response from the bitcoinjs guys.
Pages:
Jump to: