Daniele Pinna [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-21 to 2018-02-19
💬 Posted a total of 21 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub16z2msvydkmd6xsjyrggnavcwrlpevfwq74x5avxrkg2dpq7cg6js5jg59c

Profile Code

nprofile1qqsdp9dcxzxmdkargfzp5yf7kv8plsukyhq02n2wkrpmy9xss0vydfguk6ucw

Author Public Key

npub16z2msvydkmd6xsjyrggnavcwrlpevfwq74x5avxrkg2dpq7cg6js5jg59c

Show more details

Last Notes

2023-06-07 18:10:57

- reply

📅 Original date posted:2018-02-19
📝 Original message:Granted that removing the 21M coin cap is basically a non-starter in de
bitcoin community I'd like to respond to a couple points in your proposal.
The Y% difficulty adjustment should still be calculated through some
averaging of a certain number N of past blocks. Otherwise two lucky high
difficulty blocks in a row could potentially grind the network to a halt.
Just imagine what would happen to the bitcoin network if the difficulty
target was magically increased by 40% all of a sudden. This is certainly
not likely but must be considered imo.
The second, and most interesting (to me at least) is how the reward should
scale with difficulty. By making the reward scale concavely
(logarithmically for example) with difficulty as well as depend on past
average difficulty AND total # of mined coins, it might be possible to
retain something close to the 21M coin cap while also disincentivizing
mining blocks with excessively large difficulties.
Let D and D_0 be the difficulty of the mind block and some reference
initial difficulty respectively. S and S_0 the total floating coin supply
and the reference initial supply. Then the reward function could look
something like this:
R(D, S; D_0,S_0) =R_0(S/S_0)*Log[1+D/D_0]/Log[2]
Where R_0(S/S_0) can be some decaying exponential function of the ratio
S/S_0 such that initially (when S=S_0) R_0=12.5.
But... As I said, this is solely for sake of argument.
Daniele
---------- Forwarded message ----------
From: Tao Effect <contact at taoeffect.com>
To: Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc:
Bcc:
Date: Sun, 18 Feb 2018 20:29:50 -0500
Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW
Copied from: https://github.com/WebOfTrustInfo/rebooting-the-
web-of-trust-spring2018/pull/13
# Blockchain Timestamps Unnecessary In Proof-of-Work?
*Author: Greg Slepak ([@taoeffect at mastodon.social](https://mastodon.social/@
taoeffect))*
----
The Bitcoin blockchain has a 10-minute target blocktime that is achieved by
a difficulty adjustment algorithm.
I assert, or rather, pose the hypothesis, that the use of timestamps in
Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with
the same security guarantees without it (except as noted in [Risks and
Mitigations](#risks-and-mitigations)), and therefore does not need miners
to maintain global clock synchronization.
The alternative difficulty adjustment algorithm would work according to the
following principles:
- The incentive for miners is and always has been to maximize profit.
- The block reward algorithm is now modified to issue coins into perpetuity
(no maximum). Any given block can issue _up to_ `X` number of coins per
block.
- The number of coins issued per block is now tied directly to the
difficulty of the block, and the concept of "epocs" or "block reward
halving" is removed.
- The chain selection rule remains "chain with most proof of work"
- The difficulty can be modified by miners in an arbitrary direction (up or
down), but is limited in magnitude by some maximum percentage (e.g. no more
than 20% deviation from the previous block), we call this `Y%`.
### Observations
- Miners are free to mine blocks of whatever difficulty they choose, up to
a maximum deviation
- The blockchain may at times produce blocks very quickly, and at other
times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty to remove
competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly is entirely up
to them. If they produce blocks quickly, each block has a lower reward, but
there are more of them. If they produce blocks slowly, each block has a
higher reward, but there are fewer of them. So an equilibrium will be
naturally reached to produce blocks at a rate that should minimize orphans.
A timestamp may still be included in blocks, but it no longer needs to be
used for anything, or represent anything significant other than metadata
about when the miner claims to have produced the block.
### Risks and Mitigations
Such a system may introduce risks that require further modification of the
protocol to mitigate.
The most straightforward risk comes from the potential increase in total
transaction throughput that such a change would introduce (these are the
same concerns that exist with respect to raising the blocksize). The
removal of timestamps would allow a cartel of miners to produce
high-difficulty blocks at a fast rate, potentially resulting in additional
centralization pressures not only on miners but also on full nodes who then
would have greater difficulty keeping up with the additional bandwidth and
storage demands.
Two equally straightforward mitigations exist to address this if we are
given the liberty of modifying the protocol as we wish:
1. Introducing state checkpoints into the chain itself could make it
possible for full nodes to skip verification of large sections of
historical data when booting up.
2. A sharded protocol, where each shard uses a "sufficiently different" PoW
algorithm, would create an exit for users should the primary blockchain
become captured by a cartel providing poor quality-of-service.
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180219/b27ba57b/attachment.html>

2023-06-07 18:06:37

- reply

📅 Original date posted:2017-09-29
📝 Original message:Maybe I'm getting this wrong but wouldn't this scheme imply that a miner is
incentivized to limit the amount of transactions in a block to capture the
maximum fee of the ones included?
As an example, mined blocks currently carry ~0.8 btc in fees right now. If
I were to submit a transaction paying 1 btc in maximal money fees, then the
miner would be incentivized to include my transaction alone to avoid that
lower fee paying transactions reduce the amount of fees he can earn from my
transaction alone. This would mean that I could literally clog the network
by paying 1btc every ten minutes.
Am I missing something?
Daniele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170929/5ecfcff9/attachment.html>

2023-06-07 18:04:57

- reply

📅 Original date posted:2017-08-22
📝 Original message:Also.... how is this not a tax on coin holders? By forcing people to move
coins around you would be chipping away at their wealth in the form of
extorted TX fees.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170823/f6446dee/attachment.html>

2023-06-07 18:01:22

- reply

📅 Original date posted:2017-05-22
📝 Original message:I couldn't agree more. It would require however for the Devs to throw their
weight behind this with a lot of momentum. Spoonnet has been under
development for quite some time now. Counter offering SegWit plus Spoonnet
12-24 months later would be a very progressive stance that I think would
catch the interest of large swaths of the community. I'd be curious to hear
Johnson's opinion on this. How much more testing would his proposal require?
Daniele
----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 May 2017 11:23:22 +0200
> From: Hampus Sj?berg <hampus.sjoberg at gmail.com>
> To: shaolinfry <shaolinfry at protonmail.ch>
> Cc: Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
> Message-ID:
> <CAFMkqK_8CfaPmZgwMqGWpRujmmyGKXhZyxK_
> tQ6f1OMHKdEMJA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I'm really happy to see people trying to cooperate to get SegWit activated.
> But I'm really unsure about the technicalities about Silbert's proposal.
>
> If we're going to do a hardfork, it makes most sense to assist Johnson in
> his spoonnet/forcenet proposals.
> Just doing a simple 2MB without fixing anything else is very uninteresting,
> and a hardfork without addressing replay protection seems really
> unprofessional to me.
> And proposing a hardfork in 4 months in the future, is completely insane.
> You cannot expect a 100% of all nodes in P2P network to upgrade in 4
> months.
>
> I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB
> September 2018, or 2019 (together with forcenet/spoonnet).
> And if not, BIP148 is gaining momentum once again so that sounds much more
> interesting.
>
> Hampus
>
> 2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
> > Someone sent me a copy of the Barry Silbert agreement, an agreement
> forged
> > between a select number of participants https://pastebin.com/VuCYteJh
> >
> > Participants agree to immediately activate Segwit, however, under a
> > different activation proposal. Since I have spent the last few months
> > researching various activation strategies of the current BIP141
> deployment,
> > as well as redeployment, I feel I am quite well placed to comment on the
> > technicalities.
> >
> > To be clear, the proposal as far as I can see does not activate BIP141,
> > but is a completely new deployment which would be incompatible with the
> > BIP141 deployment. I'm not sure how that can be considered "immediate"
> > activation. Surely immediate activation would just be for miners to start
> > signalling and segwit would be activated in 4-5 weeks. The proposal seems
> > to require a lower 80% threshold, I assume because they were unable to
> > convince 95% of the hashpower to go trigger activation.
> >
> > There are a few options to activating segwit now, the first being for 95%
> > of hashrate to signal. The second is for the community to deploy BIP148
> > UASF which will force miners to signal segwit. Being a UASF it is date
> > triggered. The third option is a redeployment of segwit on a new bit, but
> > requires waiting for the existing deployment to time out, because all the
> > p2p messages and service bits related to segwit must be replaced too
> (which
> > is what BIP149 does).
> >
> > A fourth option, first suggested to me by James Hilliard, was to make
> > BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded
> > this up a few weeks ago https://github.com/bitcoin/
> > bitcoin/compare/master...shaolinfry:segsignal but didnt get around to
> > posting to the ML yet. This effectively lowers the threshold from 95% to
> > 65% as coded, or could be upped to 80% or whatever was preferable.
> >
> > I think this removes the primary risk of BIP148 causing the creation of
> > two chains, and gives an improved chance to get segwit activated quickly
> > (assuming a majority of miners wish to go this route). But hash a primary
> > disadvantage of still leaving the activation in the hands of miners. If
> it
> > doesn't work out, then BIP149 can then be used as proposed, but it'll be
> > even safer because we'll have futher guaged support.
> >
> > References:
> >
> > SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...
> > shaolinfry:segsignal
> > BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> > BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
> >
> > I think the Barry Silbert agreement is very ill considered, and clearly
> > lacking peer review from the technical community. Suggestions of a HF in
> 4
> > months are completely unrealistic and without technical merits. But more
> > importantly, closed door agreements between selected participants is not
> > how to garner consensus to change a $30bn decentralized system. The
> purpose
> > of my email is to try and assist in the "immediate activation of segwit"
> > which only requires hashrate to participate; and to provide some
> techincal
> > input since I have done a great deal of research and development into the
> > topic.
> >
> > Given the history we've already passed the point where we should be
> > expecting miners to cooperate in lowering their own fee income with a
> > capacity increase; but we should be open to all reasonable options in the
> > interest in moving things forward in a safe and collaborative way.
> >
> > _______________________________________________
> > 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/20170522/7b48551a/attachment.html>

2023-06-07 17:59:28

- reply

📅 Original date posted:2017-04-06
📝 Original message:Can you please not forget to supply us more details on the claims made
regarding the reverse engineering of the Asic chip?
It is absolutely crucial that we get these independently verified ASAP.
Daniele
Message: 2
> Date: Thu, 6 Apr 2017 21:38:31 +0000
> From: Gregory Maxwell <greg at xiph.org>
> To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on
> the Bitcoin POW function
> Message-ID:
> <CAAS2fgSTrMjKZVpL4wRidnzTCC9O3OEF=oCnROf1pggz2cDgJA at mail.
> gmail.com>
> Content-Type: text/plain; charset=UTF-8
> On Wed, Apr 5, 2017 at 9:37 PM, Gregory Maxwell <greg at xiph.org> wrote:
> > each block MUST either contain a BIP-141 segwit commitment or a
> > correct WTXID commitment with ID 0xaa21a9ef.
> It was just pointed out to me that the proposed ID (which I just
> selected to be above the segwit one) collides with one chosen in
> another non-BIP proposal. This wasn't intentional, and I'll happily
> change the value when I update the document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/6fcc62db/attachment.html>

2023-06-07 17:58:18

- reply

📅 Original date posted:2017-03-29
📝 Original message:What about periodically committing the entire UTXO set to a special
checkpoint block which becomes the new de facto Genesis block?
Daniele
------------------------------
Message: 5
Date: Wed, 29 Mar 2017 16:41:29 +0000
From: Andrew Johnson <andrew.johnson83 at gmail.com>
To: David Vorick <david.vorick at gmail.com>
Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
Message-ID:
<CAAy62_+JtoAuM-RsrAAp5eiGiO+OHLDjzqgbnF2De7TUU7TyYg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I believe that as we continue to add users to the system by scaling
capacity that we will see more new nodes appear, but I'm at a bit of a loss
as to how to empirically prove it.
I do see your point on increasing load on archival nodes, but the majority
of that load is going to come from new nodes coming online, they're the
only ones going after very old blocks. I could see that as a potential
attack vector, overwhelm the archival nodes by spinning up new nodes
constantly, therefore making it difficult for a "real" new node to get up
to speed in a reasonable amount of time.
Perhaps the answer there would be a way to pay an archival node a small
amount of bitcoin in order to retrieve blocks older than a certain cutoff?
Include an IP address for the node asking for the data as metadata in the
transaction... Archival nodes could set and publish their own policy, let
the market decide what those older blocks are worth. Would also help to
incentivize running archival node, which we do need. Of course, this isn't
very user friendly.
We can take this to bitcoin-discuss, if we're getting too far off topic.
On Wed, Mar 29, 2017 at 11:25 AM David Vorick <david.vorick at gmail.com>
wrote:
>
> On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
> wrote:
>
> What's stopping these users from running a pruned node? Not every node
> needs to store a complete copy of the blockchain.
>
>
> Pruned nodes are not the default configuration, if it was the default
> configuration then I think you would see far more users running a pruned
> node.
>
> But that would also substantially increase the burden on archive nodes.
>
>
> Further discussion about disk space requirements should be taken to
> another thread.
>
>
> --
Andrew Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20170329/9b48ebe3/attachment.html>
------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9ef02e82/attachment.html>

2023-06-07 17:55:48

- reply

📅 Original date posted:2017-01-27
📝 Original message:Your BIP implementation should stress the capacity to softfork the rate of
blocksize increase if necessary. You briefly mention that:
*If over time, this growth factor is beyond what the actual technology
offers, the intention should be to soft fork a tighter limit.*
However this can work both ways so that the rate can potentially be
increased also. I think just mentioning this will soothe a lot of future
critiques.
Daniele
*Message: 5Date: Fri, 27 Jan 2017 01:06:59 +0000From: Luke Dashjr
<luke at dashjr.org
<luke at dashjr.org>>To: bitcoin-dev at lists.linuxfoundation.org
<bitcoin-dev at lists.linuxfoundation.org>Subject: [bitcoin-dev] Three
hardfork-related BIPsMessage-ID: <201701270107.01092.luke at dashjr.org
<201701270107.01092.luke at dashjr.org>>Content-Type: Text/Plain;
charset="utf-8"I've put together three hardfork-related BIPs. This is
parallel to the ongoingresearch into the MMHF/SHF WIP BIP, which might
still be best long-term.1) The first is a block size limit protocol change.
It also addresses threecriticisms of segwit: 1) segwit increases the block
size limit which isalready considered by many to be too large; 2) segwit
treats pre-segwittransactions ?unfairly? by giving the witness discount
only to segwittransactions; and 3) that spam blocks can be larger than
blocks mininglegitimate transactions. This proposal may (depending on
activation date)initially reduce the block size limit to a more sustainable
size in the short-term, and gradually increase it up over the long-term to
31 MB; it will alsoextend the witness discount to non-segwit transactions.
Should the initialblock size limit reduction prove to be too controversial,
miners can simplywait to activate it until closer to the point where it
becomes acceptableand/or increases the limit. However, since the BIP
includes a hardfork, theeventual block size increase needs community
consensus before it can bedeployed. Proponents of block size increases
should note that this BIP doesnot interfere with another more aggressive
block size increase hardfork in themeantime. I believe I can immediately
recommend this for adoption; however,peer and community review are welcome
to suggest
changes.Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki
<https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki>Code:
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize
<https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize>(consensus
code changes only)2) The second is a *preparatory* change, that should
allow triviallytransforming certain classes of hardforks into softforks in
the future. Itessentially says that full nodes should relax their rule
enforcement, aftersufficient time that would virtually guarantee they have
ceased to beenforcing the full set of rules anyway. This allows these
relaxed rules to bemodified or removed in a softfork, provided the proposal
to do so is acceptedand implemented with enough advance notice. Attempting
to implement this hasproven more complicated than I originally expected,
and it may make more sensefor full nodes to simply stop functioning (with a
user override) after thecut-off date). In light of this, I do not yet
recommend its adoption, but amposting it for review and comments
only.Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
<https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki>3)
Third is an anti-replay softfork which can be used to prevent replayattacks
whether induced by a hardfork-related chain split, or even in
ordinaryoperation. It does this by using a new opcode
(OP_CHECKBLOCKATHEIGHT) for theBitcoin scripting system that allows
construction of transactions which arevalid only on specific
blockchains.Text:
https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki
<https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki>Luke*
Daniele Pinna, Ph.D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170127/50920e07/attachment.html>

2023-06-07 17:54:54

- reply

📅 Original date posted:2016-12-11
📝 Original message:How is the adverse scenario you describe different from a plain old 51%
attack? Each proposed protocol change where 51% or more of the network
can potentially game the rules and break the system should be considered
just as acceptable/unacceptable as another.
There comes a point where some form of basic honesty must be assumed on
behalf of participants benefiting from the system working properly and
reliably.
Afterall, what magic line of code prohibits all miners from simultaneously
turning all their equipment off... just because?
Maybe this 'one':
"As long as a majority of CPU power is controlled by nodes that are not
cooperating to attack the network, they'll generate the longest chain and
outpace attackers. The network itself requires minimal structure."
Is there such a thing as an unrecognizable 51% attack? One where the
remaining 49% get dragged in against their will?
Daniele
On Dec 10, 2016 6:39 PM, "Pieter Wuille" <pieter.wuille at gmail.com> wrote:
> On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> We have models for estimating the probability that a block is orphaned
>> given average network bandwidth and block size.
>>
>> The question is, do we have objective measures of these two quantities?
>> Couldn't we target an orphan_rate < max_rate?
>>
>
> Models can predict orphan rate given block size and network/hashrate
> topology, but you can't control the topology (and things like FIBRE hide
> the effect of block size on this as well). The result is that if you're
> purely optimizing for minimal orphan rate, you can end up with a single
> (conglomerate of) pools producing all the blocks. Such a setup has no
> propagation delay at all, and as a result can always achieve 0 orphans.
>
> Cheers,
>
> --
> Pieter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/53c05206/attachment.html>

2023-06-07 17:54:53

- reply

📅 Original date posted:2016-12-10
📝 Original message:We have models for estimating the probability that a block is orphaned
given average network bandwidth and block size.
The question is, do we have objective measures of these two quantities?
Couldn't we target an orphan_rate < max_rate?
On Dec 10, 2016 1:01 PM, <bitcoin-dev-request at lists.linuxfoundation.org>
wrote:
Send bitcoin-dev mailing list submissions to
bitcoin-dev at lists.linuxfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
bitcoin-dev-request at lists.linuxfoundation.org
You can reach the person managing the list at
bitcoin-dev-owner at lists.linuxfoundation.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."
Today's Topics:
1. Managing block size the same way we do difficulty (aka
Block75) (t. khan)
2. Re: Managing block size the same way we do difficulty (aka
Block75) (s7r)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 Dec 2016 10:27:32 -0500
From: "t. khan" <teekhan42 at gmail.com>
To: bitcoin-dev at lists.linuxfoundation.org
Subject: [bitcoin-dev] Managing block size the same way we do
difficulty (aka Block75)
Message-ID:
<CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
BIP Proposal - Managing Bitcoin?s block size the same way we do difficulty
(aka Block75)
The every two-week adjustment of difficulty has proven to be a reasonably
effective and predictable way of managing how quickly blocks are mined.
Bitcoin needs a reasonably effective and predictable way of managing the
maximum block size.
It?s clear at this point that human beings should not be involved in the
determination of max block size, just as they?re not involved in deciding
the difficulty.
Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
passing the decision to miners/pool operators, the max block size should be
adjusted every two weeks (2016 blocks) using a system similar to how
difficulty is calculated.
Put another way: let?s stop thinking about what the max block size should
be and start thinking about how full we want the average block to be
regardless of size. Over the last year, we?ve had averages of 75% or
higher, so aiming for 75% full seems reasonable, hence naming this concept
?Block75?.
The target capacity over 2016 blocks would be 75%. If the last 2016 blocks
are more than 75% full, add the difference to the max block size. Like this:
MAX_BLOCK_BASE_SIZE = 1000000
TARGET_CAPACITY = 750000
AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
TARGET_CAPACITY
To check if a block is valid, ? (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
For example, if the last 2016 blocks are 85% full (average block is 850
KB), add 10% to the max block size. The new max block size would be 1,100
KB until the next 2016 blocks are mined, then reset and recalculate. The
1,000,000 byte limit that exists currently would remain, but would
effectively be the minimum max block size.
Another two weeks goes by, the last 2016 blocks are again 85% full, but now
that means they average 935 KB out of the 1,100 KB max block size. This is
93.5% of the 1,000,000 byte limit, so 18.5% would be added to that to make
the new max block size of 1,185 KB.
Another two weeks passes. This time, the average block is 1,050 KB. The new
max block size is calculated to 1,300 KB (as blocks were 105% full, minus
the 75% capacity target, so 30% added to max block size).
Repeat every 2016 blocks, forever.
If Block75 had been applied at the difficulty adjustment on November 18th,
the max block size would have been 1,080KB, as the average block during
that period was 83% full, so 8% is added to the 1,000KB limit. The current
size, after the December 2nd adjustment would be 1,150K.
Block75 would allow the max block size to grow (or shrink) in response to
transaction volume, and does so predictably, reasonably quickly, and in a
method that prevents wild swings in block size or transaction fees. It
attempts to keep blocks at 75% total capacity over each two week period,
the same way difficulty tries to keep blocks mined every ten minutes. It
also keeps blocks as small as possible.
Thoughts?
-t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20161205/c24d6c6d/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 10 Dec 2016 12:44:31 +0200
From: s7r <s7r at sky-ip.org>
To: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Managing block size the same way we do
difficulty (aka Block75)
Message-ID: <c318f76d-0904-2e1b-453b-60179f8209bb at sky-ip.org>
Content-Type: text/plain; charset="utf-8"
t. khan via bitcoin-dev wrote:
> BIP Proposal - Managing Bitcoin?s block size the same way we do
> difficulty (aka Block75)
>
> The every two-week adjustment of difficulty has proven to be a
> reasonably effective and predictable way of managing how quickly blocks
> are mined. Bitcoin needs a reasonably effective and predictable way of
> managing the maximum block size.
>
> It?s clear at this point that human beings should not be involved in the
> determination of max block size, just as they?re not involved in
> deciding the difficulty.
>
> Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
> passing the decision to miners/pool operators, the max block size should
> be adjusted every two weeks (2016 blocks) using a system similar to how
> difficulty is calculated.
>
> Put another way: let?s stop thinking about what the max block size
> should be and start thinking about how full we want the average block to
> be regardless of size. Over the last year, we?ve had averages of 75% or
> higher, so aiming for 75% full seems reasonable, hence naming this
> concept ?Block75?.
>
> The target capacity over 2016 blocks would be 75%. If the last 2016
> blocks are more than 75% full, add the difference to the max block size.
> Like this:
>
> MAX_BLOCK_BASE_SIZE = 1000000
> TARGET_CAPACITY = 750000
> AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
> TARGET_CAPACITY
>
> To check if a block is valid, ? (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
>
> For example, if the last 2016 blocks are 85% full (average block is 850
> KB), add 10% to the max block size. The new max block size would be
> 1,100 KB until the next 2016 blocks are mined, then reset and
> recalculate. The 1,000,000 byte limit that exists currently would
> remain, but would effectively be the minimum max block size.
>
> Another two weeks goes by, the last 2016 blocks are again 85% full, but
> now that means they average 935 KB out of the 1,100 KB max block size.
> This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
> that to make the new max block size of 1,185 KB.
>
> Another two weeks passes. This time, the average block is 1,050 KB. The
> new max block size is calculated to 1,300 KB (as blocks were 105% full,
> minus the 75% capacity target, so 30% added to max block size).
>
> Repeat every 2016 blocks, forever.
>
> If Block75 had been applied at the difficulty adjustment on November
> 18th, the max block size would have been 1,080KB, as the average block
> during that period was 83% full, so 8% is added to the 1,000KB limit.
> The current size, after the December 2nd adjustment would be 1,150K.
>
> Block75 would allow the max block size to grow (or shrink) in response
> to transaction volume, and does so predictably, reasonably quickly, and
> in a method that prevents wild swings in block size or transaction fees.
> It attempts to keep blocks at 75% total capacity over each two week
> period, the same way difficulty tries to keep blocks mined every ten
> minutes. It also keeps blocks as small as possible.
>
> Thoughts?
>
> -t.k.
>
I like the idea. It is good wrt growing the max. block size
automatically without human action, but the main problem (or question)
is not how to grow this number, it is what number can the network
handle, considering both miners and users. While disk space requirements
might not be a big problem, block propagation time is. The time required
for a block to propagate in the network (or at least to all the miners)
is directly dependent of its size. If blocks take too much time to
propagate in the network, the orphan rate will increase in unpredictable
ways. For example if the internet speed in China is worse than in
Europe, and miners in China have more than 50% of the hashing power,
blocks mined by European miners might get orphaned.
The system as described can also be gamed, by filling the network with
transactions. Miners have the monetary interest to include as many
transactions as possible in a block in order to collect the fees.
Regardless how you think about it, there has to be a maximum block size
that the network will allow as a consensus rule. Increasing it
dynamically based on transaction volume will reach a point where the
number got big enough that it broke things. Bitcoin, because its
fundamental design, can scale by using offchain solutions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/
attachments/20161210/c231038d/attachment-0001.sig>
------------------------------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
End of bitcoin-dev Digest, Vol 19, Issue 4
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/1747b6c1/attachment-0001.html>

2023-06-07 17:49:49

- reply

📅 Original date posted:2016-03-08
📝 Original message:This seems unnecessarily complicated ("don't use cannon to kill mosquito"
kind of thing). If the community were interested in a realtime hashrate
rebalancing proposal one could simply adjust difficulty at each new block
using the current method.
If faster relaxation in case of adversity is required, it suspect that it
would suffice to perform a weighted average of the previous 2016 blocks
instead of the standard averaging that is currently done. It should be
possible to find an optimal weighting based on historical interblock timing
data. I look into it over the next couple of days.
dpinna
> ------------------------------
>
> Message: 3
> Date: Tue, 8 Mar 2016 22:05:07 +0000
> From: Bob McElrath <bob_bitcoin at mcelrath.org>
> To: Dave Hudson <dave at hashingit.com>
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
> Message-ID: <20160308220507.GA4388 at mcelrath.org>
> Content-Type: text/plain; charset=us-ascii
>
> Dave Hudson via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org] wrote:
> > I think the biggest question here would be how would the difficulty
> > retargeting be changed? Without seeing the algorithm proposal it's
> difficult
> > to assess the impact that it would have, but my intuition is that this is
> > likely to be problematic.
>
> I have no comment on whether this will be *needed* but there's a simple
> algorithm that I haven't seen any coin adopt, that I think needs to be: the
> critically damped harmonic oscillator:
>
> http://mathworld.wolfram.com/CriticallyDampedSimpleHarmonicMotion.html
>
> In dynamical systems one does a derivative expansion. Here we want to
> find the
> first and second derivatives (in time) of the hashrate. These can be
> determined
> by a method of finite differences, or fancier algorithms which use a
> quadratic
> or quartic polynomial approximation. Two derivatives are generally all
> that is
> needed, and the resulting dynamical system is a damped harmonic oscillator.
>
> A damped harmonic oscillator is basically how your car's shock absorbers
> work.
> The relevant differential equation has two parameters: the oscillation
> frequency
> and damping factor. The maximum oscillation frequency is the block rate.
> Any
> oscillation faster than the block rate cannot be measured by block times.
> The
> damping rate is an exponential decay and for critical damping is twice the
> oscillation frequency.
>
> So, this is a zero parameter, optimal damping solution for a varying
> hashrate.
> This is inherently a numeric approximation solution to a differential
> equation,
> so questions of approximations for the hashrate enter, but that's all.
> Weak
> block proposals will be able to get better approximations to the hashrate.
>
> If solving this problem is deemed desirable, I can put some time into
> this, or
> direct others as to how to go about it.
>
> --
> Cheers, Bob McElrath
>
> "For every complex problem, there is a solution that is simple, neat, and
> wrong."
> -- H. L. Mencken
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160309/9e70ecd6/attachment.html>

2023-06-07 17:45:48

- reply

📅 Original date posted:2015-12-09
📝 Original message:If SegWit were implemented as a hardfork, could the entire blockchain be
reorganized starting from the Genesis block to free up historical space?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/685bb9ff/attachment.html>

2023-06-07 17:42:18

- reply

📅 Original date posted:2015-10-02
📝 Original message:The recently published paper I referenced cite's the Cuckoo cycle
algorithm, discusses its limitations and explains how their proposed
algorithm greatly improves on it. Again.... you're probably in a WAYYY
better position to judge this than I am. My question was purely
hypothetical as I wanted to know where the core devs stand on flipping the
mining ecosystem upside down.
Thanks for your link though, I'll read it right now (before finishing the
research article i posted :) ).
Daniele
Daniele Pinna, Ph.D
On Fri, Oct 2, 2015 at 10:14 AM, Adam Back <adam at cypherspace.org> wrote:
> There are papers demonstrating this "protection from ASIC/FPGA
> optimization" to be basically impossible
> https://download.wpsoftware.net/bitcoin/asic-faq.pdf and yet people
> keep trying...
>
> See also John Tromps cuckoo cycle paper, seems close to the best you
> could expect from memory hard.
>
> Adam
>
> On 2 October 2015 at 10:02, Daniele Pinna via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The following paper proposing an asymmetric memory-hard PoW had been
> > recently published:
> >
> > http://eprint.iacr.org/2015/946.pdf
> >
> > My intent is not to promote the paper as I have not finished studying it
> > myself. I am however interested in the dev-list's stance on potentially
> > altering the bitcoin PoW protocol should an algorithm that guarantees
> > protection from ASIC/FPGA optimization be found.
> >
> > I assume that, given the large amount of money invested by some miners
> into
> > their industrial farms this would represent a VERY contentious hard fork.
> >
> > It is, however, also true that a novel optimization-resistant algorithm
> > could greatly ameliorate decentralization in the bitcoin network due to a
> > resurgence of desktop/cellphone mining.
> >
> > Where do the core devs stand on this matter, hypothetical as it may be?
> >
> > Dpinna
> >
> >
> > _______________________________________________
> > 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/20151002/0ca300a8/attachment-0001.html>

2023-06-07 17:42:17

- reply

📅 Original date posted:2015-10-02
📝 Original message:Interesting! I didn't notice BIP 99's anti-miner hardfork proposal....
thanks for pointing it out to me.
Dpinna
Daniele Pinna, Ph.D
On Fri, Oct 2, 2015 at 10:20 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > should an algorithm that guarantees protection from ASIC/FPGA
> optimization be found.
>
> This is demonstrably impossible: anything that can be done with software
> can be done with hardware. This is computer science 101.
> And specialized hardware can always be more efficient, at least
> energy-wise.
>
> On the other hand, BIP99 explicitly contemplates "anti-miner hardforks"
> (obviously not for so called "ASIC-resistance" [an absurd term coined to
> promote some altcoins], but just for restarting the ASIC and mining market
> in case mining becomes too centralized).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151002/af19280a/attachment.html>

2023-06-07 17:42:16

- reply

📅 Original date posted:2015-10-02
📝 Original message:The following paper proposing an asymmetric memory-hard PoW had been
recently published:
http://eprint.iacr.org/2015/946.pdf
My intent is not to promote the paper as I have not finished studying it
myself. I am however interested in the dev-list's stance on potentially
altering the bitcoin PoW protocol should an algorithm that guarantees
protection from ASIC/FPGA optimization be found.
I assume that, given the large amount of money invested by some miners into
their industrial farms this would represent a VERY contentious hard fork.
It is, however, also true that a novel optimization-resistant algorithm
could greatly ameliorate decentralization in the bitcoin network due to a
resurgence of desktop/cellphone mining.
Where do the core devs stand on this matter, hypothetical as it may be?
Dpinna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151002/1f3c81ea/attachment.html>

2023-06-07 17:38:59

- reply

📅 Original date posted:2015-09-01
📝 Original message:My paper did show that the advantage decreased with the block reward.
However, in that limit, it also seemed to imply that a network state would
appear where the revenue per unit hash decreased with increasing hashrate
which should be impossible as just discussed.
In a followup email, I showed how the origin of this effect stems from the
orphaning factor used which doesn't preserve the full network revenue per
unit block. This led me to correct my assertions by pointing out that our
miner profit equations seemed to be just lower bounds to the miner's true
expected profit. As such, just because the *lower bound* on the revenue per
unit hash advantage decreases with the block reward, this doesn't
necessarily imply that the *real* revenue per unit hash advantage does also.
I suspect that the orphaning factor used, independently of the specific
form of the block relay time, is incorrect or incomplete as stated.
Best,
Daniele
Daniele Pinna, Ph.D
On Tue, Sep 1, 2015 at 10:06 AM, Peter R <peter_r at gmx.com> wrote:
> On 2015-09-01, at 12:56 AM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote
>
>
> FWIW I did a quick math proof along those lines awhile back too using
> some basic first-year math, again proving that larger miners earn more
> money per unit hashing power:
>
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03272.html
>
>
> I don't believe anyone is arguing otherwise. Miners with a larger
> fraction of the network hash rate, *h*/*H*, have a theoretical advantage,
> all other variables in the miner's profitability equation held constant.
>
> Dpinna originally claimed (unless I'm mistaken) that his paper showed that
> this advantage *decreased* as the block reward diminished or as the total
> fees increased. This didn't seem unreasonable to me, although I never
> checked the math.
>
> Best regards,
> Peter
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/352b7446/attachment.html>

2023-06-07 17:38:43

- reply

📅 Original date posted:2015-08-30
📝 Original message:Since my longer post seems to be caught in moderator purgatory I will
rehash its results into this much smaller message. I apologize for the
spamming.
I present a theorem whose thesis is obvious to many.
*THESIS: All hashrates* *h' > h generate a revenue per unit of hash v' >
v. *
Let us absurdly[1] assume that an optimal hashrate *h* exists where the
average revenue for each hash in service is maximized. This will result
from perpetually mining blocks of size *q,* is *v. *All larger hashrates *h'
> h* will generate an average revenue per hash *v' < v*(effectively the
conclusion of my paper) due to the higher orphan risk carried from having
to mine blocks of size *q' > q*. Leading from Peter's model and my
analysis, the origin of this balance lies in the fact that larger miners
must somehow be forced to mine larger blocks which in turn carry a larger
orphan risk.
What happens if a large miner *h'* chooses not to mine his optimal block
size *q' *in favor of a seemingly "sub-optimal" block size* q*?
Since he mines a block of identical size as the smaller miner, they will
both carry identical orphan risks[2], and win identical
amounts*R+M(q)* whenever
they successfully mine a block. Since the larger miner can statistically
expect to win *h'/h* more blocks than the smaller miner, they will each
earn an identical revenue per unit of hash *R+M(q)/h*.
This however directly contradicts the assumption that an optimal hashrate
exists beyond which the revenue per unit of hash *v' < v*if *h' > h. *
*Q.E.D *
This theorem in turn implies the following corollary:
*COROLLARY: **The marginal profit curve is a monotonically increasing of
miner hashrate.*
This simple theorem, suggested implicitly by Gmaxwell disproves any and all
conclusions of my work. Most importantly, centralization pressures will
always be present.
Furthermore,
[1] https://en.wikipedia.org/wiki/Reductio_ad_absurdum
[2] Orphan risks will actually favor the larger hashrate miner leading to
greater revenues per unit of hash.
I thank the dev-list for its valuable time and exchange on the subject
matter. I stand by for any further comments and questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150830/d3a426a1/attachment.html>

2023-06-07 17:38:29

- reply

📅 Original date posted:2015-08-29
📝 Original message:I'd like to submit this paper to the dev-list which analyzes how miner
advantages scale with network and mempool properties in a scenario of
uncapped block sizes. The work proceeds, in a sense, from where Peter R's
work left off correcting a mistake and addressing the critiques made by the
community to his work.
The main result of the work is a detailed analysis of mining advantages
(defined as the added profit per unit of hash) as a function of miner
hashrate. In it, I show how large block subsidies (or better, low mempool
fees-to-subsidy ratios) incentivize the pooling of large hashrates due to
the steady increasing of marginal profits as hashrates grow.
The paper also shows that part of the large advantage the large miners have
today is due to there being a barrier to entry into a high-efficiency
mining class which has access to expected profits an order of magnitude
larger than everyone else. As block subsidies decrease, this
high-efficiency class is expected to vanish leading to a marginal profit
structure which decreases as a function of hashrate.
This work has vacuumed my entire life for the past two weeks leading me to
lag behind on a lot of work. I apologize for typos which I may not have
seen. I stand by for any comments the community may have and look forward
to reigniting consideration of a block size scaling proposal (BIP101)
which, due to the XT fork drama, I believe has been placed hastily and
undeservedly on the chopping block.
https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
Regards,
Daniele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/527d1332/attachment.html>

2023-06-07 17:38:13

- reply

📅 Original date posted:2015-08-30
📝 Original message:I think that the argument for Peter's optimal block construction algorithm
(leading to the definition of the Fee Demand Curve) is that in the limit of
a mempool with a very large number of transactions, you should be able to
assume that for any given transaction [image: i] of size [image: s_i] and
fee density [image: \phi_i], many transactions [image: j] will exist such
that [image: s_j<s_i] and [image: \phi_j=\phi_i]. This means that, in
solving the knapsack problem, one has the choice of including what
effectively amounts to fractions of transactions. This in turn results in
an unbounded knapsack problem for which Peter's greedy algorithm is an
asymptotically optimal solution.
Obviously this breaks down in small mempool scenarios where the
discreteness of transactions can not be washed away (such as the current
state of the network).
I hope this clarifies your point.
Daniele
---------- Forwarded message ----------
From: Daniele Pinna <daniele.pinna at gmail.com>
Date: Sun, Aug 30, 2015 at 1:11 PM
Subject: Another issue with the Fee Demand curve
To: Peter R <peter_r at gmx.com>
This was pointed out to me by Tom Harding.
Choosing what the optimal way of choosing transactions to be included in a
block is a knapsack problem (an NP-complete problem!):
https://en.wikipedia.org/wiki/Knapsack_problem
For which your suggested solution, which is by no means exact, is known as
the "Greedy Approximation Algorithm". This algorithm in turn works best
only when a very large quantity of high density transactions is available
in the mempool.
This wouldn't invalidate your proof but it may significantly alter the
optimal block size value.
Just thought I would throw this your way.
Daniele
---------- Forwarded message ----------
From: Tom Harding <tomh at thinlink.com>
Date: Sat, Aug 29, 2015 at 10:21 PM
Subject: Re: [bitcoin-dev] Unlimited Max Blocksize (reprise)
To: Daniele Pinna <daniele.pinna at gmail.com>
Daniele --
Thanks! I printed it and read the whole thing. It's really a great step
forward building on the Peter R paper. The conclusions are enticing. I'm
looking forward to understanding it in more detail and participating in the
discussion.
I find your work to be rational and scholarly without being obscure,
pedantic, or getting caught up in unimportant details. It has a long-term
focus.
"The optimal strategy, ﬁrst analyzed in [3]" I don't recall whether Peter
R considered constrained block space or not, but if it is considered,
simple fee-density prioritization is not necessarily optimal (it is a
knapsack problem).
On 8/29/2015 10:16 AM, Daniele Pinna wrote:
Here you go Tom!
https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
Daniele Pinna, Ph.D
On Thu, Aug 27, 2015 at 12:59 AM, Tom Harding <tomh at thinlink.com> wrote:
>
> Thanks for posting this. I'm very interested to read your paper when it
> is available.
>
>
>
> On 8/26/2015 3:22 PM, Daniele Pinna via bitcoin-dev wrote:
>
> I don't get how it's very risky to have the Mike and Gavin redirect the
> course of the bitcoin protocol but it's totally fine to consider complex
> miner voting protocols as a hard fork option.
>
> I believe that this community has not given due weight to the analysis
> proposed by Peter__R on the existence of fee markets with uncapped max
> blocksizes. The critiques made toward his work were in no way definitive
> and discussion just stopped. Is it the math that bothers people?
>
> If his work stands the test of scrutiny, then a controlled raising of the
> max blocksize in the interim to ease into the fee market dynamic described
> is the best option. Possibly a stepwise BIP101 where the community
> hardforks every two years until we all trust the fee market dynamics.
>
> The main critique to uncapped max blocksizes which I've heard stems from
> our incapacity to quantify the advantages that large miners have over
> smaller ones. As I will show in an upcoming paper, these advantages do not
> stem from the act of propagating large blocks but rather from the block
> subsidies which allow miners to mine unnecessary large blocks irregardless
> of the fees contained therein. One typical example is Peter Todd's
> suggested attack whereby a miner creates a massive block filled with spam
> transactions that pay himself solely to slow down the rest of the network
> and gain an advantage. Putting aside the increased orphan risk arising from
> the propagation of such a large block, this attack would never be viable if
> it weren't for the existence of current block subsidies.
>
> As such, exponential increases to the max blocksize make perfect sense
> since the block reward decreases exponentially also. All arguments invoking
> rates of technological advances (see Gavin's original posts) don't mean
> anything. Rational miners will NOT be incentivized to mine gargantuan spam
> filled blocks in the presence of a vanishing block reward.
>
> I truly hope this matter gets the consideration it deserves. Particularly
> with the upcoming scaling workshops.
>
> Dpinna
> On Aug 21, 2015 11:35 PM, "Daniele Pinna" <daniele.pinna at gmail.com> wrote:
>
> "I ran some simulations, and if blocks take 20 seconds to propagate, a
> network with a miner that has 30% of the hashing power will get 30.3% of
> the blocks."
>
> Peter_R's analysis of fee markets in the absence of blocksize limits [1]
> shows that the hashrate advantage of a large miner is a side-effect of
> coinbase subsidization. As the block rewards get smaller, so will large
> miner advantages. An easy way to think about this is as follows:
>
> Currently, the main critique of larger blocksizes is that we'll connected
> miners can cut out smaller miners by gratuitously filling up blocks with
> self-paying transactions. This only works because block subsidies exist.
> The moment block rewards become comparable to block TX fees, this exploit
> ceases to be functional.
>
> Basically, large miners will still be forced to move full blocks, but it
> will go against their interest to fill them with spam since their main
> source of income is the fees themselves. As a result, large miners (unlike
> smaller ones) will lose the incentive to mine an un full block this evening
> the playing field.
>
> In this context, large blocksizes as proposed by BIP100-101 hope to
> stimulate the increase of TX fees by augmenting the network's capacity. The
> sooner block rewards become comparable to block fees, the sooner we will
> get rid of mine centralization.
>
> Dpinna
>
> [1]
> http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150830/cb456797/attachment-0001.html>

2023-06-07 17:38:12

- reply

📅 Original date posted:2015-08-26
📝 Original message:I don't get how it's very risky to have the Mike and Gavin redirect the
course of the bitcoin protocol but it's totally fine to consider complex
miner voting protocols as a hard fork option.
I believe that this community has not given due weight to the analysis
proposed by Peter__R on the existence of fee markets with uncapped max
blocksizes. The critiques made toward his work were in no way definitive
and discussion just stopped. Is it the math that bothers people?
If his work stands the test of scrutiny, then a controlled raising of the
max blocksize in the interim to ease into the fee market dynamic described
is the best option. Possibly a stepwise BIP101 where the community
hardforks every two years until we all trust the fee market dynamics.
The main critique to uncapped max blocksizes which I've heard stems from
our incapacity to quantify the advantages that large miners have over
smaller ones. As I will show in an upcoming paper, these advantages do not
stem from the act of propagating large blocks but rather from the block
subsidies which allow miners to mine unnecessary large blocks irregardless
of the fees contained therein. One typical example is Peter Todd's
suggested attack whereby a miner creates a massive block filled with spam
transactions that pay himself solely to slow down the rest of the network
and gain an advantage. Putting aside the increased orphan risk arising from
the propagation of such a large block, this attack would never be viable if
it weren't for the existence of current block subsidies.
As such, exponential increases to the max blocksize make perfect sense
since the block reward decreases exponentially also. All arguments invoking
rates of technological advances (see Gavin's original posts) don't mean
anything. Rational miners will NOT be incentivized to mine gargantuan spam
filled blocks in the presence of a vanishing block reward.
I truly hope this matter gets the consideration it deserves. Particularly
with the upcoming scaling workshops.
Dpinna
On Aug 21, 2015 11:35 PM, "Daniele Pinna" <daniele.pinna at gmail.com> wrote:
"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3% of
the blocks."
Peter_R's analysis of fee markets in the absence of blocksize limits [1]
shows that the hashrate advantage of a large miner is a side-effect of
coinbase subsidization. As the block rewards get smaller, so will large
miner advantages. An easy way to think about this is as follows:
Currently, the main critique of larger blocksizes is that we'll connected
miners can cut out smaller miners by gratuitously filling up blocks with
self-paying transactions. This only works because block subsidies exist.
The moment block rewards become comparable to block TX fees, this exploit
ceases to be functional.
Basically, large miners will still be forced to move full blocks, but it
will go against their interest to fill them with spam since their main
source of income is the fees themselves. As a result, large miners (unlike
smaller ones) will lose the incentive to mine an un full block this evening
the playing field.
In this context, large blocksizes as proposed by BIP100-101 hope to
stimulate the increase of TX fees by augmenting the network's capacity. The
sooner block rewards become comparable to block fees, the sooner we will
get rid of mine centralization.
Dpinna
[1]
http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/21a71634/attachment.html>

2023-06-07 17:37:48

- reply

📅 Original date posted:2015-08-21
📝 Original message:"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3% of
the blocks."
Peter_R's analysis of fee markets in the absence of blocksize limits [1]
shows that the hashrate advantage of a large miner is a side-effect of
coinbase subsidization. As the block rewards get smaller, so will large
miner advantages. An easy way to think about this is as follows:
Currently, the main critique of larger blocksizes is that we'll connected
miners can cut out smaller miners by gratuitously filling up blocks with
self-paying transactions. This only works because block subsidies exist.
The moment block rewards become comparable to block TX fees, this exploit
ceases to be functional.
Basically, large miners will still be forced to move full blocks, but it
will go against their interest to fill them with spam since their main
source of income is the fees themselves. As a result, large miners (unlike
smaller ones) will lose the incentive to mine an un full block this evening
the playing field.
In this context, large blocksizes as proposed by BIP100-101 hope to
stimulate the increase of TX fees by augmenting the network's capacity. The
sooner block rewards become comparable to block fees, the sooner we will
get rid of mine centralization.
Dpinna
[1]
http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/46bb14ef/attachment.html>

2023-06-07 17:32:54

- reply

📅 Original date posted:2015-08-30
📝 Original message:"However, that is outside the scope of the result that an individual
miner's profit per block is always maximized at a finite block size Q* if
Shannon Entropy about each transaction is communicated during the block
solution announcement. This result is important because it explains how a
minimum fee density exists and it shows how miners cannot create enormous
spam blocks for "no cost," for example. "
Dear Peter,
This might very well not be the case. Since the expected revenue *<V>* in
our formulas is but a lower bound to the true expected revenue, and the fee
supply curve [image: M_s(Q)\propto 1/\langle V\rangle], if the true
expected revenue doesn't decay faster than the mempool's average
transaction fee (or, more simply, if it doesn't decay to zero) then the
maximum miner surplus will be unbounded and unhealthy fee markets will
emerge.
Best,
Daniele
Daniele Pinna, Ph.D
On Sun, Aug 30, 2015 at 10:08 PM, Peter R <peter_r at gmx.com> wrote:
> Hi Daniele,
>
> I don't think there is any contention over the idea that miners that
> control a larger percentage of the hash rate, *h */ *H*, have a
> profitability advantage if you hold all the other variables of the miner's
> profit equation constant. I think this is important: it is a centralizing
> factor similar to other economies of scale.
>
> However, that is outside the scope of the result that an individual
> miner's profit per block is always maximized at a finite block size Q* if
> Shannon Entropy about each transaction is communicated during the block
> solution announcement. This result is important because it explains how a
> minimum fee density exists and it shows how miners cannot create enormous
> spam blocks for "no cost," for example.
>
> Best regards,
> Peter
>
>
> 2) Whether it's truly possible for a miner's marginal profit per unit of
> hash to decrease with increasing hashrate in some parametric regime.This
> however directly contradicts the assumption that an optimal hashrate exists
> beyond which the revenue per unit of hash *v' < v *if *h' > h. *
> *Q.E.D *
>
> This theorem in turn implies the following corollary:
>
> *COROLLARY: **The marginal profit curve is a monotonically increasing of
> miner hashrate.*
>
> This simple theorem, suggested implicitly by Gmaxwell disproves any and
> all conclusions of my work. Most importantly, centralization pressures will
> always be present.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150830/a637ef09/attachment-0001.html>

2023-06-07 15:49:13

- reply

2023-06-07 15:45:08

- reply