Re: [bitcoin-dev] Security problems with relying on transaction fees for security
BIP119, OP_CTV, allows value to be assigned in a predetermined tree of payments that confirms with a single output. This allows batched transactions in the predetermined tree (e.g. withdrawals from a centralized exchange) to be anchored in a way that disallows double-spending of the inputs, yet allows the recipients to smooth out mining fees for their withdrawal outputs, at their leisure. It's a perfect design for a world where there are always more transactions to be made than block space allows, yet only some of them are urgent. As it applies to concerns mentioned in this thread, it can be used to shift transaction fees to later blocks. Whenever smoothing transaction fees would be a nice-to-have, this is one way to have it. https://utxos.org/uses/scaling/ https://utxos.org/analysis/bip_simulation/ On Tue, Jul 12, 2022 at 9:49 AM Peter wrote: > With 3000 Lightning open/ close tx per block and 6 billion adults > it's 38 years of backlog to onboard the entire adult > population. That's not including corporations. Separately, OP_CTV also allows slightly different payment channels from the existing Lightning Network, that allow non-interactive batched opens. Using this technique, onboarding 6 billion adults to payment channels would be limited only by their willingness to participate. https://utxos.org/uses/non-interactive-channels/ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
>Probably the only thing Bitcoiners should do is to advertise this rather than >to make it some sort of secret Satoshi made this clear in the beginning that mining will trend to where energy is free. During this stage of bootstrapping we need a security budget to prevent nation state attacks. In the future we will need to lose money mining Bitcoin to prevent the reemergence of a fiat reserve currency. The emission curve lasts over 100 years because Bitcoin success state requires it to be entrenched globally. We all work for Satoshi because he invented a currency that is digital and deflationary. Gold doesn't work as a deflationary currency because of physical limitations. Yes, today people are spending some of their Bitcoin to protect the remainder of their bag. We should expect this to continue into the future. I routinely give away Bitcoin to grow support for it in my local jurisdiction. This is another form of securing Bitcoin (people power). This helps protect my deflationary wealth increase and is net profitable in my view because increased adoption powers deflation. If Bitcoin loses its deflationary promise then it will be abandoned. In the future all the miners will be energy producers. There may be small home miners who have excess energy but most energy is produced by governments today and likely in the future. So, a potential solution is you take 1% of your Bitcoin annually to secure the network for the promise of 10% deflation (increase in purchasing power). More likely large holders will be doing this. Yes, there will be free riders. Today there's also free riders who receive part of our Bitcoins via tax collection and welfare. In the future they receive free deflation instead and are incentived to save Bitcoin to receive this stipend. Regards Peter Kroll Original Message On 12 Jul 2022, 07:57, Erik Aronesty wrote: >> we can expect mining to transition to a public service from the current >> for-profit business model > > I get it now > > Game theory would predict all of the major players mining in the future will > be large holders > > If you're holding a hundred Bitcoin you should take one, sell it for mining > equipment and use it to ensure the rest is stable > > I guess that's perfectly reasonable > > Yeah I'm on board with the idea that this is a non-issue > > Interested parties will continue to maintain the security of the chain with > the same basic game theoretic stuff > > Bitcoin doesn't need a security budget > > Existing holders have the ability the means and the incentive to secure their > funds > > Probably the only thing Bitcoiners should do is to advertise this rather than > to make it some sort of secret > >>___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> > we can expect mining to transition to a public service from the current > for-profit business model > I get it now Game theory would predict all of the major players mining in the future will be large holders If you're holding a hundred Bitcoin you should take one, sell it for mining equipment and use it to ensure the rest is stable I guess that's perfectly reasonable Yeah I'm on board with the idea that this is a non-issue Interested parties will continue to maintain the security of the chain with the same basic game theoretic stuff Bitcoin doesn't need a security budget Existing holders have the ability the means and the incentive to secure their funds Probably the only thing Bitcoiners should do is to advertise this rather than to make it some sort of secret > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
The Bitcoin emission curve requires a 2x value increase per 210,000 blocks to maintain the existing security level. Transactions are practically irreversible when the value the miners expend (not receive) is greater than said transaction value. If you send 1000 gold grams of value in a transaction then it's finalized after 1000 gold grams worth of energy have been spent on mining blocks. Bitcoin is bootstrapping from the English population and its final steady state is to eliminate fiat and be a global reserve currency and a daily transactional currency. So, we should engineer for other language and religious communities to join in. Saturday and Sunday are business days in a large portion of the planet. Bike shedding a tail emission to try to support Bitcoin with the current 2% to 4% global adoption (in terms of holding not spending) as the world's premier pet rock is a poor strategy. We can expect Bitcoin to never have a steady value because businesses turn profits on average of 10% so there will be a steady increase in hoarding to fuel number go up technology. Prices will be more reliably accounted for in gold grams, as well as corporate and government accounts being denominated in gold grams not satoshis. We can expect the boom and bust economic cycle to disappear when the price of money (interest rates) is set by the market. The value of money will still be set by the government via average government wages. With 3000 Lightning open/ close tx per block and 6 billion adults it's 38 years of backlog to onboard the entire adult population. That's not including corporations. If we assume 20% of people use non-custodial Lightning but they each have 5 channels open we are back to 38 years backlog. There's a cost and risk to reorganize the chain to chase fees in a zero block reward world. And as stated miners can leave honey in the mempool pot. We shouldn't expect empty mempools with occational transactions with outlier large fees that cause overnight reorganizations. In a state of victory, nation-states will use solar power during the daytime to ensure local entities have priority access to confirmations and Bitcoin will receive nation-state altruism in such a future as it receives person-based altruism today. Because we as individuals and nation states all win if we keep the Schelling point of 21M bitcoins. We shouldn't make naive miner centralization models when there's national security considerations to keep the chain moving forward in a stable way. Big miners won't take all the fees and put small miners out of business because energy production itself is decentralized and idle energy will always keep a diverse set of miners on the network. Block rewards are no guarantee of security as we have seen with lesser PoW coins (Ethereum Classic and others). And during the Bitcoin immaculate conception period of 2009 to 2012 the block reward served mainly as a distribution method since JP Morgan had enough GPU power to reorganize us to block 0 but that didn't happen. So, the block reward offered little security in those days. Bitcoin works but in order to win it needs global adoption. No amount of arbitrary inflation can ensure a sufficient security budget. Block rewards are to distribute the money we can expect mining to transition to a public service from the current for-profit business model when there's a 38 year backlog and every nation is on board for the game theoretic reason to deny any single nation the power of seigniorage of the global reserve currency. Regards Peter Kroll (pointbiz / BTCCuracao)___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Mon, Jul 11, 2022 at 2:53 PM Peter Todd wrote: > > The only type of fee-smoothing scheme that is feasible is to smooth an > entirely > separate category of fees that are made mandatory. For example, you could > achieve the economic impact of inflation by having a fixed value*time > based fee > that goes to timelocked anyone-can-spend outputs in the coinbase to push > the > fee forward to other miners. > I'm not sure what the implications would be of charging coins for moving based on their value times how long since they last moved would be (I *think* that's what you're suggesting). It isn't obviously bad, but feels weird to me. That said, a scheme which would work would be to have a fixed minimum fee of satoshis/vbyte which is required to be repaid out by the miner into a pool and they get back a fixed fraction of what was in that pool. The pool could simply be a rolling coin which keeps the balance. That's still a bit ugly but doesn't lessen block size significantly, is fairly coherent, and is a soft fork. It's the best emergency measure I'm aware of. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
