Manuel Costa [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-10-03 to 2022-07-14
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:11:51

- reply

📅 Original date posted:2022-07-14
📝 Original message:> There is a smarter way. Just send 0.01 BTC per block to the timelocked
outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that
percentage will grow over time, as basic block reward will shrink, and we
will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess
what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it
simply means you can lock 2,100 BTC in an endless circulation loop, and
avoid this "tail supply attack".
My understanding of this is that it would basically remove 0.01 BTC rewards
from the next 210k blocks, and then do nothing.
After 210k blocks have passed, you're just rolling it forward, taking from
the anyone can spend output and locking it in a new one for 210k blocks
from now.
You're basically just using the next 210k block's reward to create a stash
of forever locked coins in a loop.
Unsure how this solves or relates to the smoothing of block rewards. Let me
know if I misunderstood.
Gino Pinuto via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
escreveu no dia quinta, 14/07/2022 à(s) 13:18:
> This is not an argument in line with bitcoin values, on that scenario only
> rich people will be able to mine and participate to the consensus process.
> Like George Soros today, he use its financial reserves to monopolize ONG
> in order to manipulate nation states. I would not define this a "tax",
> moreover a cost to maintain control over the network.
>
> Those rich holders could crate a cartel and without market dynamics all
> game theory stop to work and the bitcoin network value drop.
>
> We should think about how to maximise the network value instead of trying
> to preserve it with corruptible practices outside of market dynamics
> principles.
>
> On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Fees and miner rewards are not needed at all for security at all since
>> long term holders can simply invest in mining to secure the value of their
>> stake.
>>
>> Isn't it enough that the protocol has a mechanism to secure value?
>>
>> Sure fees *might* be enough.
>>
>> But in the event that they are not, large holders can burn a bit to make
>> sure the hashrate stays high.
>>
>> I know, I know it's a tax on the rich and it's not fair because smaller
>> holders are less likely to do it, but it's a miniscule tax even in the
>> worst case
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> > This specific approach would obviously not work as most of those
>>> outputs would be dust and the miner would need to waste an absurd amount of
>>> block space just to grab them, but maybe there's a smarter way to do it.
>>>
>>> There is a smarter way. Just send 0.01 BTC per block to the timelocked
>>> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that
>>> percentage will grow over time, as basic block reward will shrink, and we
>>> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess
>>> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it
>>> simply means you can lock 2,100 BTC in an endless circulation loop, and
>>> avoid this "tail supply attack".
>>>
>>> So, fortunately, even if "tail supply attackers" will win, we will still
>>> have a chance to counter-attack by burning those coins, or (even better) by
>>> locking them in an endless circulation loop, just to satisfy their
>>> malicious soft-fork, whatever amount it will require. Because even if it
>>> will be mandatory to timelock 0.01 BTC to the current block number plus
>>> 210,000, then it is still perfectly valid to move that amount endlessly,
>>> without taking it, just to resist this "tail supply attack".
>>>
>>>
>>> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > What about burning all fees and keep a block reward that will smooth
>>> out while keeping the ~21M coins limit ?
>>>
>>> This would be a hard fork afaict as it would go against the rules of the
>>> coinbase transaction following the usual halving schedule.
>>>
>>> However, if instead we added a rule that fees have to be sent to an
>>> anyone can spend output with a timelock we might be able to achieve a
>>> similar thing.
>>>
>>> Highly inefficient example:
>>>
>>> - Split blocks into 144 (about a day)
>>> - A mined block takes all the fees and distributes them equally into 144
>>> new outputs (anyone can spend) time locked to each of the 144 blocks of the
>>> next day.
>>> - Next day, for each block, we'd have available an amount equivalent to
>>> the previous day total fees / 144. So we deliver previous day's fees
>>> smoothed out.
>>>
>>> Notes:
>>> 144 is arbitrary in the example.
>>> This specific approach would obviously not work as most of those outputs
>>> would be dust and the miner would need to waste an absurd amount of block
>>> space just to grab them, but maybe there's a smarter way to do it.
>>>
>>>
>>>
>>>
>>> Gino Pinuto via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
>>> escreveu no dia quarta, 13/07/2022 à(s) 13:19:
>>> What about burning all fees and keep a block reward that will smooth out
>>> while keeping the ~21M coins limit ?
>>>
>>>
>>> Benefits :
>>> - Miners would still be incentivized to collect higher fees transaction
>>> with the indirect perspective to generate more reward in future.
>>> - Revenues are equally distributed over time to all participants and we
>>> solve the overnight discrepancy.
>>> - Increased velocity of money will reduce the immediate supply of
>>> bitcoin cooling down the economy.
>>> - Reduction of velocity will have an impact on miners only if it
>>> persevere in the long term but short term they will still perceive the
>>> buffered reward.
>>>
>>>
>>> I don't have ideas yet on how to elegantly implement this.
>>>
>>>
>>>
>>> On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > The emission curve lasts over 100 years because Bitcoin success state
>>> requires it to be entrenched globally.
>>>
>>> It effectively doesn't. The last 100 years from 2040-2140 only emits a
>>> pittance of about 0.4 of all bitcoin.
>>>
>>> What matters for proper distribution is the shape of the emission
>>> curve. If you emit 99% in the first year and 1% in the next 100 years,
>>> your emission "lasts" over 100 years, and you achieve a super low
>>> supply inflation rate immediately after 1 year, but it's obviously a
>>> terrible form of distribution.
>>>
>>> This is easy to quantify as the expected time of emission which would
>>> be 0.99 * 0.5yr + 0.01* 51yr = 2 years.
>>> Bitcoin is not much better in that the expected time of emission of an
>>> bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years.
>>>
>>> Monero appears much better since its tail emission yields an infinite
>>> expected time of emission, but if we avoid infinities by looking at
>>> just the soft total emission [1], which is all that is emitted before
>>> a 1% yearly inflation, then Monero is seen to actually be a lot worse
>>> than Bitcoin, due to emitting over 40% in its first year and halving
>>> the reward much faster. Ethereum is much worse still with its huge
>>> premine and PoS coins like Algorand are scraping the bottom with their
>>> expected emission time of 0.
>>>
>>> There's only one coin whose expected (soft) emission time is larger
>>> than bitcoin's, and it's about an order of magnitude larger, at 50
>>> years.
>>>
>>> [1]
>>> https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
>>> _______________________________________________
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20220714/c61c1ae4/attachment.html>

2023-06-07 23:11:51

- reply

2023-06-07 23:11:48

- reply

📅 Original date posted:2022-07-13
📝 Original message:> What about burning all fees and keep a block reward that will smooth out
while keeping the ~21M coins limit ?
This would be a hard fork afaict as it would go against the rules of the
coinbase transaction following the usual halving schedule.
However, if instead we added a rule that fees have to be sent to an anyone
can spend output with a timelock we might be able to achieve a similar
thing.
Highly inefficient example:
- Split blocks into 144 (about a day)
- A mined block takes all the fees and distributes them equally into 144
new outputs (anyone can spend) time locked to each of the 144 blocks of the
next day.
- Next day, for each block, we'd have available an amount equivalent to the
previous day total fees / 144. So we deliver previous day's fees smoothed
out.
Notes:
144 is arbitrary in the example.
This specific approach would obviously not work as most of those outputs
would be dust and the miner would need to waste an absurd amount of block
space just to grab them, but maybe there's a smarter way to do it.
Gino Pinuto via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
escreveu no dia quarta, 13/07/2022 à(s) 13:19:
> What about burning all fees and keep a block reward that will smooth out
> while keeping the ~21M coins limit ?
>
> Benefits :
> - Miners would still be incentivized to collect higher fees transaction
> with the indirect perspective to generate more reward in future.
> - Revenues are equally distributed over time to all participants and we
> solve the overnight discrepancy.
> - Increased velocity of money will reduce the immediate supply of bitcoin
> cooling down the economy.
> - Reduction of velocity will have an impact on miners only if it persevere
> in the long term but short term they will still perceive the buffered
> reward.
>
> I don't have ideas yet on how to elegantly implement this.
>
>
> On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > The emission curve lasts over 100 years because Bitcoin success state
>> requires it to be entrenched globally.
>>
>> It effectively doesn't. The last 100 years from 2040-2140 only emits a
>> pittance of about 0.4 of all bitcoin.
>>
>> What matters for proper distribution is the shape of the emission
>> curve. If you emit 99% in the first year and 1% in the next 100 years,
>> your emission "lasts" over 100 years, and you achieve a super low
>> supply inflation rate immediately after 1 year, but it's obviously a
>> terrible form of distribution.
>>
>> This is easy to quantify as the expected time of emission which would
>> be 0.99 * 0.5yr + 0.01* 51yr = 2 years.
>> Bitcoin is not much better in that the expected time of emission of an
>> bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years.
>>
>> Monero appears much better since its tail emission yields an infinite
>> expected time of emission, but if we avoid infinities by looking at
>> just the soft total emission [1], which is all that is emitted before
>> a 1% yearly inflation, then Monero is seen to actually be a lot worse
>> than Bitcoin, due to emitting over 40% in its first year and halving
>> the reward much faster. Ethereum is much worse still with its huge
>> premine and PoS coins like Algorand are scraping the bottom with their
>> expected emission time of 0.
>>
>> There's only one coin whose expected (soft) emission time is larger
>> than bitcoin's, and it's about an order of magnitude larger, at 50
>> years.
>>
>> [1]
>> https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
>> _______________________________________________
>> 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/20220713/a72fcc5e/attachment-0001.html>

2023-06-07 23:11:48

- reply

2023-06-07 23:10:05

- reply

📅 Original date posted:2022-06-19
📝 Original message:"Long time listener, first time caller". Just sharing my 2 sats:
While I find it stimulating, I think this discussion (and other similar
doom-like scenarios) is somewhat irrelevant in practice.
When the time comes and if we start seeing issues with block rewards being
too low to maintain acceptable security, we're going to have multiple
solutions being implemented for it, and definitely a hard fork to
indefinitely maintain some degree of block subsidy is going to be within
them.
If it is indeed confirmed that the original chain is now insecure,
consensus should eventually coalesce in one of the hard forks that can
actually keep moving forward with some degree of security assurance.
I feel like people sometimes think of these systems as when they fail
there's a full loss, but that's not the case as the history is not lost,
and so we can move forward from that history with multiple alternatives and
allow the social/economic consensus to dictate which one becomes the new
accepted chain.
The genie is out of the box, and some chain whose history is prefixed by
Bitcoin's current chain history will always exist.
The only type of problems we should truly be worrying about are ones that
might invalidate the security of the history itself, like a cryptographic
breakthrough (quantum computing for example) that would turn some or all
utxos into "anyone can spend".
Transitions might be disorderly and filled with drama and discussion as the
"block size wars" in 2017, but anyone who doesn't want to "vote", can
always just keep their utxos frozen in place while the drama sorts itself
out, and maintain whatever holdings they previously had on the new accepted
chain.
Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> escreveu
no dia domingo, 19/06/2022 à(s) 11:32:
> On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote:
> > Hi Peter,
> >
> > > Only because the block reward goes away. If it was made to continue
> > > indefinitely - most likely with an inflation hard fork - demand for
> block space
> > > would not be critical to Bitcoin's security.
> >
> >
> > I am not completely against your proposal although 100% sure this will
> not have "consensus" to be implemented. I think if bitcoin doesn't have
> enough demand for block space, it should die. I will be sad if bitcoin
> doesn't exist but it should be a lesson for all the people opposing soft
> forks based on drama and politics instead of technical review.
> >
> > I don't see anything wrong with users paying 100x fees for opening and
> closing LN channels.
>
> The PoW security of Bitcoin benefits all Bitcoin users, proportional to the
> value of BTC they hold; if Bitcoin blocks aren't reliably created the
> value of
> *all* BTC goes down. It doesn't make sense for the entire cost of that
> security
> to be paid for on a per-tx basis. And there's a high chance paying for it
> on a
> per-tx basis won't work anyway due to lack of consistent demand.
>
> It would be extremely unfortunate if one of the very few decentralized
> ways to
> store value died simply because we couldn't find a way to pay to keep it
> secure.
>
> --
> 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/20220619/6e169224/attachment.html>

2023-06-07 22:59:45

- reply

📅 Original date posted:2021-10-03
📝 Original message:Good morning everyone,
Just wanted to point out a few things for discussion which may or may not
be obvious:
1) A simple scheme as described by ZmnSCPxj first can lead way for a
standardized process where people can excuse their legitimate attempts to
actually introduce vulnerabilities, where they create the precommit and
then attempt to introduce the vulnerability. If it goes wrong they have
plausible deniability by revealing it and possibly saving their reputation.
2) A more complex scheme as described by Ryan (from my very rough
understanding) seems to imply a random selection of team for attempting the
attack, which might be limiting, since someone willing to do it and with
enough knowledge to attempt it properly might not be picked.
It seems to me that an ideal process would start from the will to attempt
it from one person (or group), which then by some process similar to what
Ryan described will pick at random a team of people to back up his claim to
be doing it in good faith. With that selection done, the initial person
would warn and gather from the randomly chosen participants a set of
signatures for a similar message as described by ZmnSCPxj and only then go
ahead with the attempt. This way you achieve:
- One person can initiate it at will.
- Other people (provably chosen at random) are insiders to that information
and have a shared precommit.
- You can't not reveal your intent in case it isn't caught, since other
randomly chosen people are in on it.
- You can't pick a specific group of people which might be willing to
collude with you to achieve a similar situation to 1).
Another important consideration is that depending on the size of the team
to be insiders, we might by chance deplete the relevant pool of outsiders
which would be adequate for reviewing the specific details of the
vulnerability being introduced.
Prayank via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> escreveu no
dia sábado, 2/10/2021 à(s) 10:20:
> This looks interesting although I don't understand few things:
>
> > The scheme should include public precommitments collected at ceremonial
> intervals.
>
> How would this work? Can you explain with an example please.
>
> > Upon assignment, the dev would have community approval to
> opportunistically insert a security flaw
>
> Who is doing the assignment?
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Oct 2, 2021, 01:45 by bitcoin-dev at rgrant.org:
>
> Due to the uneven reputation factor of various devs, and uneven review
> attention for new pull requests, this exercise would work best as a
> secret sortition.
>
> Sortition would encourage everyone to always be on their toes rather
> than only when dealing with new github accounts or declared Red Team
> devs. The ceremonial aspects would encourage more devs to participate
> without harming their reputation.
>
> https://en.wikipedia.org/wiki/Sortition
> https://en.wikipedia.org/wiki/Red_team
>
> The scheme should include public precommitments collected at
> ceremonial intervals.
>
> where:
> hash1 /* sortition ticket */ = double-sha256(secret)
> hash2 /* public precommitment */ = double-sha256(hash1)
>
> The random oracle could be block hashes. They could be matched to
> hash1, the sortition ticket. A red-team-concurrency difficulty
> parameter could control how many least-significant bits must match to
> be secretly selected. The difficulty parameter could be a matter of
> group consensus at the ceremonial intervals, based on a group decision
> on how much positive effect the Red Team exercise is providing.
>
> Upon assignment, the dev would have community approval to
> opportunistically insert a security flaw; which, when either caught,
> merged, or on timeout, they would reveal along with the sortition
> ticket that hashes to their public precommitment.
>
> Sortition Precommitment Day might be once or twice a year.
>
>
> _______________________________________________
> 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/20211003/a5d700cb/attachment-0001.html>