NBitcoin : Stealth Address, DarkWallet compliant

[Nicolas Dorier]

I finished implementing StealthAddress in NBitcoin.

Key scan = new Key();
Key spend = new Key();
BitcoinStealthAddress address = spend.PukKey.CreateStealthAddress(scan.PubKey,Network.Main);
//The receiver publish the address on a forum or whatever....
//Sender then create payment
Key ephem = new Key(); //Optional, CreatePayment create one if not specified
StealthPayment payment = address.CreatePayment(ephem);
//In you want to include the payment to a transaction
Transaction tx = new Transaction();
payment.AddToTransaction(tx);
//Receiver receive the payment via the block chain with (address.Bitfield.GetPayments(tx))
Key key = spend.Uncover(scan,payment.Metadata.EphemKey);
//Or, if you just want the public key (equals to key.PubKey)
PubKey pubkey = spend.PubKey.UncoverReceiver(scan, payment.Metadata.EphemKey);

You can replay these steps in parallel with sx to verify the implementation.
There is a deterministic unit test for that : https://github.com/NicolasDorier/NBitcoin/blob/master/NBitcoin.Tests/StealthAddressTests.cs#L179

Enjoy,

Github : https://github.com/NicolasDorier/NBitcoin
Nuget : Install-Package NBitcoin

[1713519510]

1713519510

[1713519510]

1713519510

[Nicolas Dorier]

Just wrote an article on it : http://www.codeproject.com/Articles/775226/NBitcoin-Cryptography-Part

[piotr_n]

cool.  let's test it. can you send me some test coins and give the address where to send them back?

Code:

waPV5rHToBq3NoR7y5J9UdE7aUbuqJybNpE88Dve7WgWhEfvMrcuaSvF6tSQ3Fbe8dErL6ks8byJPcp3QCK2HHviGCSjg42VgMAPJb

btw, do you support prefix length other than 0?

[Nicolas Dorier]

yes it supports prefix.
TestNet is unavailable at my place, the dns seed nodes seems down ?!

Try to send this transaction to the TestNet, it should works if I did not made a mistake on the sig part.

0100000001695f9c647d044563d2fff95fba1bd5cf1d35d75611ddbd8b1da80a4dff7aa8a000000 0006a47304402200e583af51ef57334f0c830e85bb809c7a23f4fbdd6d5557dbec1a2216c578bee 02203c54f1c2205ab0c21a511cbd1a2006bc339693d329cee7fb881aae44c6323dee012102ccea4 5d5eb89ea63dee2dd567beef6dd38b2edb3ebf3d85ef45c537ff1af1bbcffffffff020000000000 000000286a26060000000002704f9c99117ba90b162859e1f5f21c7e1805bc6c0594cc4e5a3dadf adf2c17bbc056fe03000000001976a9148f1516c7c20207a22940133f878351ac3681b56b88ac00 000000

All of these are down for me

vFixedSeeds.Add(new NetworkAddress()
{
   Endpoint = new IPEndPoint(IPAddress.Parse("109.123.116.245").MapToIPv6(), 18333)
});
vSeeds.Clear();
vSeeds.Add(new DNSSeedData("bitcoin.petertodd.org", "testnet-seed.bitcoin.petertodd.org"));
vSeeds.Add(new DNSSeedData("bluematt.me", "testnet-seed.bluematt.me"));
vSeeds.Add(new DNSSeedData("Blockexplorer.com", "blockexplorer.com"));

[piotr_n]

Try to send this transaction to the TestNet, it should works if I did not made a mistake on the sig part.

It says the signature of your tx is invalid.

Here is the list of 90 testnet peers from my db:

Code:

    95.85.39.28   18333
   46.4.106.234   18333
  94.102.53.181   18333
  5.135.159.139   18333
188.226.138.211   18333
188.165.238.173   18333
   46.28.204.15   18333
109.201.135.216   18333
      5.9.2.145   18333
   46.182.106.2   18333
109.201.154.201   18333
188.165.246.217   18333
  108.62.62.235   18333
  184.107.180.2   18333
  198.50.215.81   18333
 188.226.176.87   18333
   75.6.237.138   18333
   93.93.135.12   18333
  54.208.21.132   18333
107.170.107.245   18333
188.230.215.236   18333
   46.28.207.68   18333
 178.63.106.253   18333
  74.207.249.18   18333
    54.209.7.19   18333
254.112.255.114   18333
  162.216.6.146   18333
  88.198.20.152   18333
  54.72.131.178   18333
     54.84.19.8   18333
162.243.123.220   18333
  87.230.26.205   18333
 178.63.106.250   18333
    78.46.97.16   18333
162.243.141.246   18333
   221.249.5.50   18333
   69.85.93.216   18333
     5.9.119.49   18333
192.161.182.207   18333
   37.59.58.130   18333
  107.170.35.88   18333
 144.76.175.228   18333
 15.125.110.219   18333
    178.63.14.7   18333
   95.85.15.189   18333
117.241.136.198   18333
 192.241.204.12   18333
 188.122.92.134   18333
 148.251.11.118   18333
  54.206.106.94   18333
 134.60.102.116   18333
 54.215.172.225   18333
   85.153.13.35   18333
  119.81.66.229   18333
   176.9.24.110   18333
 54.252.141.122   18333
199.231.187.226   18333
162.242.155.221   18333
  23.253.92.253   18333
  116.24.15.116   18333
 91.121.140.111   18333
    46.4.120.71   18333
   83.80.206.63   18333
 94.190.126.105   18333
 107.170.99.148   18333
148.251.236.175   18333
 198.50.156.105   18333
 137.117.217.85   18333
 137.135.219.45   18333
  212.108.45.54   18333
 87.195.172.209   18333
 115.118.49.234   18333
   194.18.61.26   18333
  41.164.148.82   18333
  93.172.61.180   18333
   85.17.26.225   18333
212.219.220.118   18333
 137.190.79.169   18333
   63.87.77.156   18333
 146.185.169.56   18333
  86.27.247.219   18333
162.242.154.199   18333
151.236.216.148   18333
   71.94.45.245   18333
  176.111.59.60   18333
  80.86.232.251   18333
     31.7.56.82   18333
107.170.113.154   18333
   178.17.8.128   18333
105.224.102.106   18333

[Nicolas Dorier]

Thanks for the seed, I will send the transaction.
I signed before adding the TxOut -_-

0100000001695f9c647d044563d2fff95fba1bd5cf1d35d75611ddbd8b1da80a4dff7aa8a000000 0006b483045022100ee96d1dbe442c1b0997526e3e66d188a9014bd0b9f39262498b2c8484520d3 49022070c0fb15145a453cf2151f7ee60d675fbf047afba1d0058ac704589fe07fdcc6012102cce a45d5eb89ea63dee2dd567beef6dd38b2edb3ebf3d85ef45c537ff1af1bbcffffffff0200000000 00000000286a26060000000003de307f3903d0cf32509c2964ea8fca2be9640dd14bc1233856aa8 0967e4e0debc056fe03000000001976a9140d31b807b4ce74cd9e1f7d0c888abbed8e30584788ac 00000000

[Nicolas Dorier]

sent, send back to msj42CCGruhRsFrGATiUuh25dtxYtnpbTx (tpfaucet)

[piotr_n]

ok - as soon as it arrives.
but it hasn't yet.

[Nicolas Dorier]

Normally it has
http://blockexplorer.com/testnet/tx/1e0bb55e0c460e403a41e3f9d578209e0c518bd2ea97121cde5db0d6443e9219#i36098884

[piotr_n]

Normally it has
http://blockexplorer.com/testnet/tx/1e0bb55e0c460e403a41e3f9d578209e0c518bd2ea97121cde5db0d6443e9219#i36098884

I don't think its correct.

With the ephemkey key of:

Code:

024272e119d08015609528fb6e9841d9a432fe0d013d60d4f332104808088e7084

And my stealth address:

Code:

waPV5rHToBq3NoR7y5J9UdE7aUbuqJybNpE88Dve7WgWhEfvMrcuaSvF6tSQ3Fbe8dErL6ks8byJPcp3QCK2HHviGCSjg42VgMAPJb
Version: 0x2b = 43
Options: 0x00 = 0
scanKey: 026aa1512f0aa20a28ac2ed3fb660aea5cbee45ea6994e4ec790cad001cd5f2643
spndKey: 02a60d70cfba37177d8239d018185d864b2bdd0caf5e175fd4454cc006fd2d75ac
sigNeed: 1
Prefix : /0

... I would be expecting the next output going to mr7F6ALhcQhZay1ufXipnESkLEB5xXuV9S
Your output goes to mk2BkyJyE8Fgzs9zpCodpG14TJQHpvUJ9s

[Nicolas Dorier]

Can I get your scan private key ? So I can verity with sx and also my framework what address it gives.

[piotr_n]

Can I get your scan private key ? So I can verity with sx and also my framework what address it gives.

Not that one, but I can generate a new address for you.

Code:

waPYjXyrTrvXjZHmMGdqs9YTegpRDpx97H5G3xqLehkgyrrZKsxGCmnwKexpZjXTCskUWwYywdUvrZK7L2vejeVZSYHVns61gm8VfU
Version: 0x2b = 43
Options: 0x00 = 0
scanKey: 0361e5c0bff39f18621693da42cd343d60e3e14b4e9eb46b220eb310a484fcebab
spndKey: 02a60d70cfba37177d8239d018185d864b2bdd0caf5e175fd4454cc006fd2d75ac
sigNeed: 1
Prefix : /0

its private scankey is:

Code:

0361e5c0bff39f18621693da42cd343d60e3e14b4e9eb46b220eb310a484fcebab

[Nicolas Dorier]

its private scankey is:

Code:

0361e5c0bff39f18621693da42cd343d60e3e14b4e9eb46b220eb310a484fcebab

It is not a private key, you copied the pubkey.

I made a new transfer on your old stealth:

Stealth Addr : waPV5rHToBq3NoR7y5J9UdE7aUbuqJybNpE88Dve7WgWhEfvMrcuaSvF6tSQ3Fbe8dErL6ks8byJPcp 3QCK2HHviGCSjg42VgMAPJb

Ephem : 9daed68ad37754305e82740a6252cf80765c36d29a55158b1a19ed29914f0cb1
Scan : 026aa1512f0aa20a28ac2ed3fb660aea5cbee45ea6994e4ec790cad001cd5f2643
Spend : 02a60d70cfba37177d8239d018185d864b2bdd0caf5e175fd4454cc006fd2d75ac

PubKey Generated : 03b4e5d3cf889840c75f0dd02ebda946151bf37e56cb888c6002c2ae5288e56de7
ID Generated : 119787de5355172ff7934303c06967697699adb2
Addr : mh7yJrZN6LwCfHymnkxUYJfJxMBQN2HX7R

TxId : 266703ce4092b03c4e2585af877eeab6ac6b77d0bf40bf05879e53bedc6e1fbe

I cross checked with tx, my PubKey Generated seems fine.

[piotr_n]

sorry

Code:

cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a

[piotr_n]

its private scankey is:

Code:

0361e5c0bff39f18621693da42cd343d60e3e14b4e9eb46b220eb310a484fcebab

It is not a private key, you copied the pubkey.

I made a new transfer on your old stealth:

Stealth Addr : waPV5rHToBq3NoR7y5J9UdE7aUbuqJybNpE88Dve7WgWhEfvMrcuaSvF6tSQ3Fbe8dErL6ks8byJPcp 3QCK2HHviGCSjg42VgMAPJb

Ephem : 9daed68ad37754305e82740a6252cf80765c36d29a55158b1a19ed29914f0cb1
Scan : 026aa1512f0aa20a28ac2ed3fb660aea5cbee45ea6994e4ec790cad001cd5f2643
Spend : 02a60d70cfba37177d8239d018185d864b2bdd0caf5e175fd4454cc006fd2d75ac

PubKey Generated : 03b4e5d3cf889840c75f0dd02ebda946151bf37e56cb888c6002c2ae5288e56de7
ID Generated : 119787de5355172ff7934303c06967697699adb2
Addr : mh7yJrZN6LwCfHymnkxUYJfJxMBQN2HX7R

With 03b4e5d3cf889840c75f0dd02ebda946151bf37e56cb888c6002c2ae5288e56de7 I'd expect address mvXf4sF4C1w5KgQyasbEWxqVyqbLNtVdnY

[Nicolas Dorier]

With 03b4e5d3cf889840c75f0dd02ebda946151bf37e56cb888c6002c2ae5288e56de7 I'd expect address mvXf4sF4C1w5KgQyasbEWxqVyqbLNtVdnY

So you agree on the generated pubkey ?
You algorithm to transform a pubkey in address does not seems right. (Hash160)
I cross checked mine with brainwallet.
Mine give 119787de5355172ff7934303c06967697699adb2

[Nicolas Dorier]

The transaction I sent is
http://blockexplorer.com/testnet/tx/e83fcbedca05f5b792cb554f7d58d77c40f0a90e91d0d63f7ddfd0fa12790136

[piotr_n]

The transaction I sent is
http://blockexplorer.com/testnet/tx/e83fcbedca05f5b792cb554f7d58d77c40f0a90e91d0d63f7ddfd0fa12790136

Yeah, this one is correct!

I'm sending it back in tx c85b654a97f0ed150ff76b6c2ef50b9aa4a1911d7186d815be1c8c02dfcb3a81

[piotr_n]

With 03b4e5d3cf889840c75f0dd02ebda946151bf37e56cb888c6002c2ae5288e56de7 I'd expect address mvXf4sF4C1w5KgQyasbEWxqVyqbLNtVdnY

So you agree on the generated pubkey ?
You algorithm to transform a pubkey in address does not seems right. (Hash160)
I cross checked mine with brainwallet.
Mine give 119787de5355172ff7934303c06967697699adb2

Oh, I had though the "public key" was the one you put after OP_RETURN.

Never mind, though.

[Nicolas Dorier]

With 03b4e5d3cf889840c75f0dd02ebda946151bf37e56cb888c6002c2ae5288e56de7 I'd expect address mvXf4sF4C1w5KgQyasbEWxqVyqbLNtVdnY

So you agree on the generated pubkey ?
You algorithm to transform a pubkey in address does not seems right. (Hash160)
I cross checked mine with brainwallet.
Mine give 119787de5355172ff7934303c06967697699adb2

Oh, I had though the "public key" was the one you put after OP_RETURN.

Never mind, though.

Have you done the same error on the previous transaction we made ?
Maybe something does not work right and I need further testing.

[piotr_n]

Have you done the same error on the previous transaction we made ?
Maybe something does not work right and I need further testing.

No, the previous two transaction were just broken, as far as I can check it.

The third one is fine, though - I received it with no problems and no modifications in my software.

[Nicolas Dorier]

Have you done the same error on the previous transaction we made ?
Maybe something does not work right and I need further testing.

No, the previous two transaction were just broken, as far as I can check it.

The third one is fine, though - I received it with no problems and no modifications in my software.

The first one broken.
The second one, I juste did double spent because I sent the third one just after on the same out.

The third one worked. I will make more unit tests.

[Nicolas Dorier]

piotr, I improved my tests and don't find any bug on it.
I don't find the reason why the first transaction would fail.

I will generate a bunch of transaction to your stealth address later today, and we'll see if they all get through.

[dabura667]

piotr, I improved my tests and don't find any bug on it.
I don't find the reason why the first transaction would fail.

I will generate a bunch of transaction to your stealth address later today, and we'll see if they all get through.

maybe piotr you are missing a modulo somewhere in your recovery code. Usually when something in bitcoin works some of the time, I find it's because you didn't mod p somewhere.

[piotr_n]

No I don't think there is anything wrong in my implementation.
Besides non-zero length prefixes, I have tested it quite much.

I can exchange coins via stealth addresses between DarkWallet and my s/w, including several sends in a single tx, and they never got missed.
So I guess it means that my implementation works?

I think it is more likely that Nicolas did something wrong during the first send.
We can try few more times though, if he wants, just to be sure.
I'm always open for more testing.


BTW, @dabura667, are you working on supporting non-zero length prefixes?
I'd like to test it against a different wallet as well.

[dabura667]

No I don't think there is anything wrong in my implementation.
Besides non-zero length prefixes, I have tested it quite much.

I can exchange coins via stealth addresses between DarkWallet and my s/w, including several sends in a single tx, and they never got missed.
So I guess it means that my implementation works?

I think it is more likely that Nicolas did something wrong during the first send.
We can try few more times though, if he wants, just to be sure.
I'm always open for more testing.


BTW, @dabura667, are you working on supporting non-zero length prefixes?
I'd like to test it against a different wallet as well.

I've only got sending working for Electrum. But yes, I have non-zero prefixes working for sending bitcoins.

Unfortunately, Electrum does not have testnet functionality, so I had to sacrifice 40 cents while experimenting.

Edit: Here's how I got it done in Python.

Code:

def check_prefix(pre_num, prefix, p_hash): # Check the first 'pre_num' bits of both 'prefix' and 'p_hash' and see if they match
    assert len(prefix) * 8 >= pre_num, "prefix length too large"
    byte_pos = 0
    while pre_num > 8: # This compares the first complete bytes as bytes if the pre_num is higher than 8 bits
        if prefix[byte_pos] != p_hash[byte_pos]:
            return False
        pre_num = pre_num - 8
        byte_pos = byte_pos + 1
    mask_prefix = (((1 << (8 - pre_num)) - 1) ^ 0xff) & int(prefix[byte_pos].encode('hex'), 16)
    mask_hash = (((1 << (8 - pre_num)) - 1) ^ 0xff) & int(p_hash[byte_pos].encode('hex'), 16)
    if mask_prefix == mask_hash: # In order to check only the first 'prebits' bits of the byte, we mask both bytes to change all bits past 'prebits' length to 0
        return True
    else:
        return False

[piotr_n]

Unfortunately, Electrum does not have testnet functionality, so I had to sacrifice 40 cents while experimenting.

That should motivate you to add testnet support there, at some point

[dabura667]

Unfortunately, Electrum does not have testnet functionality, so I had to sacrifice 40 cents while experimenting.

That should motivate you to add testnet support there, at some point

That would involve messing with the servers... and I'm not near good enough to add testnet support to the Electrum server repo...

heck, I'm not even good enough to do anything... but I do the best I can. :-)

[piotr_n]

Unfortunately, Electrum does not have testnet functionality, so I had to sacrifice 40 cents while experimenting.

That should motivate you to add testnet support there, at some point

That would involve messing with the servers... and I'm not near good enough to add testnet support to the Electrum server repo...

heck, I'm not even good enough to do anything... but I do the best I can. :-)

oh, don't be so modest.

you are certainly good enough to be a pioneer of implementing the stealth payments

[Nicolas Dorier]

piotr_n,
I am going to send 13 transactions to waPYjXyrTrvXjZHmMGdqs9YTegpRDpx97H5G3xqLehkgyrrZKsxGCmnwKexpZjXTCskUWwYywdUvrZK 7L2vejeVZSYHVns61gm8VfU
Do you confirm you have the spend priv key and scan priv key ?
(Scan = cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a)

[piotr_n]

piotr_n,
I am going to send 13 transactions to waPYjXyrTrvXjZHmMGdqs9YTegpRDpx97H5G3xqLehkgyrrZKsxGCmnwKexpZjXTCskUWwYywdUvrZK 7L2vejeVZSYHVns61gm8VfU
Do you confirm you have the spend priv key and scan priv key ?
(Scan = cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a)

yes - go ahead, send.

[Nicolas Dorier]

ok all sent, you should get in a block in one hour or more. I did not included fees.
I have all my ephem keys

[piotr_n]

ok.
in case if they got mined, let me know.

[Nicolas Dorier]

already mined oO
And already 3 confirmation... wow what's going on on testnet.

[piotr_n]

I received 7 of them

Code:

21	245388	2014/05/26 17:28	21af862200c988833069cd2f03c2d71204b17ac927a134b918289ad91d6f0702	1	0.04615384	@mmFbAfaoku8yiFm29FMzaWs1KjWmR97Gp1
22	245388	2014/05/26 17:28	26edb0e8fe514d687a747643c909da55cd528fe6707727cfc42cf93eb29830aa	1	0.04615384	@mhvGm1Jn1A34zeRpde1DyjN2bqyBdybQP5
23	245388	2014/05/26 17:28	3f65e6bb638e9cbb03a6faa5f6ecda63b68ce7a170415e3fd7043117b4bf315f	1	0.04615384	@muKQnGmRv5LRw74nHUNYjrP5nexU6NoKKk
24	245388	2014/05/26 17:28	405842102fd3ca84784be5ea4401185a0063f0335090ebd7350430e41bac5128	1	0.04615384	@mp7JcYzerKnFjf8sVPesr8ing7XEwpvWEK
25	245388	2014/05/26 17:28	5f951ff1f7b33d315b7c8e6b650a0ed4803f4d4b9980b16dc0ab28be3d62f6f0	1	0.04615384	@n4grftiTd4VuFAbBwTNcr62RBvyQ3UKyQn
26	245388	2014/05/26 17:28	a655de23abb19fb8c006acc6687c5c810390d4dc58fc658040a1cd19be507b26	1	0.04615384	@mtJoTeZ7MdS2mh1anzAGD9PoEXiucm8ixq
27	245388	2014/05/26 17:28	cb51a3ec324996633613f9ef2aff0971c1430b9460fd75a6ebfff343f1e31870	1	0.04615384	@mngp9i8D9nYv6y4EqPVeZyNa1iajNVE2mj

[Nicolas Dorier]

There is something waky here... (7 of 13 worked)
Can you check what is going on with txid 7efb90526034f0eac6b4f897ea0dcf617b03b29e8b0b4f1660b1fb76740b45f1

http://blockexplorer.com/testnet/tx/7efb90526034f0eac6b4f897ea0dcf617b03b29e8b0b4f1660b1fb76740b45f1

[piotr_n]

Can you check what is going on with txid 7efb90526034f0eac6b4f897ea0dcf617b03b29e8b0b4f1660b1fb76740b45f1

the metadata:

Code:

0600000000:02d3a7c713f0fb9eadaf23d121f5f66a11f4ca780a353ecb1c88ae48646529e1d6

...multiplied with the secret scan key:

Code:

cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a

... comes down to the secret C of:

Code:

ba05b377c50e08b4ad293d58f6e1c494c2e55c829a12c7a289ae015d307193f7

.. and this tells me to expect the coins at address mhBmC8iBR422X5mUYZ2NqT4qin8rGrmMgj (key: 03f6ceafe6669e8c8d0439bbbd4c644779b6ab98b077d61e9d26492ee4d026e217)
your coins went to: mh1A4K7kK5wr7WxCNaHuzhC4LDU8TseBnU

would you like me to expand all the steps, how it goes to it?

[Nicolas Dorier]

Them EphemKey was 23eef32c39ccfd1267f0cd45841dc5bf8deae0184dad16993949d1707c4fb9b6
I'm checking the result against sx, one moment.

[piotr_n]

I think I know what is your problem.

The sha256 hashing that you do at the EphemKey
Before hashing it always has 03 byte in front, despite whether the calculated key had 02 or 03.

[piotr_n]

dont ask me why it is always 03 - it is also strange for me.

but now at least I know how to recover the coins we lost before.
where do you want them?

[Nicolas Dorier]

Just checked

Code:

Usage: sx stealth-uncover EPHEM_PUBKEY SCAN_SECRET SPEND_PUBKEY
NICO@aois-linux2:~$ sx stealth-uncover 02d3a7c713f0fb9eadaf23d121f5f66a11f4ca780a353ecb1c88ae48646529e1d6 cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a  02a60d70cfba37177d8239d018185d864b2bdd0caf5e175fd4454cc006fd2d75ac
02bbc9fccbe03de928fc66fcd176fbe69d3641677970c6f8d558aa72f72e35e0cb

Which is the address where I sent.

[Nicolas Dorier]

dont ask me why it is always 03 - it is also strange for me.

but now at least I know how to recover the coins we lost before.
where do you want them?

You can send back to me.
However your result is not consistent with SX why is it the case ? Which one to trust ?

[piotr_n]

What is your address?

It seems like the implantation in sx is different from the one in DW.
DW always overwrites 02 with 03 before hashing it.
sx - doesnt seem so; takes either 02 or 03, depending how it came out.
Now we need to figure how it should be.

[piotr_n]

I think your/sx implementation makes more sense, but if I make it like this I won't be DW compatible anymore.

Look at line 42: https://github.com/darkwallet/darkwallet/blob/develop/js/util/stealth.js
... and here, line 99: https://github.com/libbitcoin/libwallet/blob/master/src/stealth.cpp

These two functions are compatible only in 50% of the cases.

[Nicolas Dorier]

need to ask to genjix on irc, i'll contact him.

mwdJkHRNJi1fEwHBx6ikWFFuo2rLBdri2h

[piotr_n]

ok. let me know what you found.

sent you back the coins.

[Nicolas Dorier]

he is afk for now.
So if I understand, the difference lies when I calculate the shared secret after the EC multiply.

My code and SX :

Code:

var pBytes = new PubKey(p.GetEncoded()).Compress().ToBytes();
var hash = Hashes.SHA256(pBytes);

DW :

Code:

var pBytes = new PubKey(p.GetEncoded()).Compress().ToBytes();
pBytes[0] = 0x03;
var hash = Hashes.SHA256(pBytes);

It about :
c = H(eQ) = H(dP) at https://wiki.unsystem.net/index.php/DarkWallet/Stealth#Dual-key_stealth

[piotr_n]

yeah I also asked it at #darkwallet, but ATM there isn't anyone around to answer

yes - except that the value is 0x03, not 0x02:

Code:

var pBytes = new PubKey(p.GetEncoded()).Compress().ToBytes();
pBytes[0] = 0x03;
var hash = Hashes.SHA256(pBytes);

I'm happy to change it in my code, but first let's figure out which approach is the desired one

[Nicolas Dorier]

I fixed my response, yes this is problematic since I don't think it is good to break existing clients and scanners.
Maybe the scanner will need to handle both case

[piotr_n]

I fixed my response, yes this is problematic since I don't think it is good to break existing clients and scanners.
Maybe the scanner will need to handle both case

nobody really uses stealth addresses yet - I don't mind changing my scanner.
it's better to do it now than to wait longer or (even worse) to check for both the values.
there are obviously two different approaches which are compatible only in 50% of cases.

I wonder which of the two is in Electrum.

[piotr_n]

it seems that this weirdness comes from electrum implementation.
see here, line 619: https://github.com/dabura667/electrum/blob/StealthAddressSend/lib/bitcoin.py

@dabura667, any comments?

[Nicolas Dorier]

From : https://github.com/darkwallet/darkwallet/blob/develop/js/util/stealth.js#L42
Is seems the JS implementation is not quite right.

A compressed pub key in the X coordinate of ECPoint, with 02 or 03 indicating if Y the odd or even.
From this two information, you can recalculate the Y which is lost during compression.

The JS implementation assume that Y is always odd... a simple modulo test on Y just before the concat would solve the problem.

[piotr_n]

agreed

but I think this implementation is based on the one from electrum, where it seems even more clear that someone just forgot to check the Y's parity, before prefixing X with the proper byte:
https://github.com/dabura667/electrum/blob/StealthAddressSend/lib/bitcoin.py#L619

[Nicolas Dorier]

sent pull request to https://github.com/darkwallet/darkwallet/pull/131, I can't run it so I hope I got it from the first time.

[piotr_n]

it is not my code, but I believe Y has a method isEven() that works faster than mod(2)

Code:

var S1 = [ point.getY().isEven() ? 2 : 3 ].concat(point.getX().toBigInteger().toByteArrayUnsigned());

EDIT:
actually, I believe the proper way is to just use the function that is already there for it:

Code:

var S1 = point.getEncoded(true)

[piotr_n]

sent pull request to https://github.com/darkwallet/darkwallet/pull/131, I can't run it so I hope I got it from the first time.

and why you cannot run it? don't you have chrome?

[Nicolas Dorier]

I hate javascript, I'll let the creator of the lib take the relay for the pull
I sent an issue for the electrum python version of the bug.

sent pull request to https://github.com/darkwallet/darkwallet/pull/131, I can't run it so I hope I got it from the first time.

and why you cannot run it? don't you have chrome?

I'm just lazy to setup a page that include these scripts, and creating a piece of code that will pass where the bug is.
I hate javascript so much.

[piotr_n]

I'm just lazy to setup a page that include these scripts, and creating a piece of code that will pass where the bug is.
I hate javascript so much.

You don't need to setup any page - its a fully functional extension for chrome.

Just checkout the repo from github, go to Chrome's "Extensions" page, enable "Developer mode" and "Load unpacked extension..." pointing it to the darkwallet folder (the one with manifest.json)

It will load the extension and then you can already use DW.
For a start better stick to testnet - it will ask you when creating a new wallet.

[dabura667]

it seems that this weirdness comes from electrum implementation.
see here, line 619: https://github.com/dabura667/electrum/blob/StealthAddressSend/lib/bitcoin.py

@dabura667, any comments?

I was aware that sticking an 0x03 on it no matter what was incorrect, but that was the only way for me to get it to work with DW.
I was meaning to do a PR for a while on DW for it, but by the time I got around to it, I couldn't find it for the life of me.
Then I forgot about it.

I should have added a comment there including my big "" that I had when I saw this in DW.

[piotr_n]

so DW was first, and you just copied it.
then I copied it...

the question is: what now?
are you going to change it?
I think we should.

[dabura667]

so DW was first, and you just copied it.
then I copied it...

the question is: what now?
are you going to change it?
I think we should.

Fixed.

But now I won't be able to recover funds with DW half of the time :-(

[piotr_n]

yeah I know.
do you have some better comm channel with DW guys?

I've been trying to let them know and ask whether they were going to fix it as well, but they don't seem to be reachable.

[Nicolas Dorier]

habitually genjix respond, tried to spam him again today, but he 404 me.

[caedes]

hey,

We agree the dw implementation is at fault, I'm going to apply the fix and think about some way so we can redeem old dw stealth funds too so I can take a bit to apply the pull request but will do it asap.

cheers and congrats on finding out the error!.

[piotr_n]

good. thx.

[genjix]

sorry Nicolas, was outside.
I'm lurking and responding when back.

btw is SX doing it correctly or not?

[Nicolas Dorier]

SX is correct, the DW implementation in javascript is not. I'm a little confused about who develops what.
Do you manage the JS implementation ?

[caedes]

I manage the js implementation and genjix the sx one.

[caedes]

Ok we have fixed the issue in darkwallet git.

The fix also is using a different api than proposed that also makes sure the point is encoded as 32 bytes, not totally sure it's required but probably is what we want, will double check that soon with genjix.

https://github.com/darkwallet/darkwallet/commit/da6a084c3102bbaf50aabd1ba524f5365f27d7ed

We also added some backwards compatibility code so funds in bad addresses won't be just stuck. Tried to make it in the most simple way and so the workaround can easily be removed later.

Thx again for finding the issue and providing a fix.

[Nicolas Dorier]

cool, glad we could help.
We had 1 chance on 2 to find the bug, if the first transaction I sent to piotr worked, we would have continued our lives with the bug lurking in the dark.