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

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

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

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

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.

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!

You've not mistakenly signed the transaction twice, but with the same key have you??

I've run 3-4 tests this morning, everything is working fine from my perspective, could you get in touch again via IRC so we can go through it step by step in an attempt to reproduce this bug.

Thanks

Definitely progress, the transaction now validates after signing, but still TX rejected when broadcasting. I've PM'd you the signed tx hex.

Got a fair chunk of the code in place its just finding the time to finish it off.

Great! Well done, keep up the good work! opensource marketplace would be so nice! Go for it, please.

Thanks!

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:

1 ) generated 2 sets of Bitcoin keys (so 2 addresses, 2 public uncompressed keys, and 2 private keys)
2 ) generated a 2-of-2 p2sh address using the public keys from step #1
3 ) sent 0.0022 BTC to that p2sh address

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 #1
7 ) sign transaction hex from step #6 with second private key from step #1
8 ) 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?

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:


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

I will add these instructions to the page very very shortly.

could you make it to support compressed keys?

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

Via bitcoin-qt, click help, then click "Debug window", then choose the console tab, and finally enter the following command:


It will then return some data, including a pubkey for that address.

Please keep in mind that it can only provide pubkeys for addresses in your wallet. Addresses that aren't in your wallet, will still return similar data but without a pub key.

Sorry about the dead link, I keep meaning to write a guide for it, I've been a little busy and not had time yet - I'll do it this evening though to avoid any future confusion.

Hope that helps.

Very interesting.

How do I get my public key? 

The multibit client provides a "Tools ... Export Private Keys" option.
And the qt client has dumprivkey.

But how do I get my PUBLIC keys?


There might be a manual there already, but:

" these can be extracted from the bitcoin client or generated using the form below "

The link is an empty "javascript:;"

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

Very cool! I'll be watching this!

Have you yet run into the problem that I just have?

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

It looks about right, but you might need a few extra tweaks also. I'll look into making a testnet mode for it shortly