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.

Code:

1st priority: block height - ascending
2nd priority: value - ascending

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?

I may be nit-picking, as the chance of an out of bounds k or bad r or s value is so infinitesimally small...

But shouldn't we all be 100% RFC 6979 compliant if possible?

Here's some of the repos I cleaned up.

https://github.com/bitpay/bitcore/pull/884

I added a similar badrs function to python-ecdsa and compared the results.

The 1 badrs (aka forcing it to loop once) gave me a different value. It turns out you missed one of the v = hmac_k(v) steps during the loop.

Adding one extra v = hmac_k(v) in each loop makes it match up with python-ecdsa perfectly (I even tried up to badrs = 30 and it was fine.

https://tools.ietf.org/html/rfc6979#section-3.2

If you follow Step h from after the k = bits2int(T) downward, then back up to the beginning of Step h to loop.

Code:

K = HMAC_K(V || 0x00)
V = HMAC_K(V)
Empty T
V = HMAC_K(V)
T = V    (since we know tlen == qlen)
k = bits2int(T)

As you can see, the original code in Bitcore was missing one V = HMAC_K(V) whereas python-ecdsa includes it in the loop.

Including this commit will make the behavior be 100% rfc 6979 compliant.

https://github.com/blockchain/My-Wallet/pull/115

RFC specifies that if the k value is out of bounds OR if r or s is 0 you must loop through Step h until a proper value is found.

The way bitcore implements this is by including an integer called "badrs" that will force entering the re-hashing loop of Step h. The incrementing of badrs is done in a do while loop around k generation and r and s calculation.

The only way this could be a security issue is if someone had a transaction + privkey pair that just happened to produce an out of bounds k (or in bitcore's case, a bad r or s)... AND they decided to sign that transaction using both bitcore/blockchain.info AND Electrum (uses python-ecdsa) and then for some reason posted those two signed transactions in the public space somehow.

Edit: Just put in PR to bitcoinjs-lib:

https://github.com/bitcoinjs/bitcoinjs-lib/pull/336

Prerequisite: Understanding how DarkWallet currently implements stealth addresses.
See: https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth

Remember: Don't turn this into a thread about yes/no to stealth in general. I would like to keep the discussion on how to make my method better, AND possible merits / demerits of this method compared to how DarkWallet currently handles them.

Here's my proposal in psuedo-Python format. (this is not a script, so don't try to run it :-P)
http://pastebin.com/bcs8XFNG

Caveats:
1. Can't send to stealth from Trezor using this method. (as you need to multiply your private key with the scan_pubkey)
    Unless Trezor allowed for performing ECmultiplication on the device, and Trezor returns the shared secret.

2. When thinking about coinjoin and other aspects where multiple people spending to multiple stealth addresses, if we consider coinjoin, we must check every input of every transaction against our info... which is costly. Doing things to mark inputs as stealth info (maybe changing the sequence value) could be considered... but for 100% stealth and 100% no way to discern stealth from normal... there seems to be no other way than to check every input.

However: that being said... it eliminates the requirement for the OP_RETURN table on Obelisk servers... and it's not much more strenuous than running a full node. (having to scan every input of every transaction etc. when blocks come in) but it will be more strenuous for SPV servers, as upon every block they will have to send every transaction to each user... it will also be hard to do on mobile devices (drain battery)... obviously the wallet file would store the most recently checked block so that it doesn't check from the beginning every time.

Perhaps a mode where the wallet doesn't actively search, but users need to input the txid or something that they receive from the sender might be good for mobile...


I am open to comments. Currently I think that the OP_RETURN usage is a hurdle to making stealth addresses ubiquitous... and I'm sure my method won't get us all the way there.

Just wanted you guys to know I'm thinking about you. :-D

PS. Electrum 2.0 /w Send-to stealth support? https://github.com/spesmilo/electrum/pull/817
      Anyone who can help test this commit, please thank you! :-)

https://github.com/spesmilo/electrum/pull/817

If anyone could pull these commits and test it out for me, I'd appreciate it.

Currently, only DarkWallet can receive stealth payment, so try making a new Main Net DarkWallet and send yourself 0.0001 BTC or so. Remember DarkWallet can only receive stealth payments after they've confirmed.

[(All protected sheets etc. are protected with the password "password")]

Hi All.

As a method of studying VBA's ins and outs, I set out to build a Bitcoin suite that would perform some of the basic operations necessary for Bitcoin usage.

I currently have the following things (very poorly) implemented:

1. SHA256 class module (borrowed from Phil Fresle http://www.frez.co.uk)
2. RIPEMD160 class module (coded myself, used some Functions from SHA256 class)
3. A crypto module with a simple, super-inefficient implementation of SECP256K1 curve of EC math. (Add, Double, Multiply, Inverse Mod, etc.)
4. I have a simple sheet that will generate a "random" new address and show both compressed and uncompressed forms. AND it allows input for a brainwallet.

Goals:

1. Learn more about VBA and coding methodology for it. (for work...)
2. Make the crypto as efficient as possible. (Currently takes anywhere from 1 to 2 minutes (depending on PC specs) to perform one EC multiply with a 256 bit scalar.)
3. Implement BIP38, BIP32, and BIP39. (These will require writing/finding class modules for SHA512, HMAC, Scrypt, etc.)

Note:

- I am doing this with the intent of learning what VBA is possible of, and in the process gain the skills to implement macros etc. at my company to increase efficiency.
- Anyone else who thinks this is a fun little hobby-esque project and would like to help out, I would be more than happy if someone gave me pointers.
- The goal #3 probably won't go anywhere until I can clear #2.


Current Implementation:
https://www.dropbox.com/s/6meu983y0busbng/Bitcoin_Address_gen.xlsm
(All protected sheets etc. are protected with the password "password")

I will put the classes and modules separately up on Github if someone else wants to contribute.

Any pointers, musings at my horrible coding, trolls, etc. are welcome! But I would definitely appreciate any tips to make EC Multiplying faster.

Thank you all in advanced!

Hi all,

In another thread, it seemed that not many people are aware (even though there is a warning message when you export a private key from a seeded address) of the (MPK + privkey_n = Master Private Key (mpk)) quirk.

I'm here to explain it.

First, some clarification.

Your seed is not your Master Private Key. Your seed is "stretched" out 100,000 times by hashing it against itself and subsequent hashes. The final hash that arises from this process is your "Master Private Key" or Extended Private Key. This is the private key to your Master Public Key.

Now that you understand this, here's some basic ECC math:

For a private-public keypair d = private, P = Public, the formula that calculates the public key from the private key is P = dG... where G is the "generator point" on the curve that Bitcoin uses for Elliptic Curve calculations. All keypairs in Bitcoin use the same Generator point G.

This relationship of P = dG is important to understand how the attack takes place.


First let's learn about Electrum's address derivation.

Well, the address derivation formula works something like this:

1. We first create an "s" which is = Hash( n:c:MPK ) where n = the index number of the address (0 = first address, 1 = second address, etc.) and c = Change addresses or not. (1 = change, 0 = regular) and MPK = your master public key.
2. Then we take that hash, use it as a private key against the generator point to get a public key R = sG
3. Then we take the master public key and add it to the sequence public key. This gives us a 3rd public key without needing to know its private key or the master private key, we will call this P_n = d_nG

Notice how nowhere in that process did I use the master private key or the private key to P_n.

Now, how do I spend bitcoins for the address at P_n?

1. I stretch the seed 100,000 times to get the Master private key.
2. Since P_n = MPK + R... we can also write the equation as d_nG = mpkG + sG.... G cancels out to get d_n = mpk + s
3. We add the master private key to the Sequence "s" (and mod by the curve order) to get d_n... with this, we can sign for the address at P_n

......

Ok, now that we understand what's going on, how are we vulnerable?

First, what does the attacker need?

1. Your Master Public Key.
2. Any one of the private keys from an individual address derived from your Master Public(/private) Key.

How do they attack you?

I know 100% that your MPK is correct, I know 100% that the private key I obtained is from that MPK's address. Normally people don't use a lot of addresses on Electrum, so even if we don't know the sequence number, we could try about 100 times and most likely find the right sequence.

Here's what I do:
1. I calculate the Bitcoin address from your private key, public key is X.
2. I attempt to guess, let's say I get it right that your number was Hash( 0:0:MPK ). Because I know your MPK and I guessed the index of your private key, I now have the sequence secret.
3. I created the public key for the sequence secret, and add it to your Master Public Key. If the end result is X, I have correctly found the sequence secret. If not, just keep guessing, its fast.
4. As we said before, private key derivation is d₀ = mpk + s... so we change it around to mpk = s - d₀
5. We know the sequence secret now, and the Bitcoin address private key. we subtract the private key from the sequence secret, modding by the curve order, we get the master private key.
6. Just in case, check if MPK = mpk * G. If it does, now you can solve any sequence address's private key.


So everyone, please treat every single individual private key on your seed's wallet as carefully as you would treat your seed.


BIP32 has the same problem, however, it also has something called "hardened keys." Which are supposed to break the chain (so you can only derive it one way) but at the expense of utility. (You won't be able to derive deeper chains from that child)


That being said. Electrum's offline signing ability and its lightweight client make it my favorite Bitcoin client to date. Just be sure to educate yourself. The same can be said with anything in life, especially Bitcoin related things, but it always helps to learn.


I hope this helps prevent theft. Please take care of your private keys.

Thank you.

The question is self-explanatory. I just want to gauge everyone's opinion on here.

Edit: I just clarified a bit in a post below.

What I mean is that, as Bitcoin is currently being used. The default is transparency.

If I give you an address, even if it's a new one, and I someday use that address in a transaction without a mixer, you can follow the grouped inputs to estimate my bitcoin holdings etc. as bitcoin gets wider uses you can probably with little effort figure out what my spending habits are where I'm spending money etc.

This will probably be fine for Joe Schmoe in middle-class USA or something, but if you are a citizen in a country that "bans bitcoin" with lethal force (who knows, it could happen)... the public will have to either A. just sit there and take it. or B. be a super hacker 1337 programmer who can write their own coinjoin implementation of a stealth address diffie hellman shared secrets while using tor networks and blahblahblah...

So I am not talking about feasibility or any specific changes to the protocol. I am just asking, if you could go back in time and create the perfect Bitcoin network by changing Satoshi's hand at coding, how would you design the protocol in regards to privacy or transparency... I don't want to get into discussion of logistics on how it can be done etc.

Hello all,

I have only recently started coding, and this was thanks to Bitcoin and all of the open source code I have to learn from.
I am currently working together with some professional devs in my country to create a bitcoin exchange that would remove all risk of us potentially running away with or getting stolen our customer's bitcoins.

The questions are as follows: (I apologize if I can't articulate well)

1. What are the logistics of using on-chain transactions only for a bitcoin exchange? I think scaling would be horrible, but if the methodology only involved sending bitcoin in a way that can be verified with no-confirms (psuedo-internal transaction) and is ok to wait the 10-minutes, I am not sure scalability would be an issue. What are the possible technical ramifications for if, let's say, bitstamp's bitcoin transactions were all on-chain? (aka should this be an area we should work on: keeping our volume off-chain)

2. If I wanted to create a 3rd private key unbeknownst to me or the customer and store the private key into a place that would automatically be released to the customer if we disappeared etc. are there any types of software or methodology of implementing such a system? This is one of the problems a lot of our resources are going to go into if we can not find an open source solution that does not involve trust. If there are services that involve trust in some company etc. please link just so I can evaluate as an option.

I am really excited about some of the talks we are having with investors, and if we can get funding we also have secondary services we're looking to piggy back on to our exchange.

I haven't looked at the price in the last three weeks or so, but from the posts I see I guess some people are enjoying the rollercoaster?

Any info or help with these 2 issues would be a big help. I greatly appreciate it in advanced.

Waiting on signed message from 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX. (The address the genesis block sent to)

I don't think that anyone who created such a system would ever NOT back up the first Bitcoin address EVER USED. (ok, so not used, but received-ed?)

Signing a message with this address, verifying that his bitcointalk account was not compromised, and informing us that he is not the Satoshi from the article.


I assume Satoshi is a decent human being, and therefore he would make a move like this to clear the innocent man from the target on his back.




Unless this is a conspiracy to flush Satoshi out of hiding to get him to speak up in order to somehow track him...


And just in case you are doubting whether I, dabura667, am not the REAL Satoshi... here's proof!


Address:
-------------
1DAbuRaxxycu6osPdmah4HaRFDw7zK3hzH
-------------
Message:
-------------
I, dabura667 (account on bitcointalk.org), guarantee I do not own the address 12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX from the genesis block.
-------------
Signature:
-------------
G9eIt1rtj9JBQl+9Byfa3LbLrrENkuBwaI/vglCTSQ+JbVDbVi7g+gV+kJKGeo+7FNlVoNj8HkB0h9C9i5uq/CE=
-------------

https://github.com/spesmilo/electrum/pull/573

I had made an issue request a while back, but after a while I realized that no one really seemed to want this functionality (or at least no one on github)

So I went and started learning python, and tinkering around. Maybe a total of 30-40 hours of messing around with pdb stepping through code to figure out things work, I have finally gotten a working, if slightly primitive and very sloppy, version.

If anyone could look at my function, look at my pull request, look at how I comment, etc. and give me feedback on anything (github manners, best practices for python, ways to improve my function, anything) I would greatly appreciate it. I have had so much fun, I started to program some small game in pygame.

I feel very proud of my accomplishment, but I realize that this is a molehill and not a mountain I have climbed. I would greatly appreciate any feedback.

If for nothing else, this helps me and my set up very nicely.

Thank you in advanced for your feedback and opinions.

dabura :-)