Topic: Why do Bitcoin Addresses exist? (Read 334 times)

Bitcoin address is a users unique link that is used to receive payment to his or her wallets, it serves just the same way as our banking number or account number
 https://www.techtarget.com/whatis/definition/Bitcoin-address

No, P2PK has 128-bit security. Even there is a topic about that: https://bitcointalksearch.org/topic/bitcoins-public-key-security-level-2859033

If you have 160-bit public key, then you have 80-bit security, in the same way as for 256-bit public key, you have only 128-bit security. Otherwise, you wouldn't see that 115-bit public key was broken, but 66-bit key protected by some hash is still not taken. Also, around half of those keys are outside of the secp256k1, so instead of 256-160=96, you have 96-1=95, because half of those keys are invalid. Of course it depends, how you handle partial keys, because if the first part is in the input, then you will get 2^96 combinations again, because then your key could be a partial x-value of some compressed key, or a partial y-value of some uncompressed key.

It has (b/2)-bit security, because anyone can freely choose any input (so you have many keys to choose from), and because there are algorithms to solve it in sqrt(n), so you don't have to check every single key, like in hashes. Also, if you have 160-bit hash, then you really need to compute 2^160 hashes, to get the same result. But if you have 160-bit partial public key, then you need only 2^80 keys.

Edit: To sum up:
But, if you swap them, then you choose in your output if that key is compressed or not:

Where do you get 95 from, and how does that lead to 80-bit security?

More generally, if outputs show b bits of the public key, and inputs the remaining 256-b bits, then what is the security?
Note that P2PK has the full b=256.

Yes, it reduces security. Normally, public keys have 128-bit security. In your scenario, they would have 80-bit security, because there would be around 2^95 valid public keys. And 80-bit ECDSA security would mean that we would be very close to breaking them, because 115-bit ECDSA public key from the puzzle was already taken, so those keys would be only 2^45 times stronger.

Also, if the same amount of data is sooner or later pushed on-chain, then it does not solve anything. If you want to calculate fees differently, then it would make more sense to change the way how your node counts minimal fees, then you will at least keep the same security level.

Edit:
It could be possible if OP_CAT would be reactivated.

They take up 12 fewer byte in the output, but end up taking another 32 byte in the input.
One can imagine another way of shortening output addresses, which doesn't cause redundancy on inputs.

Namely, an output address could be the top 160 bits of the public key. And to spend this output, the corresponding input needs to provide the missing 12 bytes (note that this requires new opcodes). That saves 20 bytes on an output/input pair compared with the current setup. Are there some downsides to this construction?

Bitcoin addresses exist to provide a way for individuals to send and receive bitcoin. They serve as a destination for bitcoin transactions and allow for the ownership of the bitcoins to be transferred. Each address is unique and is created using a public key, which is derived from a private key that is used to access and control the bitcoins associated with the address.

I don't specifically know why addresses were invented but I can think of two reasons.

• 1. It is useful to keep the public key secret until it is needed.
• 2. Addresses take up much less space

WoW the mwixnet idea is really clever. It reminds me of zero knowledge ceremonies where only one person has, to be honest for it to work. Thanks for the link!

And having people share script (which contain condition to spend/lock the Bitcoin) instead?


Wrong, bitcoin address basically is just abstraction/representative of script. It's also the reason you could send and receive Bitcoin using same address.

See https://bitcointalksearch.org/topic/m.56288711

An implementation for Grin is underway at https://github.com/mimblewimble/mwixnet/

    Reusing address based on your story, could potentially damage the address-based system. it can compromise privacy.

The utxo-based system also has drawbacks such as the need for more complex scripts to manage advanced transactions.

I think these resources might help you:

1. Bitcoin Script
2. The Bitcoin Whitepaper
3. Mastering Bitcoin

I am glad that you value the transparency offered by Bitcoin, this is a solid reason for how Bitcoin currently is!

This is definitely a great answer. I looked at your list and it is great. I bookmarked it! Thanks again for the response!

You are slightly confused about how bitcoin actually works. It is not based on "accounts" or "addresses", bitcoin is purely UTXO based. Meaning each time you want to send bitcoin you spend UTXOs in a transaction by providing an unlocking script to the locking script of the UTXO using the smart contract system Bitcoin has in form of scripts.
Address is on a higher layer targeting the user and user interface to make it easier to use, not the low level protocol.

In my opinion, the downside to MimbleWimble / grin is that it's an interactive protocol. Meaning I can't just give someone my address, go offline and they can send me Bitcoin at any time.

Especially if we talk about larger sums that I want to hold in cold storage or if I use a mobile wallet that goes to sleep after a few minutes in the background.

The probably biggest reason 'Why Bitcoin addresses exist' and BTC doesn't use grin's (or a similar) model is that Bitcoin is much older and when satoshi came up with it, nobody was thinking about address reuse and deeply about privacy yet. Bitcoin was pseudonymous from the start and it was known not to be perfect in terms of privacy. But these are pretty advanced concepts that were always meant to be tackled later on (i.e. now).

You could argue that Lightning gives Bitcoin the feature you are looking for: anonymous, but interactive payments, without addresses.

Maybe you have some Bitcoin Layer 1 privacy ideas or papers that I missed and I'd be glad if you would post them here: [Megathread] Bitcoin Layer 1 Privacy - concepts, ideas, research, discussion

because i can go private or not private .

because i can easily and simply run a legal taxable business with repeatable traceable addresses.

Some want to be tracked and traced when they make money.

and if you want to hide btc and be private its possible. difficult but possible.

Look up my public often repeated 1J address in my profile it goes back in time for years. 2013 and hundreds of traceable transactions .


https://bitcointalksearch.org/user/philipma1957-64507

1Jd…

Grin seemed to bring in some sort of "shuffling" method to reduce traceability by allowing accounts/addresses to move funds and make them less traceable - I don't think mimble wimble fully had a complete level of privacy before that but I could be wrong.

You seem to have resuggested public key cryptography but in a different way. Bitcoin might also transition to using mimble wimble at some point (and I'm under the impression it will, or at least become more private) but I don't think they're going to be doing that yet (it might be similar to how sharding isn't done on eth yet and is planned to be activated in 4 years or however long they expect it to take now even though it's been coded on harmony for a while).

Thanks for the info! I will look more into the issue that you mentioned!

Because then it is possible to send your payment, when your recipient is offline. In the old times, it was possible to connect to another node by typing its IP address, then getting a new public key directly from that recipient, and make a direct payment to such public key.

Reusing public keys is also possible, in the same way as reusing addresses.

You cannot ban address reuse on a protocol level. It would break backward compatibility, and invalidate timelocked transactions.

Then you will have more problems, for example your signatures will no longer be tied to specific outputs, so it would be like using SIGHASH_ANYPREVOUT all of the time. And that means transaction invalidation will be impossible. Funding an address will make the same transaction valid again. And that would cause a lot of spam. Also, it will then never be possible to invalidate any transaction, because even if conflicting transaction will be included, you could still send funds again, and then reuse the same signature for another transaction, when your account will be funded.

Also, it would mean that miners could repeat the same transactions over and over again, because they can include free transactions. So, they can create A->B->C->...->Z->A transaction circle, and include it in every block, all over again, with the same signatures.

I recently began diving into the Mimble Wimble protocol. I found the white paper and general work around it to be amazing. It brings me to question the existence of utxos and addresses in Bitcoin. Coins like monero and mimble wimble derivatives function today with no on-chain addresses, and I am curious as to why addresses exist on the bitcoin blockchain. My understanding is that you can get rid of addresses and have people sign utxo's directly with ECC. It seems that addresses sorta function like accounts in eth and utxos's function for transactions in mimble wimble. Bitcoin seems to have both utxos and addresses and has some of the downsides of both approaches. Addresses in bitcoin lead to address reuse which is bad for privacy. Address reuse is prevalent today also. I thought all last night about the issue and I could not come up with a fundamental downside to Bitcoin ditching addresses and just going utxo only. I also thought about bitcoin going the opposite direction and just using addresses as accounts and getting rid of utxo's, sorta like eth. I know bitcoin would unlikely adopt these things due to coordination issues. I would love to learn more about these technical questions. Any links to further readings or thoughts on the issue would be greatly appreciated. Thank you so much for your time!