Did I just lost my BTG ?

[nferruzzi]

Ok, I've attempted to use your tool but something doesn't seems fine to me and I think I've lost everything.
Basically I got a Ledger Nano S, installed the BTG application and got an address to receive the sum "ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35"

then following your "easy" guide I tried to move my fund from this old transaction

https://blockchain.info/tx/56714ec2e79e29154643306c4960462fba68292a292e8bbe076ab050cd774a25

address 1GRvDoGj77RTgZtZ2Y5nAaFJ6YCTKTPFnV index 26

node tx.js BTG create prevtx=56714ec2e79e29154643306c4960462fba68292a292e8bbe076ab050cd774a25 prevaddr=1GRvDoGj77RTgZtZ2Y5nAaFJ6YCTKTPFnV prevamount=0.594 previndex=26 privkey=privkey addr=ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 fees=0.00001001

https://btgexp.com/tx/8c76ce917dc9f278d71befbaee817eac9d7225e729e15db16bb986f144769551

and looking at the transaction dump I didn't realise my addr was different not just the same but with a different encoding.

So now I'm here asking, are they lost ? thanks

[Ayms]

No if you have access to address ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35, it is the same than GNfGDhGMDuSQ8znf34XNaBBAskmpnFT2pD where the funds were sent (0.58938541 BTG), ie if you have the private key, that works for both

Indeed addresses are the same with a different encoding, if you have a wallet already you can use the same, see https://github.com/Ayms/bitcoin-wallets to convert addresses

So I don't know what you mean by "I got a Ledger Nano S, installed the BTG application and got an address to receive the sum" (frightening, you guys should stop relying on stupid stuff, it should have given to you a G address (p2pkh), not a A one (p2sh)) but I suppose that you have the private key corresponding to ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35, then GNfGDhGMDuSQ8znf34XNaBBAskmpnFT2pD, so your funds are still yours (I don't know what you want to do but using the tool again with this address and tx 8c76ce917dc9f278d71befbaee817eac9d7225e729e15db16bb986f144769551 with the private key that you are supposed to have will just work again)

Please keep me updated and let me know if I can help

And if something is unclear in my "easy" guide then please let me know how to improve it

[nferruzzi]

Thanks for your reply.

well unfortunately (for me) I may be one of the guy who relay on stupid stuff and get burned. The ledger supports both legacy (G address I guess) and segwit (A address ?). I just used segwit because its their default option.

Also, in this case, I've no access to the private key (of course the point of an hardware wallet is to secure them and avoid any kind of direct backup) still I've my seed words and I believe I can recreate them with some compatible software out there (the protocol to generate the keys should be like a standard no?)

I think without the pk I'm out of options, right ? because I've access to the wallet of this address ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 but it doesn't show any amount on it, while the one in the transaction has the proper amount.

https://btgexp.com/address/GNfGDhGMDuSQ8znf34XNaBBAskmpnFT2pD

Sorry for the confusion but I'm still confused about the guide because from "a user experience" point of view, the transaction generated is not compatible with my wallet and I'm not so sure what I should do now; would have it worked if I used a G address ? maybe this should be pointed out.
Edit: should this considered a problem of the wallet itself, to recognise transactions with both address ?

[Ayms]

For now you have address A which corresponds to address G (which again are the same), then the coins are still yours, that's for sure, don't worry about that

Your (stupid) wallet just does not find them, and this (stupid) wallet defaulted to supposed "segwit" A-addresses, which are p2sh addresses whether segwit or not, the (stupid) wallet should have given you a G address

Why the (stupid) wallet does not find your funds, while again the addresses are the very same ones, I don't know, it's not a pb of transaction compability, the transaction is valid, has been accepted and mined by the network in a block, you don't care about a G or A address

At the end it does not make any difference, the only thing that you need is the private key that unfortunately the (stupid) wallet will not give back to you

I will add a section about (stupid) wallets and common related misunderstandings, that's the very intent of this module: manage things by your own, don't use (stupid) wallets

Now, to solve your case, please email me in private if you like (once you think there is no way for you to succeed) everything needed to possibly recover your private key (indeed the (stupid) wallet has not invented anything and keys can be retrieved from the seed)

[nferruzzi]

Thanks for you support, I've been able to recover my private key using this tool here

https://github.com/iancoleman/bip39

using BIP141 with derivation path m/49'/156'/0'/0

Next would be to use the tool to send the whole amount to a G address ? something like

node tx.js BTG create prevtx=8c76ce917dc9f278d71befbaee817eac9d7225e729e15db16bb986f144769551 prevaddr=GNfGDhGMDuSQ8znf34XNaBBAskmpnFT2pD prevamount=0.58938541 previndex=0 privkey=privkey addr=GW54q4adbAyo8xPoF3SMTTzXM84SBRXvai fees=0.00001001

this should move the amount to another of my wallet

[nferruzzi]

Ok I've not sent the transaction because I got this

Version BTG
create
--- With your network fees the advised amount is: 0.58480659
--- Previous amount is: 0.58938541
--- Amount to spend is: 0.58480659
--- Network fees are: 0.00001001
--- Dev fees are: 0.00456881
Address corresponding to private key is **GgLonc5g21CqZfT4LX9m8byMDVPtgmK2Cp**
----- Transaction hash: 2655ca598897a0bf26486cf4c42bbbe0051a4ef03d0214e36502e23978111b38
Transaction body:
[...]
Complete transaction:
[...]
Size 250 bytes
Network Fees: 1002 - 4.01 satoshis/byte
Dev Fees: 456880
------------- Check - deserialize
{ input:
   [ { hash: '8c76ce917dc9f278d71befbaee817eac9d7225e729e15db16bb986f144769551',
       n: 0,
       scriptSigLen: <Buffer 6b>,
       scriptSig: [Object],
       data: null,
       nSequence: <Buffer ff ff ff ff> } ],
  output:
   [ { nValue: 58480659,
       scriptPubkeyLen: <Buffer 19>,
       scriptPubkey: <Buffer 76 a9 14 86 1d f0 80 6c e4 8d 56 e1 5e 1c 5b 47 db e4 c9 6d a7 08 4a 88 ac>,
       address: 'GW54q4adbAyo8xPoF3SMTTzXM84SBRXvai',
       type: 'p2pkh' },
     { nValue: 456880,
       scriptPubkeyLen: <Buffer 19>,
       scriptPubkey: <Buffer 76 a9 14 5b 79 a9 d2 9a 34 f2 f2 84 ec dd 33 00 9f fa 5e 02 52 b6 89 88 ac>,
       address: 'GSBbeuKPu4d6HKJhtPgk7XayMcaXyQy8TS',
       type: 'p2pkh' } ],
  s: 0,
  nVersion: <Buffer 02 00 00 00>,
  nbinput: 1,
  nboutput: 2,
  nLockTime: <Buffer 00 00 00 00> }
------------- End Check - deserialize
------------- Check - verify
----- Transaction hash: 2655ca598897a0bf26486cf4c42bbbe0051a4ef03d0214e36502e23978111b38
signature: 
[...]
message to be signed: 
[...]
**Bad transaction**
----- Transaction hash: 2655ca598897a0bf26486cf4c42bbbe0051a4ef03d0214e36502e23978111b38
------------- End Check - verify

I used the private key for this address ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 but the log reports:

Address corresponding to private key is GgLonc5g21CqZfT4LX9m8byMDVPtgmK2Cp not GNfGDhGMDuSQ8znf34XNaBBAskmpnFT2pD

Now I'm lost :(

[Ayms]

The tool double check several times that everything is correct, this is complicate and at the end if you get 'Transaction verified' it is very very very unlikely that the transaction is not correct

And if you get 'Bad transaction' then for sure the transaction is not correct, probably you did not get the right private key

The BIP39 tool really gives you a private key whose public key is GNfGDhGMDuSQ8znf34XNaBBAskmpnFT2pD or ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 ? Could you please post here what is says without unveiling the private key?

I don't know what Ledger Nano S is doing, I suppose that you have read https://medium.com/@trionkidnapper/ledger-nano-s-restoring-a-device-using-recovery-phrase-d80051ecf17a, they are talking about BIP44, but you used segwit (then BIP141...)

I have not implemented segwit because I don't see very well the interest compared to complicating things more and nobody knows who will support it eventually and when (except btg)

I have to take a look at the segwit address format

[Ayms]

Segwit addresses are the same too, thanks if you can send the requested info

[nferruzzi]

Hello,

I understand things get complicated, but I still have some hope :)

the public key using BIP141 is this one and the address match the one I've used to create the initial transaction.

m/49'/156'/0'/0/0 | ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 | 02914637d9f66b1fbf7e71269bf54168cf7aa9be016cc6fd6fb4ff9e5706745297

Meanwhile I've experimented a bit and , I don't know if its a good thing or not but, the transaction gets verified if I do pass prevaddr=GgLonc5g21CqZfT4LX9m8byMDVPtgmK2Cp

20:52 $ node tx.js BTG create prevtx=8c76ce917dc9f278d71befbaee817eac9d7225e729e15db16bb986f144769551 prevaddr=GgLonc5g21CqZfT4LX9m8byMDVPtgmK2Cp  prevamount=0.58938541 previndex=0 privkey=privkey addr=GW54q4adbAyo8xPoF3SMTTzXM84SBRXvai fees=0.00001001

{ input:
   [ { hash: '8c76ce917dc9f278d71befbaee817eac9d7225e729e15db16bb986f144769551',
       n: 0,
       scriptSigLen: <Buffer 6b>,
       scriptSig: [Object],
       data: null,
       nSequence: <Buffer ff ff ff ff> } ],
  output:
   [ { nValue: 58480659,
       scriptPubkeyLen: <Buffer 19>,
       scriptPubkey: <Buffer 76 a9 14 86 1d f0 80 6c e4 8d 56 e1 5e 1c 5b 47 db e4 c9 6d a7 08 4a 88 ac>,
       address: 'GW54q4adbAyo8xPoF3SMTTzXM84SBRXvai',
       type: 'p2pkh' },
     { nValue: 456880,
       scriptPubkeyLen: <Buffer 19>,
       scriptPubkey: <Buffer 76 a9 14 5b 79 a9 d2 9a 34 f2 f2 84 ec dd 33 00 9f fa 5e 02 52 b6 89 88 ac>,
       address: 'GSBbeuKPu4d6HKJhtPgk7XayMcaXyQy8TS',
       type: 'p2pkh' } ],
  s: 0,
  nVersion: <Buffer 02 00 00 00>,
  nbinput: 1,
  nboutput: 2,
  nLockTime: <Buffer 00 00 00 00> }
------------- End Check - deserialize
------------- Check - verify
----- Transaction hash: 56b1a7585d45ebfdd811ea0ec80f729791a51c6372239919451abb769810dc28
signature: 
[...]
message to be signed: 
[...]
----- Transaction verified

should I try this command ?

[Ayms]

Please wait, let me check things tomorrow, could you please email me in private the complete transaction above, or, better, the complete dump (don't worry the private key is not in there) ?

[Ayms]

I don't need the logs in fact, it's normal that your transaction is verified since you gave the correct input (ie the correct public key corresponding to the private key)

Public key 02914637d9f66b1fbf7e71269bf54168cf7aa9be016cc6fd6fb4ff9e5706745297 is GgLonc5g21CqZfT4LX9m8byMDVPtgmK2Cp or AeGm1ycMNJFhJAMkyE9yritYmvXjzzANz5 and still does not correspond to the output to spend, so you don't have the correct private key

Not sure why the BIP39 tool tells you that 02914637d9f66b1fbf7e71269bf54168cf7aa9be016cc6fd6fb4ff9e5706745297 corresponds to ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 but this is not the case

[nferruzzi]

When I use BIP30 there is only a combination of paramaters that give me the address ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 in the list of my addresses (with it's corresponding public and private key).

BIP141
Derived path: m/49'/156'/0'/0
Script Semantic: P2WPKH nested in P2SH (the only one working, P2WPKH crash the js)

I thought that being able to see my address was enough to believe its private key is fine.

[Ayms]

How did you find the derived path: m/49'/156'/0'/0?

Difficult to guess what you did and what the address tool said...

[nferruzzi]

m/49' I don't remember but I think I got it from some ledger guide
156' is the btg registered coin type (https://github.com/satoshilabs/slips/blob/master/slip-0044.md)
0' means first account
0 public address (1 would be the change address)

[Ayms]

It looks strange m/49'/156'/0'/0, should better be m/49'/156'/0'

You can try https://github.com/Ayms/bitcoin-wallets (I just modified it a bit), put at the end of index.js:

var hd=generate_keys_bip32(new Buffer('your seed','hex'),new Buffer('26','hex')); hd.deriveChild(49).deriveChild(156).deriveChild(0);

And then: node index.js

[Ayms]

And if you are sure about m/49'/156' then you can try the above from 0 to 100 until you see your address

[nferruzzi]

I'm stuck, what is the "seed" ? I've a BIP39 Seed or a BIP32 root key but none of them generate the address I'm looking for: GNfGDhGMDuSQ8znf34XNaBBAskmpnFT2pD

Just to be sure, using the bip39 tool, I've been able to generate the proper address for a "legacy" address I had using the bip39 tool with bip32 and derived path m/44'/156'/0'/0

But with your wallets tool and using the bip39seed/bip32 root key as seed I get different addresses; I also added an extra deriveChild since it looks my correct address from the bip39 tool are at depth 4 not 3

[nferruzzi]

Just out of curiosity, do you know what it means the ' in the path ? m/44'/156'/0' or m/44/156/0 generate different address

[Ayms]

Of course I know what it means the ' stands for hardened keys, that's the default for bitcoin, bitcoin-wallets and any other wallets

Starting to be a bit fed up of this bip39 stuff and tool which does not give you the seed (and btw you sent all of your private info to this online tool... then they know everything now about your wallet), really is it easier to retrieve x words coming from nowhere than a simple 64 characters hex seed string?

I will modify bitcoin-wallets so you can enter the "BIP32 Root key" instead of the seed, that's a (stupid) feature anyway that should be there

On your side please keep concentrated, m/44 or m/49, please check the path or there is no way to recover

And no, the bip39 tool did not give you the correct address, depth is 3 not 4 usually, and if it was 4 most likely it would be /0' at the end, not /0

Just to be sure, using the bip39 tool, I've been able to generate the proper address for a "legacy" address I had using the bip39 tool with bip32 and derived path m/44'/156'/0'/0

Please email me what the tool says for the "proper address"

[nferruzzi]

Thanks for clarification about the ' ! btw I don't use that tool online I've a local clone :)
I'll wait for the BIP32 root key feature and then try again.

Just to be sure, using the bip39 tool, I've been able to generate the proper address for a "legacy" address I had using the bip39 tool with bip32 and derived path m/44'/156'/0'/0

Please email me what the tool says for the "proper address"

basically I've another ledger nano s BTG wallet with the receiving address GW54q4adbAyo8xPoF3SMTTzXM84SBRXvai

By configuring the tool with my words and these options

I got this result which is exactly the address that I see on my wallet

btw just to let you know, I appreciate your help a lot. Thanks

[Ayms]

Maybe the offline version of this bip39 tool can be trusted

I will implement the root key, but now your m/49 is m/44...

Could you please show me where you saw ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 in the tool?

[nferruzzi]

Sure

[Ayms]

Well, you found the correct address... I was wrong, BIP141 addresses are different (P2SH-P2WPKH) and yours is a combination of BIP39/141/44, crazy stuff...

Shxt, unfortunately we are fxcked, because the output to spend is a p2pkh one, not a segwit p2sh, see what is happening on Bitcoin Cash which is similar https://www.reddit.com/r/btc/comments/6z56x3/attention_benevolent_bch_miners_a_bch/?st=jaqq0y62&sh=78757a75 and https://news.bitcoin.com/hundreds-bitcoin-cash-stuck-segwit-addresses-might-way-get-back/

But unlike BCH our problem here is that the module did not embed the output into a p2sh one, because the module does not handle p2sh, so it is impossible to recover

It's not difficult to implement segwit/p2sh but for now I have added a check so this can not happen again, sorry I did not foresee this case before

[Ayms]

Closing, unfortunately we would need the private key corresponding to ALbDT4o2aCVFsVhMfmXbJJ6NSBugAY1n35 which we don't have