Nostr notes by aliashraf.btc At protonmail [ARCHIVE]

📅 Original date posted:2022-08-19 📝 Original message:Hi ...

2023-06-07T23:12:44Z

In reply to nevent1q…gvfj
_________________________

📅 Original date posted:2022-08-19
📝 Original message: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 <bitcoin-dev at lists.linuxfoundation.org> 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 enfranchised into any new system. So, no need for bike shedding the original design which is a Schelling Point.
>
> Regards
>
> Peter Kroll
>
> pointbiz/ BTCCuracao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220819/5d3300ef/attachment.html>;

📅 Original date posted:2022-08-01 📝 Original message:> ...

2023-06-07T23:12:21Z

In reply to nevent1q…0h66
_________________________

📅 Original date posted:2022-08-01
📝 Original message:> On Sat, Jul 30, 2022 at 05:24:35PM +0000, 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 <bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Sat, Jul 30, 2022 at 05:24:35PM +0000, 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2022-07-24 📝 Original ...

2023-06-07T23:12:04Z

In reply to nevent1q…evxq
_________________________

📅 Original date posted:2022-07-24
📝 Original message:------- Original Message -------
On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220724/8de09dce/attachment.html>;