Topic: A suggestion to periodically destroy (or remove to secondary storage for Archivi (Read 236 times)

Anyways, I am not discussing Satoshi fractions UTXOs here, I'm just ringing a bill that there is more than 10.8 m addresses holding less than 350BTC
This is ≥13.5% of total UTXOs, and even addresses are just a lowerbound on UTXOs ( can hold more than 1 UTXO)
 They all holding less than 10,000 Sat with an average of 3300 Satoshi each  
...
You could warn people that say after  1 month, any UTXO below some threshold is  say more than 6 months age will be donated (instead of deleted) next month.
People who care about their few cents will simply wait for a low TX fee time and collect their UTXOs in a single larger one

You are wrong. Old nodes would not accept blocks as you describe.

Each block can have its coinbase transaction have an output total the block subsidy plus the sum of all inputs, less the sum of all outputs. However, coinbase transactions do not need to receive the total amount and can receive less, in which case the subsequent amount will not carry over to future coinbase transactions in future blocks.

Further, when a single satoshi output is received to a new address, when that output is combined with other unspent outputs, the sum of the inputs to this transaction will not equal the sum of the outputs (less the tx fee).

-For burned you may archive them as I said about dust
.
-For  lightning TX adding dust, let me add before I answer that in bitInfoCharts there are more 7.6m (i.e. making a total of 10m UTXOs≤ 4.1$ this way with av. 3312Sat. each).
-Back to the LN matter, well I don't recall that from Tadge Dyraj MIT lectures about HTLC, but it was mentioned in the Bitcoin-Dev list here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019636.html

When I recontacted the msg writer he replied
.
In fact, I do not find his explaination changing the main fact ... you force them to create 2 when the lock is ended 1 signed by the party who get the money is spent, the spending of the other is optional.
.
Let me add the fact that in today 10 Feb 2022, 18:51 Egypt timing, at least (no. addresses are lowerbound on UTXOs) 13.536% of the total set are less than 10,000 Sat (10,810,544 < 0.0001 BTC, UTXO today is 79.863m)

One of the good things about bitcoin is that it is not like the banking system!

Not always. The IsStandard() method seems to have some cracks that transactions could still fall through. For example a PMS or P2PK output script could contain provably invalid public keys or P2WPKH scripts could pay to a hash that has a CastToBool() == false since the program itself is not checked.

They are most probably burnt not provably burnt.

This doesn't sound correct.

It is more complicated, because it is casted between int64 and uint32. It was discussed here: https://bitcointalksearch.org/topic/going-backward-in-time-5365359
You can set your time to 2040 and see that Bitcoin Core will have problems with that. And because doing it in backward-compatible way is impossible, it has to be done in a hard-fork way.

1- First, I do not understand what the fraction bits and the idea of 0.5 Sat has to do with what I'm suggesting?Fractions appeared in my original post in average only and that's not a real value in the ledger.

2-About those being funds or people money, would you accuse a bank of stealing/destroying your money if they announced accounts with less than 1$ (≤41 cent in our case) have say 6 months to be spent otherwise we are going to close them?

3-
I think this is classified/included in non-standard UTXOs; that's my understanding.

4-I know those burned UTXOs are not officially classified as burned by Bitcoin Core, but they are burned. Both are published as burn addresses, and one of them is the zero address no one can retrieve them.

5-Maybe it seems right now this improvement (saving about 5% of storage)is kind of doesn't worth the effort or the trouble. However, keep in mind that every lightning network TX adds 1 dust UTXO, the number increased by about 2k in one day (from 3.1489m to 3.1509m) all holding 0.01 BTC in total
.
-Finally, I do not have a Bitcoin full node to start a fork!
I'm just like finishing/completing a research thread that I've started so that I don't leave a missing piece(s) to whoever may read it even as a survey or report in the future, but I've begun reading and almost moved to another research point.

That single satoshi is not burned. If you create outputs with zero satoshis that contain non-zero amounts (seen only by new nodes), then old nodes will see that as fees. So, to keep track of fractional satoshis, some additional coinbase output can be created, then this single satoshi will be first collected and saved as a coinbase output, when sending two 0.5 satoshi transaction, and will be taken back when sending one satoshi later to the old address. But: that satoshi will be ever taken only when sending back to the old address. In case of sending to the new address, it will be a single satoshi, expressed as a zero satoshi output.

Because the BTC community agreed that things should be solved in a soft-fork way, whenever possible. Every problem can be solved in a hard-fork way, but BTC decided to not do that, unless we are forced to do so (like in 2038 year problem). So, technically you can just do a hard-fork, but practically many BTC users will disagree, so you will see a hard-fork introducing fractional satoshis on other coins, and a soft-fork on BTC.

I asked if there is a technical reason why there can't be a hard fork, not if there is a reason why one would not be needed. As I noted, a hard fork is not needed currently.

It seems I previously responded to your referenced thread, and as I previously mentioned, a soft fork would not be a solution to allowing for increased precision for bitcoin transactions. For example, if Bob were to send Allice two 0.5 staoshi transactions, Alice could proceed to send Charlie a 1 satoshi transaction (all ignoring tx fees) that should show up as 1 satoshi. A non-upgraded node would see a transaction with two zero-value inputs and one output worth 1 satoshi, which would violate consensus rules and as such would be invalid.

Yes, it is. There is no need for any hard-fork if you can do the same in a soft-fork or no-fork way. Currently, LN counts things in millisatoshis. There are less than 2,1*10^15 satoshis, but it does not mean there will be less than 2,1*10^15 UTXO's. You can create zero satoshi outputs and spend them. It is non-standard in mainnet, but acceptable in testnet, so you can see how it works. If you want to represent millisatoshis on-chain, you can use zero satoshis and add consensus rules to count things properly (old nodes will see zeros, so they will skip amount validation, new nodes will check everything). Also, when we will have a need to use smaller amounts, it will probably be possible to represent any coin owned by many people in a single UTXO. Also there are more ideas to represent fractional satoshis, just there is no need to introduce them now: https://bitcointalksearch.org/topic/representing-fractional-satoshis-in-difficulty-like-format-5330102

Yes, that's what we mean by hard forking. It's entirely possible to have a distinguish between amounts prior the change and after the change. For instance, the transactions with the extra decimals could contain some sort of prefix to avoid your problem.

I think we've taken a completely hypothetical scenario. However, if it ever became extremely expensive, it's a reasonable question that requires some discussion, you can't just deny that Bitcoin must remain the same. Every time it changed, it was for the better.

Is there a technical reason why we could not implement a hard fork that changes the units (a single satoshi) to 1.00 verses 1? Obviously, such a hard fork is not needed currently, but if the price increases enough, or if adoption is sufficiently high that single satosi transactions are common, a hard fork may be necessary.

The above would change the current block subsidy (not reward, the reward includes both the transaction fees and the block subsidy) to 625000000.00 per block. I don't think the above would affect the halving logic, as it could remain unchanged.

Non-standard is just a point of view. For example OP_0 <160-bit> is non-standard if you ask bitcoin core v0.13 or OP_2 <256-bit> is non-standard if you talk to bitcoin core 22.0. That doesn't mean you can get rid of any of them though.

Only coins sent to OP_RETURN outputs are burnt, everything else including the 2 examples here are NOT.


P.S. At least if you want to talk about deleting UTXOs I was expecting you to mention unspendable scripts not spendable but small ones! That would have at least made some sense. Outputs like the one that used an empty hash like this:
This is provably unspendable.

bitcoin already has dust limits to make small amounts not really viable for spending

---

the bitcoin protocol does not have decimal places. never has, never will. and nothing should change that
your talking about the GUI display math that makes large numbers look small on screen for human visual aid graphic representation

the protocol has the reward currently sitting at 625000000 units per block.
100101010000001011111001000000 in binary
thats the real hard rule.
not the gui software display denomination of 6.25

bitcoin started with
100101010000001011111001000000000   =5000000000(50)
halving simply removes a binary bit
10010101000000101111100100000000     =2500000000(25)
1001010100000010111110010000000       =1250000000(12.5)
100101010000001011111001000000         =625000000(6.25)

to add 3 "decimals" is not simply adding on bits

it changes current 6.25
100101010000001011111001000000
to become
1001000110000100111001110010101000000000

this not only affects the numerics long term
but also the number of halvings remaining, meaning 10 extra halvings meaning changing from a 2140 end date to 2180 end date

but not only that.
a legacy node would see 'new' value appear as 6250btc where new software sees 6.25000000000
a new software would see legacy value appear as 0.0625000000

so alot of cludgy math and checks would need to be done to make sure no one accidentally swaps wrong value from legacy to new
very ugly to do and can cause alot of bugs and problems

especially if a change such as this does not last or gets undone. suddenly reverting to legacy means that 1000X more coins were made during the period than it should have.

no one should even be considering breaking bitcoin that much to fit some other network numeric scheme.. if the other network doesnt match bitcoin numerics. THEY should change THEIR network protocol to match bitcoin.. not the other way around.

I think there is an argument to keep very small UTXOs on your hard drive rather than in RAM. Anyone who owns a small UTXO could still do so, however, a node who receives a transaction/block with a UTXO under a threshold would need to access the UTXO stored on their hard drive rather than in RAM to validate if it is part of the UTXO set.

The above would reduce costs associated with running a node as RAM is much more expensive than hard drive storage, and there are many UTXOs that are unlikely to ever get spent.

---

As Dave mentioned, under no circumstances should any UTXO go from being spendable to being non-spendable.

So easy, that's Bitcoin. That's why Bitcoin was, is and will always be successful.

Why don't you do it? Why do you want our responses if you think it's a good idea? Dave told you that it's pointless as Bitcoin promotes immutability, but you disagree. No problem, that's why forks exist.

Fork the code and start modifying it. Do what you believe that it's better for the community and if it gets recognition, you will have made it. However, this will not be true:
And it'll never be true, because the moment you, either individually or collectively, start censoring what's Bitcoin and what's not, that very moment, you will have harmed the principles. And I know that when people put their privileges above their principles, they soon lose both.

1-Your hypothetical claim means 1BTC will reach 100m$ (10⁸)
2-you can remove them to secondary storage for archiving, just not being part of the system state.
3-you will give people a warning, so whomever wants to collect a few cents forgetten here or there can collect them.
.
4-Burned & non-standard UTXOs will never be needed, and even if they are a less burden they will add more scarcity because they do hold considerable BTC values

It's not needed.  It's pointless.

And if 1BTC becomes worth some truly large value of fiat and it's decided to add more decimal places to the protocol since 0.00000001 is now worth $1 then you just took a lot of money out of a lot of peoples pockets.

The entire point of BTC is that it's an immutable blockchain and what is there today will be there FORVER. Period. Full stop.

-Dave

-I think you may remember me sending to you about my proposal to partition ( and other stuff all about) the UTXO set Merkle in bridge servers providing proofs Stateless nodes.
-While those previous suggestions might not have been on the most interest of core Developers, I think this one I happened to notice is:

-When I contacted bitInfoCharts to divide the first interval of addresses, they kindly did divided to 3 intervals. From here:
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
-You can see that there are more than 3.1m addresses holding ≤ 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat per address.
-Keeping in mind that an address can hold more than 1 UTXO; ie, this is even a lowerbound on the number of UTXOs holding such small values.
-Noticing also that every lightning network transaction adds one dust UTXO (actually two one of which is instantly spent, and their dust limit is 333 Sat not even 546), ie, this number of dust UTXOs will probably increase with time.
.
-Therefore, a simple solution would be to follow the difficulty adjustment idea and just delete all those, or at least remove them to secondary storage for Archiving with extra cost to get them back, along with non-standard UTXOs and Burned ones (at least for publicly known, published, burn addresses). Benefits are:

1- you will relieve the system state from the burden of about 3.8m UTXOs
(3.148952m
+ 0.425m non-standard
https://txstats.com/dashboard/db/non-standard-outputs-statistics?orgId=1
+ 0.178m burned
https://blockchair.com/bitcoin/address/1111111111111111111114oLvT2
https://blockchair.com/bitcoin/address/1CounterpartyXXXXXXXXXXXXXXXUWLpVr
as of today 6Feb2022)
, a number that will probably increase with time.

2-You will add to the scarcity of Bitcoin even with a very small amount like 14.9 BTC. ( But for non-standard it's about for 12.6k, for burned maybe more)

3-You will remove away the risk of using any of these kinds for attacks as happened before.
.
-Finally, the parameters could be studied for optimal values; I mean the 1st delete, the periodical interval, and also the delete threshold (maybe all holding less than 1$ not just 546 Sat need to be deleted, can you imagine 7.6m more holding less than 4.1$ with av. of 1.882$ per address)
.
That's all
Thank you very much