TeraPool (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
July 07, 2011, 04:35:32 PM |
|
I mean... when I attempt to validate an address and bitcoind is running testnet... both testnet and bitcoin addresses are valid addresses.
That is not true however, or rather it cannot be true, can it?
You cannot send bitcoins to a testnet address, can you?
|
|
|
|
twmz
|
|
July 07, 2011, 04:40:30 PM |
|
bitcoin addresses are valid destinations on testnet (you can send test coins to a bitcoin address)
testnet addresses are not valid destinations on non-testnet (you can not send normal coins to a testnet address).
validateaddress essentially is validating that an address is a valid destination address.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5376
Merit: 13385
|
|
July 07, 2011, 04:45:11 PM |
|
The address version of testnet is 111 instead of 0. Bitcoin sees all address versions lower than its current version as valid. So testnet sees mainnet addresses as valid.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
TeraPool (OP)
Newbie
Offline
Activity: 42
Merit: 0
|
|
July 10, 2011, 12:12:47 AM |
|
bitcoin addresses are valid destinations on testnet (you can send test coins to a bitcoin address)
testnet addresses are not valid destinations on non-testnet (you can not send normal coins to a testnet address).
validateaddress essentially is validating that an address is a valid destination address.
So you can send testnet coins then to a bitcoin address? How would you send them from the bitcoin address back to a testnet address? So technically the client could generate a bitcoin address key pair for testnet accounts, it simply does not by default? Any external reading on this? Questions, questions, questions..!!
|
|
|
|
twmz
|
|
July 11, 2011, 01:36:07 AM |
|
So you can send testnet coins then to a bitcoin address?
I think you're getting confused by the difference between addresses and networks. Maybe you exported your address and private key from your normal client wallet.dat and imported it into your testnet client. Now you have a normal looking bitcoin address on a testnet client. If you have a normal style address on the testnet, you can send testnet coins to it. That doesn't mean that the coins are going to magically show up at that address on the normal network. They will only be at that address on the test network. Why do this? I can't think of a reason why you would want to do this, but the reality is that you can. You can't send coins between networks. They have different block chains.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5376
Merit: 13385
|
|
July 11, 2011, 03:25:24 AM |
|
On testnet, mainnet addresses are basically "aliases" of their equivalent testnet addresses. Sending to 1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6 is exactly the same as sending to mytEhA9yrhwC62ZGydszhJu5VagBZj2z7t. The only difference between these two addresses is the version and checksum: the public key hash is the same.
If you copy your wallet.dat from mainnet to testnet, your receiving addresses will all still be there: they will just have been changed to their "testnet" aliases. The associated mainnet versions will still work for transactions on testnet.
On testnet, there are actually 111 valid ways of expressing of every address. These are all the same: 1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6 ihtPDNHkrxp8MDkHVEwMWxYG6LRMEvGhC 283VNKfaU3RgwnMqJuaFqeEKtbbN1Q5KFY 2XP6MRxsBDtZmDVvLKuaKmW7X6rJiSaZ9Z 2vihLYG9tQMSaee1MkEtotmu9c7FSBxg9a 3L4JKeZSbapKQ5n6PAaDJ23gn7NCD2x9V1 ...
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
|
|
July 26, 2011, 11:23:12 PM |
|
The address version of testnet is 111 instead of 0. Bitcoin sees all address versions lower than its current version as valid. So testnet sees mainnet addresses as valid.
I HAVE to ask for any explanation about that I mean, either devs want any address version is ok for any network (and address versions become useless) or they want exactly one address version par network Why accepting all lower ones but not higher ones?
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5376
Merit: 13385
|
|
July 27, 2011, 12:02:51 AM |
|
I HAVE to ask for any explanation about that I mean, either devs want any address version is ok for any network (and address versions become useless) or they want exactly one address version par network Why accepting all lower ones but not higher ones?
The address checking code assumes that any version lower than the latest version is handled elsewhere in the code. Future versions could not possibly be handled. Example: If we move to SHA-256 hashes instead of RIPEMD-160 hashes, the address version will change to 1. Addresses with version 0 will still be valid, though: they will just be handled with the old code instead of the new code, or maybe trying to use them will trigger an informative error. Testnet doesn't include the cases for old versions that the checking code expected.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
|
|
July 27, 2011, 12:12:20 AM |
|
The address checking code assumes that any version lower than the latest version is handled elsewhere in the code. Future versions could not possibly be handled.
Example: If we move to SHA-256 hashes instead of RIPEMD-160 hashes, the address version will change to 1. Addresses with version 0 will still be valid, though: they will just be handled with the old code instead of the new code, or maybe trying to use them will trigger an informative error.
Testnet doesn't include the cases for old versions that the checking code expected.
Everything is clear now, thanks
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
lfm
|
|
August 07, 2011, 07:17:37 PM |
|
On testnet, mainnet addresses are basically "aliases" of their equivalent testnet addresses. Sending to 1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6 is exactly the same as sending to mytEhA9yrhwC62ZGydszhJu5VagBZj2z7t. The only difference between these two addresses is the version and checksum: the public key hash is the same.
If you copy your wallet.dat from mainnet to testnet, your receiving addresses will all still be there: they will just have been changed to their "testnet" aliases. The associated mainnet versions will still work for transactions on testnet.
On testnet, there are actually 111 valid ways of expressing of every address. These are all the same: 1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6 ihtPDNHkrxp8MDkHVEwMWxYG6LRMEvGhC 283VNKfaU3RgwnMqJuaFqeEKtbbN1Q5KFY 2XP6MRxsBDtZmDVvLKuaKmW7X6rJiSaZ9Z 2vihLYG9tQMSaee1MkEtotmu9c7FSBxg9a 3L4JKeZSbapKQ5n6PAaDJ23gn7NCD2x9V1 ...
I understand that, I don't understand why this behavior is useful or desirable in any way. Couldn't we just say when running i testnet mode you need to use the 111 tagged version of the address. The others will generate an error. It seems to me it would prevent some mistakes sending testnet coins to limbo when we think we are sending mainnet coins.
|
|
|
|
jackjack
Legendary
Offline
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
|
|
August 07, 2011, 07:23:50 PM |
|
On testnet, mainnet addresses are basically "aliases" of their equivalent testnet addresses. Sending to 1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6 is exactly the same as sending to mytEhA9yrhwC62ZGydszhJu5VagBZj2z7t. The only difference between these two addresses is the version and checksum: the public key hash is the same.
If you copy your wallet.dat from mainnet to testnet, your receiving addresses will all still be there: they will just have been changed to their "testnet" aliases. The associated mainnet versions will still work for transactions on testnet.
On testnet, there are actually 111 valid ways of expressing of every address. These are all the same: 1KNHQ7513gVwJv5fG4ucsPgkdb5Ub9UzR6 ihtPDNHkrxp8MDkHVEwMWxYG6LRMEvGhC 283VNKfaU3RgwnMqJuaFqeEKtbbN1Q5KFY 2XP6MRxsBDtZmDVvLKuaKmW7X6rJiSaZ9Z 2vihLYG9tQMSaee1MkEtotmu9c7FSBxg9a 3L4JKeZSbapKQ5n6PAaDJ23gn7NCD2x9V1 ...
I understand that, I don't understand why this behavior is useful or desirable in any way. Couldn't we just say when running i testnet mode you need to use the 111 tagged version of the address. The others will generate an error. It seems to me it would prevent some mistakes sending testnet coins to limbo when we think we are sending mainnet coins. The theymos' post, 3 posts above is rather clear It's for when we'll use a new kind of addresses, e.g. when we'll use addresses version 2, it would be useful to send coins to old addresses... Also, testnet coins sent to bitcoin address are easily retrievable, I made a guide about that
|
Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2 Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5376
Merit: 13385
|
|
August 07, 2011, 07:36:18 PM |
|
I understand that, I don't understand why this behavior is useful or desirable in any way. Couldn't we just say when running i testnet mode you need to use the 111 tagged version of the address. The others will generate an error. It seems to me it would prevent some mistakes sending testnet coins to limbo when we think we are sending mainnet coins.
Yes, but this should be a special case for testnet.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
lfm
|
|
August 07, 2011, 07:40:41 PM |
|
The theymos' post, 3 posts above is rather clear It's for when we'll use a new kind of addresses, e.g. when we'll use addresses version 2, it would be useful to send coins to old addresses...
Also, testnet coins sent to bitcoin address are easily retrievable, I made a guide about that
Well sorry but it wasn't all that clear to me. A new address version would seem to need a lot more code than just <= version and it is a hypothetical future use as opposed to the implemented current use of the version byte I understand how you can just switch wallets around to retrieve the "lost" coins but if the sent to address isn't yours it may not be as easy as you make it sound. True they're "just" testnet coins lost, no big deal I suppose but I still found it inconvenient and it just seems like a simple fix and the objections are rather abstract/hypothetical.
|
|
|
|
|