Nostr notes by Giuseppe B [ARCHIVE]

📅 Original date posted:2023-03-03 🗒️ Summary of this ...

2023-06-07T23:20:14Z

In reply to nevent1q…pltv
_________________________

📅 Original date posted:2023-03-03
🗒️ Summary of this message: Proposal for a new protocol rule, min_fees, where miners set a minimum fee for the next block to increase network security and incentivize higher fees.
📝 Original message:This will indeed give some power to the miners. But they have no incentives
in posting super high numbers as that means they won't get paid or they
will with a lot of delay.
This is not simply like setting the price for a product that has a fixed
quality. In the case of the mining services, setting the price also means
setting the quality of the product you offer (as higher price = higher
security). This is simply a way to let miners have have a say about the
quality of the product that they offer. They can always set 0 min fees and
settle for the lowest quality/ low price service, or maybe find out that
offering a better product for a higher price actually makes them more
money.

On Fri, Mar 3, 2023, 3:45 AM WMOURA <neo.m.revolutions at gmail.com> wrote:

> Hello,
>
> In my amateur opinion, I imagine that this would give excessive power to the miner, introducing a bug in the system, because if the miner put an absurdly high minimum rate intentionally or not, this would cause a serious problem, or not.
>
>
> Em qua., 1 de mar. de 2023 às 17:25, Giuseppe B via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> escreveu:
>
>> Hello everyone,
>>
>> I'm relatively new here so what I'm proposing could have already been
>> discussed, or may be flawed or inapplicable. I apologize for that.
>>
>> I was picturing a situation where block rewards are almost zero, and the
>> base layer is mainly used as a settlement layer for relatively few large
>> transactions, since the majority of smaller ones goes through LN.
>>
>> In such a case it may very well be that even if transaction amounts are
>> very consistent, transaction fees end up being very small since there is
>> enough space for everyone in a block. Users wouldn't mind paying higher
>> fees as they know that that would increase the network security, however
>> nobody wants to be the only one doing that. Miners would of course like
>> being paid more. So everyone involved would prefer higher fees but they
>> just stay low because that's the only rational individual choice.
>>
>> Therefore I was imagining the introduction of a new protocol rule,
>> min_fees, that would work like this:
>> - the miner that gets to mine a block appends a min_fee field to the
>> block, specifying the minimum fees that need to be contained in the
>> following block in order for it to be valid.
>> - one can also mine an empty block and reset the min_fee, to avoid the
>> chain getting stuck.
>>
>> min_fees could either represent the total fees of the following block, or
>> the minimal fee for each single transaction, as a percentage of the value
>> transacted. Both seem to have some merits and some potential drawbacks. Of
>> course min_fees=0 would correspond to the current situation.
>>
>> It looks to me that this could have the potential to bring the
>> equilibrium closer to a socially optimal one (as opposed to individually
>> optimal), and to benefit the network security in the long term. Of course
>> it's just a rough sketch and it would deserve a much deeper analysis. I was
>> just interested in knowing if you think that the principle has some merit
>> or if it's not even worth discussing it for some reason that I'm not
>> considering.
>>
>> Cheers,
>>
>> Giuseppe.
>>
>> _______________________________________________
>> 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/20230303/62aece2e/attachment-0001.html>;

📅 Original date posted:2023-03-03 🗒️ Summary of this ...

2023-06-07T23:20:13Z

In reply to nevent1q…8qnn
_________________________

📅 Original date posted:2023-03-03
🗒️ Summary of this message: Proposal for a new protocol rule, min_fees, to specify the minimum fees required in the following block for network security and stability. The author disagrees with the idea that people will always coordinate for the optimal outcome.
📝 Original message:Hi shesek,

Minimum fees may not be the right mechanism. However I disagree with the
general idea that "if it's optimal for society to do X then they'll do X".
There's plenty of examples where people fail to coordinate in the absence
of a suitable framework, see the "free rider" problem with public goods or
even the simple prisoner's dilemma.

On Thu, Mar 2, 2023, 1:39 AM Nadav Ivgi <nadav at shesek.info> wrote:

> Hi Giuseppe,
>
> One side-effect this has is that until enough fees accumulate in the
> mempool to satisfy min_fees, the rational behaviour for miners would be to
> try and fork the chain tip, competing for the fees in the latest block
> (+whatever got into the mempool in the meanwhile and can fit in). This
> could lead to increased reorgs/orphan rates and chain instability. It could
> also lead to miners preferring to set their low_fee to zero, to avoid other
> miners from forking their blocks off.
>
> I'm also not sure that this would actually change much. If humanity is
> willing to spend X BTC/day on mining fees, it doesn't really matter if it's
> spread out through fewer or more blocks.
>
> shesek
>
> On Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello everyone,
>>
>> I'm relatively new here so what I'm proposing could have already been
>> discussed, or may be flawed or inapplicable. I apologize for that.
>>
>> I was picturing a situation where block rewards are almost zero, and the
>> base layer is mainly used as a settlement layer for relatively few large
>> transactions, since the majority of smaller ones goes through LN.
>>
>> In such a case it may very well be that even if transaction amounts are
>> very consistent, transaction fees end up being very small since there is
>> enough space for everyone in a block. Users wouldn't mind paying higher
>> fees as they know that that would increase the network security, however
>> nobody wants to be the only one doing that. Miners would of course like
>> being paid more. So everyone involved would prefer higher fees but they
>> just stay low because that's the only rational individual choice.
>>
>> Therefore I was imagining the introduction of a new protocol rule,
>> min_fees, that would work like this:
>> - the miner that gets to mine a block appends a min_fee field to the
>> block, specifying the minimum fees that need to be contained in the
>> following block in order for it to be valid.
>> - one can also mine an empty block and reset the min_fee, to avoid the
>> chain getting stuck.
>>
>> min_fees could either represent the total fees of the following block, or
>> the minimal fee for each single transaction, as a percentage of the value
>> transacted. Both seem to have some merits and some potential drawbacks. Of
>> course min_fees=0 would correspond to the current situation.
>>
>> It looks to me that this could have the potential to bring the
>> equilibrium closer to a socially optimal one (as opposed to individually
>> optimal), and to benefit the network security in the long term. Of course
>> it's just a rough sketch and it would deserve a much deeper analysis. I was
>> just interested in knowing if you think that the principle has some merit
>> or if it's not even worth discussing it for some reason that I'm not
>> considering.
>>
>> Cheers,
>>
>> Giuseppe.
>>
>> _______________________________________________
>> 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/20230303/e25eabe3/attachment-0001.html>;

📅 Original date posted:2023-03-01 🗒️ Summary of this ...

2023-06-07T23:20:12Z

In reply to nevent1q…p48d
_________________________

📅 Original date posted:2023-03-01
🗒️ Summary of this message: Proposal for a new protocol rule, min_fees, to specify minimum fees for the following block, potentially bringing equilibrium closer to socially optimal.
📝 Original message:Hello everyone,

I'm relatively new here so what I'm proposing could have already been
discussed, or may be flawed or inapplicable. I apologize for that.

I was picturing a situation where block rewards are almost zero, and the
base layer is mainly used as a settlement layer for relatively few large
transactions, since the majority of smaller ones goes through LN.

In such a case it may very well be that even if transaction amounts are
very consistent, transaction fees end up being very small since there is
enough space for everyone in a block. Users wouldn't mind paying higher
fees as they know that that would increase the network security, however
nobody wants to be the only one doing that. Miners would of course like
being paid more. So everyone involved would prefer higher fees but they
just stay low because that's the only rational individual choice.

Therefore I was imagining the introduction of a new protocol rule,
min_fees, that would work like this:
- the miner that gets to mine a block appends a min_fee field to the block,
specifying the minimum fees that need to be contained in the following
block in order for it to be valid.
- one can also mine an empty block and reset the min_fee, to avoid the
chain getting stuck.

min_fees could either represent the total fees of the following block, or
the minimal fee for each single transaction, as a percentage of the value
transacted. Both seem to have some merits and some potential drawbacks. Of
course min_fees=0 would correspond to the current situation.

It looks to me that this could have the potential to bring the equilibrium
closer to a socially optimal one (as opposed to individually optimal), and
to benefit the network security in the long term. Of course it's just a
rough sketch and it would deserve a much deeper analysis. I was just
interested in knowing if you think that the principle has some merit or if
it's not even worth discussing it for some reason that I'm not considering.

Cheers,

Giuseppe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230301/0e1bca3d/attachment-0001.html>;

📅 Original date posted:2022-07-11 📝 Original message:I ...

2023-06-07T23:11:35Z

In reply to nevent1q…820j
_________________________

📅 Original date posted:2022-07-11
📝 Original message:I think the discussion has some anecdotic interest but has zero relevance
as far as any decision making is concerned.

Any extension of block rewards after the current deadline should only be
done if and only if the community agrees that it is the only way to keep
the network secure.

The fact that a mild inflation is sometimes compensated by coin loss is
like a bonus.

On Mon, Jul 11, 2022, 11:56 AM Stefan Richter via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I very much agree with AJ here. This is something I remember discussing on
> Bitcointalk back in 2011: I find it highly intuitive that the amount of
> lost coins is not a constant fraction of the supply, because people get
> better at keeping their coins with increasing value, distribution and
> technology/best practices. I also think that we have observed this effect
> in practice since then. The bulk of coins that are supposed to be lost (via
> onchain analysis) haven't been moved since at least 2010. Of course, in
> most cases, we'll never know, but the assumption of constant loss rate
> seems unreasonable.
>
> Cheers
> Stefan
>
> Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> schrieb am Mo., 11. Juli 2022, 04:32:
>
>> On Sat, Jul 09, 2022 at 08:46:47AM -0400, Peter Todd via bitcoin-dev
>> wrote:
>> > title: "Surprisingly, Tail Emission Is Not Inflationary"
>>
>> > Of course, this isn't realistic as coins are constantly being lost due
>> to
>> > deaths, forgotten passphrases, boating accidents, etc. These losses are
>> > independent:
>>
>> This isn't necessarily true: if the losses are due to a common cause,
>> then they'll be heavily correlated rather than independent; for example
>> losses could be caused by a bug in a popular wallet/exchange software
>> that sends funds to invalid addresses, or by a war or natural disaster
>> that damages key storage hardware. They're also not independent over
>> time -- people improve their key storage habits over time; eg switching
>> to less buggy wallets/exchanges, validating addresses before using them,
>> using distributed multisig to prevent a localised disaster from being
>> catastrophic.
>>
>> > the *rate* of coin loss at time $$t$$ is
>> > proportional to the total supply *at that moment* in time.
>>
>> This is the key assumption that produces the claimed result.
>>
>> If you're losing a constant fraction, x (Peter's \lambda), of Bitcoins
>> each year, then as soon as the supply increases enough that the constant
>> reward, k, corresponds to the constant fraction, ie k = x*N(t), then
>> you've hit an equilibrium. (Likewise if you're losing more than you're
>> increasing -- you just need to wait until N(t) decreases enough that you
>> reach the same equilibrium point) You don't really need any fancy maths.
>>
>> But that assumption doesn't need to be true; coins could primarily be
>> lost in "black swan" events (due to bugs, wars or disasters) rather
>> than at a predictable rate -- with actions taken thereafter such that
>> the same event repeating is no longer the same level of catastrophe,
>> but instead another new black swan event is required to maintain the same
>> loss rate. If that's the case, then the rate at which funds are lost will
>> vary chaotically, leading to "inflationary" periods in between events,
>> and comparatively strong deflationary shocks when these events occur.
>>
>> Alternatively, losses could be at a predictable rate that's entirely
>> different to the one Peter assumes.
>>
>> One alternative predictable rate that seems plausible to me is if funds
>> are lost due to people not be careful about losing small amounts; even
>> though they are careful when amounts are larger. So when 10k BTC was
>> worth $40, maybe it doesn't matter if you misplace a hard drive with
>> 7500 BTC on it since that's only worth $30; but by the time 7500 BTC
>> is worth $150M, maybe you take a bit more care with that, but are still
>> not too worried if you lose 1.5mBTC, since that's also only worth $30.
>>
>> To mathematise that, perhaps there are K people holding Bitcoin, and with
>> probability p, each loses $100 (in constant 2009 dollars say, so that we
>> can ignore inflation) of that Bitcoin a year through carelessness. For
>> an equilibrium to occur in that case, you need:
>>
>> N(t) + k - (100/P * Kp) = N(t)
>>
>> where P is the price of Bitcoin (again in constant 2009 dollars) and k
>> is Peter's fixed tail subsidy. Simplifying gives:
>>
>> P = K * 100p/k
>>
>> But k and p are constant by assumption in this scenario, so equilibrium
>> is reached only if price (P) is exactly proportional to number of
>> users (K). That requires you to have a non-inflationary currency
>> (supply is constant) with constant adoption (assume K doesn't change)
>> that maintains a constant price (P=K*100p/k) in real terms even if the
>> economy is otherwise expanding or contracting.
>>
>> More importantly, just from a goals point of view, x is something we
>> should be finding ways to minimise it over time, not leave constant.
>> In fact, you could argue for an even stronger goal: "the real value held
>> in BTC lost each year should decrease", that is, x should be decreasing
>> faster than 1/(N(t)*P).
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> 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/20220711/a217aea1/attachment-0001.html>;

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

2023-06-07T23:10:58Z

In reply to nevent1q…pxpe
_________________________

📅 Original date posted:2022-07-07
📝 Original message:It's the first time I read about the security budget and it definitely
sounds scary to me.
If it only takes a few million dollars to attack BTC and make it completely
unusable for one day, I suppose it's only a matter of time before some
hedge fund actually does it, using a short position to profit from the huge
panic sell wave and global loss of confidence that would result from it.
It seems even cheaper to do than the recent attack to Terra, unless I'm
missing something.

On Wed, Jul 6, 2022, 1:10 PM <vjudeu at gazeta.pl> wrote:

> > If the only realistic (fair, efficient & proportionate) way to pay for
> Bitcoin's security was by having some inflation scheme that violated the 21
> million cap, then agreeing to break the limit would probably be what makes
> sense, and in the economic interest of its users and holders.
>
> So, Paul Sztorc was right again, there are three options: Enormous Block
> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come
> From Merged Mining: .
> And I think using Merged Mining is the best option. More about that:
> https://www.truthcoin.info/blog/security-budget-ii-mm/
>
> > Another option, if we were to decide we are over-secured in the short
> term, would be to soft-fork in a reduction in the current and near-future
> mining rewards, by somehow locking the coins in a contract that deprived
> the miner of the full reward, and then using that contract to pay the
> rewards out far in the future, should at some point we feel the security
> budget was insufficient.
>
> Yes, that's also possible, RSK uses that. And making some kind of
> soft-fork for that is also possible, but I don't know if miners will agree
> to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY
> OP_DROP OP_TRUE".
>
> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >Bitcoin's finite supply is the main argument for people investing in it,
> the whole narrative around bitcoin is based on its finite supply. While it
> has its flaws and basically condemns bitcoin to be only used as a store >of
> value (and not as a currency), I don't think it's worth questioning it at
> this point.
> >
> >Just my 2 sats.
> >
> >Giuseppe.
>
>
> A finite supply alone is not enough to give something value, as it must
> also be useful in some way. In the case of Bitcoin, various forms of
> cryptographic security must all work - and work together - to make Bitcoin
> useful. If the only realistic (fair, efficient & proportionate) way to pay
> for Bitcoin's security was by having some inflation scheme that violated
> the 21 million cap, then agreeing to break the limit would probably be what
> makes sense, and in the economic interest of its users and holders.
>
> There will always be competitive pressures with respect to efficiency, and
> both being over-secured and under-secured would be economically inefficient
> for a crypto currency, and thereby laving room for a more optimally-secured
> competitor to gain ground. Currently there is zero feedback in the Bitcoin
> system between what we might think is the optimum amount of security and
> what actually exists. There is also zero agreement on how much security
> would constitute such an optimum. Figuring out how much security is needed,
> or even better, figuring out a way to have a market mechanism to answer
> that question, will be an important project.
>
> Another option, if we were to decide we are over-secured in the short
> term, would be to soft-fork in a reduction in the current and near-future
> mining rewards, by somehow locking the coins in a contract that deprived
> the miner of the full reward, and then using that contract to pay the
> rewards out far in the future, should at some point we feel the security
> budget was insufficient. Anthony Towns presented a form of this concept in
> greater detail at a Scaling Bitcoin conference some years ago. While this
> solution, if employed, would only work for some finite amount of time, it
> is possible that could give additional decades before the accumulated
> security budget was exhausted.
>
>
> Corey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/0f3be846/attachment-0001.html>;

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

2023-06-07T23:10:54Z

In reply to nevent1q…ymds
_________________________

📅 Original date posted:2022-07-03
📝 Original message:Bitcoin's finite supply is the main argument for people investing in it,
the whole narrative around bitcoin is based on its finite supply. While it
has its flaws and basically condemns bitcoin to be only used as a store of
value (and not as a currency), I don't think it's worth questioning it at
this point.

Just my 2 sats.

Giuseppe.

On Sun, Jul 3, 2022, 11:44 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> On Wed, Jun 29, 2022 at 12:44:11PM +0200, Kate Salazar via bitcoin-dev
> wrote:
> > > On an idealistic level, I agree with Keagan that it would make sense to
> > > have "a balance of fees to that effect". I think doing that would be
> > > technically/economically optimal. However, I think there is an enormous
> > > benefit to having a cultural aversion to monetary inflation and the
> > > consequences of convincing the bitcoin community that inflation is ok
> could
> > > have unintended negative consequences (not to mention how difficult
> > > convincing the community would be in the first place). There's also the
> > > economic distortion that inflation causes that has a negative effect
> which
> > > should also be considered. The idea of decaying utxo value is
> interesting
> > > to consider, but it would not solve the economic distortion that
> > > monetary inflation causes, because that distortion is a result of
> monetary
> > > devaluation (which decaying utxos would be a form of). Then again,
> maybe in
> > > this case the distortion of inflation would actually be a correction -
> > > correcting for the externality of benefit received by holders. I'm
> > > stream-of-consciousnessing a bit, but anyways, I suspect its not worth
> the
> > > trouble to perfect the distribution of bitcoin blockchain security
> costs to
> > > include holders. Tho, if I were to go back in time and influence how
> > > bitcoin was designed, I might advocate for it.
> > >
> >
> > Pool operators are free to request larger fees from older utxos, or from
> > all utxos, or from newer utxos, at their judgement, looking at the
> > blockspace demand census and at what the other pool operators are doing.
> > This is not consensus, it's policy. It's not a technology problem, it's
> > solved above in the social layer.
>
> If pool operators can easily collude like you are proposing, we have a
> serious
> problem with pool centralization.
>
> What you would actually expect in a healthy Bitcoin ecosystem is for some
> pool
> operators to defect, and them winding up mining those transactions for
> market-based fees, eventually forcing the pool operators who are trying to
> charge a discriminatory premium to give up.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220703/5934b536/attachment-0001.html>;