[coinb.in] Open Source, Multi Signature, HD Wallet, SegWit/Bech32 and more!

[btcmsia]

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.

[1715029408]

1715029408

[OutCast3k]

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.

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 will add these instructions to the page very very shortly.

[ktorn]

could you make it to support compressed keys?

Unfortunately, you can't use an address in replace of a pubkey.

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?

[OutCast3k]

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?

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.

Thanks.

[ABISprotocol]

Thanks!

[ADcoin.me]

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

[OutCast3k]

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?

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.

Start from step 4.

Cheers

[OutCast3k]

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

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

[ktorn]

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.

Start from step 4.

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

[OutCast3k]

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.

Start from step 4.

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

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

[ktorn]

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!

[OutCast3k]

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.

[OutCast3k]

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.

[ktorn]

This issue has now been fixed 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!

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?

[OutCast3k]

This issue has now been fixed 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!

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?

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.

[ktorn]

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.

[btcmsia]

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.

[OutCast3k]

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

[ABISprotocol]

OutCast3k:

thank you, you are a good entity

much thanks

very excellent

etc

[ktorn]

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