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.
Topic: NBitcoin : Stealth Address, DarkWallet compliant (Read 3494 times)
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.
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.
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.
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.
I manage the js implementation and genjix the sx one.
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 ?
Do you manage the JS implementation ?
sorry Nicolas, was outside.
I'm lurking and responding when back.
btw is SX doing it correctly or not?
I'm lurking and responding when back.
btw is SX doing it correctly or not?
good. thx.
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!.
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!.
habitually genjix respond, tried to spam him again today, but he 404 me.
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.
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.
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.
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 :-(
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.
then I copied it...
the question is: what now?
are you going to change it?
I think we should.
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?
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. 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.I hate javascript so much.
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.
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.
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.
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.
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?
it is not my code, but I believe Y has a method isEven() that works faster than mod(2)
EDIT:
actually, I believe the proper way is to just use the function that is already there for it:
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)
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.
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
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
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.
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.
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?
see here, line 619: https://github.com/dabura667/electrum/blob/StealthAddressSend/lib/bitcoin.py
@dabura667, any comments?
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.Maybe the scanner will need to handle both case
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.
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
Maybe the scanner will need to handle both case
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:
I'm happy to change it in my code, but first let's figure out which approach is the desired one
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);
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
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 :
DW :
It about :
c = H(eQ) = H(dP) at https://wiki.unsystem.net/index.php/DarkWallet/Stealth#Dual-key_stealth
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);
var hash = Hashes.SHA256(pBytes);
DW :
Code:
var pBytes = new PubKey(p.GetEncoded()).Compress().ToBytes();
pBytes[0] = 0x03;
var hash = Hashes.SHA256(pBytes);
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
ok. let me know what you found.
sent you back the coins.
sent you back the coins.
need to ask to genjix on irc, i'll contact him.
mwdJkHRNJi1fEwHBx6ikWFFuo2rLBdri2h
mwdJkHRNJi1fEwHBx6ikWFFuo2rLBdri2h
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.
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.
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.
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.
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?
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 ?
Just checked
Which is the address where I sent.
Code:
Usage: sx stealth-uncover EPHEM_PUBKEY SCAN_SECRET SPEND_PUBKEY
NICO@aois-linux2:~$ sx stealth-uncover 02d3a7c713f0fb9eadaf23d121f5f66a11f4ca780a353ecb1c88ae48646529e1d6 cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a 02a60d70cfba37177d8239d018185d864b2bdd0caf5e175fd4454cc006fd2d75ac
02bbc9fccbe03de928fc66fcd176fbe69d3641677970c6f8d558aa72f72e35e0cb
NICO@aois-linux2:~$ sx stealth-uncover 02d3a7c713f0fb9eadaf23d121f5f66a11f4ca780a353ecb1c88ae48646529e1d6 cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a 02a60d70cfba37177d8239d018185d864b2bdd0caf5e175fd4454cc006fd2d75ac
02bbc9fccbe03de928fc66fcd176fbe69d3641677970c6f8d558aa72f72e35e0cb
Which is the address where I sent.
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?
but now at least I know how to recover the coins we lost before.
where do you want them?
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.
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.
Them EphemKey was 23eef32c39ccfd1267f0cd45841dc5bf8deae0184dad16993949d1707c4fb9b6
I'm checking the result against sx, one moment.
I'm checking the result against sx, one moment.
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?
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
Can you check what is going on with txid 7efb90526034f0eac6b4f897ea0dcf617b03b29e8b0b4f1660b1fb76740b45f1
http://blockexplorer.com/testnet/tx/7efb90526034f0eac6b4f897ea0dcf617b03b29e8b0b4f1660b1fb76740b45f1
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
already mined oO
And already 3 confirmation... wow what's going on on testnet.
And already 3 confirmation... wow what's going on on testnet.
ok.
in case if they got mined, let me know.
in case if they got mined, let me know.
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
I have all my ephem keys
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.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,
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)
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)
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 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
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 heck, I'm not even good enough to do anything... but I do the best I can. :-)
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 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.
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
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.
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.
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.
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, 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.
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.
Have you done the same error on the previous transaction we made ?
Maybe something does not work right and I need further testing.
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.
Have you done the same error on the previous transaction we made ?
Maybe something does not work right and I need further testing.
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.
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.
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.
The transaction I sent is
http://blockexplorer.com/testnet/tx/e83fcbedca05f5b792cb554f7d58d77c40f0a90e91d0d63f7ddfd0fa12790136
Yeah, this one is correct!http://blockexplorer.com/testnet/tx/e83fcbedca05f5b792cb554f7d58d77c40f0a90e91d0d63f7ddfd0fa12790136
I'm sending it back in tx c85b654a97f0ed150ff76b6c2ef50b9aa4a1911d7186d815be1c8c02dfcb3a81
The transaction I sent is
http://blockexplorer.com/testnet/tx/e83fcbedca05f5b792cb554f7d58d77c40f0a90e91d0d63f7ddfd0fa12790136
http://blockexplorer.com/testnet/tx/e83fcbedca05f5b792cb554f7d58d77c40f0a90e91d0d63f7ddfd0fa12790136
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
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
sorry
Code:
cc411aab02edcd3bccf484a9ba5280d4a774e6f81eac8ebec9cb1c2e8f73020a
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.
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
Can I get your scan private key ? So I can verity with sx and also my framework what address it gives.
Normally it has
http://blockexplorer.com/testnet/tx/1e0bb55e0c460e403a41e3f9d578209e0c518bd2ea97121cde5db0d6443e9219#i36098884
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
ok - as soon as it arrives.
but it hasn't yet.
but it hasn't yet.
sent, send back to msj42CCGruhRsFrGATiUuh25dtxYtnpbTx (tpfaucet)
Thanks for the seed, I will send the transaction.
I signed before adding the TxOut -_-
I signed before adding the TxOut -_-
Quote
0100000001695f9c647d044563d2fff95fba1bd5cf1d35d75611ddbd8b1da80a4dff7aa8a000000 0006b483045022100ee96d1dbe442c1b0997526e3e66d188a9014bd0b9f39262498b2c8484520d3 49022070c0fb15145a453cf2151f7ee60d675fbf047afba1d0058ac704589fe07fdcc6012102cce a45d5eb89ea63dee2dd567beef6dd38b2edb3ebf3d85ef45c537ff1af1bbcffffffff0200000000 00000000286a26060000000003de307f3903d0cf32509c2964ea8fca2be9640dd14bc1233856aa8 0967e4e0debc056fe03000000001976a9140d31b807b4ce74cd9e1f7d0c888abbed8e30584788ac 00000000
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
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.
All of these are down for me
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.
Quote
0100000001695f9c647d044563d2fff95fba1bd5cf1d35d75611ddbd8b1da80a4dff7aa8a000000 0006a47304402200e583af51ef57334f0c830e85bb809c7a23f4fbdd6d5557dbec1a2216c578bee 02203c54f1c2205ab0c21a511cbd1a2006bc339693d329cee7fb881aae44c6323dee012102ccea4 5d5eb89ea63dee2dd567beef6dd38b2edb3ebf3d85ef45c537ff1af1bbcffffffff020000000000 000000286a26060000000002704f9c99117ba90b162859e1f5f21c7e1805bc6c0594cc4e5a3dadf adf2c17bbc056fe03000000001976a9148f1516c7c20207a22940133f878351ac3681b56b88ac00 000000
All of these are down for me
Quote
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"));
{
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"));
cool. let's test it. can you send me some test coins and give the address where to send them back?
btw, do you support prefix length other than 0?
Code:
waPV5rHToBq3NoR7y5J9UdE7aUbuqJybNpE88Dve7WgWhEfvMrcuaSvF6tSQ3Fbe8dErL6ks8byJPcp3QCK2HHviGCSjg42VgMAPJb
btw, do you support prefix length other than 0?
Just wrote an article on it : http://www.codeproject.com/Articles/775226/NBitcoin-Cryptography-Part
I finished implementing StealthAddress in NBitcoin.
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
Quote
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);
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
Jump to: