Bitcoin Forum

I recently found this address: https://mempool.space/de/address/1111111111111111111114oLvT2 (https://mempool.space/de/address/1111111111111111111114oLvT2) I researched it and I found out that it is used as a proof of burn address. What are your thoughts of it?
In my opinion it does not make sense, since the value is destroyed and not transferred to the other project even if it might seem like it in the first place. Also there could be an option built into the bitcoin network to burn coins, but actually insert them into blocks to be redistributed to the miners. What are your thoughts on this?

Where is it used as a Proof of Burn? I only know 1Counterparty[1][2] that does it.

It does make sense. The value is destroyed from the Bitcoin network, but that's the condition for the other coin to create circulation. You can't have as much as you want, because you can't fake your bitcoin's burning, nor can you double-spend. It's a brand new coin that depends on bitcoin.

What doesn't make sense is to buy it.  :)

Transaction fees!  ;)

---

[1] https://counterparty.io/get-started/
[2] https://mempool.space/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr

My thoughts are that you are very new and you get confused by things already discussed.
Oh well, it's still one way to learn :)


Lost and burned coins do have a good meaning: make everybody's coins more valuable. As Satoshi himself said:



Burning coins and redistributing coins are completely different things.
Burning means making the coins completely gone. Those addresses' keys will never be found.
Redistributing coins means still keeping them in circulation.

There was a discussion somewhat related to this not long ago, maybe this link is in the right direction: https://bitcointalk.org/index.php?topic=5398949.msg60214879#msg60214879 (or a few posts before)
From my understanding, you can easily make transaction that sends nothing to nobody (OP_RETURN) and instead send the funds as miners' fee only.
Or, possibly, you can (also with OP_RETURN) lock completely some funds.

So imho there are in-built functionalities, just the people don't really know how to use them.
And many find it more "cool" to send pennies to Satoshi's address, to 1111111111111111111114oLvT2 or to 1BitcoinEaterAddressDontSendf59kuE.

Im here one year longer than you  :o

But still in my opinion it does not make sense to burn the coins. If they get redistributed to the miners then they would also be lost to the people that "burned" them but are not lost to the network. The other coins that you get for the "burned" coins can't benefit in any way if the coins are not redistributed, since if they get redistributed also you can only buy the same amount of coins.

Here are the informations I found: https://bitcoin.stackexchange.com/questions/70241/whats-with-this-address-1111111111111111111114olvt2

It makes perfect sense.

People that send their coins there have their reasons. Those coins are lost forever. There's no need to do anything about these coins in Bitcoin.

It's similar to throwing a coin into an unreachable space, it's lost forever.

This reminded me of my favourite burner address: 1BitcoinEaterAddressDontSendf59kuE

Here you can read a lot of articles about it: https://allprivatekeys.com/btc/1BitcoinEaterAddressDontSendf59kuE

O M G.
1. Apologies.
2. No offense, but under what rock where you hiding? I mean, you're not asking about anything new...


Well, as said, to the rest it does make sense, for various reasons - from proving something to making some addresses of theirs "seen" or leaving on-chain messages to posterity, or simply getting rid of something they consider too small value.


That's correct. However, in some/many cases the goal is different. If they just don't need the (dust) coins they can simply leave them untouched forever in their own wallet.


This part I didn't really get, sorry. There are various motifs behind burning coins and I may have not understood good enough your use case.
I will only tell that for example Binance is (more or less) regularly burn a fairly big amount of BNB just to make the other coins more scarce (i.e. more expensive).

No worries haha, I was under the same rock that satoshi is still sitting under  ;D


Well as far as I understand people burn their coins in many cases to be able to have the right to receive an altcoin. If they "burn" it by sending it to an address that nobody has the private key, they can get for example 10 Altcoin for 10 BTC. If now they would send 10 BTC to an address that just redistributes the BTC they would still only get 10 Altcoin.
I can see the argument that you really want to burn the coins to make bitcoin more scarce but in my opinion the amounts are way to little for it to have an impact on the network.
Also of course there are reasons why people would really want to burn their coins, but I don't really see that reason if you only want to have the right to get Altcoins. But I get it that many people would see that differently.

In that case, indeed, there are better ways.

For example, I remember Byteball was using a bot that was requesting people sign a message (message the bot was sending) with the private key of the Bitcoin address. Then that one was getting the same amount of altcoin as the number of Bitcoin in that address.
No coins are lost and ownership is also proven. A nicer and smarter approach imho.

But, they supposedly do benefit in some other way. That's why altcoins exist. They supposedly do something bitcoin can't do, and a mechanism to prevent double-spending is Proof-of-Burn.

That's a bad analogy, because you can't prove you've burnt it, and burning bitcoin makes sense only if you're able to prove it.

Note that sending coins to perfectly valid addresses, such as 1Counterparty, doesn't necessarily mean they're removed from circulation. There are more than 79 octillion private keys, on average, that can unlock these outputs.

For provably burning, use OP_RETURN.

1Counterparty currently has 2,130.96 BTC. That's 0.01% of the total circulation. It does have a little impact, and that's just from counter party.

Why does that make it more provable? As far as I know this just adds am Message to the transaction?

And it doesn't make sense to throw money in to wells, fountains, or other water features in order to "make a wish", and yet people do it probably tens of thousands of times a day all over the world. Ultimately, such is the beauty of bitcoin. Your coins are yours and yours alone, and you can use them however you wish. If you want to burn your coins then you are free to do so, even if everyone else thinks it's a stupid idea.

Also worth pointing out that coins in such addresses are not provably burned. They could still be spent in the future, if someone either stumbles across the correct private key or if the ECDLP and hash functions are broken and someone can reverse engineer a necessary private key for one of these addresses. Only coins which are sent to unspendable outputs, such as OP_RETURN, are provably burned.

Because an OP_RETURN script cannot be unlocked, and so these coins cannot be spent. Coins in burn addresses can be unlocked by one of the correct private keys, it is just that no one knows what those private keys are.

Well my whole point was, if it may be that people burn their coins maybe because the bitcoin network does not offer an address that does not lock the coins but redistributes them. But I guess it would be to difficult to implement such an address now in the network for a quiet little use that it would offer.


Ok that makes sense.

The question would be - redistributes them to whom? You can't redistribute them to everyone since there would not be enough coins to go around. Provably burning coins such as with OP_RETURN outputs is the only way to effectively redistribute them to everyone, by making everyone else's coins equally more rare and therefore equally more valuable.

If you want to redistribute them to miners, then as above, just add them all to the fee of your transaction. Alternatively, if you want to get rid of them then you could gift them to a charity or project which accepts bitcoin, such as Tor, Tails, Wallet Scrutiny, mempool.space, or the devs themselves.

Bitcoin protocol simply doesn't have mechanism to redistribute your coin. Some altcoin have redistribute mechanism under certain condition (e.g. coin not moved in 3 years), but there's concern how should it works and who should receive it (all non-empty address, miner, master node, etc.). For Bitcoin, you need to do it by yourself.

I know I have said this before but that is not 100% true / proven.
With some of these addresses:
We *assume* that due to the math that nobody has the address.
We can prove that to generate the address through brute force cannot be done before the sun goes nova and destroys the Earth.
We CANNOT prove that nobody has it.

You can't prove a negative. And there is always the 2^160 to 1 chance (close enough to zero to be zero but still not zero)that someone has one of them.

Sorry it's just one of those things that I think should be out there.

-Dave

There is no good reason why you should give miners any coins for free, and burn addresses is a good concept in my opinion.
It's the similar thing like if you wanted to burn and destroy paper money for any reason, making it unusable in future, we have same thing here with Bitcoin.
This only makes Bitcoin more valuable because it reduces real circulating supply of coins and it increases value and demand for Bitcoin.

Not only that but that someone will end up cracking to get the cash if the balance gets too big. The chance of that is probably even bigger.

It is not possible to "crack" a bitcoin address. Besides, if anyone wanted to waste their time on an impossible task they would have chosen one of the existing addresses with large balance instead of a burn address that would have far less.
For example 1P5ZEDWTKTFGxQjZphgWPQUpe554WKDfHQ contains about $4 billion worth of bitcoin.

There are two nice ways to burn coins: the user-based way is called OP_RETURN, but there is also miner-based way: it is possible to just claim less coins in the coinbase transaction. Then, they are burned, and chain reorganization is the only way to get them back into the circulation. When it comes to burning, my favourite way is the miner way, because it has no trace in the UTXO set for all clients, just because there is no output that can be used to show that "here are some burned coins".

I think the miner way is a bit different though, as the coins were never generated in the first place. The coins were not technically burnt, they just never existed, a potential not realized. Also, not many people are in that position, you need to be a lucky miner.

But yeah, burning coins with OP_RETURN is great because the outputs are provably unspendable, which is not the case when sending coins to a 1BitcoinEater address.

Although I can see how some users might prefer burning coins by sending them to those addresses, it's a bit like throwing a coin into a fountain kind of thing. Also I'm sure some wallets don't provide the ability to run script, so sending to a 1BitcoinEater address might be the only option for some.

You can burn existing coins, just by sending them as a fee, and then simply not taking them in the coinbase transaction. So yes, you can also burn existing coins in this way.

As already said (just you didn't bother to read), burning coins means getting the amount out of circulation forever.
If you send them as fee, they are spent (you no longer have them), but not burned (since the miners receive the fees too, it's considered still in circulation).

You are somewhat right, since the link is broken between the spender and the receiver (miner), hence they don't receive the exact same coins (input).
But the term "burning" is used for amounts no longer in circulation, not necessarily inputs.
This is how I see it.

I mean, miners can burn existing coins in this way. For users, there is OP_RETURN. So, if a miner will send a transaction, and will put some coins as a fee, then the same miner can simply take less amount in the coinbase transaction, then those fees will be burned. That's why miner-based burning is not limited only to the new coins.

OK, this is an interesting approach. Not such a common practice, but it is possible; actually I think that there were some coins burned (kind of) like this - most probably due to miners' mistakes while experimenting.

I meant that using burner addresses like the bitcoineater one, no one really knows if someone possesses the private key to it or not. you don't expect that anyone knows it but you don't know exactly how they came up with that address so you can't really say for sure. as more bitcoin comes into the "burner address" and none of it ever gets sent out, you get more confidence that maybe it really is the case that no one knows a private key for it. but you aren't sure 100%. i wouldn't trust a burner address. unless i was the one that made it up. but then other people couldnt trust me. so it's like a circular problem that can't get resolved.


Well I don't think that's how people go about trying to crack bitcoin addresses by picking a particular one. But that address would certainly be one they would want to know about. But why is someone using a legacy address to hold that much BTC? That seems risky. In the sense that it's an all or nothing proposition. Lose your private key or if someone else gets your private key, it's all gone.

It is unlikely. Very unlikely. Like there is a 1:2^160 chance that someone has it.

Simple, for legacy addresses just take some 160-bit number, and encode it in base58. For example, if you use all zeroes, you will get "76a914000000000000000000000000000000000000000088ac", so it will be 1111111111111111111114oLvT2. Then, you can change "0000000000000000000000000000000000000000" to something else. You just have 20 bytes, so let's use "username@example.com", in UTF-8 it will be "757365726e616d65406578616d706c652e636f6d". So, the script would be "76a914757365726e616d65406578616d706c652e636f6d88ac", then after using decodescript in Bitcoin Core console again, we will get 1Bi2JKSzSMosNFLGqm5SdDEzxUhsCAry9t.

Also, you can also do it in another way, you can put it explicitly in the address. You just need base58 encoding. So, you can use those characters: "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz". You take some of them, and form some name, like "1AmGar1oniconAndThis1sMyBurnAddress". But it is a bit too long, however, still we can reach something. For example this one: 1AmGar1oniconAndThis1sMyBurnAknqFh. Some last characters have to be changed, because there is a checksum, but playing with https://learnmeabitcoin.com/technical/base58 and Bitcoin Core should give you any burn address you want.

But still, I prefer miner-based burning, because then there is no address, there is no additional UTXO, everything is burned without leaving any overhead on-chain, just less coins are taken in the coinbase transaction, and nobody can get them back, without re-mining the whole chain from that point.

Why not? If miners will be paid for burning coins, then I think they will have an incentive to do that. Some people thought about Proof of Burn, it is definitely possible to encourage miners to burn some coins, if they could be rewarded somehow for doing that. And burning coins in Proof of Burn should be done as garlonicon said, then it is clearly connected with mining, and no additional outputs are needed, so it requires no additional on-chain bytes.

I can also imagine that waiting 100 blocks may be inconvenient, so some miners could agree to mine a specific coinbase transaction on behalf of some user, just to receive some coins on-chain, that could be spent immediately. Also, because miners include transactions, it may be possible to do that atomically, like "I will give you those coins, only if you mine any coinbase transaction for me".

Then that is a different argument than "cracking the address".
You are right, there is no proof that the burn address is not-generated using a private key regardless of how unlikely it is. But that is still not called "cracking" since the creator would already have the key.

Because it is 100% secure as long as the key was generated correctly (used a strong random generator) and kept safe.

Nobody can "get your key" as long as you are protecting it correctly. Besides if you are incapable of protecting one key, you are not going to be able to protect multiple either.

It's precisely that - in this day and age, a sane miner would never burn fees or rewards - they would take the maximum amount possible, given the equipment and electricity costs. So this method of burning cannot be counted on to be utilized.

A sane miner wouldn't do it deliberately, but perhaps accidentally.

The reward of block 501726 (https://blockchair.com/bitcoin/block/501726) was failed to be claimed. In block 124724 (https://blockchair.com/bitcoin/block/124724), the miner destroyed 0.01000001 BTC, 0.01 in fees and 1 sat in block subsidy. The person who solved block 526591 (https://blockchair.com/bitcoin/block/526591) chose to reward himself with half the block subsidy. Genesis block does also burn coins, for a reason, yet, unknown.

No sane person, generally, burns coins purposefully.

I would also point out that sending to a "burner" address will increase the size of the UTXO set, while an op return transaction will not. So sending to a "burner" address will make it more expensive for everyone to run a full node.

---

I have generated the address bc1q3lj2xv859lf5a8jqk60lhev4czd590tue7qjjg and have access to the private key. Mathematically speaking, the chances that I have the private key associated with the above address is the same that I have the private key to any other arbitrary address that is valid.

If someone generated a private key, and calculated the associated address, they could tell people to send coin to that address to "burn" said coin. OTOH, if someone were to randomly generate a valid address in a way that does not involve generating a private key, it can generally be safely assumed that no one has access to the associated private key, if in fact the address was generated in a random way. The problem is that it is not possible to know if someone generated the private key or if they generated a random, valid address.

I wouldn't say the reason is unknown. The coinbase transaction from the genesis block is not entered in to the UTXO set, and so it cannot be spent, as any transaction trying to spend it would be rejected as nodes cannot locate the input.

Unless you mean the reason Satoshi did this? Likely just an oversight.

---

Just to add something else to the discussion: There are provably unspendable burn addresses which are not OP_RETURN outputs. The largest one I am aware of, which contains 2,609 unspendable bitcoin, is here: https://blockchair.com/bitcoin/address/s-272edf45031dd498e7b3ae89e11ff21b. This address requires a pubkeyhash of 0 to be unlocked, which cannot be reached from RIPEMD-160, and so these coins cannot be spent.

I think numbers selected in a "nothing up my sleeve" way can be "trusted" in general. But of course using OP_RETURN is cheaper. And the cheapest is miner-based burning, because then it takes zero additional on-chain bytes, so it is possible to put more transactions, and get (or burn) more coins, so it is more effective. I think if people want to introduce Proof of Burn as a consensus rule, then it should be done on a mining level.

The reason may be that nobody else could have a chance to mine that. Or another reason is that starting from an empty database is obvious way of starting the chain. Also, people assume that the first address belongs to the creator, in theory Satoshi could release it, so that someone else could mine that (with the same newspaper text), but then everything was on so early stage, that there was no reason to put someone else's address here, that could make it easier to attack later, by claiming that someone is Satoshi, because that person was lucky enough to mine the Genesis Block. Also, making the Genesis Block spendable could make people think that Bitcoin had a premine of 50 BTC. Fortunately, it is not the case. Also, it means that 21 millions are initially reduced by 50 BTC, because it is counted in the halving schedule (that is clearly visible also in regtest, after mining all coins locally).

I cannot think of a way that it would be possible to prove to an arbitrary third party that you generated an address at random, without generating the associated private key.

OP_RETURN transactions are really the most appropriate way to "burn" any coin that you "need" to be burned. Based on current consensus implementations, this coin cannot be spent. Implementing "burning" transactions at the mining level would require the consent of the specific miner that finds the block that includes the subject transaction(s). Someone could "burn" 1BTC by including a 1BTC transaction fee into their transaction, and the miner could produce total outputs that are 1BTC less than the block subsidy plus the sum of all transaction fees, however, I don't think many miners would be willing to do this.

Chances of it being an oversight are low, in my opinion.
If you think about it, Genesis block and its reward (worth $1.5 million today) is technically a premine IF it could be spent and that's would not have been a good thing to have in Bitcoin.

Taking less coins in the coinbase transaction is a no-fork. That means, you can stay in the current network and always do that. We can't see a lot of burned bitcoins, because there is no incentive. But: if it would be "please burn 1 BTC, and I will give you 2 BTC", then some miners could agree to do that. Another option is to create something based on Bitcoin, where all coins that are burned in the coinbase transaction, will automatically reappear on some other chain with some other features. That chain could have zero coins initially, and create them by burning bitcoins. But of course, having two-way-peg is better than one-way-peg, we saw that in practice in some tokens like 1CounterpartyXXXXXXXXXXXXXXXUWLpVr. Imagine that all of those coins could be burned in the coinbase transaction, instead of sitting on that address. Using OP_RETURN is another option, but then it is not directly connected with mining, and I think consensus rules should be connected with that.

I'm not sure that would have been a motivating factor for Satoshi. Was a "pre-mine" even a concept which existed prior to altcoin creators using it to make themselves richer at the expense of their users? Would Satoshi even have known of the concept of "pre-mining"? If he was overly concerned about being seen to be pre-mining, then it doesn't make sense for him to have mined the first block 5 days prior to announcing the release of the software to the mailing list.

And you could equally argue that the genesis block isn't a pre-mine; it's a regular mine. Pre-mining is setting aside x amount of coins before your chain is even launched. The genesis block wasn't that, but rather the standard block reward for mining a block. It just so happened to be the first block.

RIPEMD-160, as the name suggests, always outputs a 160 bit/20 byte number. If it was to output 0000000000000000000000000000000000000000, then that would give the address 1111111111111111111114oLvT2 as has been discussed above, which is not provably unspendable however unlikely it is that someone knows one of the private keys. However, because it always outputs a 160 bit number, it will never output 0, and so there is no private key which will be able to unlock this script and move these coins.

The basic concept of a pre-mined coin is "coins that were produced in an unfair way when one party has all the advantage". In other words the fact that nobody else could mine block 0 and Satoshi mined it in private makes the reward of that block "pre-mined". I'd say that the fact that he mined the block doesn't change that.
In contrast block 1 could have been mined by anybody since the software was released and the network was live before the block was found, which makes the rewards of blocks 1+ fair distribution.

What pre-mined altcoins do is the same thing, they just remove the effort to mine a valid block by summoning the coins out of thin air but the principle of "coins created in an unfair way" is the same.

There is no reason to reinvent the wheel. It is already possible to burn coin via OP_RETURN transactions.

You are proposing something along the lines of creating an altcoin that sits on top of bitcoin, while using bitcoin's legitimacy to further its own.

If you are paying a miner 2BTC to burn 1BTC, then you are only burning 1BTC, and not 3BTC, although I think many would claim to be burning 3BTC.

I would tend to agree with oeleo above. In addition to his points, I don't think satoshi anticipated there being a lot of interest in mining bitcoin in it's very early days, and it appears that he had the capacity to mine many blocks while bitcoin was only days/weeks/months old. The coin from the first block is a drop in the bucket compared to the coin that satoshi is estimated to have mined.

If you were to create some altcoin Today, on June 4th, you could disseminate the announcement of said altcoin via some channel that is unlikely to get a lot of attention, mine the very early blocks of said altcoin "fairly", and later announce your altcoin via some other channel that is likely to get more attention and interest on June 10th (for example).

While satoshi did announce bitcoin via a channel that resulted in it getting the maximum attention possible, the attention that it initially got was very small.

the author of popular altcoin miner deliberately burned a pretty good chunk of money to prove his software releases and associated gpg key were genuine.

check the post (sorry its an altcoin but the principle should apply to any coin)

https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869

I checked the post and I still don't understand why he burned the coins. If he wanted to state his GPG key's fingerprint, he could just announce it with an OP_RETURN message, if Ethereum has any (alternatively, in Bitcoin). No need to remove coins from circulation.

i gather he had to burn coin from his miners built in fee address so it had to be eth from that particular address, not btc. so he burned like 20 grand usd worth of eth to show it. unsure about if eth has some sort of equivalent to op_return or some universal way to sign an addy.

Generally all the chains use such kind of addresses to burn their coins, obviously this is not a very full proof idea but the problem is that cryptos work on proof of work or proof of stake so which means something which has POW or POS has come into existence now you cannot remove that PoW done for that crypto which is why we say Cryptos are not imaginary money. Now because that POW cannot be destroyed you cannot burn the coin in any other manner you just treat it in such a way that it is removed from circulation.

Well it's as secure as a legacy address can be if they did what you are suggesting. But that doesn't mean they couldn't make it more secure. For example, use an address format that gives more bits of security. 256 vs 160.


I know but ever heard the saying "don't put all your eggs in one basket? In the unlikely event that someone was to find out their single private key they would lose everything. That's why it is smart to diversify your funds. And don't use the same address more than once which they obviously have FAILED to do thus leaking their public key to the whole world. Now instead of being 160-bit secure, they are down to 128-bit security level.

Clearly the person or company behind that address has no idea about bitcoin. They are making amateur mistakes.

They could have also chosen an OP_RETURN alternative too. The bits have little matter. Nobody's going to start brute forcing each address.

Where are you referring to? The BitcoinEater address? If so, it hasn't revealed its public key, since it's a burning address. You reveal your public key when you spend one of the outputs.

I wouldn't say they do. Sending to a burning-looking address is the easiest way to "burn" bitcoin, because spending to an address is, obviously, supported by all wallets.

160 bit hash in addresses provides enough security, and that's the important part.

Public key is meant to be public otherwise if there were any risks in revealing your public key, the whole Bitcoin system falls apart. It doesn't matter what a single person does (like not reusing address).

Why burn at all though? Could he not just have signed a message from that address confirming his PGP key?

Who's to say that is all their eggs? Perhaps they have several such addresses.

All bitcoin private keys provide "only" 128 bits of security.

Isn't this true only if you know their respective public keys? Because if you don't, you have no better method than just brute-forcing against the 160-bit hash.

Both are possible. Signing message is covered under EIP-191[1] and EIP-712[2]. Not sure about OP_RETURN equivalent, but it's quite common to use data field[3] where popular blockexplorer such as etherscan support converting the data to UTF-8.

[1] https://eips.ethereum.org/EIPS/eip-191 (https://eips.ethereum.org/EIPS/eip-191)
[2] https://eips.ethereum.org/EIPS/eip-712
[3] https://ethereum.org/en/developers/docs/transactions/#the-data-field (https://ethereum.org/en/developers/docs/transactions/#the-data-field)

ofc this thing is derived from plain wrong pubkey. and that's how it should been

There are many times, when you know that keys. They are public. You always know them in all Taproot addresses. You always know them in all multisigs, because they are based on public keys, not on public key hashes, if you are a participant in a multisig, you know the public key of another party. Also, if you look at your mempool, you will see a lot of public keys inside transaction inputs.

So, if ECDSA is unsafe, then Bitcoin is unsafe, multisig is unsafe, Taproot is unsafe, and Lightning Network is unsafe. A lot of existing coins could be stolen if ECDSA would be broken.

Yes, but public keys are supposed to be, well, public. If your security relies on keeping your public key secret, then your security is flawed.

As garlonicon points out, there are so many scenarios in which your public key is revealed that this should be assumed to be the default position (especially as people move to taproot addresses). In addition to the ones he has listed, consider all reused addresses and P2PK addresses. There are also many non-transaction or non-address related ways in which people expose their public keys, such as by using any non-Core wallet which sends xpubs to a server, or uploading their xpubs to some other service. Wallet software generally doesn't protect your public keys in the same way it does with your private keys, meaning you can leak them much more easily.

Thinking you are more secure because you think your public key is secret is a false sense of security. Unnecessary security at that.

my opinion OP_RETURN is only for those who wanna burn their coins for themselves. if you offer this to user who wanna something for burned btc - for him you'd just send it to your address tellin him it's burned

Right now it does. But not eventually. Quantum computer can reduce that to 80 bits.

Then why do you think Satoshi invented Pay to Public Key hash? It's not just to save disc space on the blockchain.


nope not that address. this one: 1P5ZEDWTKTFGxQjZphgWPQUpe554WKDfHQ As I mentioned, one day this person might wake up and realize all their bitcoins are gone. poof. vanished. sent somewhere else. i say that because it will be one of the top targets not only for traditional hackers but also for quantum computers.

if it's a company behind this address then I hope it's not an exchange I ever do business with since either they are really dumb (a person knows the private key and could steal all the money) or they are using some type of Shamir Secret Sharing on a single private key which is probably an awful idea too.


That's why satoshi didn't just stop with the public key because he figured if someone ever broke the elliptic curve they would still have to break the hash functions. additional layer of security.

assume at your own risk.

You don't have to just "think" your public key is secret. You can make sure it is. and if you do that then it is more secure than if someone knows the public key. that's just a simple fact. I can have 256 bits of security if I use a particular address type or I can have 160 bits if I go with legacy. It's up to me. But if I do something stupid like re-use my bitcoin address, then it immediately goes down to 128 bits. Again just another fact.


They will be unsafe at some point. Maybe before people have time to react and some people might lost some bitcoin because of that. They have exascale computers now. Zettascale is coming after that. And probably Quantum Computers too.

Still wouldn't change the fact that they are doing it all wrong with that one address. Re-using it. If they have other similar addresses, they probably doing the same thing with it too. Bad idea.

Quantum computers are not magic tools that can solve any problem!

P2PKH existed from early days, it wasn't invented later.


That day we all wake up to an entirely different world where the banking system no longer works, military secrets are leaked and abused by the enemies and a large part of the internet would fall apart. You see the cryptography used in bitcoin and the security level is not just specific to bitcoin.

Bitcoin keys provide 128-bit of security, you can't have more than that regardless of your address type.

If you burn coins from the chain then the total coin supply will change. If you can remove coins, then it would mean you can add coins too. Nobody wants that. Once a coin is lost, it is lost. It is the whole point of a limited supply blockchain and bitcoin is just that.

Burn addresses might not make any sense to you but it is what it is. You'll have to live with that if you are using bitcoin because it is not going to change.

And where did I ever say that? Quantum computers could solve certain types of problems because algorithms are known for those certain types of problems.

I didn't say it was invented later. I said Satoshi invented it. Is that wrong?


your'e trying to lump in other things along with bitcoin to try and make it sound like someone would have to be irrational to attack bitcoin using a quantum computer. perhaps bitcoin is a simpler target to go after than some of the things you mentioned. ever think of that?

Sure you can. You have can have 256 bits as long as you don't leak the public key. Surprised you don't realize that.

Exactly. They can solve "certain types of problems" but they can't magically decrease the 128-bit security of a EC private key to 80 bit.

It sounded to me like you were suggesting it came later.

The point is to say cryptography is not going to be broken as easily as you think otherwise we wouldn't have built so much on top of it. Historically this has also been true. We can always foresee the technical developments including hardware capabilities that could lead to weakening a cryptography algorithm and we have always been replacing them with stronger ones for the past thousand+ years.

The key will still provide 128-bits of security.

And if that ever becomes the case, then bitcoin will move to quantum resistant signatures. Relying on then insecure hash functions and keeping your public keys secret is not a tenable solution.

Keeping your public key secret means never spending your coins. As I said above, if your security relies on your public key being secret, then your security is broken. Long before this becomes an issue, bitcoin will fork to quantum resistant signatures.

---

If you think that 128 bits of security is insecure, then you should probably stop using bitcoin. Even if you believe that all your coins are protected by 256 bits of security, the many millions of bitcoin present in addresses with exposed public keys is enough to completely crash the price of bitcoin to zero if they were suddenly all stolen and everyone lost confidence in bitcoin's security.

Quantum computers cannot reduce anything. Quantum computers are just a scam hidden behind weird probabilistic equations, which are very conveniently excluding almost all real life noise. Quantum computers are so weak, that cannot factor a 6-bit number using the almighty Shor's algorithm - which "breaks ECDLP" - the number 35 turned out just too big for reliable factorization.

I didn't say they could do that. What I said is they can reduce the security of a hash function in half. From 160 bits down to 80 bits.


Well I don't know all what's gone on in the past 1000+ years with regards to that but I'd say the quantum computer threat is kind of a new paradigm.



If all you know is my bitcoin address, say it is a 256-bit hash. Then to attack it you could do no better than brute force search to find a pre-image. So my security is 256 bits for that. Keep in mind too that there are about 2^256 bitcoin private keys.


You make it sound so simple like flipping a switch and it's all taken care of. They don't even know what signature scheme they would use.

A 256-bit hash function such as Sha-256 is secure against quantum computer pre-image attacks. 128 bits secure. Which by your own admission is good enough security.

No it doesn't. It just means you only use your bitcoin address one time. After that you use another one you never used before. Because once you use it the first time, the public key becomes a permanent record on the blockchain. At that point, you don't want to have funds in it anymore. it's just part of an overall security protocol for best practice.

It's not that it relies on it but given the choice, I prefer not to let anyone know my public key or keys. I feel more secure that way. Luckily bitcoin allows that by simply not re-using the same address more than once. I might have other security protocols too which are designed to make me feel more secure against someone cracking my private key. Such as not storing my bitcoin on an android app, etc.

I think there's logistical issues in doing something like that though. Are you just going to fork bitcoin? And the old legacy chain dies off? What happens to Satoshi's bitcoin?

I think 128 bits of security is on the fence. I'd like to see higher. But it is what it is. The only way to get higher security is to change curves or change how you use the curve secp256k1. if a bitcoin public key had 256 bits of security then I wouldn't have such an issue with my public key being known.
but as it is now, i think it wise to not use a bitcoin address more than once. if i'm going to use bitcoin.


Quantum Computers do not equal Shor's algorithm. I'm pretty sure if they really wanted to they could factor something bigger than 35 though. We're way past that.

Why would we? A credible threat from quantum computing is decades away. Why would we discuss and settle on a quantum resistant algorithm now, knowing that when it comes to actually be necessary the algorithm we chose today will almost certainly be long outdated and replaced by something stronger, quicker, more efficient, etc?

And as soon you broadcast a transaction from that address, then your public key is exposed, allowing a malicious miner with a quantum computer to steal your coins. So again, if your security relies on keeping your public key private, then your security is broken.

That's absolutely fine if that's what you want to do, and everyone should be avoiding address re-use anyway from a privacy point of view. But it is not a viable solution against quantum attacks.

The old chain doesn't die, we simply introduce a new quantum resistant address type. We've introduced many new address types over the course of bitcoin's history, such as segwit and now taproot, with no effect on previous blocks.

At 200 exahash, it would take the entire bitcoin network about 54 billion years to perform 2¹²⁸ hashes. And that's just simple hashes using highly efficient ASICs. Worth mentioning that if you think 128 bits is insecure, not only should you stop using bitcoin as I said above, but you probably need to stop using banks or even the internet and just keep all your money in cash under your mattress.

Dear heavens.  I opened this thread with the intent of sending a merit to the first person to provide the correct information.  Although some mentioned OP_RETURN before that, nobody properly explained its significance before page 2.

There is only one correct way to burn bitcoins:  OP_RETURN.

Please, stop permanently and irreparably bloating the UTXO set with coins that are stuck in limbo!  You are hurting Bitcoin.  So-called “burner” addresses are misnamed.  They do not burn the coins:  They trap the coins.  They should be called “trap addresses”.  Placing sats in the amount field of an OP_RETURN output actually burns them.

The consensus rules for OP_RETURN were designed that way for a reason.  Use the consensus rules for their intended purpose.

Also, to add to what PN7 said:  There are some people out there who like to audit the Bitcoin supply.  Coins removed from the Bitcoin supply via OP_RETURN are accounted properly in those audits:  They no longer exist.

Due to coins burnt in OP_RETURN (plus at least one anomalous coinbase that destroyed coins, IIRC), the BTC max supply is less than the theoretical maximum of 20,999,999.97690000 BTC.  (It never was exactly 21 million BTC.)  Every time someone puts money in an OP_RETURN output, the maximum supply is reduced.  To find the exact numbers for the current existing supply and the current maximum supply, search for a supply audit—or do one yourself.

---

There have been quite a few, actually. I'll quote a previous post of mine:

For anyone interested (at time of writing):

Theoretical maximum supply:
(210,000 * 50) + (210,000 * 25) + (210,000 * 12.5) + ((739,692-629,999) * 6.25) = 19,060,581.25 BTC

Actual supply taken from my node using gettxoutsetinfo as of block 739,692 = 19,060,367.17900217 BTC

Discrepancy = 214.07099783 BTC

Links below cite a few more.


https://blog.okcoin.com/btc-developer-asks-where-are-the-coins/
(from developer who worked on adding the gettxoutsetinfo RPC.)

https://bitcoin.stackexchange.com/questions/38994/will-there-be-21-million-bitcoins-eventually/38998#38998
(sipa, linked by above.)

Earlier thread (you’ve merited this before; not sure if it got linked here yet):
https://bitcointalk.org/index.php?topic=675321.0

Useful:
https://bitcoin-supply.com/

An audit:
https://www.pierrerochard.com/auditing-bitcoin-supply/

The 2,609 BTC listed at the top of that first link, and included in the "Permanently Lost" total of the second link, is the same that I discussed earlier in this thread here: https://bitcointalk.org/index.php?topic=5400954.msg60285429#msg60285429 and https://bitcointalk.org/index.php?topic=5400954.msg60286180#msg60286180

A bit of an outlier, since these coins are not removed from the supply as with OP_RETURN outputs, but are still provably unspendable as they cannot be unlocked. If you want to add these 2,609.36304319 to the discrepancy I reach above, then the new value becomes 2,823.43404102 BTC.

I would point out that in order to know the public key, you either need to have access to the private key, or have learned information from someone who has access to the private key. The "bitcoinEater" address is claimed to be an address for which no one has the associated private key. If this is true, there is no projected risk that the private key will be able to be calculated based on the address. If it is not true, whoever has the private key can just steal the coin.

Obviously, it is difficult to know with certainty if the "bitcoinEater" address is really one for which no one knows the private key.

It's impossible to know with certainty, but you can easily be certain there's no such owner. Same as with PoW. You can't know with certainty that one spent millions of dollars to find a valid hash, but you can easily assume it's true, and you'll be right. One ought to spend millions, on average, to accomplish that.

It's realistically impossible to find a valid Proof-of-Work without the work.

Trying to brute force that address for all intents and purposes is not going to work. If you say that someone is trying to brute force that specific address, I would respond that they will be unsuccessful.

The risk to someone knowing the private key associated with the "bitcoinEater" address is that someone could have happened to have generated the private key associated with that address, saw its potential use, and published the address for people to "burn" coin to.

No, I was referring to why and how sure you should be there's no such owner.

I understand the point you are making, but your analogy isn't a great one. Occasionally someone does find a block without doing the work, as we see when an empty block is mined within a few seconds of the preceding block. The amount of work done to find such a block is only a very small fraction of the average amount of work done across all blocks at a similar difficulty. So sometimes you do find a valid solution without doing (much of) the work.

Further, sometimes you'll see a miner with the hash power of just a single ASIC finding a block. Multiple such examples here: https://bitcoinmagazine.com/markets/third-solo-bitcoin-miner-finds-valid-block. So sometimes you do find a valid solution without spending millions of dollars.

The chance of these things happening is small, but not zero. The chance of someone knowing the private key to 1BitcoinEaterAddressDontSendf59kuE is exponentially smaller, but is still not zero.

The proof that there's work remains, though. Maybe taking a block as an example is a bad analogy, because one might mine easier than another sometimes, but the difficulty is a humanly insusceptible parameter that reveals with quite certainty that there's work.

From a quick -getinfo, it's 29897409688833.63. You can't fake that, nor can you drop it by 90%* by any chance, due to the abrupt exposure of average accuracy. There's a specific work devoted, that's publicly known, miners who thrive to finding a valid hash, ASICs in limited supply. The ability for someone who "has not worked for it" to get such vanity address, AKA PoW, is very small, but less than the ability to reward themselves more than it currently has, especially at the time it firstly received coins.

Chances aren't 0%, but it's 100% pointless.

---

So you don't care what happens to peoples' bitcoin who choose not to move to this new address type? I don't think that's a reasonable solution to require people to send their bitcoin to a new address type to avoid losing their funds. That's not the same as segwit or taproot as people had a choice and the default action (none) did not have an adverse affect on them. You didn't answer the question either.
 

Please show me anything quantum, that could factor big numbers (or even small); besides the obvious random search (adiabatic, annealing, etc), which doesn't scale, and is in fact faster on classical computers.

Who is this "we"? All I see is random buzzwords and utter failure. They wanted to factor, and failed miserably. Now there are 127 qbit computers. And they cannot factor 6 bit numbers.

Repeating buzzwords doesn't make it truth.

Well, that's a completely separate debate. If the time comes that the ECDLP is broken by quantum computer and we can no longer rely on elliptic curve cryptography, then bitcoin will and must fork to some quantum resistant algorithm.

The question you are posing is how to go about doing that. Saying that you don't think it's reasonable to expect people to send their bitcoin to a new address type is missing the point - if ECDLP is broken, then all current addresses are vulnerable. We can't make ECDLP magically secure again and let people continue to use their current addresses.

The only option is to introduce a new quantum resistant address type and  give everybody plenty of time to move across to it (in the order of several years). What happens with coins that don't move becomes the real issue here - do we either decide as a community to permanently lock them* so they can never be moved again, or do we just ignore them and let them be stolen by whoever manages to first and then re-enter the general circulation. I am in favor of the latter option.

*Perhaps the best option, but one which would need a lot more work to be viable, would be to lock all these coins but provide a mechanism to unlock them if the real owner can provide some quantum-resistant proof that they are indeed the real owner. An example would be if I could prove that I owned the seed phrase which generated a given wallet or address. Such a mechanism (if developed) would only solve this issue for seed phrase generated addresses though, and there are a lot of vulnerable coins in P2PK address and other non HD wallets that this does not address.

Me too. Also because that option can be turned easier to the first one, than the other way around. If coins will be stolen, then it will be possible to burn them. But if they will be burned, it will be quite hard to recreate them. I think we could just let that situation resolve itself. If someone will grab all coins, then miners could reject to mine that, or they could mine it for themselves. Some miners could decide to burn all of such coins, and then other people could follow that chain.

So, moving those coins by using OP_RETURN or destroying them inside the coinbase transaction, by sending them as a fee, may be better than artificially blacklisting them. Burning coins by breaking the private key, would be no-fork solution. Locking them somehow without owning the key, would be a soft-fork. And in case of such soft-fork, there will always be a question: is it censorship? And is it needed?

But, if they get burned, it doesn't make sense to recreate them later. They are either removed from circulation or not.

I'm highly against this. If miners start rejecting transactions they don't like, despite according to their fee rate, we would no longer have censorship resistance. Furthermore, bringing these old coins into circulation, again, would either increase the supply or make them double-spent. In either case, it'd only be bad for bitcoin.

I am just as sure that the BitcoinEater address has no owner as I am that every other address that has never sent any transactions has no owner. There is nothing special about the BitcoinEater address that makes it any less likely to have an owner.

Just tossing this out here:


In theory, this could be done without revealing the seed, using a zero-knowledge proof:  In theory, any operation that can be performed by a computer can have its correct performance proved in zero knowledge.  In practice, I think that running BIP39 (replete with 2048 iterations of PBKDF2-HMAC-SHA512!) and BIP32 inside an arithmetic circuit would be obscenely expensive.  Zero-knowledge proof coins go to great lengths to design protocols that are efficient inside a ZK arithmetic circuit—sometimes even inventing their own cryptographic primitives.  SHA2 functions are bad mojo here.  

In an emergency, for a one-time movement of vulnerable coins, perhaps it may be feasible even to do some expensive operations.

Furthermore, zero-knowledge proofs would allow secure spending of coins from some keypool keys, etc.  It seems impossible to provide any help there:  If the public key has been exposed, then the only secret information can be deduced by an attacker with a large quantum computer.  But if the public key has never been revealed, then you can reduce this to the security of the hash.  Anything that can be reduced to the security of a hash smells good!

Perhaps Greg Maxwell’s later-regretted meme about the safety of not revealing public keys may have some merit, after all.  Racing a quantum attacker to spend your coins is a bad idea, when you need to reveal the public key to spend your coins.  But a ZK proof could let you never reveal the public key!  Prove in zero knowledge that you know a private key, which produces an undisclosed public key, which has the publicly known hash.  [Edit:  Or, keep it simple.  Prove in zero knowledge that you know the preimage to the hash, and “somehow” use that to spend the coins.  A proper approach here would need to be designed carefully, and subjected to a rigorous security analysis.  —End of edit.]

Caveat:  I had the idea for how to do this about three seconds ago.  The idea may be broken or infeasible.

And in all of the above, I won’t go beyond handwaving.  We would anyway need to see what the future state of the art is in post-quantum ZK proof systems.  Current systems are a mixed bag.  zk-SNARKs seem to have some limited resistance to some quantum computing attacks, but are probably not useful here; zk-STARKs are fully post-quantum.  This is a hot research area, and the state of the art has advanced very rapidly in the past 9 years.  IMO, as of 2022, zk-SNARKs have only just reached maturity for the current generation of deployed use cases.  Given that PQ crypto is itself a hot research area, I would expect that researchers should be interested in advancing the state of the art for PQ ZK proofs.

On a related note, I have some clever ideas for how at least a little bit of PQ crypto could be kludged into Bitcoin right now—to let people efficiently record in the blockchain a PQ way to claim their coins in this type of scenario.  (There are obviously some inefficient ways to spam the blockchain for this; don’t do it!)  Will not yet discuss:  I usually try to break the security of my own oh-so-clever ideas, before I foist them on others.  If more people did that, there would be less noise on this forum.

---

Yesterday, I began to write a reply to some of the other above posts re the titular topic of “burner addresses”, i.e. trap addresses.  I need to learn to write terser, less detailed technical posts.

Edit:  While I was mulling and writing the above, PN7 said in two sentences what took me twenty pages:


Worries about the security of an address with human-language semantics that take the whole Hash160 are logically equivalent to newbie questions about “what if someone accidentally generates the same private keys as I do?”

The reason not to use trap addresses is that they trap unspendable coins in the UTXO set.

For that reason, and only that reason, the one and only correct way to burn coins is to use OP_RETURN.

And you come to that conclusion, how?


Better sooner than later then. The sooner the better. But they can't do it sooner you said because it needs time for research. but nist already is in their final stages. and bitcoin will probably have to go with something they crown. whether that's good or bad.

Well the reason I say it's not reasonable is that not everyone is going to be able to move their bitcoins. Most people that used bitcoin in the past and probably many of them today think that their bitcoin is safe forever and there would be no need to ever change anything about it. But some people won't be alive maybe they gifted their bitcoin to some future descendents in a will or something. maybe using something like nlocktime. so all the descendent has is a (hopefully) secret transaction they can broadcast at some future time. they wont have any private key so they wont be able to "move any funds" to a new address type without first letting them to go the old address type first. now you can say that is dumb inheritance planning but maybe its the best they could do is put it in a bank deposit vault and that's it.

Well, how would you prove quantum resistance? Or would you just cross your fingers and hope it was. Because if it ever got cracked them bitcoin would really be in trouble then. So whatever address type they move to they better get it right the first time is all i can say i don't think they get a second shot.

well you're assuming it has to be one or the other. if someone didn't spend using the address then no one is going to crack it unless they can crack hash functions which is not realistically possible. now all they have to do is get a bitcoin mining setup and try and mine their own transactions and don't broadcast their transaction but just mine a block it is in.



Well if you could pull something like that off, you might as well just use it as your new signature scheme to replace the broken one. No need for a new quantum resistant address. For seed phrases anyway...but why couldn't it apply to other things too? If it can work with a seed phrase why not with any other piece of information?

that's an interesting concept but i'm not sure if it is possible. hash functions don't have any type of exploitable structure to them.

Why are people arguing with a troll who is habitually derailing threads with plausible-looking nonsense?

I know that I inadvertently somehow contributed, by replying to a remark by o_e_l_e_o that caught my attention.  The brainstorm thus inspired is offtopic here; it deserves its own thread, which I should make in due course when I have time to elaborate on it a bit.

This thread is about so-called “burner addresses”, which I say should be more properly called trap addresses.

The user who is derailing threads is free to make a thread to discuss his concerns about quantum computers.  Though I’m not sure of what value that would be; the development forum has already had numerous such threads, some of which were eventually locked by the moderators due to pointless repetition.  Anyway, I will be reporting this user’s continued offtopic posts as offtopic.  This shall be my one and only offtopic reply to him here:

---

It not only possible, but nowadays quite easy to prove in zero knowledge that you know the preimage of a hash, without revealing the preimage.  Empirical evidence:  Zcash exists, and it works.  (Take a look at its “nullifier” system that prevents double-spends of shielded notes; it does something conceptually related, but much more complicated.)

You clearly have no idea what you are talking about.  With your gabble about “exploitable structure”, you are just trolling with b.s. abuse of jargon to try to make yourself sound like a cryptographer.

Although hash functions should not be able to go from hash to original (they should not be able to be reversed, and they should be one way), it is not possible to know with certainty that a particular hash function is, in fact one-way. In the past, encryption algorithms that were thought to be unbreakable have been broken by cryptographers.

maybe im misunderstanding something.

if i take one megabyte (or 8 megabits) chunk of data and hash it down to a 128 bit hash, how can that be reversed? ie there are more bits information in the original than in the hash. therefore information is irretrievably thrown away, yes?

As I noted, it should not be possible to reverse a hash function. If there was some kind of pattern in the output of the hash function, in theory, the function could be reversed.

Some hash functions also have limits as to how much data can be hashed. In theory, a hash function could be reversed in a way such that you can take the hash and calculate every potential input with a range the input having a data size of 0 through the maximum.

That’s the Pigeonhole Principle.  It is the same reason why it is mathematically impossible to build a lossless compressor that produces a shorter output for every input, recursively apply it to its own output, and thus, reductio ad absurdum, losslessly compress all data in the universe down to 1 bit of information.  All lossless compressors produce outputs longer than the input for some inputs; all compressors that produce a shorter output for every possible input are lossy compressors, whose outputs cannot all be decompressed with bit-for-bit identical roundtrip results.

Crackpots perennially annoy or entertain us with new designs for compressors that claim to violate the Pigeonhole Principle.  It is the information-theoretic counterpart to teaching those stupid physicists that a true genius can harvest free energy from the Earth’s rotation, or build a perpetual motion machine.  (Reviewing recent threads, I am just waiting for stereotypical crackpot SapphireSpire to invent a way to compress the blockchain with recursive lossless compression.  Not a few have tried that.)

A cryptographically secure hash function is also called a compression function.  Needless to say, it is a very lossy compressor that irretrievably discards most of the input information.

---

No, even CRC-32 cannot be inverted to retrieve the input.  Even CRC-8 cannot be inverted to retrieve the input.


Even a cryptographic hash with a finite domain of preimages (inputs) will map an astronomically huge set of different preimages to each possible image (output).  Even if the hash is ridiculously broken, the image does not and cannot contain sufficient information to distinguish each possible preimage uniquely, or even to a practically useful degree of probability.  Not if your only starting information is the hash image!

It would be easier to address this, if you were to state what concrete goal you are trying to achieve.  Your post about this did not quote or reference any prior posts.  OT here, but I note as a precaution just in case if it was in reference to anything I said, or any reader may be confused to assume so:  Proving a statement in zero knowledge as I proposed does not rely in any way, shape, or form on inverting the hash.  That would be obvious to anyone who knows how modern zero-knowledge proof systems work (https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/#how-zkcp-works).  (Maxwell’s description in that blog post is a good bird’s-eye overview, but it describes the state of the art in early 2016; nowadays, the trusted setup has been replaced with something trustless, and ZK proof systems now require orders of magnitude less CPU and memory.)

'

If you re-read what i said, I said it sounded interesting but i wasn't sure if it was possible. Hash functions dont have nice mathematical properties such as h(a+b)=h(a)+h(b). You are clearly a genius though as evidenced by your continued brilliant posts on this particular topic of zero knowledge proofs. Bitcoin is really lucky to had someone like that because they might be able to help bitcoin become quantum resistant.

That is not reversing a hash, that is called finding a collision.
Theoretically and practically hash functions (both cryptographically secure and insecure algorithms) are and will always be irreversible.
To put simply if you can reverse the following function and tell me what `a` and `b` were you can also reverse hash functions:

You can use homomorphic encryption if you need such properties.

Exactly. Inside hash functions, there are many things that are irreversible. If you have "uint32=mod(otherUint32+anotherUint32,2^32)", then there is no chance to reverse it, because for any given "uint32", there are 2^32 possible pairs of "(otherUint32,anotherUint32)", that will lead us to the same result. Also, there are binary operations, like AND, OR, XOR, that will mix it further, and make it a complete mess. Also don't forget about rotations, they are making it rock solid, because then tracking dependencies between single bits is getting exponentially harder. I think some explanation of the hash functions, based on reduced number of rounds, should be prepared, I will add it to my TODO list.

Homomorphic encryption would not grant such properties to a hash—not to the hash itself—but that is irrelevant here:  Such properties are not needed.  The ignoramus who spat out that brilliant observation was making a non sequitur, like observing that hash functions are not the colour mauve.  Well, of course not.  So what?


To illustrate:  For publicly known Hash160 image H of secret preimage secp256k1_pubkey, you can prove in zero knowledge that you ran a program that outputs true for the following:


Verifying the proof does not require any knowledge of secp256k1_pubkey.

Neat trick, eh?  That’s the toy version; it simply proves that you know the unrevealed public key.  Building this into a system that permits secure spending of funds would necessarily be more complicated; and since the objective here is post-quantum emergency salvaging of coins, it may need to use something other than current-generation zk-SNARKs.^*

It is not merely theoretical.  Zcash has been deployed in production for almost six years, running a financial network where you prove in zero knowledge that you ran a program that validates your own transaction.  Consensus nodes then verify your proof, without knowing any information about the transaction’s inputs and outputs.  With a nod to Clarke, “Any sufficiently advanced cryptography is indistinguishable from magic.”

I have believed for years that zero-knowledge proofs will take over the world.  When time permits, I will open the new thread that I’ve been intending for days about zero-knowledge proofs, and the application thereof in Bitcoin.  (A prior impetus for that was my desire to avoid derailing another thread (https://bitcointalk.org/index.php?topic=5401114.msg60290629#msg60290629) with discussion of using ZK proofs to build a trustless BTC wrapper/bridge.)  It will be self-moderated to cut noise.  Meanwhile, those who are curious about the topic can find a research bibliography and a little survey of implementations here:

https://zkp.science/ (https://zkp.science/)

FHE is an entirely different topic—and another hot area of rapidly developing research.  I want to learn more about that, and especially about potential applications thereof for solving the problem that we can’t publish secrets on a public blockchain.  If you have knowledge and ideas on this subject, that would be interesting!


I suggest an inductive reductio ad absurdum:  “Hash” some data with CRC-8, which has no cryptographic security whatsoever (https://users.ece.cmu.edu/~koopman/crc/crc8.html).  Attempt to retrieve the data.  If you succeed, then you have discovered that CRC-8 is a lossless compressor that can compress large amounts of arbitrary data down to a single byte!  That’s obviously impossible.  Q.E.D.:  Hash functions cannot be inverted to retrieve their inputs.

Your thread about hash functions will also be interesting.

---

^* zk-STARKs are PQ crypto; they rely only on the security of a hash function, but I am not sure if they are the best option here.  There is some debate about zk-SNARKs and quantum computing attacks; I would need to learn more before opining.  Edit 2022-06-11 (original (https://archive.ph/BZjzw#selection-5927.0-5929.240)):  Duh, I conflated soundness with zero-knowledge.  AFAIK, there is no debate about whether a quantum computer that could break typical ECC could annihilate the soundness of zk-SNARKs—that is, whether it would be able to forge fake proofs.  The question, rather, is of how much privacy Zcash users would retain against retrospective decryption in a post-quantum world.  That depends on the intricacies of the Zcash protocol, not only on the properties of zk-SNARKs.  AFAIK, Zcash users will retain privacy for, and only for, funds received by addresses that have never been revealed anywhere that a quantum attacker could find it.  AFAIK (and I am not sure about this), the SNARKs themselves lack information that could be recovered by a quantum attacker; but the Zcash protocol encrypts transaction details on-chain with ordinary use of EC public-key cryptography, using a public key derived from the receiving address.  Of course, the quantum attacker could break the latter.  Anyway, STARKs it is—those are PQ crypto.

Well I don't think that would work. But if you think so then maybe you can explain more about how you can just spend bitcoin by proving you know the pre-image of the hash. Using words like "somehow" doesn't help your case at all.




I tend to agree but the thing is nodes don't have to store OP_RETURN transactions. Those are provably unspendable so if you want to have something that is stored by every node forever then you have to store it in the utxo set.


i'm still skeptical that you can do anything to make bitcoin be quantum resistant using zk snarks. and make it be efficient and make it so that i never need to share my public key all i ever need to do is share my address. if that was the case then why wouldn't bitcoin be doing that right now?

i doubt such a thread is going to accomplish any meaningful objectives because you seem to have a disdain for people you deem to not know as much about the topic as you do.


you don't even know if the bitcoineater hash corresponds to a public key or not. there may not even exist a public key that hashes to it.

I think this word was used, because there is no BIP that you could follow step-by-step. But I know it is possible, you can try Homomorphic Encryption, and then come back with news like "Homomorphic Encryption cannot solve this, because of that". But I think you will also see, that it is possible.

You never need to have anything that is stored always and forever, by every node. Putting data in OP_RETURN is better. Putting them as a witness is better. Not putting them on-chain and committing to them is better. There are many ways that are better (and cheaper) than trapping coins.

Because programmers have more ideas, than they can turn into code in their lifetime. Also because people are unaware of the technical details behind some ideas. Some altcoiners could stay with Bitcoin, if they would know, how many things they could do, without creating any new coins. For example this one, Using Merged Mining on a separate zero supply chain, instead of sidechains (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020532.html). You know what was the first response (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020537.html)? The first sentence was "I proposed something similar years ago". You know what does it mean? It means many people have many ideas, but they have more of them, than they are capable of turning into practical software. And there were many such cases, where someone proposed something, and received a response that "something similar was proposed before". Here is another example: Adding SIGHASH to TXID (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020432.html). And the first response (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020433.html). The first sentence was "Have you seen the inherited ID proposal from John Law on this list?". After reading more and more such examples, the conclusion is simple: people have many ideas. But having some idea and sharing that is one thing. Coding all of that is another thing, much harder, and that's why you don't have such features yet. But I think they will come, contributions are welcome, to make it real, it is needed to turn ideas into code.

I prefer talking with people that know the topic, instead of people that are polite. They don't have to use nice words. Especially when they are right, for example in case of this topic. It is derailed. It should be splitted somehow.

Of course. In case of hash functions, it is possible to have some hashes that are unreachable, and that no message can be hashed to that. But it is hard to prove it, without breaking such hash function.

To get back on topic regarding burner addresses:

Nodes do store OP_RETURN transactions, just as they store every transaction. What they don't do is add these unspendable outputs to their UTXO set. Any data stored using OP_RETURN outputs is still very much forever part of the blockchain.

With (almost) 2²⁵⁶ possible private keys and 2¹⁶⁰ possible P2PKH addresses, then it is highly likely that there is a valid private key. But yes, impossible to prove without finding such a key. But still, this goes back to the original point: When you cannot prove one way or another whether a private key exists or whether someone knows that private key, then these coins are not provably unspendable.

He evidently wants to prevent pruning.  That is actively malicious.

This is not about trap addresses, a.k.a. “burner addresses”.  The stated goal implies a desire to store arbitrary data (https://www.semanticscholar.org/paper/Data-Insertion-in-Bitcoin's-Blockchain-Sward-Vecna/1cfa3fb23db52cc5b057108d160446ef01caf786), 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.

The stated goal exhibits a wanton disregard for abuse of memory and CPU resources needed by the UTXO set.  (It’s not only about disk; but a blockchain spammer does not care.)

The stated goal is intentionally to force “Be Your Own Bank” Bitcoiners who run 24/7 online nodes at home on inexpensive hardware to serve as unpaid file hosts.

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.

This is when I start cursing.


There exist altcoins that facilitate, and even encourage the storage of arbitrary data on their blockchains.  Some of them require in practice at least 256 GiB RAM (preferably 512 GiB), 32 CPU cores, terabytes of fast NVMe SSDs, and at least 1 Gbps commercial-grade Internet to run a performant node—and they still struggle to keep up with the flood of data (https://github.com/solana-labs/solana/issues/21604).  Go to them and pay their fees, if you want to store arbitrary data; if your data are so precious that you fancy forcing low-resource Bitcoin nodes never to prune it, then surely, you must be willing to pay for it.  To be extra-helpful, I hereby offer my consultant services at a rate of $1,000/hour to anyone who needs assistance spamming the hell out of storing his precious-snowflake data on the Solana blockchain; my rate is subject to change without notice, as the dollar continues to inflate into utter worthlessness.  There also exist file-storage blockchain projects, which may be suitable for whatever use you have in mind; expect to pay your way.


There should be approximately slightly less than 2⁹⁶ valid keys per address.  (Not the same number for every address, of course.)  If it were significantly not so—due to “unreachable” hashes, or otherwise—then the distribution of hash images would be distinguishable from the uniform distribution; that breaks it for anything that relies on the Random Oracle Model, among other problems.  I would be very interested in seeing the reasons why people believe that RIPEMD-160 is so badly broken.

As I said above, and as PrimeNumber7 noted, there is no cause for a security concern that someone may have the private key.  Not if the full Hash160 has some human-language semantics, in the style of a vanity address.  That is essentially a type of Nothing-Up-My-Sleeve Number.  The resulting address is not “provably unspendable”—to the contrary, there are around 2⁹⁶ ways to spend it, which is why it needs to remain in the UTXO set.  But we can be confident that nobody knows how to spend it.  If you are worried that someone out there may have the private key, then you should also be worried that someone can find the private keys for your own addresses.

---

Larry has been been labouring under the mistaken belief that I need to prove to him that my idea can work.  That’s not my problem.

I did make one significant error in a statement above.  (Hey, if PN7 can sometimes have a “need more coffee” moment here, then so can I!)  It will be corrected presently, with an appropriate note.  Edit:  Done.  See correction to footnote in this post. (https://bitcointalk.org/index.php?topic=5400954.msg60329182#msg60329182)

I don't think it is "so badly broken". I think that some values may sometimes be unreachable, because this area is unknown, as long as some hash function is not fully broken. For example, SHA-256 returns 256-bit hash, SHA-512 returns 512-bit hash. One is just expanded version of another one. But it is possible to shrink it in the same way as it was expanded. Then, you can reach SHA-128 (16-bit) or SHA-64 (8-bit). And after running some tests, for some rounds I exhausted the search space in some cases. For example, when something is double-hashed, then (obviously) for some hashes it may turn out that there is no solution at all, just because it is not a bijection, and then if there are collisions, then there are also cases, where there is no solution.

When it comes to addresses, then they are double-hashed. First by SHA-256, and then by RIPEMD-160. I don't have a proof that all addresses are always reachable (it is very likely that they are), but I won't be surprised if some of them won't be. If you have "uint32=AND(0xbadc0ded,someOtherUint32)", then 0xffffffff is unreachable. If you have "uint32=OR(0xc0deba5e,otherUint32)", then 0x00000000 is unreachable. Inside hash functions, there is a mess. Some operations preserve bijection, but it is not always the case. Then, if you have 64 rounds in some hash function, it may be the case that for 63 rounds you will reach some value, but not for 64 rounds, because of internal operations, where dependencies between bits won't let you reach some result.

Hash functions will typically use the modulo operator (the remainder when dividing a number by a particular another number).

A very simple hash function, that can easily be reversed might be one that only accepts integers from 0 through 100, and will output the mod 10 of the input. So the 'hash' of 11 would be 1, and the input of a 'hash' output of 1 could be any of 1, 11, 21, 31, 41, 51, 61, 71, 81, or 91.

Sometimes, businesses will use a simple hash function, similar to the above to store user-provided data, but prior to finding the modulo of the input, they will add a "salt" to the input as a means to prevent the user from being able to arbitrarily creating collisions.

The 'a' + 'b' = 10 formula is not a hash function. A hash function will always take a single input, and will produce the same output every time the same input is used.

Salt is added only to increase the difficulty of brute forcing if the database of that site was leaked.

I never said it is a hash function, it is one of many steps used in a hash function and if you can't reverse that, you can not reverse the hash itself!
This is the last thing that happens in SHA256 before the final hash is produced:

ok you got me. i'm not a big fan of it, pruning that is. but maybe not for the reasons you think. i think every node should have to store all the blockchain data and here is why: 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.


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.

You have to design a system to be robust against people trying to abuse it. Because, and this might be a suprise to you, but they will try. Anything they can do to disrupt it and make it nonfunctional they'll try. People have different reasons for their behavior. Some just want to cause destruction, some just want to hog up resources in a greedy way. But I think we should all agree that people act in their best self interests. And do things they thnk will benefit them even at the cost to others in some cases. I'm sure some of you guys/gals here on the forum are better than that and wouldn't try and abuse some feature of bitcoin but the world at large is another story. We can't just trust people do be nice in the real world. Bitcoin is better than that. Should be better than that.


That's right. I want anyone that runs a node to store the entire blockchain for me so that I can see all of my old transactions. You can call that greedy or whatever you like but to me, that's what I want.

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.


Curse all you like but you only have the bitcoin developers to blame for any shortcomings of the bitcoin protocol as far as what it allows people to do.

Well we got a bit off track but burner addresses are I would assume, to your way of thinking, an abuse of the bitcoin network. And to an extent, I would agree. But again, we only have bitcoin devs to blame for allowing something to be possible if they really do frown upon it. Now where I think you go wrong though is in assuming I or anyone wants to pay to store data. I'm well aware of services like filecoin but I don't think its a very good deal. It's only temporary storage. I am not willing to pay forever to store data. So you're wrong.

How about unlimited lifetime storage for $1000? Can you offer me that?

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

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.

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.

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.

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.

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.


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.

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.

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.


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.

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?

So isn't that an argument against pruning?

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.

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?

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

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

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 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.

"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.

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.

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.

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.

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.

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.

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.

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.
 
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.

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?

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.

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)

How does bitcoin core know me vs "other people"? How does it know which transactions are mine and which are "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. or consulting an external blockchain explorer to get transaction informations.

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?

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

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.

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.

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".

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

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.

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.

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.

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?

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...

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.

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

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.


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.

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 wasn't looking to create a new wallet. I already had a funded multisig address. Was just needing to spend from 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.


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.

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.

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

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.

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 (https://blockchair.com/bitcoin/transaction/f0cd68ea11f2d17d2e6a8d8aa19d929ccd35b6c70302da5bf6179df513dc8d42).

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".

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.

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

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

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).

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.

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.

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


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].


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 (https://en.bitcoin.it/wiki/OP_RETURN)
[2] https://electrumx.readthedocs.io/en/latest/protocol-basics.html#block-headers (https://electrumx.readthedocs.io/en/latest/protocol-basics.html#block-headers)

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...



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.


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.


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.

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?

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

No, it wouldn't. It would simply reduce the fee you need to pay to secure entry to the next block at times when the mempool is full, but it would make absolutely zero difference to the average block time and therefore the expected time for that next block to be mined.

If you want to reduce the confirmation time then you need to change consensus to aim for a lower difficulty. This doesn't solve the problem of making bitcoin "more usable in everyday life", though, since to have a block time low enough for point of sale transactions (i.e. a few seconds at most), you end up with frequent stale blocks and chain re-orgs, necessitating that you would have to wait for many more confirmations anyway.

You are right with what you say but I just meant that the average confirmation time would be quicker since many people just pay 1-2 sats/vByte and this transactions will also then get processed pretty quickly. Still it always depends of course on how crowded the network is and that at the moment is not a problem but could be one in the future. It was also planned to upgrade the block size by satoshi but since he disappeared it never happened.

I think in that last sentence, Satoshi correctly predicted that the max block size may never be increased. And I think the Bitcoin community will go that route, and if they will ever increase something, then it will be the max witness size, not the max block size. Also, you can see that the max witness size is just a parameter you can change in your node, everything is prepared for changing that, little tweaks here and there will do the trick, if the community will ever decide to do that.

Sounds like you just want every transaction in the mempool to be confirmed in the next block, regardless of how many there are or what fees they pay. There are already various forks of bitcoin which do this if this is what you are looking for, although be prepared for your money to be worthless since they all constantly devalue against bitcoin since nobody actually uses them.

It did happen. The limit on the block size was increased from 1 megabyte to 4 million weight units. This gives a theoretical maximum size of 4 megabytes, although the largest actual block we've had so far, block 682,482, was 2.4 megabytes.

Yes of course the value goes down since nobody needs the 5th fork of bitcoin that has nothing else than a little bigger block size, but thats not the point. If you for example don't like the Bitcoin logo you could also create a fork with a better logo and nobody would use it. Still it would not mean that people are not satisfied with your new logo.


Yes but if I remember correctly it was planned by satoshi to monitor the amount of transactions and then adjust the block size if it seems the mempool is to crowded. Not as a one time thing but maybe every few month or years. But I will research his posts to this.

But the mempool isn't too crowded. Yes, there are times when it fills up, but even then "high priority" fees only go up to a few dozen sats/vbyte which is hardly unreasonable, and it rapidly clears out again.

Here is a visual representation of the mempool over the last year: https://jochen-hoenicke.de/queue/#BTC%20(default%20mempool),1y,weight.

The vast majority of the time the mempool is not overly full, and even a fee of 1 sat/vbyte will confirm within a couple of blocks. If we reach the stage where the mempool permanently has a large backlog of transactions, and nothing below 50 sats/vbyte ever confirms before being dropped, then sure, there might be an argument for further increasing the block size. But at the moment that is far from the case.

There are people that pay more than 500 USD worth of bitcoin just to get their transaction confirmed in a reasonable time if the network is crowded. How can you be a professional payment network if you have to delay your shopping or payment because in a few days the fee could 100 times lower.. but that’s already very far away from the topic.

Anybody paying this much for a transaction fee either has no idea how bitcoin works and is grossly overpaying or has such a massive transaction that requires that much fee to be included in a block. $500 total fee with bitcoin @$30k is about 0.016BTC, assuming the tx size was 200 bytes that makes it a 8000 sat/byte fee. Never in entire bitcoin's history has fee gone up that much!

Here is an example of a massive transaction paying $480 fee for 270 kb (ie 1000 times bigger than regular transactions). The fee rate here is 11 sat/vbyte
https://blockchair.com/bitcoin/transaction/4ab61b2aa6aa16b00a4e3bed62ce0c476b230e3b99198833720e2ad54d697a69

Then that is the fault of those people, not bitcoin, as pooya has explained above. I've used bitcoin for years and probably around 95% of my transactions pay 1 sat/vbyte in fees. Increasing the block size doesn't stop people paying ridiculous fees if they don't know what they are doing. The solution to that is either education or wallet software for newbies which enforces a hard upper limit on how high of a fee you can pay.

Also worth noting that many of the transactions in the mempool which pay far higher fees than necessary are exchanges or other centralized services which have a much lower incentive to pay low fees since their customers cover their costs, such as Binance charging an absolutely outrageous 50,000 sats per withdrawal, which should actually cost a few hundred sats at most.

Again, no block size or block time is sufficient for point of sale transactions. The solution to this is either zero confirmation non-RBF transactions for values the merchant is willing to accept, or the Lightning network. If you are paying for something online or making a large purchase like a car or a house, then whether you confirm in 10 minutes or a few hours is irrelevant.

We have some upper limits in Bitcoin Core, you can mine 50 regtest BTC and test that. Putting for example 49 coins as a fee would be rejected by default, when the size of the transaction will be few hundred bytes or something like that.

The default limits for Bitcoin Core are here: https://github.com/bitcoin/bitcoin/blob/8be652e43964329c1f2dadd676916b53e5c40974/src/wallet/wallet.h#L106-L109

Essentially, you will return an error if you try to set a fee above either 0.1 BTC in total, or 0.01 BTC per kilobyte (which is 1000 sats/byte). Worth pointing out that these are simply local protocols for the Bitcoin Core wallet and are not consensus rules. High fee transactions are still perfectly valid and standard and will be relayed through the network just fine.

These are obviously absurdly high fees though. For newbies that don't know what they are doing and are paying $500 fees as suggested above, then they need to be shown a warning at much lower levels than this.

It's now "only" 20,000 sats (https://bitcointalk.org/index.php?topic=5402403.msg60350465#msg60350465), while they pay 1 sat/byte and even use unconfirmed parents (https://bitcointalk.org/index.php?topic=5402403.msg60348510#msg60348510) after which one of their users paid 10 LTC (https://bitcointalk.org/index.php?topic=5402403.msg60354222#msg60354222) to accelerate it.
Just one of many reasons why I don't like the scam exchange (https://bitcointalk.org/index.php?topic=5370726.msg59540906#msg59540906).

Me too, but the one transaction I made around 800 sat/byte (in 2017) seriously increased my average fee per transaction.

The mean blocktime is 10 minutes.  In the exponential distribution, the mean is meaningless to everyday life.  Median blocktime is about 7 minutes; lowest quartile is <= ~3 minutes; upper quartile is >= ~13 minutes.  IMO, it means much more to everyday usage that half of blocks are much faster than 10 minutes (but the average is dragged up to 10 minutes by the long exponential tail).

---

He explicitly wants to force others to pay a cost that he explicitly refuses to pay.  I was correct when I accused him of being “actively malicious”.

The funny part is, his understanding of Bitcoin is so poor that he doesn’t even know what node pruning does and does not do.  He believes that node pruning affects his view of block explorers, and make his own transactions unavailable.  Say what!?  Node pruning is strictly opt-in, and it only affects local data availability for those who choose to prune their own nodes.

Last week, I began writing a post to split this misunderstanding off to Beginners & Help, where it properly belongs and where the discussion may help others.  (Interrupted by personal circumstances 13 June (https://bitcointalk.org/index.php?topic=178336.msg60362257#msg60362257); no time for it now.)

---

I disagree.  I think that they suffered some application of the Law of Intended Consequences, and then realized how profitable it is to rip everyone off for gas.

There exist Ethereum competitors who attain Turing completeness at much lower cost; and I think that it could be done even better!

Nowadays, most gas is burned.  That reduces the supply of ETH.  After they started the gas-burning thing, something like $5 billion worth of ETH was burned in the latter part of 2021.  How does this work in practice?  Speaking from experience:  I myself wound up paying about $2,000 for gas with ETH at $3.8k–$4k, just because I needed to make a relatively small number of contract invocations; thus, I had to bid up ETH at high prices to burn most of what I bought, with the rest going to miners.  (I currently hold no ETH but dust.)

I think they like that situation just fine.

Well to be fair, bitcoin itself isn't tied to anything of value. So it really has no value other than perceived value - the value people attribute to it in their own head. That is one of its weaknesses. Creating bitcoin and then trying to layer value on top of it by hooking it up with stablecoins is not an ideal solution. As we can see, stablecoins have their own issues. One of them being they are not trustless. So the value bitcoin has can't be considered trustless if bitcoin is ever based on one.


That's a minor issue with bitcoin is that someone can make a duplicate copy of it and the only difference between their copy and the real bitcoin is the popularity of one of them.

That’s a common myth.  Bitcoin’s price is not directly caused by subjective perceptions:  It is a result of the market, based on supply and demand.  Perceptions are one factor in the “demand” side of that.  There are other factors to demand; and perceptions do not alter supply.

Ultimately, Bitcoin’s fundamental value derives from its facilitation of productive economic activity, which would be costlier, infeasible, or impossible without Bitcoin.  I know that I have done productive non-Bitcoin, non-market business with Bitcoin, which I could not have done without Bitcoin.  That’s not extraordinary:  It is being an ordinary Bitcoiner who uses Bitcoin as money, rather than a purely speculative buyer who just wants “number go up”.  The more such people they are, the higher the organic, non-speculative demand for BTC.

This discussion of economics is far off-topic for the development forum.  I feel obliged to answer something that is more usually nocoiner FUD or newbie confusion.  If you have further questions about this, I refer you to Bitcoin Discussion or Economics.


You talk like a Bcasher with Bitcoin Envy.  If you suppose that the only difference is popularity, your gross ignorance is showing (again).

Bitcoin forks often retain design flaws that Bitcoin has fixed, such as the transaction malleability fixed by Segwit.  (Part of my wrath at Bcashers is anger about how by opposing and FUDding Segwit, they sought to preserve a security flaw.)  Many of them are ill-maintained.  None of them has Bitcoin’s network security against double-spends (and indeed, some of them have been 51%-attacked).  This list of differences could be much continued; but I think most people with the knowledge level to post in the development forum are already very well aware of the diffrences.

To be pedantic: 63.2% of blocks are faster than 10 minutes.

Still, the point still stands that increasing block size does nothing to reduce block time or make bitcoin more suitable as a point of sale currency. For this, you need second layer solutions.

That is a problem for people who are using stablecoins, and not for bitcoin. Bitcoin had value long before stablecoins existed. Bitcoin will have value long after the last stablecoin has imploded, as seems to be the trend. I have never once owned a single cent of a stablecoin or ever so much as thought about the value of my bitcoin in terms of stablecoins. If your tie your bitcoin in to some stablecoin and that stablecoin collapses, then that's a problem for you, but bitcoin will continue on unchanged.

If you believe that to be the case, then why haven't heavily advertised forks which are bankrolled by centralized parties taken the top spot? There is much more bitcoin has over useless forks than its popularity.

Pedantry is good.  I spoke imprecisely.  I was thinking of the median.  Statistically, exactly 50% of blocks arrive within about 6:56 m:s or less; that is >= 30.7% faster than 10 minutes, “much faster” in my book.

Although this is tangential to the context in which it was raised, I miss no opportunity to help address a common error.  Most Bitcoiners get this wrong—even most regulars in Development & Technology.  Most blocks take nowhere near 10 minutes to arrive; the average of the exponential distribution is almost meaningless to everyday-life usage questions of “how long will this take?”, and the exponential distribution generally defies human intuition.

People also tend not to understand that in a memoryless system, the statistically expected arrival time starts “right now”—whenever “now” is.  Without checking when the last block occurred, I know that at the moment I make this post, the next block has a 25% chance of arriving within about 2:53 from now, a 50% chance of arriving within 6:56 from now, a 75% chance of arriving within 13:52 from now, and a 25% chance of arriving >= 13:52 from now.  The arrival time of the last block is irrelevant.


Increasing the block size to reduce confirmation time would be like purposely becoming obese to become a better marathon runner.  Say what?  It won’t work, and it’s unhealthy.

Which is 0.693 of 10 minutes, with 0.693 of course being the natural logarithm of 2. Isn't math fun!

I have saved a rough draft of a post I've been meaning to polish up and post for a while regarding Poisson processes, because as you say, they are generally poorly understood even by more experienced users. It was inspired by this post and the discussion which followed: https://bitcointalk.org/index.php?topic=5368838.msg58369934#msg58369934

This is important, as we seen not infrequently people proposing to reduce the block time to 1 minute (or something similar) in an effort to allow bitcoin to be used for point of sale transactions, not realizing that even with such a short average block time a not insignificant number of blocks will still take far too long to be found to make point of sale transactions reliably quick (without even mentioning the other problems which accompany a reduced block time, such as increased stale blocks and chain re-orgs).