Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
Hi Peter, everyone This issue has been discussed thoroughly in bitcointalk, general discussions are more suited to forums, I believe, still First and foremost, it is more than obvious that bitcoin block subsidy algorithm is a total disaster, not just for the zero subsidy security consequences, but also for the overly rewarding scheme that favors (few) first-runners against (masses of) people who join later, a policy that looks to be a cheap marketing trick rather than a decent strategic monetary, system design, no matter how natural it is presumed nowadays, after being implemented by Bitcoin. For now, the brilliance of the idea behind Bitcoin and the enthusiasm have compensated for its bizzar, upside-down inflation policy, in practice as newcomers have been paying the price to lucky first-runners and adopting anyway. Is it happening for low block subsidy? Is it going to be solved somehow? I don't think so. With subsidy still being the major (like 90%) portion of the block reward, there is an equalizer factor pushing equilibrium by paying security costs on behalf of current coin owners.Note that every single new bitcoin paid as subsidy is actually paid by the rest of the wallets proportional to their balance. Other than its direct contribution to security, once understood as a ballance-based taxing scheme, it is a crucial mechanism for re-distribution of wealth because to compensate for their costs, unlike speculators (who are among the worst adopters of Bitcoin, and unfortunately the most influencers), miners are used to dumping their coins, providing more fair opportunities for people to join. So, halving and the hard cap, put both adoption and security as risk, It is why, unlike "believers", I'm deeply concerned about a future with low block subsidy because it puts both security and adoption in an awkward situation. Additionally, It is not considered an engineering practice by any measure to speculate about the security of a system that we abundantly recommend to friends, family for joining. We need proofs, security proof, ease of adaptation proof, etc., Fantasies are not proofs, having faith in a magical incentive mechanism that fixes everything is not an argument, let alone being a proof. Incentives are irrelevant, rules, schemes, projects, and so fort, matter. There are always incentives in games, but rules are in charge of determining the fate. Without rules, there is no game, flawed schemes and rules move the game behind its equilibrium to fail eventually. I've not to mention the unfeasibility of tempering Bitcoin's basic consensus rules, Bitcoin rules are not subject to change specially when it comes to something that is widely considered a basic characteristic, a Schelling point, and so forth. So, it is the paradoxical situation: we are exposed to, on one hand, it is a deficiency and on the other hand it is inevitable because is critically hard-code to Bitcoin, advertised more than any feature as its identity. But it is our job, isn't it? Dealing with the impossible and taking care of it, but I think before reaching to that point we have to settle the basics.: - There is a problem with long term security and adoption consequences. - It is built deeply to bitcoin consensus rules, and considered a critical - It is not going to disappear magically, neither it will be addressed by whales, etc. - The 21M cap, halving, and generally, Bitcoin consensus, is not subject to change. Don't panic, it is not exactly a catch-22 situation. Tip: It is always possible to help a system without aggressive intervention, either by smart tweaks or by supporting it using other system(s). Cheers, Ali Ashraf --- Original Message --- On Tuesday, August 16th, 2022 at 8:35 PM, Peter via bitcoin-dev wrote: > Hi Jaroslaw, > In the Prisoner's Dilemma the prisoners cannot communicate. In Bitcoin large > holders are able to communicate with each other. Also, prisoners need not > make an all or nothing decision in Bitcoin. Miners can join and leave the > network freely over time. You can change your decision based on the decision > of others. > > The Bitcoin design is such that security is volatile but the issuance of > blocks is timely and evened out to a 10 minutes average even after the reward > is exhausted. > > The existing incentive that miners earn money for including transactions is > enough to motivate human nature. Transaction initiators have an incentive to > mine and run full nodes for personal interest. > >>Noone will waste his renewable energy on unprofitable Antminer while he/she >>can sell this energy for the market price. > > The law in most jurisdictions prevents the resale of spare electricity unless > an expensive license is obtained (and in most cases no license is available > as the government maintains a monopoly). Mining with waste electricity is > reducing losses. Another incentive to motivate human nature. > > Bitcoin holders can be
Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
> On Sat, Jul 30, 2022 at 05:24:35PM +, alicexbt via bitcoin-dev wrote: > like a hashcash-based alternative broadcast scheme. Hi Peter, I've been mulling the idea of attaching work to low fee txns, both as a compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfortunately, both suffer from ASICs: For spam proof case, the adversary can easily buy a used/obsolete device to produce lots of spam txns very cheaply, unless you put the bar very high, making it almost impossible for average users to even try. The compensation scenario is pretty off-topic, still, interesting enough for 1 min read: Wallets commit to the latest blockchain state in the transaction AND attach work. It is considered contribution to the security (illegitimate chains can't include the txn), hence isrewarded by fee discount/exemption depending on the offset of the state they've committed to (the closer, the better) and the amount of work attached. For this to work, block difficulty is calculated inclusive with the work embedded in the txns, it contains. Sophisticated and consequential, yet not infeasible per se. Unfortunately, this scheme is hard to balance with ASICs in the scene too, for instance, you can't subsidize wallets for their work like with a leverge, because miners can easily do it locally, seizing the subsidies for themselves, long story, not relevant just ignore it. Cheers, Ali --- Original Message --- On Monday, August 1st, 2022 at 3:00 PM, Peter Todd via bitcoin-dev wrote: > On Sat, Jul 30, 2022 at 05:24:35PM +, alicexbt via bitcoin-dev wrote: > > > However, I think developers should not make any changes in the default > > minimum fee rate required for relay. If there are incentives for users and > > miners to change it, they should use non-default value. In case, miners > > want to experiment with lower fee rate and see if this increases revenue > > they could try using it on odd dates (even dates remain default) for a > > month. We all could analyze how this worked for different mining pools and > > non-default value (lower or higher) could become normal in the future. > > > Without a way for lower-fee-rate transactions to get to those miners, > experiments like that are pointless. > > If you want to propose things like this, propose a way to get non-standard txs > to miners, like a hashcash-based alternative broadcast scheme. > > -- > 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] On a new community process to specify covenants
I suppose it is more about spending from vaults, rather than locking in. A covenant would impose rules for spending tx.e.g. :Don't spend this output unless it is claimed by a tx which 1) Spends it as a whole in the very first output. 2) This output is P2SH with specified script pattern ( a TLC script with redeem options) Both normal and theft spends are enforced to lock the funds for a reasonable amount of time, providing opportunity for neutralizing the theft just in case. This is becoming more complex once the redeem (cold) key is susceptible to theft and should be prevented from being able to reclaim funds when the legitimate spends has time locked the funds. It is done by requiring the redeem path to comply with a similar pattern with modifications e.g. this (redeem) tx fails unless a specific txid is published at least n blocks earlier. This way a cold key only theft won't be able to take advantage because s/he has not access to the specific txid which is generated before and is kept as a 3rd secret, add whatever complexity you wish to. Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Sunday, July 24th, 2022 at 10:52 PM, Bram Cohen via bitcoin-dev wrote: > On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev > wrote: > >> Indeed this range has grown wild. Without aiming to be exhaustive (I'm >> certainly missing some interesting proposals lost in the abyss of >> bitcointalk.org), we can mention the following use-cases: multi-party >> stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" >> layered commitments [14], programmable vaults [15], multi-events contracts >> [16], blockchain-as-oracle bets [17], spacechains [18], trustless collateral >> lending [19], ... > > The big question you missed is whether capabilities are in scope for a > covenants proposal. In particular, vaults work a lot better when payments to > them are immediately locked up in the vault rather than it having to do a > step to accept them first.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
--- Original Message --- On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev wrote: > Hi Michael, > > I'm thinking such a covenant effort would be more a technical process aiming > to advance the state of covenant & contracting knowledge, collect and > document the use-cases, exchange engineering learnings from the prototype, > share the problem space, etc. In the same fashion we have the BOLT one or > even more remote the IETF working groups about a bunch of Internet technology > [0]. I think that Taproot/Schnorr has set a high standard in terms of > safety-first and careful Bitcoin engineering effort, aggregating 8 years of > thinking around MAST and friends but also exploring other signature schemes > like BLS. And I hope with covenants we aim for higher standards, as if there > is one learning from Taproot we could have spent more time working out > use-cases prototypes (e.g joinpools) and standard libraries to mature, it > could have save actual headache around x-pubkeys [1] Hi Antoine, Claiming Taproot history, as best practice or a standard methodology in bitcoin development, is just too much. Bitcoin development methodology is an open problem, given the contemporary escalation/emergence of challenges, history is not entitled to be hard coded as standard. Schnorr/MAST development history, is a good subject for case study, but it is not guaranteed that the outcome to be always the same as your take. I'd suggest instead of inventing a multi-decades-lifecycle based methodology (which is weird by itself, let alone installing it as a standard for bitcoin projects), being open-mind enough for examining more agile approaches and their inevitable effect on the course of discussions, Cheers,___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
