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  |
|
|
|
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. |
|
|
|
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. the order that signatures are added no longer matters. |
|
|
|
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. |
|
|
|
Cubes in stock
|
|
|
|
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 |
|
|
|
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. |
|
|
|
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 |
|
|
|
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. |
|
|
|
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: 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. |
|
|
|
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:;" Via bitcoin-qt, click help, then click "Debug window", then choose the console tab, and finally enter the following command: verifyaddress <youraddress>
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. |
|
|
|
Can I order 2.
Will send payment if you can confirm they'll be available. Thanks.
Hey waves, Can confirm that 2+ are available, send the payment and let me know your details. Edit: there is more if anyone else wants them |
|
|
|
I'd like fast shipping so will wait 'till you actually have them in stock There is a small shipment being sent tomorrow. |
|
|
|
Any cubes in stock now?
Sorry seemed to have missed this. No - I don't have any in stock this second, but would expect them in at the end of this week coming, if you place your order today. |
|
|
|
Coin.bin is a fantastic set of tools.
I am not familiar with javacript or crypto to start changing things but how do I set this to use testnet addresses,
I would guess it has to do with x.unshift being set to 0x11
Is that correct?
It looks about right, but you might need a few extra tweaks also. I'll look into making a testnet mode for it shortly |
|
|
|
Got my Cube rewired last week - it's now running on the OCZ 600W PSU using both 12V rails (using a 8-pin ATX to 6-pin PCI-E). It's got a 6 day uptime at just a shade over 38GH. Working perfectly.
Good to hear! |
|
|
|
Price dropped to 0.86 btc!See the original post for more information
|
|
|
|
The CX750 does seem to keep getting mentioned as failing to work properly with the cube, I'm not sure why though, you'd think it would work fine...
I think it's the most easily-available high-spec PSU in the UK which may be why there are so many reports. You don't hear the negative ones. As I said, I've tried swapping the PSUs over between my cubes, but it's still the same cube that has the problems. Sill, it's called overclocking -- it's not guaranteed to work in all cases I guess. Anyway, since the 4 dud chips came back online, the hashrate is not far off what it was like in high clock mode when they were broken. ALSO: I may be stupid but I just worked out that you can slot the cases together! That is so awesome. I want to buy another 50 now and build bizarre lego-like mining structures out of them! (If only I could afford it... ) I love that you can easily stack them together also |
|
|
|
There's something with these Cubes and the CX750. Lots of folks have them working perfectly with this PSU, and others like me can't get the Cube to work for shit with the CX750. It's frustrating.
My Cube ran perfectly at High for a week on the OCZ 600W PSU, but it locks up on High. Works OK on Low, though. I need to rewire a bit to get the Cube running off both 12V rails on the OCZ.
Can't say I'm very pleased with the Cube - it's a fussy fecker. Not like the old Blades which have been rock solid.
The CX750 does seem to keep getting mentioned as failing to work properly with the cube, I'm not sure why though, you'd think it would work fine... |
|
|
|
I'll do escrow as well, I can even handle mutli signature address transactions via https://coinb.in/multisig/ my pubkey is listed already. enjoy! |
|
|
|
|
Show Posts
