John Carvalho [ARCHIVE] on Nostr: đź“… Original date posted:2022-07-08 đź“ť Original message:vjudeu at gazeta.pl, what ...
đź“… Original date posted:2022-07-08
đź“ť Original message:vjudeu at gazeta.pl, what you describe is not possible without a hard fork,
just like Eric said. There is no atomic way to move Bitcoin off of Bitcoin.
You can use Bitcoin txns, or you can use trust/custody, or you can make a
shitcoin. There is no way to actually divide or transfer sats to another
network.
This talk of inflation is absurd and forced and ignores all understanding
of Bitcoin and economic primitives. You would all do better to listen to
Eric and appreciate him taking the time to elaborate.
In the end, I will reiterate. Proof of work and the difficulty adjustment
scheme already solve all of these issues. When blockspace demand increases,
fees increase, more miners mine, security goes up. Thus any theoretical
supply increase would have the opposite effect.
All of these arguments for inflation amount to "That restaurant is too
popular, nobody goes there anymore." If people are using Bitcoin, miners
will mine. If all Bitcoin users are hodling only, then demand is gone, and
miners will leave. It is elegant.
Stop trying to fix Bitcoin, it isn't broken.
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
On Fri, Jul 8, 2022 at 5:59 AM <vjudeu at gazeta.pl> wrote:
> > Simply fork off an inflation coin and test your theory. I mean, that’s
> the only way it can happen anyway.
>
> That would be an altcoin. But it can be done in a simpler way: we have 21
> million coins. It doesn't matter if it is 21 million, if it is 100 million,
> or if it is in some normalized range from 0 to 1, where you can always
> know, what fraction of the total supply you have. So, if the total supply
> is constant, then it is all about proportions. And that means, you can
> create some system on top of Bitcoin, that would move coins from users to
> miners. It is all about that: if all coins are mined, then they can move
> only if users will move them. So if you want to change that, it is all
> about encouraging them to put their coins in some evil Lightning channel,
> when they will lose their coins over time. That's how inflation works.
>
> So, imagine some evil channel, where you can put for example 0.01 BTC, and
> have a time-based fee, so you will pay 1000 satoshis per day. Guess what:
> 1000 days, and your coins are gone! That means, if anyone want to test
> inflation, it is possible right here and right now. Good luck to convince
> people to use your inflationary system in a non-obfuscated way, because
> that's how it truly looks like: if you double coin supply, you can reach
> the same by halving all amounts.
>
>
> On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Value is subjective, though a constraint of 1tx per 10 minutes seems
> unlikey to create a fee of 5000x that of 5000tx. This is of course why I
> stated my assumption. Yet this simple example should make clear that at
> some point a reduction in confirmation rate reduces reward. Otherwise a
> rate of zero implies infinite reward.
>
>
> You cannot support the blanket statement (and absent any assumption) that
> lower confirmation rates produce “much higher fees” or “better security”.
>
>
> What you call a “bidding war” is merely market pricing, as it occurs with
> any good. People *always* will pay as much as they will pay. This is
> tautological. What you cannot say is how much more someone will pay at any
> given time for any given good, until they have done it. And I’m pretty sure
> Bitcoin hasn’t done it.
>
>
> You cannot prove what the price of anything will be, nor can any “papers”.
> The absurdity of S2F should have clearly demonstrated that by now. Value is
> an individual human preference.
>
>
> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
> these people are not getting confirmed (economic rationality always
> assumed).
>
>
> The assumption of 1 sat txs filling blocks is based on a
> disproportionately high subsidy. A subsidy of 50btc would imply somewhere
> in the neighborhood of $200 per tx in fees today, and as $680. As that
> falls, fees will continue to keep miners at the same profit level. If
> demand does not rise to compensate (as it always has) then hash rate will
> fall.
>
>
> Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin
> is a market money. Like gold it is produced at market cost. Yet it will
> prevent Bitcoin from achieving any meaningful level of censorship
> resistance. This of course should make people look closely at such
> arguments.
>
>
> Of course, once you have a censor, block space gets really small for those
> who want to resist the censor. Then of course only fees can offset the
> censorship. Without fee-based tx confirmation (for anonymity), and/or with
> a disproportionate subsidy going to the censor, a censor can operate
> profitably and indefinitely (under the assumption of constant demand).
> There is no reason to assume demand for censored txs wouldn’t even
> increase, given the white market blessing which so many seem to want.
>
>
> But there is of course no real issue here. Simply fork off an inflation
> coin and test your theory. I mean, that’s the only way it can happen anyway.
>
>
> e
>
>
> On Jul 7, 2022, at 14:11, Erik Aronesty <erik at q32.com> wrote:
>
>
>
> The relationship between block size and fees is not remotely linear. In
> a restricted environment, the fee rewards are much higher.
>
>
> **the ones moving more sats will win the top spots and will pay as much as
> is reasonable**
>
>
> Smaller blocks produce better security for the network both in validation,
> and in fees.
>
>
> Without a bidding war for space, everyone can post 1 SAT/byte
>
>
> With a bidding war for space, larger transactions will pay much higher
> rates. There have been a number of papers written on this but you can
> concoct a trivial example to prove it.
>
>
>
>
> On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric at voskuil.org> wrote:
>
>
>
> It’s not clear how reducing block size changes the fee aspect of the block
> reward. Assuming half the space implies twice the fee per avg tx the reward
> remains constant.
>
>
> Any additional cost of processing more or less bytes would not matter,
> because of course this is just a cost that gets nulled out by difficulty —
> average profit (net income) is the cost of capital.
>
>
> The reason for smaller vs. larger blocks is to ensure that individuals can
> afford to validate. That’s a threshold criteria.
>
>
> Given unlimited size blocks, miners would still have to fix a point in
> time to mine, gathering as much fee as they can optimize in some time
> period presumably less than 10 minutes. The produces a limit to transaction
> volume, yet neither reward nor profit would be affected given the above
> assumptions. The difference would be in a tradeoff of per tx fee against
> the threshold.
>
>
> Given Moore’s Law, that threshold is constantly decreasing, which will
> make it cheaper over time for more individuals to validate. But the
> difference for miners for smaller blocks is largely inconsequential
> relative to their other costs.
>
>
> Increasing demand is the only thing that increases double spend security
> (and censorship resistance assuming fee-based reward). With rising demand
> there is rising overall hash rate, despite block reward and profit
> remaining constant. This makes the cost of attempting to orphan a block
> higher, therefore lowering the depth/time requirement implied to secure a
> given tx amount.
>
>
> These are the two factors, demand and time. Less demand implies more time
> to secure a given amount against double spend, and also implies a lower
> cost to subsidize a censorship regime. But the latter requires a
> differential in reward between the censor and non-censoring miners. While
> this could be paid in side fees, that is a significant anonymity issue.
>
>
> e
>
>
> On Jul 7, 2022, at 10:37, Erik Aronesty <erik at q32.com> wrote:
>
>
>
> > > We should not imbue real technology with magical qualities.
>
>
> > Precisely. It is economic forces (people), not technology, that provide
> security.
>
>
>
> Yes, and these forces don't prevent double-spend / 51% attacks if the
> amounts involved are greater than the incentives.
>
>
> In addition to "utility", lowering the block size could help prevent this
> issue as well... increasing fee pressure and double-spend security while
> reducing the burden on node operators.
>
>
> Changes to inflation are, very likely, off the table.
>
>
>
>
>
>
> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev
> wrote:
> >> Billy,
> >>
> >> Proof of work and the difficulty adjustment function solve literally
> >> everything you are talking about already.
> >
> > Unfortunately you are quite wrong: the difficulty adjustment function
> merely
> > adjusts for changes in the amount of observable, non-51%-attacking,
> hashing
> > power. In the event of a chain split, the difficulty adjustment function
> does
> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
> > against a censor, the difficulty adjustment does nothing.
>
> Consider falling hash rate due to a perpetual 51% attack. Difficulty
> falls, possibly to min difficulty if all non-censors stop mining and with
> all censors collaborating (one miner). Yet as difficulty falls, so does the
> cost of countering the censor. At min difficulty everyone can CPU mine
> again.
>
> Given the presumption that fees rise on unconfirmed transactions, there is
> inherent economic incentive to countering at any level of difficulty.
> Consequently the censor is compelled to subsidize the loss resulting from
> forgoing higher fee transactions that are incentivizing its competition.
>
> With falling difficulty this incentive is compounded.
>
> Comparisons of security in different scenarios presume a consistent level
> of demand. If that demand is insufficient to offset the censor’s subsidy,
> there is no security in any scenario.
>
> Given that the block subsidy (inflation) is paid equally to censoring and
> non-censoring miners, it offers no security against censorship whatsoever.
> Trading fee-based block reward for inflation-based is simply trading
> censorship resistance for the presumption of double-spend security. But of
> course, a censor can double spend profitably in any scenario where the
> double spend value (to the censor) exceeds that of blocks orphaned (as the
> censor earns 100% of all block rewards).
>
> Banks and state monies offer reasonable double spend security. Not sure
> that’s a trade worth making.
>
> It’s not clear to me that Satoshi understood this relation. I’ve seen no
> indication of it. However the decision to phase out subsidy, once a
> sufficient number of units (to assure divisibility) had been issued, is
> what transitions Bitcoin from a censorable to a censorship resistant money.
> If one does not believe there is sufficient demand for such a money, there
> is no way to reconcile that belief with a model of censorship resistance.
>
> > We should not imbue real technology with magical qualities.
>
> Precisely. It is economic forces (people), not technology, that provide
> security.
>
> e
>
> >> Bitcoin does not need active economic governanance by devs or meddlers.
> >
> > Yes, active governance would definitely be an exploitable mechanism. On
> the
> > other hand, the status quo of the block reward eventually going away
> entirely
> > is obviously a risky state change too.
> >
> >>>> There is also zero agreement on how much security would constitute
> such
> >>> an optimum.
> >>>
> >>> This is really step 1. We need to generate consensus on this long
> before
> >>> the block subsidy becomes too small. Probably in the next 10-15 years.
> I
> >>> wrote a paper
> >
> > The fact of the matter is that the present amount of security is about
> 1.7% of
> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7%
> is also
> > already an amount low enough that it's much smaller than economic
> volatility.
> >
> > Obviously 0% is too small.
> >
> > There's zero reason to stress about finding an "optimal" amount. An
> amount low
> > enough to be easily affordable, but non-zero, is fine. 1% would be fine;
> 0.5%
> > would probably be fine; 0.1% would probably be fine.
> >
> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31%
> tax on
> > savings; 0.1% works out to be 7.2%
> >
> > These are all amounts that are likely to be dwarfed by economic shifts.
> >
> > --
> > 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220708/aa305616/attachment-0001.html>;
đź“ť Original message:vjudeu at gazeta.pl, what you describe is not possible without a hard fork,
just like Eric said. There is no atomic way to move Bitcoin off of Bitcoin.
You can use Bitcoin txns, or you can use trust/custody, or you can make a
shitcoin. There is no way to actually divide or transfer sats to another
network.
This talk of inflation is absurd and forced and ignores all understanding
of Bitcoin and economic primitives. You would all do better to listen to
Eric and appreciate him taking the time to elaborate.
In the end, I will reiterate. Proof of work and the difficulty adjustment
scheme already solve all of these issues. When blockspace demand increases,
fees increase, more miners mine, security goes up. Thus any theoretical
supply increase would have the opposite effect.
All of these arguments for inflation amount to "That restaurant is too
popular, nobody goes there anymore." If people are using Bitcoin, miners
will mine. If all Bitcoin users are hodling only, then demand is gone, and
miners will leave. It is elegant.
Stop trying to fix Bitcoin, it isn't broken.
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
On Fri, Jul 8, 2022 at 5:59 AM <vjudeu at gazeta.pl> wrote:
> > Simply fork off an inflation coin and test your theory. I mean, that’s
> the only way it can happen anyway.
>
> That would be an altcoin. But it can be done in a simpler way: we have 21
> million coins. It doesn't matter if it is 21 million, if it is 100 million,
> or if it is in some normalized range from 0 to 1, where you can always
> know, what fraction of the total supply you have. So, if the total supply
> is constant, then it is all about proportions. And that means, you can
> create some system on top of Bitcoin, that would move coins from users to
> miners. It is all about that: if all coins are mined, then they can move
> only if users will move them. So if you want to change that, it is all
> about encouraging them to put their coins in some evil Lightning channel,
> when they will lose their coins over time. That's how inflation works.
>
> So, imagine some evil channel, where you can put for example 0.01 BTC, and
> have a time-based fee, so you will pay 1000 satoshis per day. Guess what:
> 1000 days, and your coins are gone! That means, if anyone want to test
> inflation, it is possible right here and right now. Good luck to convince
> people to use your inflationary system in a non-obfuscated way, because
> that's how it truly looks like: if you double coin supply, you can reach
> the same by halving all amounts.
>
>
> On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Value is subjective, though a constraint of 1tx per 10 minutes seems
> unlikey to create a fee of 5000x that of 5000tx. This is of course why I
> stated my assumption. Yet this simple example should make clear that at
> some point a reduction in confirmation rate reduces reward. Otherwise a
> rate of zero implies infinite reward.
>
>
> You cannot support the blanket statement (and absent any assumption) that
> lower confirmation rates produce “much higher fees” or “better security”.
>
>
> What you call a “bidding war” is merely market pricing, as it occurs with
> any good. People *always* will pay as much as they will pay. This is
> tautological. What you cannot say is how much more someone will pay at any
> given time for any given good, until they have done it. And I’m pretty sure
> Bitcoin hasn’t done it.
>
>
> You cannot prove what the price of anything will be, nor can any “papers”.
> The absurdity of S2F should have clearly demonstrated that by now. Value is
> an individual human preference.
>
>
> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
> these people are not getting confirmed (economic rationality always
> assumed).
>
>
> The assumption of 1 sat txs filling blocks is based on a
> disproportionately high subsidy. A subsidy of 50btc would imply somewhere
> in the neighborhood of $200 per tx in fees today, and as $680. As that
> falls, fees will continue to keep miners at the same profit level. If
> demand does not rise to compensate (as it always has) then hash rate will
> fall.
>
>
> Propping up hash rate with subsidy will not be “inflationary”, as Bitcoin
> is a market money. Like gold it is produced at market cost. Yet it will
> prevent Bitcoin from achieving any meaningful level of censorship
> resistance. This of course should make people look closely at such
> arguments.
>
>
> Of course, once you have a censor, block space gets really small for those
> who want to resist the censor. Then of course only fees can offset the
> censorship. Without fee-based tx confirmation (for anonymity), and/or with
> a disproportionate subsidy going to the censor, a censor can operate
> profitably and indefinitely (under the assumption of constant demand).
> There is no reason to assume demand for censored txs wouldn’t even
> increase, given the white market blessing which so many seem to want.
>
>
> But there is of course no real issue here. Simply fork off an inflation
> coin and test your theory. I mean, that’s the only way it can happen anyway.
>
>
> e
>
>
> On Jul 7, 2022, at 14:11, Erik Aronesty <erik at q32.com> wrote:
>
>
>
> The relationship between block size and fees is not remotely linear. In
> a restricted environment, the fee rewards are much higher.
>
>
> **the ones moving more sats will win the top spots and will pay as much as
> is reasonable**
>
>
> Smaller blocks produce better security for the network both in validation,
> and in fees.
>
>
> Without a bidding war for space, everyone can post 1 SAT/byte
>
>
> With a bidding war for space, larger transactions will pay much higher
> rates. There have been a number of papers written on this but you can
> concoct a trivial example to prove it.
>
>
>
>
> On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric at voskuil.org> wrote:
>
>
>
> It’s not clear how reducing block size changes the fee aspect of the block
> reward. Assuming half the space implies twice the fee per avg tx the reward
> remains constant.
>
>
> Any additional cost of processing more or less bytes would not matter,
> because of course this is just a cost that gets nulled out by difficulty —
> average profit (net income) is the cost of capital.
>
>
> The reason for smaller vs. larger blocks is to ensure that individuals can
> afford to validate. That’s a threshold criteria.
>
>
> Given unlimited size blocks, miners would still have to fix a point in
> time to mine, gathering as much fee as they can optimize in some time
> period presumably less than 10 minutes. The produces a limit to transaction
> volume, yet neither reward nor profit would be affected given the above
> assumptions. The difference would be in a tradeoff of per tx fee against
> the threshold.
>
>
> Given Moore’s Law, that threshold is constantly decreasing, which will
> make it cheaper over time for more individuals to validate. But the
> difference for miners for smaller blocks is largely inconsequential
> relative to their other costs.
>
>
> Increasing demand is the only thing that increases double spend security
> (and censorship resistance assuming fee-based reward). With rising demand
> there is rising overall hash rate, despite block reward and profit
> remaining constant. This makes the cost of attempting to orphan a block
> higher, therefore lowering the depth/time requirement implied to secure a
> given tx amount.
>
>
> These are the two factors, demand and time. Less demand implies more time
> to secure a given amount against double spend, and also implies a lower
> cost to subsidize a censorship regime. But the latter requires a
> differential in reward between the censor and non-censoring miners. While
> this could be paid in side fees, that is a significant anonymity issue.
>
>
> e
>
>
> On Jul 7, 2022, at 10:37, Erik Aronesty <erik at q32.com> wrote:
>
>
>
> > > We should not imbue real technology with magical qualities.
>
>
> > Precisely. It is economic forces (people), not technology, that provide
> security.
>
>
>
> Yes, and these forces don't prevent double-spend / 51% attacks if the
> amounts involved are greater than the incentives.
>
>
> In addition to "utility", lowering the block size could help prevent this
> issue as well... increasing fee pressure and double-spend security while
> reducing the burden on node operators.
>
>
> Changes to inflation are, very likely, off the table.
>
>
>
>
>
>
> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev
> wrote:
> >> Billy,
> >>
> >> Proof of work and the difficulty adjustment function solve literally
> >> everything you are talking about already.
> >
> > Unfortunately you are quite wrong: the difficulty adjustment function
> merely
> > adjusts for changes in the amount of observable, non-51%-attacking,
> hashing
> > power. In the event of a chain split, the difficulty adjustment function
> does
> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
> > against a censor, the difficulty adjustment does nothing.
>
> Consider falling hash rate due to a perpetual 51% attack. Difficulty
> falls, possibly to min difficulty if all non-censors stop mining and with
> all censors collaborating (one miner). Yet as difficulty falls, so does the
> cost of countering the censor. At min difficulty everyone can CPU mine
> again.
>
> Given the presumption that fees rise on unconfirmed transactions, there is
> inherent economic incentive to countering at any level of difficulty.
> Consequently the censor is compelled to subsidize the loss resulting from
> forgoing higher fee transactions that are incentivizing its competition.
>
> With falling difficulty this incentive is compounded.
>
> Comparisons of security in different scenarios presume a consistent level
> of demand. If that demand is insufficient to offset the censor’s subsidy,
> there is no security in any scenario.
>
> Given that the block subsidy (inflation) is paid equally to censoring and
> non-censoring miners, it offers no security against censorship whatsoever.
> Trading fee-based block reward for inflation-based is simply trading
> censorship resistance for the presumption of double-spend security. But of
> course, a censor can double spend profitably in any scenario where the
> double spend value (to the censor) exceeds that of blocks orphaned (as the
> censor earns 100% of all block rewards).
>
> Banks and state monies offer reasonable double spend security. Not sure
> that’s a trade worth making.
>
> It’s not clear to me that Satoshi understood this relation. I’ve seen no
> indication of it. However the decision to phase out subsidy, once a
> sufficient number of units (to assure divisibility) had been issued, is
> what transitions Bitcoin from a censorable to a censorship resistant money.
> If one does not believe there is sufficient demand for such a money, there
> is no way to reconcile that belief with a model of censorship resistance.
>
> > We should not imbue real technology with magical qualities.
>
> Precisely. It is economic forces (people), not technology, that provide
> security.
>
> e
>
> >> Bitcoin does not need active economic governanance by devs or meddlers.
> >
> > Yes, active governance would definitely be an exploitable mechanism. On
> the
> > other hand, the status quo of the block reward eventually going away
> entirely
> > is obviously a risky state change too.
> >
> >>>> There is also zero agreement on how much security would constitute
> such
> >>> an optimum.
> >>>
> >>> This is really step 1. We need to generate consensus on this long
> before
> >>> the block subsidy becomes too small. Probably in the next 10-15 years.
> I
> >>> wrote a paper
> >
> > The fact of the matter is that the present amount of security is about
> 1.7% of
> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7%
> is also
> > already an amount low enough that it's much smaller than economic
> volatility.
> >
> > Obviously 0% is too small.
> >
> > There's zero reason to stress about finding an "optimal" amount. An
> amount low
> > enough to be easily affordable, but non-zero, is fine. 1% would be fine;
> 0.5%
> > would probably be fine; 0.1% would probably be fine.
> >
> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31%
> tax on
> > savings; 0.1% works out to be 7.2%
> >
> > These are all amounts that are likely to be dwarfed by economic shifts.
> >
> > --
> > 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220708/aa305616/attachment-0001.html>;