Coinb.in is a free and open source project released under the MIT license. In its early stages when its primary focus was to develop a proof of concept multisig solution in javascript but now it is a wallet and a playground for bitcoiners to experiment with.

Coinb.in is run and funded by the generosity of others in terms of development and hosting.

Whilst bitescrow.org is pretty neat, unless I'm mistaken it seems to use a different method to facilitate an escrow, it does not seem to use multi signature addresses and is limited to the number of parties that can take part.

What I have developed allows for true multi signature addresses to created in within your browser, and all the outputs are compatible with bitcoin-qt.

To clarify, a multi signature address starts with a 3, like this address 39wJtGk78E76AKpUKLhzrhmwVyZZHfCUbV it does not start with a 1 like normal addresses.

You're right, I will defiantly add more information to the site about the process shortly.

A "redeem script" contains 2 pieces of information, the public keys and the minimum number of signatures required to use it as a spendable input. It is also used to generate the multi signature address itself. There should be some information on the bitcoin wiki about this, but I will also add it to the site shortly.

I believe its possible to manipulate the timestamp of the transaction in the way you've requested, although I will need to do a little bit of testing first.

Very good. Allows use of multisigs without installing bitcoin-qt and downloading the blockchain.

However you shouldn't use the word "escrow" to describe this. This isn't escrow because the escrow agent cannot run off with the money. Also "escrow" agents are heavily regulated in many parts of the world, while arbitrators, adjudicators, mediators, judges, reconcilers, referees, umpires, etc are not subject to that regulation.Changing the word doesn't change much in law, but its bad to give the wrong idea to lawyers since multisig transactions are not something that's ever existed before to my knowledge.

Also you might want to look at http://www.bitrated.com/ which does the same thing but requires an account and has some other features. I don't think it can be easily used with an online auction site, like bitmit.net with multisigs. Your site seems much better for that.

edit: some other thoughts.1. If the public key is copied in with a mistake it could lead to loss of funds. Perhaps we need a standard for base58check public keys? According to the wiki (https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes) you'd use the version byte 42 but it's marked "proposed" and I can't find any other info on it.

Very good. Allows use of multisigs without installing bitcoin-qt and downloading the blockchain.

However you shouldn't use the word "escrow" to describe this. This isn't escrow because the escrow agent cannot run off with the money. Also "escrow" agents are heavily regulated in many parts of the world, while arbitrators, adjudicators, mediators, judges, reconcilers, referees, umpires, etc are not subject to that regulation.Changing the word doesn't change much in law, but its bad to give the wrong idea to lawyers since multisig transactions are not something that's ever existed before to my knowledge.

Also you might want to look at http://www.bitrated.com/ which does the same thing but requires an account and has some other features. I don't think it can be easily used with an online auction site, like bitmit.net with multisigs. Your site seems much better for that.

edit: some other thoughts.1. If the public key is copied in with a mistake it could lead to loss of funds. Perhaps we need a standard for base58check public keys? According to the wiki (https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes) you'd use the version byte 42 but it's marked "proposed" and I can't find any other info on it.

Good point on the terminology, you're right, "escrow" probably isn't the right term. I'll have a think about what to change it to, but I am open to suggestions..

Also I agree I should validate the public keys, to prevent loss of funds, I'll try and come up with something later today.

1. If the public key is copied in with a mistake it could lead to loss of funds. Perhaps we need a standard for base58check public keys? According to the wiki (https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes) you'd use the version byte 42 but it's marked "proposed" and I can't find any other info on it.

Added a check to make sure public keys are valid

Also, looking to also re-brand it from "escrow" to something else, any suggestions are welcome.

Also you might want to look at http://www.bitrated.com/ which does the same thing but requires an account and has some other features. I don't think it can be easily used with an online auction site, like bitmit.net with multisigs. Your site seems much better for that.

It doesn't do the same thing; Coinb.in has a general purpose tool that can be used for many kinds of multi-signature transactions, while Bitrated was created specifically to facilitate arbitration services and has an interface that was optimized for that purpose. Also, Bitrated does not require setting up an account - its optional and only for arbitrators that wants to be listed on the website, and buyers/sellers don't have accounts at all (and I believe it should be quite easy to use with something like bitmit).

Also you might want to look at http://www.bitrated.com/ which does the same thing but requires an account and has some other features. I don't think it can be easily used with an online auction site, like bitmit.net with multisigs. Your site seems much better for that.

It doesn't do the same thing; Coinb.in has a general purpose tool that can be used for many kinds of multi-signature transactions, while Bitrated was created specifically to facilitate arbitration services and has an interface that was optimized for that purpose. Also, Bitrated does not require setting up an account - its optional and only for arbitrators that wants to be listed on the website, and buyers/sellers don't have accounts at all (and I believe it should be quite easy to use with something like bitmit).

Also you might want to look at http://www.bitrated.com/ which does the same thing but requires an account and has some other features. I don't think it can be easily used with an online auction site, like bitmit.net with multisigs. Your site seems much better for that.

It doesn't do the same thing; Coinb.in has a general purpose tool that can be used for many kinds of multi-signature transactions, while Bitrated was created specifically to facilitate arbitration services and has an interface that was optimized for that purpose. Also, Bitrated does not require setting up an account - its optional and only for arbitrators that wants to be listed on the website, and buyers/sellers don't have accounts at all (and I believe it should be quite easy to use with something like bitmit).

Very few people in the real world posses a client capable of sending coins to a multi-sig address. Testnet worked fine for me, but on mainnet blockchain.info doesn't support multi-sig sending, for example....

Very few people in the real world posses a client capable of sending coins to a multi-sig address. Testnet worked fine for me, but on mainnet blockchain.info doesn't support multi-sig sending, for example....

bitcoinqt and electrum send to them.Which is ridiculous, p2sh addresses have been out for years.

i'm using bitcoin-qt v0.8.6 now, all new addresses generated in my wallets only use compressed keys.

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.

If you want to find a pubkey, of an address in bitcoin-qt then, click help, then click the "Debug window", then choose the console tab, and finally enter the following command:

Code:

verifyaddress <youraddress>

The console will then output some data, including a pubkey. You will only be provided pubkeys for addresses in your wallet.

I think btcmsia is talking about compressed public keys, not addresses.When you 'validateaddress' a Bitcoin-qt v0.8.x address, what you get are compressed public keys ("iscompressed":"true") whereas coinb.in expects uncompressed ones.

In my case I'm trying to use coinb.in to create and use a 2-of-2 address, but I'm stuck. I've done all the operations below from coinb.in:

So far so good. The funds are in the p2sh address, with 12 confirmations as I type this.

This is where the problems begin.

When creating a transaction, it looks like it doesn't support sending to p2sh addresses , so I can't send change back to the address that I just created, nor to any other p2sh address (I have tried a couple of them). It only generates the transaction hex when I use non p2sh addresses. That is a significant issue for me. I really need to send the change back to the same address.

Anyway, I decided to retrieve the BTC back to one of my non p2sh addresses, and I'm still stuck. Here's the steps I've taken:

4 ) generate new transaction using redeem script from step #2, sending 0.0021 to a normal bitcoin address and with 0.0001 fee. Transaction hex is generated successfully.5 ) verify the transaction hex from step #4. the verification is successful, and the input and outputs look OK.6 ) sign transaction hex from step #4 with first private key from step #17 ) sign transaction hex from step #6 with second private key from step #18 ) broadcast the transaction hex from step 7"TX rejected"

I noticed that the signed transaction hex from steps #6 and #7 cannot be verified like the original transaction hex in step #5, with "Unable to decode" error. However when pasting those same hex strings to https://coinb.in/decode-raw-transaction.html it decodes them successfully.

So far so good. The funds are in the p2sh address, with 12 confirmations as I type this.

This is where the problems begin.

When creating a transaction, it looks like it doesn't support sending to p2sh addresses , so I can't send change back to the address that I just created, nor to any other p2sh address (I have tried a couple of them). It only generates the transaction hex when I use non p2sh addresses. That is a significant issue for me. I really need to send the change back to the same address.

Anyway, I decided to retrieve the BTC back to one of my non p2sh addresses, and I'm still stuck. Here's the steps I've taken:

4 ) generate new transaction using redeem script from step #2, sending 0.0021 to a normal bitcoin address and with 0.0001 fee. Transaction hex is generated successfully.5 ) verify the transaction hex from step #4. the verification is successful, and the input and outputs look OK.6 ) sign transaction hex from step #4 with first private key from step #17 ) sign transaction hex from step #6 with second private key from step #18 ) broadcast the transaction hex from step 7"TX rejected"

I noticed that the signed transaction hex from steps #6 and #7 cannot be verified like the original transaction hex in step #5, with "Unable to decode" error. However when pasting those same hex strings to https://coinb.in/decode-raw-transaction.html it decodes them successfully.

Any idea what could be going wrong with this?

Hey ktorn,

I'll get the issue sorted with not being able to send back to multi sig addresses, but first lets find out what went wrong when building a serialized/hex transaction and recover your funds.

If you cant pop back on IRC (I missed you by 15 minutes), and you're still having problems, can you PM me the following;

1, the public keys you used.2, the minimum number of signatures required you set.3, the address and redeemScript it generated for you.

So far so good. The funds are in the p2sh address, with 12 confirmations as I type this.

This is where the problems begin.

When creating a transaction, it looks like it doesn't support sending to p2sh addresses , so I can't send change back to the address that I just created, nor to any other p2sh address (I have tried a couple of them). It only generates the transaction hex when I use non p2sh addresses. That is a significant issue for me. I really need to send the change back to the same address.

Anyway, I decided to retrieve the BTC back to one of my non p2sh addresses, and I'm still stuck. Here's the steps I've taken:

4 ) generate new transaction using redeem script from step #2, sending 0.0021 to a normal bitcoin address and with 0.0001 fee. Transaction hex is generated successfully.5 ) verify the transaction hex from step #4. the verification is successful, and the input and outputs look OK.6 ) sign transaction hex from step #4 with first private key from step #17 ) sign transaction hex from step #6 with second private key from step #18 ) broadcast the transaction hex from step 7"TX rejected"

I noticed that the signed transaction hex from steps #6 and #7 cannot be verified like the original transaction hex in step #5, with "Unable to decode" error. However when pasting those same hex strings to https://coinb.in/decode-raw-transaction.html it decodes them successfully.

Any idea what could be going wrong with this?

Thanks for providing the information via pm/irc, the bug found should be fixed. If you could re-test and get back to me that would be great, thanks.

OK, after going over a few tests with OutCast3k we think we nailed the issue.

In a nutshell: Currently the order of the signatures matters.

Our tests involved a 2-of-2 multisig address, which I created with 2 pubkeys (lets call them pub1 and pub2).

When spending from the multisig address, signing the transaction with priv1 first and priv2 second always failed when broadcasting (with TX rejected).But when signing the same transaction in the opposite order, using priv2 first and priv1 secondly the broadcast worked OK.

Thanks OutCast3k for spending a considerable amount of time in troubleshooting this!

OK, after going over a few tests with OutCast3k we think we nailed the issue.

In a nutshell: Currently the order of the signatures matters.

Our tests involved a 2-of-2 multisig address, which I created with 2 pubkeys (lets call them pub1 and pub2).

When spending from the multisig address, signing the transaction with priv1 first and priv2 second always failed when broadcasting (with TX rejected).But when signing the same transaction in the opposite order, using priv2 first and priv1 secondly the broadcast worked OK.

Thanks OutCast3k for spending a considerable amount of time in troubleshooting this!

Yup, the order of the signatures seems to matter, I'll currently trying to work out a solution.

OK, after going over a few tests with OutCast3k we think we nailed the issue.

In a nutshell: Currently the order of the signatures matters.

Our tests involved a 2-of-2 multisig address, which I created with 2 pubkeys (lets call them pub1 and pub2).

When spending from the multisig address, signing the transaction with priv1 first and priv2 second always failed when broadcasting (with TX rejected).But when signing the same transaction in the opposite order, using priv2 first and priv1 secondly the broadcast worked OK.

Thanks OutCast3k for spending a considerable amount of time in troubleshooting this!

Yup, the order of the signatures seems to matter, I'll currently trying to work out a solution.

Thanks ktorn, for beta testing and finding the issue.

Will post back when fixed.

This issue has now been fixed the order that signatures are added no longer matters.

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.

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.

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

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

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

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.

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

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.

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.

- Does your 1% fee apply to every transaction or only those transactions involving disputes?

- bitrated has a field where you can enter a transaction agreement or contract that specifies, among other things, what the modes of payment will be and what proof of payment must be provided in the event of a dispute. There is no such field on coinb.in. So how would you decide what to do in the event of a dispute?

- Does your 1% fee apply to every transaction or only those transactions involving disputes?

- bitrated has a field where you can enter a transaction agreement or contract that specifies, among other things, what the modes of payment will be and what proof of payment must be provided in the event of a dispute. There is no such field on coinb.in. So how would you decide what to do in the event of a dispute?

Hey,

As it stands, the 1% fee would only be applied to those transactions involving disputes.

Most users here seem to make an agreement and sign it with their PGP key in the event a dispute arises, a few other users will get in touch first. Saying that, I suppose a possible solution could be to have users create a message/agreement and sign it (in the browser) with their corresponding private key and then that could be used by the mediator if their is a dispute.

- Does your 1% fee apply to every transaction or only those transactions involving disputes?

- bitrated has a field where you can enter a transaction agreement or contract that specifies, among other things, what the modes of payment will be and what proof of payment must be provided in the event of a dispute. There is no such field on coinb.in. So how would you decide what to do in the event of a dispute?

Hey,

As it stands, the 1% fee would only be applied to those transactions involving disputes.

Most users here seem to make an agreement and sign it with their PGP key in the event a dispute arises, a few other users will get in touch first. Saying that, I suppose a possible solution could be to have users create a message/agreement and sign it (in the browser) with their corresponding private key and then that could be used by the mediator if their is a dispute.

Do you have suggestions or preferences yourself? (or anybody else?)

Easiest solution would be that the buyer and seller come to an agreement and email it to you. You verify receipt by replying with a quote.

Multisig is hard enough as it is. I think if you asked people to sign messages with private keys they would just blank out

You're right, I will defiantly add more information to the site about the process shortly.

A "redeem script" contains 2 pieces of information, the public keys and the minimum number of signatures required to use it as a spendable input. It is also used to generate the multi signature address itself. There should be some information on the bitcoin wiki about this, but I will also add it to the site shortly.

I believe its possible to manipulate the timestamp of the transaction in the way you've requested, although I will need to do a little bit of testing first.

Thanks for pointing out the broken link, I've since fixed it.

What if I lose the redeemScript? is there a way to retrieve it or regenerate it? If I don't have the RedeemScript, is it still possible to spend the coins given you have the required keys to "unlock" the transaction?

You're right, I will defiantly add more information to the site about the process shortly.

A "redeem script" contains 2 pieces of information, the public keys and the minimum number of signatures required to use it as a spendable input. It is also used to generate the multi signature address itself. There should be some information on the bitcoin wiki about this, but I will also add it to the site shortly.

I believe its possible to manipulate the timestamp of the transaction in the way you've requested, although I will need to do a little bit of testing first.

Thanks for pointing out the broken link, I've since fixed it.

What if I lose the redeemScript? is there a way to retrieve it or regenerate it? If I don't have the RedeemScript, is it still possible to spend the coins given you have the required keys to "unlock" the transaction?

Yes you can regenerate the redeem script. You cannot lose your multisig address; you can lose some privkeys - as long as you [or your Agents] saved the total number required to sign. Best to move & back them up securely [pref using thumbdrive & a browser on a computer that has never connected to the internet ever]

git | | ID'Bitcoin is the progress toward a society of privacy. The savage’s whole existence is public, ruled by the laws of his tribe. Bitcoin is the process of setting man free from men'

This multisig script does not accept mixed or uncompresed. [the multisig "function" is not exclusive to this script - you can do multisig txs other ways, but they are not cool]. You can generate new uncompressed keys using this also. You do not want to sign with a wallet address that's been used or is/was/might ever be holding funds. You will have to expose your privkey and create unnecessary vulnerabilities to your existing flimsy security efforts. Better to generate new pubkeys just for controlling your multisig.

git | | ID'Bitcoin is the progress toward a society of privacy. The savage’s whole existence is public, ruled by the laws of his tribe. Bitcoin is the process of setting man free from men'

Enter the uncompressed public keys of all the participants, to create a multi signature address. Maximum of 20 allowed.

This is incorrect actually. While the underlying CHECKMULTISIG opcode can support up to 20 pubkeys, P2SH has an additional limit of 520 bytes for the scriptPubKey. That gives a size-dependent maximum of 15 compressed pubkeys, and just 7 with the larger uncompressed keys.

Enter the uncompressed public keys of all the participants, to create a multi signature address. Maximum of 20 allowed.

This is incorrect actually. While the underlying CHECKMULTISIG opcode can support up to 20 pubkeys, P2SH has an additional limit of 520 bytes for the scriptPubKey. That gives a size-dependent maximum of 15 compressed pubkeys, and just 7 with the larger uncompressed keys.

Perhaps I'm missing something - it seems to work fine for me using 20 uncompressed [dont recall if I've tried having all 20 required signers yet - trying now]. I understand this code somewhat[not enough]; Please elaborate if possible & let me know what lines are P2SH - I thought this was a bit different. I'm digging through it blindly.

That's "signature operations", not signatures. SigOps is just a metric used to restrict the amount of CPU time processing a block takes as an anti-DoS measure - it's got nothing to do with the actual number of signatures.

You'll find you can create that P2SH address with the Bitcoin RPC interface, but you can't actually spend from it succesfully. Kinda misleading really - if you could do up a patch to fix that and make createmultisigaddress raise an error that'd be great.

I'm working on a project to create a multisig service and need to create keys server-side without exposing them to end users. My first thought was to refactor your work to run in a node.js server. Does this seem like a good solution, and if so have you looked into doing anything similar?

Ultimately I need to be able to create key pairs, validate user public keys, and create/sign multisig addresses. For signing I am planning to have users partially sign a multisig transaction with their keys and then send that to my server for final signature and broadcasting from the server. This would likely mean needing to confirm partially signed transactions sent to the server, though I haven't looked into the feasibility of that yet. Does your code already support partial signing and validation?

Enter the uncompressed public keys of all the participants, to create a multi signature address. Maximum of 20 allowed.

This is incorrect actually. While the underlying CHECKMULTISIG opcode can support up to 20 pubkeys, P2SH has an additional limit of 520 bytes for the scriptPubKey. That gives a size-dependent maximum of 15 compressed pubkeys, and just 7 with the larger uncompressed keys.

Peter, Is there any prospect in the future for these limits to be increased? It seems to me there are quite a lot of applications for larger than 15.Or if that just leads to unacceptably big transactions even with appropriate fees, is there some way that I haven't quite thought of to combine multisig keys to get bigger consensus mechanisms? Or is it possible to use some kind of Shamir's secret sharing idea? (I only know the idea vaguely, not sure how it would work in practice).

Peter, Is there any prospect in the future for these limits to be increased? It seems to me there are quite a lot of applications for larger than 15.Or if that just leads to unacceptably big transactions even with appropriate fees, is there some way that I haven't quite thought of to combine multisig keys to get bigger consensus mechanisms? Or is it possible to use some kind of Shamir's secret sharing idea? (I only know the idea vaguely, not sure how it would work in practice).

Btw, nice work on the site guys.

I'm at the Financial Crypto conference right now and actually just talked to a guy who claims to know of a researcher who has come up with a n-of-m threshold signature scheme that is compatible with existing Bitcoin signatures. Hopefully this will pan out - if it does you'll be able to do secure multisig without a single-point-of-failure (as Shamir's secret sharing does) with transactions and addresses that look identical to standard ones and are the same size as standard transactions. I didn't ask if there were any limits on how many keys could be combined, but there probably aren't.

Peter, Is there any prospect in the future for these limits to be increased? It seems to me there are quite a lot of applications for larger than 15.Or if that just leads to unacceptably big transactions even with appropriate fees, is there some way that I haven't quite thought of to combine multisig keys to get bigger consensus mechanisms? Or is it possible to use some kind of Shamir's secret sharing idea? (I only know the idea vaguely, not sure how it would work in practice).

Btw, nice work on the site guys.

I'm at the Financial Crypto conference right now and actually just talked to a guy who claims to know of a researcher who has come up with a n-of-m threshold signature scheme that is compatible with existing Bitcoin signatures. Hopefully this will pan out - if it does you'll be able to do secure multisig without a single-point-of-failure (as Shamir's secret sharing does) with transactions and addresses that look identical to standard ones and are the same size as standard transactions. I didn't ask if there were any limits on how many keys could be combined, but there probably aren't.

Thanks. I realised after I wrote that that Shamir shares *secrets* not signatures so that's no good (I guess the clue was in the title ). Could something be hacked together with CoinSwap?

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

Thanks for the tip. Will do

Edit: actually before I go through all that ... doesn't this mean it won't work?:

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

Thanks for the tip. Will do

Edit: actually before I go through all that ... doesn't this mean it won't work?:

... I'd like to be able to use this script on an offline computer... but right now it checks the balance of the multisig address and won't let me generate a transaction if it think that address has a zero balance. If I'm not online, I'm not sure if it would let me generate a transaction or not... any tips or workarounds?

... I'd like to be able to use this script on an offline computer... but right now it checks the balance of the multisig address and won't let me generate a transaction if it think that address has a zero balance. If I'm not online, I'm not sure if it would let me generate a transaction or not... any tips or workarounds?

I'll probably just edit the source code locally for what I want... but, for what it's worth, I think other people may want to run this on an offline computer too.

Just made my first successful multisignature transaction with this. Pretty sweet.

... I'd like to be able to use this script on an offline computer... but right now it checks the balance of the multisig address and won't let me generate a transaction if it think that address has a zero balance. If I'm not online, I'm not sure if it would let me generate a transaction or not... any tips or workarounds?

I'll probably just edit the source code locally for what I want... but, for what it's worth, I think other people may want to run this on an offline computer too.

Just made my first successful multisignature transaction with this. Pretty sweet.

I will have a think about this feature and consider adding it to the next update.

... I'd like to be able to use this script on an offline computer... but right now it checks the balance of the multisig address and won't let me generate a transaction if it think that address has a zero balance. If I'm not online, I'm not sure if it would let me generate a transaction or not... any tips or workarounds?

I'll probably just edit the source code locally for what I want... but, for what it's worth, I think other people may want to run this on an offline computer too.

Just made my first successful multisignature transaction with this. Pretty sweet.

I will have a think about this feature and consider adding it to the next update.

Very nice implementation. Watching it.I have a a couple of quick questions if someone can clarify.

1) What are the requirements / pre-requisite softwares or client that is required to be running on the server to implement it.

2) On coinb.in/multisig i see that there is a 1% Agent fee option. How does that work? Is it like as soon as the multi-address is funded, the 1% fee is sent to OutCast3k's (or any agent's) bitcoin address.?

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

Does this mean that the reference client hasn't implemented the BIP as stated? It is supposed to verify that the serialized script is standard, right?

Is the issue that the isStandard() only checks the scriptPub and the serialized script is in the scriptSig?

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

Does this mean that the reference client hasn't implemented the BIP as stated? It is supposed to verify that the serialized script is standard, right?

Is the issue that the isStandard() only checks the scriptPub and the serialized script is in the scriptSig?

The 520 byte limit for the redeemscript is "absolute" (not depending on isStandard()). ie your m signatures plus your n pubkeys plus a few bytes must be less than 520.

The 500 byte limit for the whole scriptSig is an isStandard() rule, and so you can send out transactions which violate this limit via for example Eligius. Or, at least, you *may* be able to.

So, I'm testing Coinb.in against Bitwasp, since clients can't really support P2SH. I've rigorously tested it against bitcoind which works fine. I love the idea of a JS tool to sign these transactions, but I'm having difficulty with a transaction. Coinb.in seems to be replacing the signature added by the first signer, rather than just adding the second?

I signed it in bitcoind (the first key in the redeemScript), then took the transaction to Coinbin, loaded the verify tab, it confirmed 1 of 2 needed signatures were there:010000000149306d4e998d629471a261e23593aa96f06e37faf9f29a773032fe01fb3ab84e00000000f400473044022041e3be1f1f5b2df1504219d45199b02822940885e347354b392e8d638a304dfe02200b380ed825e2b82bcdebdf8986ceb58e90de7f0dca73185c491b174cbd3502c9014ca95221031174b9ebf4014181289a3923d6d17205a25808dbd6397bc747e0a5631948adc741043ce7c793baf8aec463114411d685b2ebb27e4b4b578543d82bba5c36e17e3950bef11cb1838c9cdb2323db12ac1c132f2aaba10cfc0b3b1528affe507436c5fc41048bff65f68fad7a6519dd8b6f9232e0ce2e39ad9df9fd1c46a26ebabfd915a7257d3fa34d90f0b02e2ddf1e954f0200037834f7987934ce096999b073eb9d4ef053aeffffffff0210270000000000001976a91463bdd38a5e555ad7c775a64139420ba302201c2d88ac204e0000000000001976a914e3ad4cf590cd02b629ca5e65ed8f27d499edefde88ac00000000

So I copied the private key from the Bitcoin Keys tab, to the Sign tab, as well as the above transaction. I clicked sign, and up pops:010000000149306d4e998d629471a261e23593aa96f06e37faf9f29a773032fe01fb3ab84e00000000f4004730440220588e2a0e528e6545cc1650bf608ca92a2eacb6cd2e8ff6e051d1206770672b11022074e0fd24e9c352ace7112feff2e1c9bd456162760a16a30e3a947bfce44ccd06014ca95221031174b9ebf4014181289a3923d6d17205a25808dbd6397bc747e0a5631948adc741043ce7c793baf8aec463114411d685b2ebb27e4b4b578543d82bba5c36e17e3950bef11cb1838c9cdb2323db12ac1c132f2aaba10cfc0b3b1528affe507436c5fc41048bff65f68fad7a6519dd8b6f9232e0ce2e39ad9df9fd1c46a26ebabfd915a7257d3fa34d90f0b02e2ddf1e954f0200037834f7987934ce096999b073eb9d4ef053aeffffffff0210270000000000001976a91463bdd38a5e555ad7c775a64139420ba302201c2d88ac204e0000000000001976a914e3ad4cf590cd02b629ca5e65ed8f27d499edefde88ac00000000

Which when passed to the Verify tab says only one signature is added, as highlighted above, and it's different to the one I added. There's an implicit reward here for anyone who can help..

So, I'm testing Coinb.in against Bitwasp, since clients can't really support P2SH. I've rigorously tested it against bitcoind which works fine. I love the idea of a JS tool to sign these transactions, but I'm having difficulty with a transaction. Coinb.in seems to be replacing the signature added by the first signer, rather than just adding the second?

I'm using Chrome on Windows. My linux netbook can't handle that page for some reason, the script becomes unresponsive (debian, iceweasel, 2gb ram), so I did it here. I'll download firefox for windows and try that.

I'm using Chrome on Windows. My linux netbook can't handle that page for some reason, the script becomes unresponsive (debian, iceweasel, 2gb ram), so I did it here. I'll download firefox for windows and try that.

I've made a couple of tweaks to the source code which should decrease the load when attempting to sign, so let me know if your netbook handles it any better.

What version of chrome are you using? How did you get on with firefox?

I tried it again on Chrome. Trying to sign the partially signed transaction just yields a transaction with one different signature.I tried with the unsigned transaction, and that failed too.

One thing that could be causing trouble is that I'm using one compressed keys, I notice it asks for them to be uncompressed when you're entering them? But, then again, the key I'm having trouble signed with came from Coinb.in.

Have you tried signing the transaction I pasted? I've used Coinbin before, and been telling a lot of people about it.

I tried it again on Chrome. Trying to sign the partially signed transaction just yields a transaction with one different signature.I tried with the unsigned transaction, and that failed too.

One thing that could be causing trouble is that I'm using one compressed keys, I notice it asks for them to be uncompressed when you're entering them? But, then again, the key I'm having trouble signed with came from Coinb.in.

Have you tried signing the transaction I pasted? I've used Coinbin before, and been telling a lot of people about it.

As I'm sure you are aware; signatures must be added to the 'scriptSig' in the same order the 'public keys' are found in the 'redeem script', because of this signatures aren't simply inserted to the scriptSig, they are rebuilt. The code for this is here:

So, I suspect when the Bitcoin.ECDSA.verify() function is called it fails to validate your signature against a public key because its the wrong kind. (i.e. its compressed when it should be uncompressed) This means its not re-added.

As I'm sure you are aware; signatures must be added to the 'scriptSig' in the same order the 'public keys' are found in the 'redeem script', because of this signatures aren't simply inserted to the scriptSig, they are rebuilt. The code for this is here:

So, I suspect when the Bitcoin.ECDSA.verify() function is called it fails to validate your signature against a public key because its the wrong kind. (i.e. its compressed when it should be uncompressed) This means its not re-added.

I'm not sure how you'd fix this exactly, but I will have a think.

Ah interesting. I didn't know they had to have a particular order. While you can't just change the public keys in the redeemScript, could scriptListPubkey() decompress public keys as they're encountered? I'm guessing elsewhere it expects them to be uncompressed too to have easy access to the full key.

Any further thoughts on this? Every client that upgrades to BIP0032 will not be able to use your service, and right now, bitcoind (the only to work with P2SH) returns compressed keys and will not work with your site.

In fact I realize now why it worked before but not now. Back then I created the address with all uncompressed keys! But this is unrealistic right now.

I don't mean to nag, but is there any sign of upcoming support for compressed keys? I think it's pretty vital, as when any party to a multisig address uses a key from bitcoind, or electrum from the next release on, will encounter the issue I had with the scriptSig reconstruction (leaving out all signatures where the key was compressed).

I've tried the service and a 2of3 worked great.however, I tried something that I actually need right now in the form of a 6-of-10 and... no go Getting a tx rejected -22 and log error says "nonstandard transaction: scriptsig-size" which I assume relates to the 500b limit mentioned earlier in the thread.Is there a way to make this work?Reading around in some other discussions I saw being mentioned that even a 15 of 15 should work, so I'm a bit confused as to why 6 of 10 doesn't.

Also OutCast, on a side note, it would be really great if you could provide the non-minified bitcoinjs code (either as a download here or in the git repo) as part of the opensource approach.

as a followup - I just tried doing a manual multisig transaction of a 6 of 10, using only compressed pub keys in the latest bitcoin core, but still getting tx rejected 22. the script is somewhat shorter than with the non-compressed, but definitely not by a huge amount.

Any ideas on how to get this to work?I've seen people saying that with compressed pub keys even a 15 of 15 could fit within the 520b limit, so what am I missing here?

as a followup - I just tried doing a manual multisig transaction of a 6 of 10, using only compressed pub keys in the latest bitcoin core, but still getting tx rejected 22. the script is somewhat shorter than with the non-compressed, but definitely not by a huge amount.

Any ideas on how to get this to work?I've seen people saying that with compressed pub keys even a 15 of 15 could fit within the 520b limit, so what am I missing here?

Hi, I'm guessing you're the same guy as I spoke with on reddit? the answer is still: use Eligius. 6 of 10 is not standard (exceeds 500 limit). Was there some aspect of that explanation that didn't make sense? (Unless it wasn't you, in which case, sorry).

Can someone make a complete tutorial for the average user to make simple 2of3 transactions?

Some questions:- what is a redeem script?- what should we put in that field?- can't there be some simplifications like predifined 2of3 addresses and transactions?- in the transaction, what should I use as inputs?

Sorry for so many questions.It would be so great if it could be usable by average users!

There seem to be a bug: in both "create transaction" and "verify transaction", the input transaction is unknown to blockchain. Is it normal?

Also, in the signing page, could there be a "verify" button or an automatic verify step before the transaction is signed?

I use chome in linux.In create new transaction, when you paste the redeem script with the middle button, the script is not activated. When you add a space or any caracter (or remove a caracter), the address goes wrong.There is no check on the redeem script integrity. This can be dangerous I think. There should be a verify step.

In the verify tab, could you add a "sign" button for transactions, or a "create transaction" for a redeem script? This would simplify the whole process.

My 3 of 5 is being rejected... The "verify script" shows all in order. Blockchain.info pushtx:

Quote

Script not of right size, expecting 2 but got 5

I couldn't use Blockchain.info's pushtx for this. *shrugs*

I just used the one on OPs website.

Coinb.in is also failing... I also just tried a 3 of 4...

3 of 4 worked fine for me... note that if you try to resubmit the same transaction it will say your txn is invalid.

My 3 of 4 just got confirmations. 3 of 5 still being rejected by both coinb.in and blockchain.info.

It might be over 500 bytes... in which case (I'm told) it won't get confirmed by anyone.

The same thing is happening to me - the 3-of-5 isn't working. I had a 2-of-3 work just fine this morning, but this afternoon, there is no way to get the 3-of-5 to work. Is coinbin not coding the transactions correctly? (Tried with blockchain.info to push too)Is my money lost for ever??? ( Thanks coinb.in...) I hope that is not the case...Thanks,-Luc

The same thing is happening to me - the 3-of-5 isn't working. I had a 2-of-3 work just fine this morning, but this afternoon, there is no way to get the 3-of-5 to work. Is coinbin not coding the transactions correctly? (Tried with blockchain.info to push too)Is my money lost for ever??? ( Thanks coinb.in...) I hope that is not the case...Thanks,-Luc

The hex encoded transaction you have given me via email appears to use non existent transaction IDs, as I've explained back to you. I don't think your money is lost, but if you could try again and note down each step you take, and the output and then contact me if it fails.

I've tried the service and a 2of3 worked great.however, I tried something that I actually need right now in the form of a 6-of-10 and... no go Getting a tx rejected -22 and log error says "nonstandard transaction: scriptsig-size" which I assume relates to the 500b limit mentioned earlier in the thread.Is there a way to make this work?Reading around in some other discussions I saw being mentioned that even a 15 of 15 should work, so I'm a bit confused as to why 6 of 10 doesn't.

Also OutCast, on a side note, it would be really great if you could provide the non-minified bitcoinjs code (either as a download here or in the git repo) as part of the opensource approach.

Thanks!

Can you drop me a email with the details, and i'll take a look. I'm not sure right now.

The same thing is happening to me - the 3-of-5 isn't working. I had a 2-of-3 work just fine this morning, but this afternoon, there is no way to get the 3-of-5 to work. Is coinbin not coding the transactions correctly? (Tried with blockchain.info to push too)Is my money lost for ever??? ( Thanks coinb.in...) I hope that is not the case...Thanks,-Luc

The hex encoded transaction you have given me via email appears to use non existent transaction IDs, as I've explained back to you. I don't think your money is lost, but if you could try again and note down each step you take, and the output and then contact me if it fails.

Thanks for reply. I think I know why. When I put my RedeemScript in your area to construct the transaction, it shows me the three inputs, but the numbers are mixed up.For example, the first one you listed from the decode transaction section is: 3fbd...120a but is listed like this in the construct transaction section: 0a12...bd3f.It looks like the 8 bit groupings are grouped together, but in some sort of reverse order (0a is at the start in one, and at the end in the other).Correct me if I'm wrong, but it looks like (to me) there is an error somewhere in your code that flipped the txid's. ?Is this a little-endian/big-endian thing?I'm not sure why it would have worked for 2-of-3 but now for 3-of-5 it's being encoded differently?-Luc

The page uses javascript to generate a multi signature address, the buyer sends the funds to the address. Once the agreement between all parties has completed a transaction can be created using the redeem script which is then signed by the participants. You can then broadcast the signed transaction into the network, releasing the funds to the chosen address.Posted from Bitcointa.lk - #puVNlkBcvhsA7bDq

Will this be coming back?Looks like an SSL error, I remember getting onto the site fine before, and then there was the ddos attack, it looks like something else is wrong now.I would like to try it on testnet.Hope to see this project continue on.

Will this be coming back?Looks like an SSL error, I remember getting onto the site fine before, and then there was the ddos attack, it looks like something else is wrong now.I would like to try it on testnet.Hope to see this project continue on.

I'm attempting to test this out and not having much success. I used two of my own existing addressed to do the test so I can't/won't provide my private keys. Here are the steps I took:

1. New MultiSig Address. Testing a 2-2.2. Got this multisig address: 3BubMVeGDzvhZyJ1iCS8vpjKgDSfT18Dh13. Sent some btc from addr1 to the multisig. This worked.4. Verified the redeem script. Says 2 signatures from both public keys are required.5. Signed redeem script with private key of addr16. Copied the result of #5 back in to the upper field and pasted in private key of addr27. Copied the result of #6 in to Verify page. Shows the original transaction id, checkmark for redeem script, minimum number of signers 2 and number of times signed 2. Shows me the correct output address and the amount.8. Copied the result of #6 in to Broadcast. TX Rejected.9. Reattempted steps 5-8 using keys in reverse order. Same result.

1.) I found a typo in the error function on line 955 of index.html: "unspent" is spelled "unpsent". Also, I noticed that the error prompt for there being no funds contained there pops up multiple times -- once per required signature. Shouldn't it just pop up once?

2.) How does this script compare to what Mycelium is doing with their Entropy device? My understanding is that on their multisig paper wallet, on what is printed out, you don't get a redeem script, you just get a multisig public address and however many compressed private keys. Is their method still fully compatible with this script?Edit: It seems that Mycelium is, instead, using some form of Shamir's Secret Sharing Scheme.

You're right, I will defiantly add more information to the site about the process shortly.

A "redeem script" contains 2 pieces of information, the public keys and the minimum number of signatures required to use it as a spendable input. It is also used to generate the multi signature address itself. There should be some information on the bitcoin wiki about this, but I will also add it to the site shortly.

I believe its possible to manipulate the timestamp of the transaction in the way you've requested, although I will need to do a little bit of testing first.

Thanks for pointing out the broken link, I've since fixed it.

What if I lose the redeemScript? is there a way to retrieve it or regenerate it? If I don't have the RedeemScript, is it still possible to spend the coins given you have the required keys to "unlock" the transaction?

Yes you can regenerate the redeem script. You cannot lose your multisig address; you can lose some privkeys - as long as you [or your Agents] saved the total number required to sign. Best to move & back them up securely [pref using thumbdrive & a browser on a computer that has never connected to the internet ever]

How would one regenerate the redeem script when having only 2 of the 3 keys?

I'm attempting to test this out and not having much success. I used two of my own existing addressed to do the test so I can't/won't provide my private keys. Here are the steps I took:

1. New MultiSig Address. Testing a 2-2.2. Got this multisig address: 3BubMVeGDzvhZyJ1iCS8vpjKgDSfT18Dh13. Sent some btc from addr1 to the multisig. This worked.4. Verified the redeem script. Says 2 signatures from both public keys are required.5. Signed redeem script with private key of addr16. Copied the result of #5 back in to the upper field and pasted in private key of addr27. Copied the result of #6 in to Verify page. Shows the original transaction id, checkmark for redeem script, minimum number of signers 2 and number of times signed 2. Shows me the correct output address and the amount.8. Copied the result of #6 in to Broadcast. TX Rejected.9. Reattempted steps 5-8 using keys in reverse order. Same result.

So now I'm stuck. Not sure what to do.

Thanks!

1) I suggest you test this with another human rather than with yourself

I am trying to use http://coinb.in/multisig/ to create a transaction.I keep getting "This address has no available balance to spend" though it has balance .The address is :369cUZdwYuCf1L987xmMz8ZJZUT1UCWVQfWhat I am missing here?

I have the same problem. After accepting the error message, I can click on the Multisig address and blockchain.info pops up, showing the rightbalance. Still there's no way of creating a transaction..

It's a real escrow with some real money. Not a fortune, but still.. Would be cool if OutCast3k could comment on that.

edit: Alright, I could figure out that the problem is not so much the multisig script, but the fact that the coinb.in API seems not to work properly.The problem with the rawgit-Version is that it refers to the https-version of the coinb.in API, which is completely down it seems. One can replace https by http in the appropriate line, then one gets the "This address has no available balance to spend" problem. The easiest solution seems to be to wait until coinb.in is back (if ever) or to use another API (but I don't know if there's something available.. I have no idea about this stuff.)

Is the coinb.in/multisig site working properly? It seems to be able to create redeem scripts properly, but the transactions page never seems to find spendable outputs. I wonder if it's API connection is broken?

Is the coinb.in/multisig site working properly? It seems to be able to create redeem scripts properly, but the transactions page never seems to find spendable outputs. I wonder if it's API connection is broken?

Indications from recent comments are that it is not working properly, I seem to recall the coinb.in/multisig site was subjected to some attacks and had problems and the github-based site (see my earlier comments in this thread) did not have any problems but then later _did_ have problems for some reason. (server perhaps) however, I am guessing the best thing to do is see if you can raise OutCast3k (careful with the spelling!) on this forum (who shows as last active June 29, 2014), it's possible that btcapparel (also on this forum) may have been in touch with OutCast3k (but probably late last year...) so it is a long shot

I would check here and open an issue:https://github.com/OutCast3k/bitcoin-multisigThere is an open issue (#16) that already represents the issue described, that is unresolved. If it remains unresolved one could fork it and develop something new, or look at the other options (CoPay, which is a multisignature tool developed by BitPay, or Armory's multisignature feature - which I'm not sure of the status of those at this time, but I recall they were serious about the development of such).

NOTE--NOTE:If you (and the other person you co-generate multisignature with) have already used coinb.in/multisig to generate something to which funds can be sent, you should both have written (or typed) down and locked away in a safe place, the following:pubkeyaddressprivkey (this is private and should only be known by the individual holding it, by the way, hence the name, privkey!!)multisig address (this is public and will typically begin with the number three, I think)redeem script(Note that there will be a bunch of gobbledygook that will be different for you than it would be for the other party who is a participant in the multisignature transaction, but at the end of it all, when you've gone through the steps, you both have a ton of info which includes, of course, public multisignature address that you can show anyone.)(Also, do not expose the paper you have all this information on, to Frog Lube, Cosmoline, or any other gunner lube which may happen to be laying around in your safe! - Because if you do it will stain it something awful.)Have fun out there.

Is the coinb.in/multisig site working properly? It seems to be able to create redeem scripts properly, but the transactions page never seems to find spendable outputs. I wonder if it's API connection is broken?

Indications from recent comments are that it is not working properly, I seem to recall the coinb.in/multisig site was subjected to some attacks and had problems and the github-based site (see my earlier comments in this thread) did not have any problems but then later _did_ have problems for some reason. (server perhaps) however, I am guessing the best thing to do is see if you can raise OutCast3k (careful with the spelling!) on this forum (who shows as last active June 29, 2014), it's possible that btcapparel (also on this forum) may have been in touch with OutCast3k (but probably late last year...) so it is a long shot

I would check here and open an issue:https://github.com/OutCast3k/bitcoin-multisigThere is an open issue (#16) that already represents the issue described, that is unresolved. If it remains unresolved one could fork it and develop something new, or look at the other options (CoPay, which is a multisignature tool developed by BitPay, or Armory's multisignature feature - which I'm not sure of the status of those at this time, but I recall they were serious about the development of such).

He fixed it. I think it was just something trivial like a changed API. I cannot endorse copay or recommend until it has a lot more testing. It's been very buggy, dangerously so.

Is the coinb.in/multisig site working properly? It seems to be able to create redeem scripts properly, but the transactions page never seems to find spendable outputs. I wonder if it's API connection is broken?

Indications from recent comments are that it is not working properly, I seem to recall the coinb.in/multisig site was subjected to some attacks and had problems and the github-based site (see my earlier comments in this thread) did not have any problems but then later _did_ have problems for some reason. (server perhaps) however, I am guessing the best thing to do is see if you can raise OutCast3k (careful with the spelling!) on this forum (who shows as last active June 29, 2014), it's possible that btcapparel (also on this forum) may have been in touch with OutCast3k (but probably late last year...) so it is a long shot

I would check here and open an issue:https://github.com/OutCast3k/bitcoin-multisigThere is an open issue (#16) that already represents the issue described, that is unresolved. If it remains unresolved one could fork it and develop something new, or look at the other options (CoPay, which is a multisignature tool developed by BitPay, or Armory's multisignature feature - which I'm not sure of the status of those at this time, but I recall they were serious about the development of such).

He fixed it. I think it was just something trivial like a changed API. I cannot endorse copay or recommend until it has a lot more testing. It's been very buggy, dangerously so.

Ah, ok, July 13, 2014 he changed it - I don't know why I didn't see it before. Thanks for pointing it out. Cheers!

Is this possible? Or is it too much hard work? Or it's no longer multi-sig because you have one computer generating all the private keys?

How about, in theory? Like, 3DabsAddress instead of 3randomlooking.

Also, can multi-sig addresses be compressed? I found this, and it requires uncompressed public keys: http://coinb.in/multisig/

*edit* then I found this thread, so I'm posting here instead.

Sorry for the late reply, i've been so busy lately!

The project is still alive and well! There is actually going to be an entirely new version released in the next week or so that will support compressed public keys and offer a few other new features! but not vanity addresses.

If anyone would like to beta test for me, please get in touch via email and i'll give you access.

Thanks everyone for your support, if you like this project please donate

-

*Edit* To everyone who has PM'd me asking if they can use the source code, yes you can its totally free to use, edit and redistribute. Enjoy!

I will do more tests appropriate to the specific use case that I have in mind. In general I thing coinb.in is great but perhaps too difficult for today's casual users - those who need click and simple one-click solution and are unable to open a new window or copy/paste. However, I am sure that it's easy to adapt the user the interface to specific use cases, hiding complex features and selecting the needed data (e.g. key and transaction to sign) automatically.

"what is not spent will be used as a transaction fee" - from the popup tip

pic related utterly scares me.

I haven't used the service, so I don't know if such a transaction would go through... But the fact it is even implied that it might is a very very scary thing and will keep me from using what otherwise looks like an excellent piece of software. Default to 100% of the value going to the transaction fee (if I don't put anything in the "amount" box) is crazy and might one day lose somebody all their coins.

A sane option might be giving a large red warning if the tx fee is larger than say 0.1% of the total value. Or not allowing it at all if it's over $1 worth or something.

If a change address is required, the user should be asked for it also with big warnings that it should be a safe, permanent address, not in a virtual machine or livecd etc (where people have lost large amounts in the past). A conservative approach to handling change is to send it right bank to the original address. Not quite as private, but better than losing money. (and still needs warnings to the user that the address/private keys they are sending from must be kept!)

HODLing for the longest time. Skippin fast right around the moon. On a rocketship straight to mars.Up, up and away with my beautiful, my beautiful Bitcoin~

"what is not spent will be used as a transaction fee" - from the popup tip

pic related utterly scares me.

I haven't used the service, so I don't know if such a transaction would go through... But the fact it is even implied that it might is a very very scary thing and will keep me from using what otherwise looks like an excellent piece of software. Default to 100% of the value going to the transaction fee (if I don't put anything in the "amount" box) is crazy and might one day lose somebody all their coins.

A sane option might be giving a large red warning if the tx fee is larger than say 0.1% of the total value. Or not allowing it at all if it's over $1 worth or something.

If a change address is required, the user should be asked for it also with big warnings that it should be a safe, permanent address, not in a virtual machine or livecd etc (where people have lost large amounts in the past). A conservative approach to handling change is to send it right bank to the original address. Not quite as private, but better than losing money. (and still needs warnings to the user that the address/private keys they are sending from must be kept!)

I agree.

I suggest to use recommended fee instead if change amount as fee and as this is advanced software, please allow users to edit transaction fee. You can send change back to origin address like xDan told.

Before I start responding to your points individually, I just want to remind you that coinb.in is aimed at the "advanced" bitcoin user and offers the "tools" required for them to understand how things work. Also the code is also remarkably simple and easy to follow compared to say bitcoinjs.

I haven't used the service, so I don't know if such a transaction would go through... But the fact it is even implied that it might is a very very scary thing and will keep me from using what otherwise looks like an excellent piece of software. Default to 100% of the value going to the transaction fee (if I don't put anything in the "amount" box) is crazy and might one day lose somebody all their coins.

A sane option might be giving a large red warning if the tx fee is larger than say 0.1% of the total value. Or not allowing it at all if it's over $1 worth or something.

The transaction would indeed go through if you signed it. The question is, who am I to prevent someone from choosing their transaction fee, regardless of how high or low it might be. It would be an unfortunate mistake to accidentally set a large fee so I will take into consideration what you've said and perhaps throw up a confirmation notice if the fee is too large. But please keep in mind this is the first time someone has mentioned this and made such a big issue about it.

If a change address is required, the user should be asked for it also with big warnings that it should be a safe, permanent address, not in a virtual machine or livecd etc (where people have lost large amounts in the past). A conservative approach to handling change is to send it right bank to the original address. Not quite as private, but better than losing money. (and still needs warnings to the user that the address/private keys they are sending from must be kept!)

Yes a change address is required, again who am I to send automatically send it back to them. My philosophy is its your money, you can do with it as you like.

If you dont want to use the tools to manually build a transaction, and want the comfort of your funds being returned to you, try the wallet instead https://coinb.in/#wallet you dont get same functionality as building the transaction yourself, and signing it etc, but if the transaction fee is your issue, you can be sure it will return it to your address. Check it out

I suggest to use recommended fee instead if change amount as fee and as this is advanced software, please allow users to edit transaction fee. You can send change back to origin address like xDan told.

The problem is not everyone would be happy with the funds being sent back to their original address, also its possible to populate the "inputs" on a new transaction with funds from multiple addresses. There is a few things to think about, because I don't want to force users to do anything they don't want to. But a confirmation notice sounds ok..

I suggest to use recommended fee instead if change amount as fee and as this is advanced software, please allow users to edit transaction fee. You can send change back to origin address like xDan told.

The problem is not everyone would be happy with the funds being sent back to their original address, also its possible to populate the "inputs" on a new transaction with funds from multiple addresses. There is a few things to think about, because I don't want to force users to do anything they don't want to. But a confirmation notice sounds ok..

Ok. As it is aimed on advanced users, shouldn't we be able to set custom fee? Currently, I can't do it. Please change it.

I suggest to use recommended fee instead if change amount as fee and as this is advanced software, please allow users to edit transaction fee. You can send change back to origin address like xDan told.

The problem is not everyone would be happy with the funds being sent back to their original address, also its possible to populate the "inputs" on a new transaction with funds from multiple addresses. There is a few things to think about, because I don't want to force users to do anything they don't want to. But a confirmation notice sounds ok..

Ok. As it is aimed on advanced users, shouldn't we be able to set custom fee? Currently, I can't do it. Please change it.

The transaction fee can be manipulated by adding another address, this can either be the address you populated the unspent funds from, or an entirely new address if you have privacy concerns.

I suggest to use recommended fee instead if change amount as fee and as this is advanced software, please allow users to edit transaction fee. You can send change back to origin address like xDan told.

The problem is not everyone would be happy with the funds being sent back to their original address, also its possible to populate the "inputs" on a new transaction with funds from multiple addresses. There is a few things to think about, because I don't want to force users to do anything they don't want to. But a confirmation notice sounds ok..

Ok. As it is aimed on advanced users, shouldn't we be able to set custom fee? Currently, I can't do it. Please change it.

The transaction fee can be manipulated by adding another address, this can either be the address you populated the unspent funds from, or an entirely new address if you have privacy concerns.

Am I miss understanding something?

No, you understood correctly and I understood wrongly. Keep up the good work.

Btw, was this newly added? If yes, is there an archive to download older version? Thank you!

>I will take into consideration what you've said and perhaps throw up a confirmation notice if the fee is too large.Great! Warnings and sane defaults are good

>But please keep in mind this is the first time someone has mentioned this and made such a big issue about itMost skilled tech people aren't much concerned or knowledgeable about the experiences of newbies, certainly. And maybe they have great confidence and don't believe they themselves can ever make a mistake when in a rush. But it happens to the best of us.

...

I think lots of fairly inexperienced Bitcoiners have paper wallets, for which this sort of thing is very useful. Previously I've used offlinewallet.appspot.com , which isn't maintained any more I don't think, so your site is a good alternative.

It's great work otherwise. I just hate to see people lose money accidentally. What with Bitcoin Core's private key pool and out of date backups, change addresses that existed only temporarily in LiveCDs, and mistyped transaction fee amounts, people have lost large amounts for entirely stupid and preventable reasons, and reading their stories is always quite heartbreaking

HODLing for the longest time. Skippin fast right around the moon. On a rocketship straight to mars.Up, up and away with my beautiful, my beautiful Bitcoin~

The idea is to make it easier to retrieve your inputs for a transaction and broadcast a transaction via coinb.in or a number of other third parties, as well as making it easier to use bitcoin testnet (and eventually altcoins).

At the time of posting this, I have only added multiple hosts to broadcasts too, and have not yet added any services to retrieve your inputs for a transaction.

Once complete though this should make coinb.in even more resilient and decentralized than most wallets.

The idea is to make it easier to retrieve your inputs for a transaction and broadcast a transaction via coinb.in or a number of other third parties, as well as making it easier to use bitcoin testnet (and eventually altcoins).

At the time of posting this, I have only added multiple hosts to broadcasts too, and have not yet added any services to retrieve your inputs for a transaction.

Once complete though this should make coinb.in even more resilient and decentralized than most wallets.

Feedback and suggestions are welcome.

So, as far as I know, there are no wallets/services that allow for Trezor+multsig (well, there's Greenaddress, but that uses their servers to do stuff).

This awesome project Open Source, Multi Signature and HD Wallet, though I have paid for a hardware cold wallet but when needed I will surely download and try this fantastic project of yours.Thank you for sharing.

Not many people seem to be donating and I need to generate enough to at least pay for the VPS. I don't want to add advertising to the site, although Google ads would probably generate me quite a bit. Does anyone have any suggestions for generating donations? I suppose I could make it optional on the new transaction page to donate, or throw up a message now and again.

Not many people seem to be donating and I need to generate enough to at least pay for the VPS. I don't want to add advertising to the site, although Google ads would probably generate me quite a bit. Does anyone have any suggestions for generating donations? I suppose I could make it optional on the new transaction page to donate, or throw up a message now and again.

Not many people seem to be donating and I need to generate enough to at least pay for the VPS. I don't want to add advertising to the site, although Google ads would probably generate me quite a bit. Does anyone have any suggestions for generating donations? I suppose I could make it optional on the new transaction page to donate, or throw up a message now and again.

Not many people seem to be donating and I need to generate enough to at least pay for the VPS. I don't want to add advertising to the site, although Google ads would probably generate me quite a bit. Does anyone have any suggestions for generating donations? I suppose I could make it optional on the new transaction page to donate, or throw up a message now and again.

What do you all think would be least intrusive?

How much are you paying per month?

You might also host your site on Github for free.

Its about 25£ a month. Its UK hosted, so probably a bit more expensive than usual. I can't run it from github as I need to be running a Bitcoin client, sometimes multiple ones.

Not many people seem to be donating and I need to generate enough to at least pay for the VPS. I don't want to add advertising to the site, although Google ads would probably generate me quite a bit. Does anyone have any suggestions for generating donations? I suppose I could make it optional on the new transaction page to donate, or throw up a message now and again.

What do you all think would be least intrusive?

How much are you paying per month?

You might also host your site on Github for free.

Its about 25£ a month. Its UK hosted, so probably a bit more expensive than usual. I can't run it from github as I need to be running a Bitcoin client, sometimes multiple ones.

Personally, I find that to be useful information! Maybe state on the website what the costs are. I'll be sure to donate a month's usage next time I use it.

Some details that are not clear to me:1. If I am a third-party (i did not participate in the creation of the multisig address or with any of the transactions or the redeem script) and I look at the blockchain and find a multisig address, will I be able to know which Bitcoin addresses were used to create the multisig address?2. If I am a third-party (same conditions as above) and I look at the blockchain, I see a confirmed transaction where a multisig address was used to send BTC to some other address, will I be able to know which of the individual Bitcoin addresses used in the creation of the multisig address actually SIGNED the transaction? i.e., if Addresses #1, #2, and 3# were used to create MultiSigAddress #1 (2 of 3 signatures required). Will I be able to know if for #1 and #3 signed the transaction (and that #2 did not participate)?

Some details that are not clear to me:1. If I am a third-party (i did not participate in the creation of the multisig address or with any of the transactions or the redeem script) and I look at the blockchain and find a multisig address, will I be able to know which Bitcoin addresses were used to create the multisig address?2. If I am a third-party (same conditions as above) and I look at the blockchain, I see a confirmed transaction where a multisig address was used to send BTC to some other address, will I be able to know which of the individual Bitcoin addresses used in the creation of the multisig address actually SIGNED the transaction? i.e., if Addresses #1, #2, and 3# were used to create MultiSigAddress #1 (2 of 3 signatures required). Will I be able to know if for #1 and #3 signed the transaction (and that #2 did not participate)?

Regardless of your involvement in creating a P2SH address, you can find which all addresses are needed to sign transaction if that multisig address has send Bitcoins from it. When sending Bitcoins, the redeemScript is included in the transaction. When you have a redeemScript, you can either break it down and find the public keys manually or you can use https://coinb.in/#verify.

Some details that are not clear to me:1. If I am a third-party (i did not participate in the creation of the multisig address or with any of the transactions or the redeem script) and I look at the blockchain and find a multisig address, will I be able to know which Bitcoin addresses were used to create the multisig address?2. If I am a third-party (same conditions as above) and I look at the blockchain, I see a confirmed transaction where a multisig address was used to send BTC to some other address, will I be able to know which of the individual Bitcoin addresses used in the creation of the multisig address actually SIGNED the transaction? i.e., if Addresses #1, #2, and 3# were used to create MultiSigAddress #1 (2 of 3 signatures required). Will I be able to know if for #1 and #3 signed the transaction (and that #2 did not participate)?

Regardless of your involvement in creating a P2SH address, you can find which all addresses are needed to sign transaction if that multisig address has send Bitcoins from it. When sending Bitcoins, the redeemScript is included in the transaction. When you have a redeemScript, you can either break it down and find the public keys manually or you can use https://coinb.in/#verify.

A few small changes in the recent update, but they might be worth mentioning.

There is now a Mediation/Arbitration Service listed on coinb.in's multisig page. This feature allows users to create multi signature 2-of-3 addresses with our public key and we will help resolve any disputes should they arrive. There is a fixed 1% fee.

Note: If you offer a (reputable) mediation/arbitration/escrow service, you can make a pull request on github to have your pubkey added to the list of mediators.

A warning message will be displayed if the fee on the new transaction page is greater than 0.01 BTC.

Fixed a bug with the retrieval of unspent outputs for litecoin.

Some extra validation on the new transaction page to indicate which field is likely invalid.