Bitcoin Forum
September 02, 2025, 08:16:08 AM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
   Home   Help Search Login Register More  
Warning: One or more bitcointalk.org users have reported that they strongly believe that the creator of this topic is a scammer. (Login to see the detailed trust ratings.) While the bitcointalk.org administration does not verify such claims, you should proceed with extreme caution.
Pages: « 1 [2]  All
  Print  
Author Topic: Why Proof of Burn cannot work cleanly in practice  (Read 1659 times)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420
Merit: 262


View Profile
November 16, 2015, 01:51:56 PM
Last edit: November 16, 2015, 02:34:40 PM by TPTB_need_war
 #21

Inertia is an interpretation of the (history of the) UTXO. It it is the context in which it is interpreted that gives rise to my design. Sure anyone can make transactions to themselves and even avoid TX fees if they are also the confirmation delegate to Sybil attack the UTXO, but...

I don't have enough info to reason about this Smiley I'll have to wait for your doc

I was purposeful too vague and abstract Embarrassed.

Just because someone can Sybil attack the UTXO, doesn't necessarily follow they can Sybil attack the "inertia" which an interpretation (a chronological, partitioned structuring) of the UTXO. Someone could send a zillion transactions to their Sybil addresses (if they can recoup the TX fees by running their own full node), but if the rest of the inertia doesn't consume those UTXO, then it isn't inertia and it is a private, virtual "subnetwork" of the attacker.

I have mentioned the long-term inertia limits the rate of change in the near-term (a form of anti-aliasing) so that objective reality in the near-term moves into the long-term history before the rate of change could enable a double-spend by "replacing the 51% of delegated authority".

It is not possible for collusion of delegates to prevent even very small percentages of the inertia from being confirmed by an ever spreading percentage of the inertia, thus the colluding delegates implicitly remove themselves from the system by censoring the growing inertia. Unlike with PoW, there is no way to stomp out all permission-less activity as it acts more like a virus that spreads. The only way to be congruent with the virus-like quality of the inertia is to not censor any portion of the inertia. During battles over perspective, there can be partial orders (partitions) in terms of consensus, but there can't be invalidity because of the anti-aliasing. The payee only has to fear that a particular partition will complete die, but due to the way inertia infects itself, this is extremely unlikely. I think I read that all of us are connected by on average only 5 degrees-of-acquaintances. Again consensus systems are probabilistic. Just like with Bitcoin, the probability of an orphaned virtual partition declines over time. One difference from Bitcoin is there isn't the requirement of not more than one virtual partition (just one longest chain), yet convergence is probabilistically inevitable. If you conceptually combined DPOS and Iota, you'd be closer to my design.

The inertia is in control. It is a force of the users. It is what we idealistically thought PoW was supposed to be as a decentralized vote. The incentive of the user to be able to transaction freely (with any human at any time, not just some portion of the UTXO) is the inertia.

One of the important aspects of making this work correctly is going entirely against the concept that Bitcoin should be only for a reserve currency for the large stake holders. To make my design work, the users of currency must be the determinants of the inertia. Micro-transactions and the need to transact widely with any one at any time without any Lightning Network corporate servers building "harvestwalls" (or however data harvesting is employed to extract profit) or other means of the rich continuing to parasite on and interfere/throttle/limit the individuals (the entropic force) that is the real economy.

I think that will be enough hints for now.

Edit: one more point is that if there are multiple long-term histories, the most objective one is the one which has all the (valid) transactions, i.e. combine the multiple histories if no one else has yet. In my analysis thus far, I have not found an ambiguity in the objectivity. The key design insight was employing anti-aliasing to make validity unambiguous.

d5000
Legendary
*
Offline Offline

Activity: 4382
Merit: 9285


Decentralization Maximalist


View Profile
November 17, 2015, 01:02:07 AM
 #22

My point is that unless the currency fluctuation is extreme to the point of causing general economic malaise, then the users of that currency as a unit-of-account have no appreciable individualized risk risk w.r.t. to the international exchange fluctuations.

I got your point here and it's perfectly acceptable for me. I have some doubts if it's possible for a cryptocurrency to become that stable (that's why I mentioned national fiat currencies). Ideally it should be that way, yes. I don't want to profoundize this issue because I think it's not that relevant for the discussion of Proof-of-burn's security.

Quote
Thus if a crypto-currency is intended to become a currency (e.g. a unit-of-account), then the "nothing at risk" will apply and my point is the "rich get richer" applies.
So let's take an ideal crypto-currency without significant price variations. Then the risk still is larger than zero because Proof of Burn does not return you exactly what you deposited, like Proof of Stake does. There are several variables that have incidence, being the most important the fluctuation of the amount of total "burnt" coins (if you burn, you cannot predict if there will be larger burns in the near future that may affect your profit).

Quote
In short, I don't see how adding risk to stake or burn deposits improves the issues with "nothing at stake" and advantage to those with the most to stake.

Here i think you misinterpreted me (I am sorry, I am not a native English speaker). I don't think PoB improves over PoS when considering the Nothing at stake problem. What I think is that in PoB there is a less direct relation between wealth and mining/minting rewards. That whole sentence was an answer to clemahieu's posting.

I also am aware of the "Short sell / Pirate attack".

Quote
It is a simple fact that volatility declines with increased liquidity (participation) and thus price. So by definition a more volatile and risky investment will have a smaller market cap and thus less security (relatively speaking). Even in my proposal to use "inertia" at the objective metric of consensus, the larger the participation, then the stronger the security of more inertia (at least the "inertia" I have in mind scales by n2 though).

That's completely true, my intention was not to put this into question.

Quote
Whereas, your described a design where risk declines as value increases, thus your security that depends on risk declines as the value increases which could provide more security. So you have two things working against each other in that design. Seems flawed.

That would be totally flawed, I agree Wink. But again, you misunderstood me. The equation of the Slimcoin and similar PoB designs is not "more risk - more security". It is totally true that in a mature market with less volatility also in Slimcoin's design the security is higher.

Perhaps I was not clear enough to make this distinction: In the first stage of a cryptocurrency - talking about the first six months, for example - in a Proof of Burn design like Slimcoin's, there can be a high participation rate although the value still is small and volatile. In Slimcoin, this ocurred, because many people saw burning in the first stage as an opportunity to grow their amount of coins and speculated on a increasing or at least stable price. But that does not mean that it's security is higher in this first volatile phase. First, because in a mature market participation should be high too because of the lesser risk, as you correctly point out, and second, because of the then probably higher price of the coins you must burn to have a possibility to attack the chain.

earonesty
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
March 07, 2016, 07:15:05 PM
 #23

You have to burn within the last 50 blocks, you cannot burn more recently than the last 10 blocks.   This effectively implements a "checkpoint".   Change the numbers of blocks as needed so that you're talking about days and hours.
monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1009


View Profile
March 07, 2016, 07:39:04 PM
 #24

You have to burn within the last 50 blocks, you cannot burn more recently than the last 10 blocks.   This effectively implements a "checkpoint".   Change the numbers of blocks as needed so that you're talking about days and hours.

'When' are the last 10 blocks?
monsterer2
Full Member
***
Offline Offline

Activity: 354
Merit: 134


View Profile WWW
April 07, 2025, 07:42:45 AM
 #25

I thought I'd update this idea with a solution to the problem as stated and also a great reason why no one will ever implement proof of burn as described in the OP:

The goal is to produce a design equivalent to Bitcoin, with the same objective consensus mechanism and security guarantees.

The major problem as stated is that miners can just dump a bunch of blocks mined in secret onto the chain to orphan the best branch instantly (Finney attack) to recoup the supposedly "sunk cost" of burning coins.

There is a way to mitigate this problem, which is to make the chain a DAG and have it be totally ordered by maximum cumulative burn. That way attackers burns always end up being a sunk cost because the DAG has a total order and no branches are orphaned.

The problem that this creates is no the is no competition to mine blocks, because every burn in the DAG counts, so every miner wins. This is a critical flaw.

The logical conclusion is to use the total order to define a rolling window of N burns, the largest of which will win the block reward. Once the reward has been won by a burn, that burn is no longer eligible to receive new rewards, the miner must burn again to be eligible. Of course, then it is optimal for every miner to submit N-1 tiny burns and one slightly larger one such that they always win the reward, leading to spam and chaos. To mitigate the problem you have to limit the block reward to the sum of the burns within the window.

Once you've done that, there is no incentive to mine because a miner can never win. If you increase the reward to be slightly larger than the sum of burns, then the coin will hyper inflate instantly because there is nothing limiting the time between blocks.

So, after all that we've learned two things, the under the heading Satoishi didn't make mistakes:

1) Without some objective measure limiting the time between blocks, you cannot have a block reward.
2) Without a mining incentive there will be no security in the chain

Hope you enjoyed this rambling and please feel free to shoot me down.

Cheers, Paul.

https://theunspent.com - the truth behind the news
nutildah
Legendary
*
Offline Offline

Activity: 3458
Merit: 9936



View Profile WWW
April 07, 2025, 08:00:56 AM
 #26

Interesting to see that you came back to expand on a nearly 10-year-old thought. I'm just curious was to what is being burned in your hypothetical: is it BTC or an entirely new coin? If its the latter, it means that you will have issued the entire supply at the genesis block, which leads to distribution issues. Perhaps I'm not totally following your idea but if implemented correctly, PoB has the capability to be the fairest consensus mechanism there is.

.
 betpanda.io 
 
ANONYMOUS & INSTANT
.......ONLINE CASINO.......
▄███████████████████████▄
█████████████████████████
█████████████████████████
████████▀▀▀▀▀▀███████████
████▀▀▀█░▀▀░░░░░░▄███████
████░▄▄█▄▄▀█▄░░░█▄░▄█████
████▀██▀░▄█▀░░░█▀░░██████
██████░░▄▀░░░░▐░░░▐█▄████
██████▄▄█░▀▀░░░█▄▄▄██████
█████████████████████████
█████████████████████████
█████████████████████████
▀███████████████████████▀
▄███████████████████████▄
█████████████████████████
██████████▀░░░▀██████████
█████████░░░░░░░█████████
███████░░░░░░░░░███████
████████░░░░░░░░░████████
█████████▄░░░░░▄█████████
███████▀▀▀█▄▄▄█▀▀▀███████
██████░░░░▄░▄░▄░░░░██████
██████░░░░█▀█▀█░░░░██████
██████░░░░░░░░░░░░░██████
█████████████████████████
▀███████████████████████▀
▄███████████████████████▄
█████████████████████████
██████████▀▀▀▀▀▀█████████
███████▀▀░░░░░░░░░███████
██████░░░░░░░░░░░░▀█████
██████░░░░░░░░░░░░░░▀████
██████▄░░░░░░▄▄░░░░░░████
████▀▀▀▀▀░░░█░░█░░░░░████
████░▀░▀░░░░░▀▀░░░░░█████
████░▀░▀▄░░░░░░▄▄▄▄██████
█████░▀░█████████████████
█████████████████████████
▀███████████████████████▀
.
SLOT GAMES
....SPORTS....
LIVE CASINO
▄░░▄█▄░░▄
▀█▀░▄▀▄░▀█▀
▄▄▄▄▄▄▄▄▄▄▄   
█████████████
█░░░░░░░░░░░█
█████████████

▄▀▄██▀▄▄▄▄▄███▄▀▄
▄▀▄█████▄██▄▀▄
▄▀▄▐▐▌▐▐▌▄▀▄
▄▀▄█▀██▀█▄▀▄
▄▀▄█████▀▄████▄▀▄
▀▄▀▄▀█████▀▄▀▄▀
▀▀▀▄█▀█▄▀▄▀▀

Regional Sponsor of the
Argentina National Team
monsterer2
Full Member
***
Offline Offline

Activity: 354
Merit: 134


View Profile WWW
April 07, 2025, 02:54:16 PM
 #27

Interesting to see that you came back to expand on a nearly 10-year-old thought. I'm just curious was to what is being burned in your hypothetical: is it BTC or an entirely new coin? If its the latter, it means that you will have issued the entire supply at the genesis block, which leads to distribution issues. Perhaps I'm not totally following your idea but if implemented correctly, PoB has the capability to be the fairest consensus mechanism there is.

Those are great questions.  Entirely new coin was the original design, and yes you're correct the entire supply has to be issued in genesis because as I wrote, you cannot increase supply via block reward without instant inflation. Essentially, it's a liquidity problem...

Had the design looked promising, I was thinking to add USDC to the chain which would be the thing that you burn to mine native coins and have the supply start at 0, to mirror bitcoin's "anyone can mine" philosophy.

https://theunspent.com - the truth behind the news
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!