Post
Topic
Board Development & Technical Discussion
Merits 8 from 3 users
Re: Thoughts on burner addresses
by
vjudeu
on 16/06/2022, 21:06:22 UTC
⭐ Merited by vapourminer (4) ,BlackHatCoiner (2) ,ETFbitcoin (2)
Quote
But at least that way, everyone would know that someone at some point did know a private key for it.
It is partially true, because the whole Script has many options. You are not forced to lock coins on public keys or public key hashes. You can make any script, like "<signature> OP_SWAP OP_CHECKSIG". And it is possible to lock coins on some outputs that require no keys at all. What then? Also, there are many ways to "trap" coins. If you require providing a valid public key, that would prevent using random hashes, but then you could use "trap public key". And if you require a valid signature, then, guess what, people could make "trap signatures". For example, we have a bug in SIGHASH_SINGLE, so it is possible to make a consensus-valid signature, without knowing the private key, so no, if you can make a signature, that only means you know the relation between (k*G) and (d*G). In some cases, you don't have to know the private key, if you abuse the system. And there is no way to prevent all ways the system can be abused. See this topic, then you can see the smallest signature, that is valid, but nobody knows the private key or signature nonce: https://bitcointalk.org/index.php?topic=5373858.0

Quote
So a rouge miner could wreak havok on the bitcoin network by stuffing their block with zero satoshi transactions. Wonderful! When are they going to start doing that?
They have no reason to do that. The block size is limited, if they include some spammy transactions, then they won't include a normal, fee-paying transactions from regular users. So, they don't have any reason to lower their coinbase reward and to create more spam. But it is possible on other altcoins, where block size limit is higher, or where there is no limit at all.

Quote
no one made the ethereum devs and node operators angry and look what happened to their fee situation
Because they want that. They chose high fees by choosing Turing completeness and executing complicated contracts on-chain. They chose large scripts, instead of making things simple, and adding new single opcodes as needed. I think it is better to introduce OP_DO_SOMETHING as a new opcode, than to force developers to write "2 2 OP_ADD 4 OP_EQUAL OP_IF ...". There is no reason to include long programs on-chain. There is no reason to execute everything on-chain, that makes it costly, when you want to write a simple game, and each move is executed on-chain, as a contract. They made it more complicated than needed, and they pay for that in fees, just because that's how they constructed their consensus.

Quote
what happens when they can't get it right as far as the fee goes is people seek alternatives
Many people moved from Bitcoin to some other coins, where Bitcoin fees went higher. But then, the same problems reappeared on other chains. When it comes to the fee model, this topic is sometimes discussed, but you don't want to pay higher fees now, because some people use some trap addresses. But if you want to change your own fee rules, then it is of course possible, Bitcoin Core has only some reasonable defaults, you can change that if you have full node, and you can enforce that, if you are a miner, then you can include or exclude transactions, based on different algorithm, it is not a hard rule in the consensus, you will stay in the same network, if you will use a different fee model.