Topic: Hidden Bitcoin addresses (Read 361 times)

The transactions do not have addresses. The information in a transaction is not base58check encoded.

Addresses are simply a "shortcut" or "slang" that we humans use to exchange the information that the wallet software needs when it builds transactions.  It doesn't actually use the addresses itself in the transaction.  When wallets see a transaction, they convert the data that is in the transaction into an address when it displays it to us so that we can use that when talking to other humans.  Block explorers do the same thing (attempt to convert raw data back into an address before showing it to us humans).

What is actually in the transaction (and the blockchain) are OUTPUT SCRIPTS.  Those output scripts encumber the output with a requirement that must be met if the output is to be used as an input into a new transaction.

So, I could tell you to please:

Create a transaction that has at least one output with an integer value of 100,000 which is encumbered with a requirement to provide an ECDSA signature (using the Secp256k1 curve) of the transaction which can be validated with a public key that will result in a hexadecimal value of 0x359ad1c9d00b23f3279f068efc995eedb63c7ba9 when that public key is first hashed with SHA256 and the result of that is then hashed with RIPEMD160.

Or I could just tell you to please send 0.01 BTC to 15tSHDP5d4ovRJgywCt5MB1NR1BeWrEf7B

These two sentences mean the same thing.  The address "15tSHDP5d4ovRJgywCt5MB1NR1BeWrEf7B" encodes all the necessary information for the wallet to know what type of script to create, and what the requirements are for that script (signature type, curve, public key hash value, hash functions to use, order to use the hash functions).

The first one is what the wallet is actually doing. The second is how we humans tell the wallet what to do (or how it tells us what it did).  The checksum in the address is just to protect you (the human) from errors such as a typo when you enter the address.  The wallet checks the checksum BEFORE it creates the script. If the checksum is incorrect, then it tells you that your address is invalid and it DOES NOT CREATE THE SCRIPT at all. If the checksum IS correct, then the wallet discards the checksum and builds the requested script.

It is only verified by the wallet software only. Addresses are solely a human thing so they never hit the network.

Addresses are not part of transactions at the protocol level, so an invalid address checksum has no effect on the validity of the transaction you make. It's just that the output that is created may not necessarily be what you expect.

So this would also mean that the checksum (Base58Check) to see if an adress is valid is something that is not implemented by the protocol, but rather by wallets/nodes themselves, (for user convenience etc..) correct?

If i were to broadcast a transaction without the checksum with my own node & a different adress format, how likely would it be that it will get accepted by a miner?

No, different address types are not necessarily invalid or unknown. If you use a new address type that just specifies some other script template, said script template is perfectly valid on the network. However it is not considered one of the standard script templates so most nodes would reject it. Most block explorers would not know what the address type is and would just show some error or garbage because they don't know how to interpret the script template into something that is human recognizable.

But there certainly have been non-standard scripts being used as outputs of a transaction. Whether they are part of some new address type that someone created is unknown, but possible.

Which could be confirmed by miners and added in a block? Why haven't we seen something like this before then by someone who would experiment with it? Or would most miners/nodes still see them as invalid/unknown as the current nonsegwit nodes see the  segwit transaction structures, and thus never get in a block??

Yes.

No.

Addresses do not actually exist on the network. They are just an encoding for some data that is human readable and easily transferable. Anyone can create a new encoding scheme, call it a new address type, and use it with software that supports that address. It still just encodes data and the wallet software will need to interpret it in order to use the address properly.

What would cause a fork is if that new address specified that the encoded data be used for something that currently cannot be done on the network. But you can just create a new address type that specifies some other script template that you want to use that isn't segwit, p2pkh, or p2sh.

Ahhhh ok... well, you can't just create a new version of Bitcoin addresses... doing so would require a fork... and given the total shit show that was the SegWit soft-fork, good luck getting ANOTHER fork accepted

In any case, to create a new version of bitcoin addresses, you'd need to "advertise" what you were doing (BIPs etc), which would give block explorers (and wallet vendors etc) plenty of time to update their systems to support the new address version before it went live.

And really... bech32 addresses aren't "hidden"... as mentioned earlier, just the b.info dev's being a bit slow and haven't got around to updating their backend "Address" end-point code to support searching/indexing bech32 addresses. Plenty of other block explorers work just fine with bech32 addresses.

It would likely be the same with any new address version created and accepted... "quality" services would update their systems, less reliable ones would probably not

The focus of my question is:
If some developers created a new version of the Bitcoin addresses and haven’t been accepted by the most of community, is it possible to appear hidden to all/ most block explorers "like Bech32 with blockchain.info"?

I believe what he means by hidden is bech32 addresses are not clickable and searchable
therefore unable to see all related transactions on those bech32 addresses
btw why the second output (change) has longer address?

and to correct my last post wording, I should say
"blockchain.info don't/haven't build indexes for bech32 addresses to allow them to be searchable"

Not sure what you're all talking about... bech32 addresses are showing up fine on blockchain.info:


Or am I just not understanding what you're all talking about?

I suppose their devs could have been super busy today!

they're not hidden but blockchain.info explorer is simply unable to decode and provide/display related data on bech32 addresses
most explorers and wallets haven't implemented segwit and not fully compatible yet
check out btc.com explorer for that txid, you can check the bech32 address there
https://btc.com/4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c

edit: sorry for unnecessary similar reply post
I was in the middle of composing my post when AdolfinWolf posted his

No, it isn't hidden, blockchain.info's indexing simply hasn't been updated/doesn't support it yet. Almost every other block explorer will index bc1... adresses just fine.

Blockchair for example, https://blockchair.com/bitcoin/transaction/4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c


You mean that an adress would generate an adress starting with gc1.... instead of bc1...  (Or anything/any combination for that matter)? I'm pretty sure these would be rejected by nodes/are simply invalid adresses, and will never be added in a block ( if you would sent from 1.. to gc1...) I also doubt you would even be able to broadcast the transaction with any of the current wallets.

Bech32 address format appear hidden in the network until more software supports it.  ex: https://blockchain.info/tx/4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c
Is this possible for Each wallet to use a different address format to be a feature to hide the contents of the addresses "different human-readable part "bc" for each wallet"?