https://blockchain.info/address/1CTnGM9uapUSg8wvdXkpJPG2nbfGcxytPF
Check the Hash 160 part of this address's page?
Look familiar?
Line 5 of your transaction is using the scriptpubkey for 1CTnGM9uapUSg8wvdXkpJPG2nbfGcxytPF for some reason...

(I think maybe you copy pasted something from earlier, or input something wrong into some tool you are using.)

Your transaction SHOULD be the following:

Then you just need to be absolutely certain that the private key you're using to sign is the key for 12ZMT7Qn2rysM3XKxkSBrVfzdXXufoS13t and you should be good to go.

Note: however, your transaction has 0 fees attached... Though, looking at your mess of a transaction history, I won't bother... Why can't all these tests be done on testnet?

I like the multisig option, but the app could use a good re-vamping UI-wise.

Suggestions:

1. Allow for separate "accounts" within the same HDM trios. (This could be handled the same way you can now "add keys" to your HDM Hot.
   - This would allow for someone with 2 devices can separate different wallets for different occasions.
2. Once you have received a transaction to the address in your account, change the address to the 2nd index address. (automated address rotation) Also automatically rotate change addresses.
   - You can add a cog button to the account management screen (Currently: key management screen) to show all the hidden addresses of the account.
3. Allow for an option in both Cold and Hot HDM mode to type in a BIP39 phrase of their own.

Also,

- Allow for spending unconfirmed.
- Allow for setting your own fee as an advanced option. (or at least letting the user lower it down to 10 bits)


Great to see HD and Multisig married like this. UX needs work, but very very nice job!

Signature can happen in any order... it's just that once you have the necessary number of signatures, you must switch around their order to meet the proper ordering requirements.

Awesome, we have a volunteer to create the ultimate Bitcoin user experience!

So, how are you going to attack the issue?

You should probably go through all the most popular wallet options, list their bad points, good points, then lay out how you would make the perfect wallet.

If you make a comprehensive analysis of what needs to be done, and developers see eye to eye with you, then I'm sure someone will volunteer hundreds of hours of their free time to build it for you. (no joke)

But if you sit there and say "oh well, no, I mean... just like, make it better, ok?" or "I think the wallet should have unicorns and microwave popcorn for the user!" then no one will take you seriously.

It's pretty dang easy to get 0 fees to go through on Electrum.

You don't even need to be that good at programming.

1. Install from source.
2. Edit source to allow 0 fees
3. Set fees to 0
4. Send bitcoin with 0 fees.

It's literally just changing 1 line of code by deleting 3 characters.
I'm sure you guys can figure it out.

2 Questions about HDM:

1. "Easy to backup (only need HDM Cold seed)" does this mean the Server key and the Hot key are derived from the cold key? (as if it wasn't, I would assume you'd also need the xpub from the server key and the xprv from the hot key to generate the addresses and sign for 2 of them.)

2. Will the user be able to scan / input their own xprv/BIP39 phrases as their key(s)? (In case I want to generate my own entropy) How would that process work?

https://github.com/bitpay/bitcore/blob/master/lib/transaction/transaction.js#L280
This will let you create a Transaction object from a raw tx 0-9a-fA-F string.

https://github.com/bitpay/bitcore/blob/master/lib/transaction/transaction.js#L43
Then just inspect the Transaction.outputs to look for the information about the transaction.

Then it would start another chain of $0.20 outputs again... or at least that's under the assumptions I am making on what you are trying to do from your explanation.

I don't think I get what you're trying to do.

So this is what you get back from blockr.


Here's the raw transaction it is referring to:

01000000017920fe9ef3a69ed78e2909f62c4eca9eb453ecc17b2703e648ef9dbb4353cfa501000 0006b483045022100cfa77f826a2845bdad66c99aef4e318678bbfb2e829c8b9cff3b611db4e209 b3022071c42415cc39b997f7d48855f3da11d49b7c435e1d09ed2a98d37346c3fd38f3012103db6 362bd31a3c590c38aa7583de5b565ab527ce8b4648245ccf7ffbb0e1f955affffffff027d5d0000 000000001976a914f077c10e90ba49739f28c483e76c49ce9facfa2588acff2a0400000000001976a9147c7f9af7dc42b8b5277039a2cc8eb710b51f17b788ac00000000


"tx" can be found by double sha256 hashing the raw transaction and reversing the byte order (to little endian)
"amount" can be found in the bold area. 1. convert to big endian 2. convert from hex to decimal 3. multiply by 100,000,000
ff2a040000000000 -> 0000000000042aff -> 273151 -> 0.00273151
"n" can be found by counting which output it is order-wise, first output is 0, etc.
"script" can be found directly after the amount in the bold+italic part (Skipping the scriptlen byte)


So what I suggest is just generating a transaction, grabbing the unspent info from the first transaction and using it to generate the second transaction etc. and unleash the chain of transactions, maybe pushing them 10-15 seconds apart (to give each one time to propagate. Also remember you must push them in order, otherwise they will get rejected for referring to a non-existent output.)

No, if you're going to send them instantly anyways, grab the unspent from your change on the way out before you push the raw transaction.

Do you know how to parse a raw transaction?

This is because the wallet you are using (or code, idk) is referring to the old output.

What you tried to do:

What you need to do:
(Where C is the Change from the first transaction you pushed)

You need to code your wallet to refer to a transaction output that isn't confirmed yet... most libraries manage outputs for addresses well only when they are confirmed.

Please note that "Address" = one bitcoin address, but "wallet" in the context of Electrum means a single 12 word seed that generates addresses deterministically.

1. If you mean you want to create multiple wallets (each one having their own 12 word seed) then just click "File" on the toolbar, then click "New/Restore" to bring up a save as... box. Type in the name you want to give your wallet (do NOT overwrite your existing wallets, so choose a different name) Then you will be asked whether you will create a new wallet or restore. This is the same menu you saw when you first made your wallet.

To open the second wallet, click "Open Wallet" from the File menu, and select the second wallet to open it.


2. If you mean that you want to generate as many addresses as you want with the same Electrum seed, then this is not safe to do for the normal user.

If you were a programmer, then it would be safe... but my rule of thumb is "if they aren't smart enough to figure out how to do it themselves, then they don't have the knowledge necessary to properly manage the addresses.

Electrum was made the way it was to make managing your wallet easy. It was not made for managing Bitcoin faucets or businesses.

If you would like to use Electrum with your business, find a programmer who understands Electrum well enough to code something for you.

Switch servers.

1. What do you mean "used in the protocol"? Do you mean what is the name of the containers in the source code?

2. https://en.bitcoin.it/wiki/Difficulty#How_is_difficulty_stored_in_blocks.3F

Once you figure out how to calculate the msb with the remaining 3 bytes at this link, you'll figure it out.

Hi all.

I would like to ask the opinion of the dev community about utxo selection when sending.

I see a lot of wallets use the following method.


I am wondering what the benefits and drawbacks of this method are.

Also, I am wondering if there are alternative utxo selection methods that have different properties.

Using the kind of defacto standard utxo selection:

So if we had 8 BTC in block 4 and 1.5 AND 0.5 BTC utxos in block 6...

For any value (even 0.5 BTC) up to 8 BTC, it will always use the 8 BTC utxo first.
Then up to 8.5 BTC it will use the 8 BTC input and the 0.5 BTC input.
Then up to 10 BTC it will use all three utxos.

So as an alternative example:
Using the above example, up to 0.5 BTC should use the 0.5 BTC input, from > 0.5 to 1.5 should use only the 1.5 BTC input, and Something > 8.5 and up to 9.5 should only use 8 BTC and the 1.5 BTC utxo.


How would my selection method differ in benefits and demerits?

On the tool bar click "File" >> "New/Restore Wallet"

*beats a normally docile dog with a stick repeatedly and laughs at it*

*cries about how they should put down this rabid dog when it retaliates with what is no more than a warning nibble*

Nice conclusion ;-)

making a k that relies on z and d will create a formula that can NEVER be solved for k.

Imagine:

r = R.x = (d+z)G
s = (k^-1)(z + dr) mod N

The weakness of using the same r value with the same private key AND different messages? Impossible. Why?

Because if you change the message z your r will ALWAYS be different. BECAUSE it is used to calculate k, AND it is mixed with an already unknown so no one can predict k. (your private key)

if you just used d as k, the r value would be the same as the x value in your pubkey and you'd be outed, as d = (z)((s - r)^-1) mod N
if you just used z as k, then anyone who saw the message would be able to calculate your key if they picked up on it. (though it might be harder to notice such a vulnerability)

However, by using a combination of both... (please follow RFC6979 and don't just add them together) there is no possible way to solve for k, and as long as the private key remains private, no way for an outside observer to calculate k.

This is why Trezor uses RFC6979 to generate k values. Because there is not enough randomness on such a small device. So it relies on math to guarantee the k is different every time.

Thank you very much. Let me know if you have any other questions about non-standard transactions.