<unnamed>

Public Key

npub16z2msvydkmd6xsjyrggnavcwrlpevfwq74x5avxrkg2dpq7cg6js5jg59c

Profile Code

nprofile1qqsdp9dcxzxmdkargfzp5yf7kv8plsukyhq02n2wkrpmy9xss0vydfgprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv97s624

Publishing to

relay.snort.social

Last Notes

2023-06-07 18:06:37 UTC

- 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 UTC

- 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 17:58:18 UTC

- 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:54:53 UTC

- 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:38:13 UTC

- 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 UTC

- 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>