Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> There is a smarter way. Just send 0.01 BTC per block to the timelocked outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that percentage will grow over time, as basic block reward will shrink, and we will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply means you can lock 2,100 BTC in an endless circulation loop, and avoid this "tail supply attack". My understanding of this is that it would basically remove 0.01 BTC rewards from the next 210k blocks, and then do nothing. After 210k blocks have passed, you're just rolling it forward, taking from the anyone can spend output and locking it in a new one for 210k blocks from now. You're basically just using the next 210k block's reward to create a stash of forever locked coins in a loop. Unsure how this solves or relates to the smoothing of block rewards. Let me know if I misunderstood. Gino Pinuto via bitcoin-dev escreveu no dia quinta, 14/07/2022 à(s) 13:18: > This is not an argument in line with bitcoin values, on that scenario only > rich people will be able to mine and participate to the consensus process. > Like George Soros today, he use its financial reserves to monopolize ONG > in order to manipulate nation states. I would not define this a "tax", > moreover a cost to maintain control over the network. > > Those rich holders could crate a cartel and without market dynamics all > game theory stop to work and the bitcoin network value drop. > > We should think about how to maximise the network value instead of trying > to preserve it with corruptible practices outside of market dynamics > principles. > > On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Fees and miner rewards are not needed at all for security at all since >> long term holders can simply invest in mining to secure the value of their >> stake. >> >> Isn't it enough that the protocol has a mechanism to secure value? >> >> Sure fees *might* be enough. >> >> But in the event that they are not, large holders can burn a bit to make >> sure the hashrate stays high. >> >> I know, I know it's a tax on the rich and it's not fair because smaller >> holders are less likely to do it, but it's a miniscule tax even in the >> worst case >> >> >> >> >> >> >> >> >> >> On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> > This specific approach would obviously not work as most of those >>> outputs would be dust and the miner would need to waste an absurd amount of >>> block space just to grab them, but maybe there's a smarter way to do it. >>> >>> There is a smarter way. Just send 0.01 BTC per block to the timelocked >>> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that >>> percentage will grow over time, as basic block reward will shrink, and we >>> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess >>> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it >>> simply means you can lock 2,100 BTC in an endless circulation loop, and >>> avoid this "tail supply attack". >>> >>> So, fortunately, even if "tail supply attackers" will win, we will still >>> have a chance to counter-attack by burning those coins, or (even better) by >>> locking them in an endless circulation loop, just to satisfy their >>> malicious soft-fork, whatever amount it will require. Because even if it >>> will be mandatory to timelock 0.01 BTC to the current block number plus >>> 210,000, then it is still perfectly valid to move that amount endlessly, >>> without taking it, just to resist this "tail supply attack". >>> >>> >>> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> > What about burning all fees and keep a block reward that will smooth >>> out while keeping the ~21M coins limit ? >>> >>> This would be a hard fork afaict as it would go against the rules of the >>> coinbase transaction following the usual halving schedule. >>> >>> However, if instead we added a rule that fees have to be sent to an >>> anyone can spend output with a timelock we might be able to achieve a >>> similar thing. >>> >>> Highly inefficient example: >>> >>> - Split blocks into 144 (about a day)
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ? This would be a hard fork afaict as it would go against the rules of the coinbase transaction following the usual halving schedule. However, if instead we added a rule that fees have to be sent to an anyone can spend output with a timelock we might be able to achieve a similar thing. Highly inefficient example: - Split blocks into 144 (about a day) - A mined block takes all the fees and distributes them equally into 144 new outputs (anyone can spend) time locked to each of the 144 blocks of the next day. - Next day, for each block, we'd have available an amount equivalent to the previous day total fees / 144. So we deliver previous day's fees smoothed out. Notes: 144 is arbitrary in the example. This specific approach would obviously not work as most of those outputs would be dust and the miner would need to waste an absurd amount of block space just to grab them, but maybe there's a smarter way to do it. Gino Pinuto via bitcoin-dev escreveu no dia quarta, 13/07/2022 à(s) 13:19: > What about burning all fees and keep a block reward that will smooth out > while keeping the ~21M coins limit ? > > Benefits : > - Miners would still be incentivized to collect higher fees transaction > with the indirect perspective to generate more reward in future. > - Revenues are equally distributed over time to all participants and we > solve the overnight discrepancy. > - Increased velocity of money will reduce the immediate supply of bitcoin > cooling down the economy. > - Reduction of velocity will have an impact on miners only if it persevere > in the long term but short term they will still perceive the buffered > reward. > > I don't have ideas yet on how to elegantly implement this. > > > On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > The emission curve lasts over 100 years because Bitcoin success state >> requires it to be entrenched globally. >> >> It effectively doesn't. The last 100 years from 2040-2140 only emits a >> pittance of about 0.4 of all bitcoin. >> >> What matters for proper distribution is the shape of the emission >> curve. If you emit 99% in the first year and 1% in the next 100 years, >> your emission "lasts" over 100 years, and you achieve a super low >> supply inflation rate immediately after 1 year, but it's obviously a >> terrible form of distribution. >> >> This is easy to quantify as the expected time of emission which would >> be 0.99 * 0.5yr + 0.01* 51yr = 2 years. >> Bitcoin is not much better in that the expected time of emission of an >> bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years. >> >> Monero appears much better since its tail emission yields an infinite >> expected time of emission, but if we avoid infinities by looking at >> just the soft total emission [1], which is all that is emitted before >> a 1% yearly inflation, then Monero is seen to actually be a lot worse >> than Bitcoin, due to emitting over 40% in its first year and halving >> the reward much faster. Ethereum is much worse still with its huge >> premine and PoS coins like Algorand are scraping the bottom with their >> expected emission time of 0. >> >> There's only one coin whose expected (soft) emission time is larger >> than bitcoin's, and it's about an order of magnitude larger, at 50 >> years. >> >> [1] >> https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin covenants are inevitable
"Long time listener, first time caller". Just sharing my 2 sats: While I find it stimulating, I think this discussion (and other similar doom-like scenarios) is somewhat irrelevant in practice. When the time comes and if we start seeing issues with block rewards being too low to maintain acceptable security, we're going to have multiple solutions being implemented for it, and definitely a hard fork to indefinitely maintain some degree of block subsidy is going to be within them. If it is indeed confirmed that the original chain is now insecure, consensus should eventually coalesce in one of the hard forks that can actually keep moving forward with some degree of security assurance. I feel like people sometimes think of these systems as when they fail there's a full loss, but that's not the case as the history is not lost, and so we can move forward from that history with multiple alternatives and allow the social/economic consensus to dictate which one becomes the new accepted chain. The genie is out of the box, and some chain whose history is prefixed by Bitcoin's current chain history will always exist. The only type of problems we should truly be worrying about are ones that might invalidate the security of the history itself, like a cryptographic breakthrough (quantum computing for example) that would turn some or all utxos into "anyone can spend". Transitions might be disorderly and filled with drama and discussion as the "block size wars" in 2017, but anyone who doesn't want to "vote", can always just keep their utxos frozen in place while the drama sorts itself out, and maintain whatever holdings they previously had on the new accepted chain. Peter Todd via bitcoin-dev escreveu no dia domingo, 19/06/2022 à(s) 11:32: > On Sun, Jun 12, 2022 at 07:16:49PM +, alicexbt wrote: > > Hi Peter, > > > > > Only because the block reward goes away. If it was made to continue > > > indefinitely - most likely with an inflation hard fork - demand for > block space > > > would not be critical to Bitcoin's security. > > > > > > I am not completely against your proposal although 100% sure this will > not have "consensus" to be implemented. I think if bitcoin doesn't have > enough demand for block space, it should die. I will be sad if bitcoin > doesn't exist but it should be a lesson for all the people opposing soft > forks based on drama and politics instead of technical review. > > > > I don't see anything wrong with users paying 100x fees for opening and > closing LN channels. > > The PoW security of Bitcoin benefits all Bitcoin users, proportional to the > value of BTC they hold; if Bitcoin blocks aren't reliably created the > value of > *all* BTC goes down. It doesn't make sense for the entire cost of that > security > to be paid for on a per-tx basis. And there's a high chance paying for it > on a > per-tx basis won't work anyway due to lack of consistent demand. > > It would be extremely unfortunate if one of the very few decentralized > ways to > store value died simply because we couldn't find a way to pay to keep it > secure. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects
Good morning everyone, Just wanted to point out a few things for discussion which may or may not be obvious: 1) A simple scheme as described by ZmnSCPxj first can lead way for a standardized process where people can excuse their legitimate attempts to actually introduce vulnerabilities, where they create the precommit and then attempt to introduce the vulnerability. If it goes wrong they have plausible deniability by revealing it and possibly saving their reputation. 2) A more complex scheme as described by Ryan (from my very rough understanding) seems to imply a random selection of team for attempting the attack, which might be limiting, since someone willing to do it and with enough knowledge to attempt it properly might not be picked. It seems to me that an ideal process would start from the will to attempt it from one person (or group), which then by some process similar to what Ryan described will pick at random a team of people to back up his claim to be doing it in good faith. With that selection done, the initial person would warn and gather from the randomly chosen participants a set of signatures for a similar message as described by ZmnSCPxj and only then go ahead with the attempt. This way you achieve: - One person can initiate it at will. - Other people (provably chosen at random) are insiders to that information and have a shared precommit. - You can't not reveal your intent in case it isn't caught, since other randomly chosen people are in on it. - You can't pick a specific group of people which might be willing to collude with you to achieve a similar situation to 1). Another important consideration is that depending on the size of the team to be insiders, we might by chance deplete the relevant pool of outsiders which would be adequate for reviewing the specific details of the vulnerability being introduced. Prayank via bitcoin-dev escreveu no dia sábado, 2/10/2021 à(s) 10:20: > This looks interesting although I don't understand few things: > > > The scheme should include public precommitments collected at ceremonial > intervals. > > How would this work? Can you explain with an example please. > > > Upon assignment, the dev would have community approval to > opportunistically insert a security flaw > > Who is doing the assignment? > > -- > Prayank > > A3B1 E430 2298 178F > > > > Oct 2, 2021, 01:45 by bitcoin-...@rgrant.org: > > Due to the uneven reputation factor of various devs, and uneven review > attention for new pull requests, this exercise would work best as a > secret sortition. > > Sortition would encourage everyone to always be on their toes rather > than only when dealing with new github accounts or declared Red Team > devs. The ceremonial aspects would encourage more devs to participate > without harming their reputation. > > https://en.wikipedia.org/wiki/Sortition > https://en.wikipedia.org/wiki/Red_team > > The scheme should include public precommitments collected at > ceremonial intervals. > > where: > hash1 /* sortition ticket */ = double-sha256(secret) > hash2 /* public precommitment */ = double-sha256(hash1) > > The random oracle could be block hashes. They could be matched to > hash1, the sortition ticket. A red-team-concurrency difficulty > parameter could control how many least-significant bits must match to > be secretly selected. The difficulty parameter could be a matter of > group consensus at the ceremonial intervals, based on a group decision > on how much positive effect the Red Team exercise is providing. > > Upon assignment, the dev would have community approval to > opportunistically insert a security flaw; which, when either caught, > merged, or on timeout, they would reveal along with the sortition > ticket that hashes to their public precommitment. > > Sortition Precommitment Day might be once or twice a year. > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
