Thoughts on burner addresses

[ABCbits]

This is not about trap addresses, a.k.a. “burner addresses”.  The stated goal implies a desire to store arbitrary data, and intentionally to defeat the purpose for which, after much debate, Core kept OP_RETURN with output data as a less-harmful way to store arbitrary data.

Yeah but it all comes down to the fact that you can't enforce anything when something is an "opt-in" mechanism. Nice people might opt in but not so nice people don't have to and probably don't care at all the affects of their actions. Their actions probably do have affects. But they don't care about them.

Fair point, but there are many reason to use OP_RETURN such as
1. Less overhead compared with abusing bitcoin address which has 4 byte checksum.
2. Easier to use. On Electrum, you just need to convert text to HEX using online tools and type OP_RETURN [HEX DATA], 0.
3. Many blockexplorer decode OP_RETURN output to text automatically.

The stated goal is intentionally to force poor people in poor countries who are desperate for sound money to store and process oh-so-precious-snowflake graffiti on their <$50 nodes forever and forever.  In the UTXO set.

poor people in poor countries may not even have a computer. and i would think are less likely to be running nodes than people that are more financially well off. the poor people probably use an app on their phone when it comes to bitcoin. come on now.

It's limitation of P2P/decentralized system where you need to verify and store some/all data. But Bitcoin community already being conservative about cost of running node.

[larry_vw_1955]

i don't ever want to one day be trying to consult a blockchain explorer and it won't show me some of my old transactions because it pruned them.

Then run your own node.

Running a bitcoin node is intensive. You not only have to have a very large 500GB or so download but you also have to sync up all the time. Now would you be willing to perform that action for every single cryptocurrency that you use? Of course not. Because you would need a bazillion hard drives.One for solana, one for ethereum, the list goes on and on. It would become a full time job just keeping all your blockchains up to date. Hopefully none of the hard drives crashed because if it did you have to download another 400GB.

No one is required to run a full node instead of a pruned node because you want them to.

Anyone can do what they want to but it would seem to me that pruning takes away your ability to look up and even construct transactions of your own. So it's not even really a useful thing for someone like me. If you have to consult an external bitcoin explorer website to get transaction data then what's the point of running a pruned node at all? It's not going to be trustless.

Although it's probably worth pointing out that any blockchain explorer which prunes all transactions from x number of blocks ago would be useless to most users and would receive very little traffic.

Exactly. Useless to people because you can't look up transactions. You can't really do anything. Except verify transactions or something. Helping the network as they say.

the poor people probably use an app on their phone when it comes to bitcoin. come on now.

Maybe. Or maybe they actually care about the core principles of bitcoin and want to be able to verify transactions and blocks themselves and not have to trust third parties to do it for them.

Maybe but I'll be honest, the last thing I would want to do if I was having trouble putting food on the table is running a bitcoin node. How would it help me?

Exactly. There were many altcoins, where people thought that "someone" will run a full node. Guess what: in some cases nobody did, and then there were cases, when it was no longer possible to create new full nodes, because all nodes were prunned, so it was no longer possible to do initial blockchain download.

So isn't that an argument against pruning?

After thinking more about that, you will understand, why storing large data on-chain is not a good idea. Then you will start to think about the opposite case: data compression, and making initial blockchain download easier, to make it more decentralized, and to encourage people to maintain the network.

No I still think that pruning leads to no one eventually having the entire blockchain. Just like you mentioned happened to "many altcoins".

Poptarts come in 13 flavors these days. Hard drives are larger than 20TB.

[o_e_l_e_o]

Running a bitcoin node is intensive.

So why do you want to remove the ability for people to run a pruned node if they cannot manage to run a full node?

Now would you be willing to perform that action for every single cryptocurrency that you use? Of course not.

That's exactly what I do. Bitcoin and Monero.

One for solana, one for ethereum, the list goes on and on.

Or maybe just don't buy centralized scam coins. Running a Solana node is pointless since the whole thing is completely centralized anyway.

Anyone can do what they want to but it would seem to me that pruning takes away your ability to look up and even construct transactions of your own.

It doesn't. You simply set up your wallet in advance, and Core will keep all the transactions relevant to your addresses after it starts to prune old blocks. A pruned node can still validate new blocks and transactions, keep your wallet up to date, and let you create transactions.

So it's not even really a useful thing for someone like me.

So then run a full node. Again, you don't get to dictate to other people what kind of node they are or are not allowed to run.

Exactly. Useless to people because you can't look up transactions. You can't really do anything. Except verify transactions or something. Helping the network as they say.

"Except verify transactions or something", as if being able to verify things for yourself isn't a core tenet of Bitcoin. And as above, a pruned node will quite easily let you look up transaction relevant to your wallet(s) - it just doesn't store everyone else's transactions too.

[vjudeu]

pruning takes away your ability to look up and even construct transactions of your own

No, you can create any transactions with Bitcoin Core, even if you are offline, and if you don't have the blockchain downloaded. You can also create and sign invalid transactions, creating coins out of thin air. It is possible from the software perspective, but then, the network could reject that.

If you have to consult an external bitcoin explorer website to get transaction data then what's the point of running a pruned node at all?

You don't have to. If you have some pruned node, then you validate everything. The only problem is that you cannot use your node to introduce other people into the network, because your blocks are pruned.

Exactly. Useless to people because you can't look up transactions. You can't really do anything. Except verify transactions or something. Helping the network as they say.

You can "verify transactions or something". And that "something" is still a lot. For example, you know exactly, who owns what, and on which output each coin is located.

[BlackHatCoiner]

Running a bitcoin node is intensive. You not only have to have a very large 500GB or so download but you also have to sync up all the time.

No, you don't, that's required only if you want to run a non-pruned full node. You can just sync and verify everything without storing all the blocks and therefore, you can run a full node with only few gigabytes of space, which is pruning, that's told to you a page now.

Exactly. Useless to people because you can't look up transactions.

You can't look up transactions of other people, but you can look up your transactions, which is the only thing that matters if you make personal use.

What's your problem exactly? I don't understand.

[larry_vw_1955]

Running a bitcoin node is intensive.

So why do you want to remove the ability for people to run a pruned node if they cannot manage to run a full node?

I was just talking about reasons I personally can't run a full node. I don't have 500GB of empty disc space to allow it to use. And I'm not going to crack open an ssd just for that purpose. sorry.

Now would you be willing to perform that action for every single cryptocurrency that you use? Of course not.

That's exactly what I do. Bitcoin and Monero.

I'm a light user of bitcoin. A light user of Litecoin, eth, solana. Since I don't using them to do transfers every day or even every month. I could go 6 months without doing a transfer. I can't justify running a node for any of them based on that. But that's my own situation. yours might be different.
 

Or maybe just don't buy centralized scam coins. Running a Solana node is pointless since the whole thing is completely centralized anyway.

I don't really care about solana's setup. I just use it from time to time if I can collect a small payment here and there. Send it to coinbase for next to nothing without having to "time" my transaction for when the mempool is running empty. I won't pay any fee. Solana just happens to be a useful tool like LTC since it has very low fees all the time. I don't care about anything else. I don't care if solana goes offline from time to time as long as it doesnt' happen when i need to use it. And if it is offline, it probably wont be offline for more than a day and then i can cash out. the benefits vs downsides you have to weigh them and decide which one outweighs the other.

Anyone can do what they want to but it would seem to me that pruning takes away your ability to look up and even construct transactions of your own.

It doesn't. You simply set up your wallet in advance, and Core will keep all the transactions relevant to your addresses after it starts to prune old blocks. A pruned node can still validate new blocks and transactions, keep your wallet up to date, and let you create transactions.

How do you "set up your wallet in advance" with all the bitcoin addresses you control?

Exactly. Useless to people because you can't look up transactions. You can't really do anything. Except verify transactions or something. Helping the network as they say.

"Except verify transactions or something", as if being able to verify things for yourself isn't a core tenet of Bitcoin. And as above, a pruned node will quite easily let you look up transaction relevant to your wallet(s) - it just doesn't store everyone else's transactions too.

I'm not so sure about that. It has no way of knowing what addresses are relevant to me so how would it know what transactions I am interested in?

That means pruned node isn't suitable for your use-case.

No its probably not. The way I see it is if I can afford to download the entire blockchain initially then i  can afford to keep it on the hard drive.

No, you don't, that's required only if you want to run a non-pruned full node. You can just sync and verify everything without storing all the blocks and therefore, you can run a full node with only few gigabytes of space, which is pruning, that's told to you a page now.

yeah but you have to always be syncing up or else your copy of the blockchain becomes outdated. meaning it doesnt contain the latest blocks and transactions. everyday you need to sync up. otherwise when you do try and sync up the sync process is going to be longer. to make up for the days you didn't sync up. just how it is. not saying its undoable but i don't like the idea of having to do that. even electrum wants to download a crap ton of blockheaders which i find to be not so nice because it just takes over my network connection. holds it hostage until it finishes doing its thing. (someone mentioned using electrum as alternative but for that reason it's not)

You can't look up transactions of other people, but you can look up your transactions, which is the only thing that matters if you make personal use.

How does bitcoin core know me vs "other people"? How does it know which transactions are mine and which are "other peoples"?

What's your problem exactly? I don't understand.

Well for example, say I have a multisig address I want to spend out of. And do it using bitcoin core. that was one of my things I didn't know if it was possible. without downloading the whole blockchain. or consulting an external blockchain explorer to get transaction informations.

[vjudeu]

I was just talking about reasons I personally can't run a full node. I don't have 500GB of empty disc space to allow it to use. And I'm not going to crack open an ssd just for that purpose. sorry.

So why you think that using "trap addresses" is better than OP_RETURN? Why do you want to make it harder for other people to run their nodes?

How do you "set up your wallet in advance" with all the bitcoin addresses you control?

Just use "createwallet" or create it from graphical interface.

I'm not so sure about that. It has no way of knowing what addresses are relevant to me so how would it know what transactions I am interested in?

It does not have to know "what addresses are relevant". It can validate new transactions, so that's all you need. It also knows about all transactions that you rescanned (if you have prunning enabled) or validated during initial blockchain download (then no rescan is needed), so it knows that.

even electrum wants to download a crap ton of blockheaders which i find to be not so nice because it just takes over my network connection

Each block header has 80 bytes. So heavy, isn't it? If you have one million block headers, it means 80 MB. For all block headers, from many years (we have 2022, and we are currently below one million blocks). Not to mention that each block header has a field called "previous block header", and you don't need to download it. So, you can take 32 bytes, and reach 48 bytes per block header. So it means 48 MB per one million block headers, if you compute block hashes on your own, instead of downloading them. And you can go further: you can compress timestamps by storing them as offsets, then you can use two bytes per timestamp, and you will cover around 30k seconds forward and backward, so that means 500 minutes forward, and 500 minutes backward. If we have 10 minutes per block, then I think VarInt or some UTF-8-like compression could shrink it quite nicely for you. So, after using aggressive optimizations, I think you could reach something like 40 bytes per block header. So heavy, how could you handle that? Not to mention that you don't have to store all of those headers, you can process them once, and then store only the last N block headers since then.

How does bitcoin core know me vs "other people"? How does it know which transactions are mine and which are "other peoples"?

If you enable wallet functionality before syncing, then it knows that by knowing which private keys you have (and which public keys or addresses you observe). Anything else is "other peoples".

Well for example, say I have a multisig address I want to spend out of. And do it using bitcoin core. that was one of my things I didn't know if it was possible. without downloading the whole blockchain.

Without downloading the blockchain? Yes, of course it is possible. Just use console and execute "createrawtransaction", then "signrawtransactionwithwallet" (or "signrawtransactionwithkey").

or consulting an external blockchain explorer to get transaction informations

You can create and sign any transaction. If it will be incorrect, the network will reject it. If you don't know, which coins are yours, then, well, you don't know if you really own any coins at all.

[o_e_l_e_o]

I was just talking about reasons I personally can't run a full node.

And you still don't get to dictate what kind of nodes other people run. If you can't be bothered to run a full node for yourself, no one else is under any onus to run a full node for you. Luckily there are plenty of people who do, and also run blockchain explorers, or Electrum servers, or all the other infrastructure you take for granted. But if some of those people want to run a pruned node for their own use only, there is absolutely no onus on them to run a full node for your benefit. And since you are never going to connect to someone else's pruned node, then you don't care if they store the details of your transactions or not. Which leads us back to burner addresses. Every server or blockchain explorer you connect to will be running a full node, which will have all the details of your transaction, whether or not you have sent coins to a burner address or an OP_RETURN output. So there is absolutely no need to bloat the UTXO set when you can use OP_RETURN outputs instead.

How do you "set up your wallet in advance" with all the bitcoin addresses you control?

I'm not so sure about that. It has no way of knowing what addresses are relevant to me so how would it know what transactions I am interested in?

It's really very simple. Download Bitcoin Core, create a new wallet, and either generate new addresses, import private keys or addresses which contain your coins, or both. Then start syncing the blockchain with pruning enabled. Whenever it finds a transaction related to one of your addresses, it will store that transaction even after it prunes the rest of the block that transaction was included in. The end result will be a synced node with the last x GB of blocks stored (x being whatever you set it to), but with every transaction related to one of your addresses also stored. You can't look up other people's transactions, but you can look up all the ones related to your addresses.

[larry_vw_1955]

So there is absolutely no need to bloat the UTXO set when you can use OP_RETURN outputs instead.

Right. So they ought to enforce that behavior but the problem is they don't know how. Because how do you tell the difference between someone storing data and someone storing bitcoin?

It's really very simple. Download Bitcoin Core, create a new wallet, and either generate new addresses, import private keys or addresses which contain your coins, or both. Then start syncing the blockchain with pruning enabled. Whenever it finds a transaction related to one of your addresses, it will store that transaction even after it prunes the rest of the block that transaction was included in. The end result will be a synced node with the last x GB of blocks stored (x being whatever you set it to), but with every transaction related to one of your addresses also stored. You can't look up other people's transactions, but you can look up all the ones related to your addresses.

Assuming it works that way for any address type I might throw at it then great. As you point out, it does have its limitations in the sense that you can't look up other peoples' transactions so if you needed to do that then you have to trust a 3rd party. Seems like alot to give up just to save some disc space. But I guess to each their own...

[vjudeu]

Right. So they ought to enforce that behavior but the problem is they don't know how. Because how do you tell the difference between someone storing data and someone storing bitcoin?

Easy. If someone is storing data, then that person could use OP_RETURN or witness data for that. Also, that person could use testnet, instead of bloating the mainnet. Or even that person could just commit to data, and store them on another chain, no chain at all, or anything, to get it timestamped by Proof of Work, commitments are enough. And commitments require no additional on-chain bytes, they can be attached to any existing transaction, before it will be broadcasted. Using "trap addresses" is the worst case, because there is no reason to do so. Also, it is more expensive than witness or OP_RETURN.

As you point out, it does have its limitations in the sense that you can't look up other peoples' transactions so if you needed to do that then you have to trust a 3rd party.

You don't have to trust anyone. You can use "importprunedfunds". You can ask any full node operator to execute "gettxoutproof" for you.

[larry_vw_1955]

Right. So they ought to enforce that behavior but the problem is they don't know how. Because how do you tell the difference between someone storing data and someone storing bitcoin?

Using "trap addresses" is the worst case, because there is no reason to do so. Also, it is more expensive than witness or OP_RETURN.

And yet the bitcoin protocol allows us to send funds to "trap addresses". This costs a fee. So the network is compensated for it. The network will then store this utxo for as long as it takes until the utxo is spent. That is how bitcoin works. The utxo might never be spent. That's part of the bitcoin protocol. The transaction fee was meant to pay for storage in the utxo set.

Now are you suggesting that utxos that are older than a certain number of blocks be purged from the database or sent to some intermediary storage where they won't pollute the utxo set for any longer? If so, maybe you can create a BIP for that.

I do understand why people get upset when people don't use OP_RETURN in favor of burner addresses but they're not arguing from a very leveraged position when they do that...meaning the bitcoin protocol allows for it. And they're saying please dont do it. So basically you're telling people how to use their money. it is their money and they should be free to spend it anyway the bitcoin protocol allows.

The worst thing is when people try and say "dont do this and dont do that because it's bad for bitcoin" when bitcoin itself allows it.

So why you think that using "trap addresses" is better than OP_RETURN?

you're asking me why I personally think that? not a big fan of op_return since "Many members of the Bitcoin community believe that use of OP_RETURN is irresponsible in part because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data" not a big fan of trap addresses either since i'm not the type of person to set fire to a $100 bill.

Why do you want to make it harder for other people to run their nodes?

Do you think it would be fair for someone running a business to curse out a customer that comes in the door 5 minutes before closing complaining that they are tired and don't want to help them? No they have to suck it up and keep their own personal issues in the rear with a smile on their face. And if they don't like the way things work then talk to the company and change the closing time to 30 minutes earlier.

Just use "createwallet" or create it from graphical interface.

I wasn't looking to create a new wallet. I already had a funded multisig address. Was just needing to spend from it.

Each block header has 80 bytes. So heavy, isn't it?

I don't know man. This was a portable version of electrum and it went wild downloading blocchain headers. I think the filesize was a couple hundred megabytes before I just stopped the program and deleted that big file. I don't need that.

As you point out, it does have its limitations in the sense that you can't look up other peoples' transactions so if you needed to do that then you have to trust a 3rd party.

You don't have to trust anyone. You can use "importprunedfunds". You can ask any full node operator to execute "gettxoutproof" for you.

I'm very unfamiliar with bitcoin core as far as that goes. All I know is I used it once to create a spending transaction using a multisignature address but in order to do that I had to use a block explorer to get the transaction inputs. Because I wasn't going to download the blockchain myself. It would have been nice to be able to simply issue commands and get those things but that seemed impossible.

[BlackHatCoiner]

it is their money and they should be free to spend it anyway the bitcoin protocol allows.

Of course, but they try to do something in an incorrect manner thinking that they're correct. You don't burn coins if you send them to any valid bitcoin address, you may trap them, but you don't burn them.

The transaction fee was meant to pay for storage in the utxo set.

And that's why an OP_RETURN transaction costs less than a "trapping" transaction.

The worst thing is when people try and say "dont do this and dont do that because it's bad for bitcoin" when bitcoin itself allows it.

Yes, it's personal responsibility after all. If a few more users mixed bitcoin, you have no idea how more difficult it'd be for chain analysis companies to trace the chain, and therefore how better it'd be for bitcoin privacy-wise. Bitcoin itself allows more things, it doesn't mean you should do them.

not a big fan of op_return since "Many members of the Bitcoin community believe that use of OP_RETURN is irresponsible in part because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data"

Actually, that's the very reason you should be a fan of OP_RETURN, because those who would have the intention to store arbitrary data would do it either way, in an inefficient way, bloating the set with unnecessary outputs such as in this case.

[vjudeu]

And yet the bitcoin protocol allows us to send funds to "trap addresses".

We could block it, but we don't want that. It is possible to require making a valid signature before receiving something, as it is in Grin, but that would make our life harder. And still, it is impossible to prove that someone still has the keys. It is always possible to generate some keys, receive something, and then remove the keys, making coins "trapped".

This costs a fee. So the network is compensated for it.

There is a difference. If you pay your fees, and your coins are moved, then the UTXO set is not bloated, because you will sooner or later move your coins. It is possible to attack Bitcoin by sending a lot of outputs with zero satoshi (or dust amounts, but zero satoshi is more dangerous, fortunately, only miners can do that) to some trap addresses, then you can almost entirely disable pruning, just by making the UTXO set very large.

The network will then store this utxo for as long as it takes until the utxo is spent.

Which may be "never", and this is the worst case, because then each full node, pruned or not, have to always store it.

Now are you suggesting that utxos that are older than a certain number of blocks be purged from the database or sent to some intermediary storage where they won't pollute the utxo set for any longer?

No. I just think that you should not spam the blockchain for no reason, if there are cheaper and better options available.

The worst thing is when people try and say "dont do this and dont do that because it's bad for bitcoin" when bitcoin itself allows it.

You don't want to see the version of Bitcoin that will make it harder. It is technically possible, but you don't want that. But if nodes will be spammed, then the community will move into some other fee model, maybe UTXO-size-based model (then, you will get a discount for consuming UTXOs, and you will pay additionally for creating a lot of UTXOs, just to prevent spam).

Do you think it would be fair for someone running a business to curse out a customer that comes in the door 5 minutes before closing complaining that they are tired and don't want to help them? No they have to suck it up and keep their own personal issues in the rear with a smile on their face. And if they don't like the way things work then talk to the company and change the closing time to 30 minutes earlier.

I think you don't want that "change the closing time to 30 minutes earlier". Here, it could be a different fee model, and I think it could be more expensive to spam the UTXO set then. And you don't want that, because it could also hit some website that want to allow withdrawing coins by making one huge transaction with large number of outputs, one output per user. By spamming the network, people will make developers and node operators angry, and the network will change the fee model to prevent spam. You don't want that.

It would have been nice to be able to simply issue commands and get those things but that seemed impossible.

Technically, it is possible. Many things are implemented now in the console version, many things are "to be implemented in the graphical interface", and many things can be added to that console version. Things are ongoing, it is just a matter of writing more code to cover those cases.

[ABCbits]

Using "trap addresses" is the worst case, because there is no reason to do so. Also, it is more expensive than witness or OP_RETURN.

And yet the bitcoin protocol allows us to send funds to "trap addresses".

Your statement is misleading. Bitcoin protocol only check whether the address is valid or not.

So why you think that using "trap addresses" is better than OP_RETURN?

you're asking me why I personally think that? not a big fan of op_return since "Many members of the Bitcoin community believe that use of OP_RETURN is irresponsible in part because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data" not a big fan of trap addresses either since i'm not the type of person to set fire to a $100 bill.

You forget to quote this part, "Despite this, OP_RETURN has the advantage of not creating bogus UTXO entries, compared to some other ways of storing data in the blockchain."[1].

Each block header has 80 bytes. So heavy, isn't it?

I don't know man. This was a portable version of electrum and it went wild downloading blocchain headers. I think the filesize was a couple hundred megabytes before I just stopped the program and deleted that big file. I don't need that.

If it's that big, it's likely you imported wallet with lots of transaction. Besides block header, Electrum also download merkle proof to prove the transaction on block[2]. It's cost when you don't want to blindly trust someone else.

[1] https://en.bitcoin.it/wiki/OP_RETURN
[2] https://electrumx.readthedocs.io/en/latest/protocol-basics.html#block-headers

[larry_vw_1955]

Your statement is misleading. Bitcoin protocol only check whether the address is valid or not.

The only way to know if an address is valid or not is to know a private key for it. Dont know that? Then you don't know if its valid address. When you use the word "valid" what you mean is just passing a simple checksum test which doesn't prove anything. I think you would be making a leap of faith to then conclude that just because it has the right "format" therefore a private key does indeed exist. maybe a small leap of faith but nonetheless still a leap of faith...

You forget to quote this part, "Despite this, OP_RETURN has the advantage of not creating bogus UTXO entries, compared to some other ways of storing data in the blockchain."[1].

I didn't forget that part, it certainly is true but what do you think about this:

On OP_RETURN: There was been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain.


And then this:

Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.

So they seem to be saying go ahead and misuse bitcoin to store data if you like we dont want you to but if you do then op_return works best. it's like they caved into the demand to store data by offering op_return but then chided people for considering to use it anyway. I bet satoshi wouldn't have been too excited about people using op_return or any mechanism to store data on chain.

If it's that big, it's likely you imported wallet with lots of transaction. Besides block header, Electrum also download merkle proof to prove the transaction on block[2]. It's cost when you don't want to blindly trust someone else.

not alot of transactions at all. maybe only 2 or 3. if that. well i thought electrum would be like a wallet that didn't need to download a huge amount of blockchain data. it's a nice software but that kind of dampered my enthusiasm for it.

We could block it, but we don't want that. It is possible to require making a valid signature before receiving something, as it is in Grin, but that would make our life harder. And still, it is impossible to prove that someone still has the keys. It is always possible to generate some keys, receive something, and then remove the keys, making coins "trapped".

But at least that way, everyone would know that someone at some point did know a private key for it. So no one would send funds to it thinking that it was a "burner address". I don't know why people send funds to popular burner addresses in the first place.

There is a difference. If you pay your fees, and your coins are moved, then the UTXO set is not bloated, because you will sooner or later move your coins. It is possible to attack Bitcoin by sending a lot of outputs with zero satoshi (or dust amounts, but zero satoshi is more dangerous, fortunately, only miners can do that) to some trap addresses, then you can almost entirely disable pruning, just by making the UTXO set very large.

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?

You don't want to see the version of Bitcoin that will make it harder. It is technically possible, but you don't want that. But if nodes will be spammed, then the community will move into some other fee model, maybe UTXO-size-based model (then, you will get a discount for consuming UTXOs, and you will pay additionally for creating a lot of UTXOs, just to prevent spam).

Unfortunately in life sometimes the good apples have to play by rules that were put in place to get control over the bad apples. But in reality when you look back on things, you realize that if this particular bad apple hadn't done something bad, another bad apple would have most likely and then you would still need the rule in place anyway.

I think you don't want that "change the closing time to 30 minutes earlier". Here, it could be a different fee model, and I think it could be more expensive to spam the UTXO set then. And you don't want that, because it could also hit some website that want to allow withdrawing coins by making one huge transaction with large number of outputs, one output per user. By spamming the network, people will make developers and node operators angry, and the network will change the fee model to prevent spam. You don't want that.

that's kind of an edge use case wouldn't you think? sending a large # of outputs in a single transaction. not what most users are doing. no one made the ethereum devs and node operators angry and look what happened to their fee situation. it went through the roof. no one wanted that but it happened. what happens when they can't get it right as far as the fee goes is people seek alternatives.

[vjudeu]

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

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.

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.

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.

[hZti]

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.

I never liked the argument that people have no reason to do a specific thing so it means that they will not do it. People can have reasons that are not understandable at this point, so if it is possible it means that there is a chance that it will be done in the future. Also if the block size is bigger there is no reason for miners to spam transactions since they would harm the network they are heavily invested in. But as I said this argument is not really valid.

[garlonicon]

Also if the block size is bigger there is no reason for miners to spam transactions since they would harm the network they are heavily invested in.

The bigger the max block size is, the more spam they could put in a single block. And that "heavily invested in" part may apply to Bitcoin, but definitely not to some altcoins, that are mined, and then exchanged into Bitcoin, just because mining altcoins and selling them is often more profitable (as long as mining is not fully decentralized, and as long as miners rely on centralized pools). Another thing is that if someone doesn't like some altcoin (like BSV, because of Craig), then that kind of spam can be always executed to make it even more centralized, and put even more weight on a few nodes that keeps the whole thing alive. Also, when the block size is not limited, then miners could generate that spam in a deterministic way, then the cost of storage is quite low for the attacker, but quite high for all other nodes, because they cannot compress data, without knowing the seed that was used to generate spam.

But as I said this argument is not really valid.

As always, it is a matter of choice. As vjudeu said, it is technically possible to prevent that spam, but the question is "should we?", because then some problems will vanish, and other problems will appear. Also, miners can do many things, that are far beyond what non-miners can do, but they don't, because they don't know how, or because they don't want to risk their block reward by mining some invalid block. And there is a distinction: user-based spam is one thing, it can be prevented on node-level, even without touching consensus, just by changing how minimal fees are calculated. Another thing is miner-based spam, this is harder to prevent, because it requires a soft-fork, to make that spam "invalid by consensus", and that sounds quite dangerous, and definitely should be heavily tested on user-level first.

[hZti]

Also if the block size is bigger there is no reason for miners to spam transactions since they would harm the network they are heavily invested in.

The bigger the max block size is, the more spam they could put in a single block. And that "heavily invested in" part may apply to Bitcoin, but definitely not to some altcoins, that are mined, and then exchanged into Bitcoin, just because mining altcoins and selling them is often more profitable (as long as mining is not fully decentralized, and as long as miners rely on centralized pools). Another thing is that if someone doesn't like some altcoin (like BSV, because of Craig), then that kind of spam can be always executed to make it even more centralized, and put even more weight on a few nodes that keeps the whole thing alive. Also, when the block size is not limited, then miners could generate that spam in a deterministic way, then the cost of storage is quite low for the attacker, but quite high for all other nodes, because they cannot compress data, without knowing the seed that was used to generate spam.

Yes it is true that on some alt coins this could be a problem but to be honest most of them are completely worthless and only have a value because people try to rip off other people. With bitcoin a bigger block size would lower confirmation time and therefore make it more usable in everyday live.

[garlonicon]

With bitcoin a bigger block size would lower confirmation time and therefore make it more usable in everyday live.

I don't think we will ever need to increase block size. I think we should implement transaction joining instead, and make things more compressed, because that's what scaling is about: scaling is simply doing more things with the same resources, so if we could handle 2x more transactions by compressing A->B->C->...->Z transaction chains into a single A->Z transaction, that would be "scaling". And then, "lower confirmation time" will come naturally, because then transactions in mempools will be joined on-the-fly by miners, so more of them will fit in a single block.