Ryan J Martin [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-01-10 to 2018-02-19
💬 Posted a total of 6 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 18:10:56

- reply

📅 Original date posted:2018-02-19
📝 Original message:To be frank, this kind of thing would be better off attempted as a fork to a new coin. Changing the max number of coins, the block reward, the difficulty algo, mining policy and protocol is going to be a non-starter. Also, what are the proposed quantifiavle benefits from removing timestamps? How would this be done at the protocol level? Are these other changes related to removing timestamps/rationale for other supply changes?
Regards,
Ryan J. Martin
On Feb 18, 2018 10:01 PM, Tao Effect via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
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<mailto: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/99c850da/attachment.html>

2023-06-07 18:08:04

- reply

📅 Original date posted:2017-12-01
📝 Original message:Interesting thoughts William, however much of what you describe already exists:
"I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block."
This happens with users deciding to pay (essentially) a fee smaller or larger than the 1999th tx in the mempool. If user is willing to pay more than the 1999th highest fee tx in mempool (or whatever tx byte 1,000,000 in a mempool ranked by tx fee) then they will get to be on the next block. This is a simplification but you get the idea.
Further, Greg Maxwell's one reply covers alot of the biggest pitfalls well. Especially that much of this already happens and that behavior in response to such a change could be hairy to predict. So I'm not sure that---what is basically--- a multi-unit Vickrey auction is the best way to go... but it is an interesting idea worth further examination.
Second, minimizing invididual user tx fees and maximizing total tx fees are essentially incompatible within the current development structure. Even if the block limit is increased to 3mb the same problem will eventually occur. While I agree it would be ideal to maximize social benefit (i.e. maximize both consumer and producer surplus) through more simple protocol changes---at least in the medium term, that isn't on the table so it is better to move on.
This is not an easy optimization problem to solve though. The difficulty is trying to model a market like bitcoin; the only thing that comes close is electricity markets. With 2,000 tx in the pool, users aren't willing to pay shit to send a tx; there is always a miner to process it. So at 2,000tx per 10 min (3.333 txps, 1mb/10min,etc) and below users price elasticity is flat. Once the pool has >2,000 tx in it, especially for any extended amount of time, users price elasticity is about as elastic as a brick and goes near vertical. This creates a situation where miners are always better off when there is a significant backlog (this can be seen in miners revenue from tx fees anytime there is an ongoing backlog).
Simply put, it would take some very large blocks to have total fees/block exceed total fees/block for constrained size blocks given the near vertical price elasticity users face when there is a backlog.
So I suspect that the multi-unit Vickrey would potentially do some to help this, but likely not much:
Users willingness to pay is what they pay---no surplus. Miner elasticity is more or less flat but we can call their willingness to accept whatever the lowest fee tx is in a block. Say it is 180 sat/b (NL), and the highest tx fee in a block (NH)is 320 sat/b. If you subtract each tx in the block (N) greater than NL
and sum the result you get surplus to miners: Σ(N1,2...- NL)
So, yes, the multi-unit Vickrey simply shifts the surplus to users. However, a case could be made that since---as mentioned in an earlier reply, the optimal strategy for miners is to accept zero fees (given their flat elasticity), and therefore all fees are surplus benefit to miners---shifting this surplus over to consumers could create some good effects. Primarily pushing users' price elasticity away from near vertical inelasticity as it would take some of the upward pressure off rapidly increasing fees in a backlog scenario.
It would be interesting to see a simulation of how this would play out, but without that this is too risky to implement.
Regards,
Ryan J. Martin (tunafizz / ohituna)
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org [bitcoin-dev-bounces at lists.linuxfoundation.org] on behalf of William Morriss via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org]
Sent: Wednesday, November 29, 2017 7:47 PM
To: bitcoin-dev at lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP Idea: Marginal Pricing
Comrades,
Long term, tx fees must support hash power by themselves. The following is an economic approach to maximize total fee collection, and therefore hashpower.
Goals
Maximize total transaction fees
Reduce pending transaction time
Reduce individual transaction fees
Challenges
Validators must agree on the maximum block size, else miners can cheat and include extra transactions.
Allowing too many transactions per block will increase the cost of the mining without collecting much income for the network.
Problem
In the transaction market, users are the demand curve, because they will transact less when fees are higher, and prefer altcoins. The block size is the supply curve, because it represents miners' willingness to accept transactions.
Currently, the supply curve is inelastic:
[cid:ii_jalpxsnl1_1600a3d9def1eaff]
Increasing the block size will not affect the inelasticity for any fixed block size. The downsides of a fixed block size limit are well-known:
- Unpredictable transaction settlement time
- Variable transaction fees depending on network congestion
- Frequent overpay
Proposal
1. Miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees are refunded to the inputs.
2. Remove the block size limit, which is no longer necessary.
Benefits
- Dynamic block size limit regulated by profit motive
- Transaction fees maximized for every block
- No overpay; all fees are fair
[cid:ii_jalqir4g2_1600a4c89811347a]
Miners individually will make decisions to maximize their block-reward profit.
Miners are incentivized to ignore low-fee transactions because they would shave the profits of their other transactions and increase their hash time.
Users and services are free to bid higher transaction fees in order to reach the next block, since their excess bid will be refunded.
The block size limit was added as a spam-prevention measure, but in order for an attacker to spam the network with low-fee transactions, they would have to offset the marginal cost of reducing the price with their own transaction fees. Anti-spam is thus built into the marginal system without the need for an explicit limit.
Rarely, sections of the backlog would become large enough to be profitable. This means every so many blocks, lower-fee transactions would be included en masse after having been ignored long enough. Low-fee transactions thus gain a liveness property not previously enjoyed: low-fee transactions will eventually confirm. Miners targeting these transactions would be at a noteworthy disadvantage because they would be hashing a larger block. I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block.
Examples
Scenario 1
Sat/byte Bytes Reward
400 500000 200000000
300 700000 210000000
200 1000000 200000000
100 1500000 150000000
50 5000000 250000000
20 10000000 200000000
A miner would create a 5MB block and receive 0.25 BTC
Scenario 2
Sat/byte Bytes Reward
400 600000 240000000
300 700000 210000000
200 1000000 200000000
100 1800000 180000000
50 4000000 200000000
20 10000000 200000000
A miner would create a 600KB block and receive 0.24 BTC
Thanks,
William Morriss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: fixedblocksize.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: fixedblocksize.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marginal.png
Type: image/png
Size: 21403 bytes
Desc: marginal.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0005.png>

2023-06-07 18:08:04

- reply

2023-06-07 18:03:34

- reply

📅 Original date posted:2017-06-20
📝 Original message:I concur with Mark's reply. Just to underscore this: Miners arent going to bother to signaling or changing a setting unless they have to. Anything that requires time--especially if requiring a restart/any time not mining or risks a crash---reduces income. So why would they change any settings unless they have to?
-Ryan J. Martin
On Jun 20, 2017 1:26 PM, Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
I think it is very naïve to assume that any shift would be temporary.
We have a hard enough time getting miners to proactively upgrade to
recent versions of the reference bitcoin daemon. If miners interpret
the situation as being forced to run non-reference software in order
to prevent a chain split because a lack of support from Bitcoin Core,
that could be a one-way street.
On Tue, Jun 20, 2017 at 9:49 AM, Hampus Sjöberg via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't think it's a huge deal if the miners need to run a non-Core node
> once the BIP91 deployment of Segwit2x happens. The shift will most likely be
> temporary.
>
> I agree that the "-bip148"-option should be merged, though.
>
> 2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>:
>>
>> Are we going to merge BIP91 or a -BIP148 option to core for inclusion in
>> the next release or so?
>>
>> Because a large percentage of miners are indifferent, right now miners
>> have to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>
>> Should we be forcing miners to choose to run non-core code in order to
>> activate a popular feature?
>>
>> - Erik
>>
>> _______________________________________________
>> 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/20170620/daf389f6/attachment-0001.html>

2023-06-07 17:58:15

- reply

📅 Original date posted:2017-03-30
📝 Original message:There is alot going on in this thread so I'll reply more broadly.
The original post and the assorted limit proposals---lead me to something I think is worth reiterating: assuming Bitcoin adoption continues to grow at similar or accelerating rates, then eventually the mempool is going to be filled with thousands of txs at all times whether block limits are 1MB or 16MB. This isn't to say that increasing the limit isn't a worthwhile change, but rather, that if we are going to change the block limit then it should be done with the intent to achieve a fee rate that maximize surplus (and minimize burden) to both users and miners. Even with implementation of a a payment channels system, the pool will likely be faced with having a mountain of txs. Thus the block limit should be optimized in such that social welfare is optimized.
Optimized is likely not keeping the limit at 1MB; this maximizes benefit to miners (producers) while minimizing users' surplus (consumer). 'Unlimited' blocks are purely the reverse; maximizing user surplus while minimizing miners' (with the added bonus of creating blocks that will put technical/hardware strain on the network). So perhaps pursue something in-between that actually optimizes based on a social welfare formula---not just an arbitrary auto-adjusting limit like the other proposals I've seen. Feel free to poke holes in this or e-mail me if curious.
Finally, with respect to getting node counts up, didn't luke-jr or someone come up with an idea of paying nodes a reward by scraping dust and pooling it into a fund of sorts? Was this not possible/feasible? Perhaps at least in the near and medium term something outside of protocol changes could be done to pay a reward to nodes. Even if this is done via voluntary donation system, it may be useful for the purposes of seeing how people respond to incentives and working out an elasticity measure of sorts for running a node.
Ryan J. Martin
rjmarti2 at millersville.edu
(on freenode: tunafizz )
________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org [bitcoin-dev-bounces at lists.linuxfoundation.org] on behalf of Aymeric Vitte via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org]
Sent: Wednesday, March 29, 2017 6:33 PM
To: Jared Lee Richardson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
I have heard such theory before, it's a complete mistake to think that others would run full nodes to protect their business and then yours, unless it is proven that they are decentralized and independent
Running a full node is trivial and not expensive for people who know how to do it, even with much bigger blocks, assuming that the full nodes are still decentralized and that they don't have to fight against big nodes who would attract the traffic first
I have posted many times here a small proposal, that exactly describes what is going on now, yes miners are nodes too... it's disturbing to see that despite of Tera bytes of BIPs, papers, etc the current situation is happening and that all the supposed decentralized system is biased by centralization
Do we know what majority controls the 6000 full nodes?
Le 29/03/2017 à 22:32, Jared Lee Richardson via bitcoin-dev a écrit :
> Perhaps you are fortunate to have a home computer that has more than a single 512GB SSD. Lots of consumer hardware has that little storage.
That's very poor logic, sorry. Restricted-space SSD's are not a cost-effective hardware option for running a node. Keeping blocksizes small has significant other costs for everyone. Comparing the cost of running a node under arbitrary conditons A, B, or C when there are far more efficient options than any of those is a very bad way to think about the costs of running a node. You basically have to ignore the significant consequences of keeping blocks small.
If node operational costs rose to the point where an entire wide swath of users that we do actually need for security purposes could not justify running a node, that's something important for consideration. For me, that translates to modern hardware that's relatively well aligned with the needs of running a node - perhaps budget hardware, but still modern - and above-average bandwidth caps.
You're free to disagree, but your example only makes sense to me if blocksize caps didn't have serious consequences. Even if those consequences are just the threat of a contentious fork by people who are mislead about the real consequences, that threat is still a consequence itself.
On Wed, Mar 29, 2017 at 9:18 AM, David Vorick via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
Perhaps you are fortunate to have a home computer that has more than a single 512GB SSD. Lots of consumer hardware has that little storage. Throw on top of it standard consumer usage, and you're often left with less than 200 GB of free space. Bitcoin consumes more than half of that, which feels very expensive, especially if it motivates you to buy another drive.
I have talked to several people who cite this as the primary reason that they are reluctant to join the full node club.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/8499f263/attachment-0001.html>

2023-06-07 17:56:09

- reply

📅 Original date posted:2017-02-10
📝 Original message:"10% say literally never. That seems like a significant disenfranchisement
and lack of consensus."
Certainly the poll results should be taken with a grain of salt and not a definitive answer or measure .
However if we agree the poll has some worth (or even if not, then lets use it as hyptothetical): If we split it into two groups: those okay with a hardfork at some point > now, and those never okay with hardfork, that means there is 90% that agree a hardfork is acceptable in the future. That said, what threshold defines consensus then? 98%? 100%?
Personally I think pursuing paths that maximize net social benefit in terms of cost surplus/burden is the best way to go since consensus is such an impossible to define, variable, case-by-case thing that doesn't always lead to the best choice.
-Ryan J. MArtin
________________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org [bitcoin-dev-bounces at lists.linuxfoundation.org] on behalf of bitcoin-dev-request at lists.linuxfoundation.org [bitcoin-dev-request at lists.linuxfoundation.org]
Sent: Thursday, February 09, 2017 7:00 AM
To: bitcoin-dev at lists.linuxfoundation.org
Subject: bitcoin-dev Digest, Vol 21, Issue 10
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. Re: A Modified Version of Luke-jr's Block Size BIP (alp alp)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Feb 2017 08:44:52 -0600
From: alp alp <alp.bitcoin at gmail.com>
To: "t. khan" <teekhan42 at gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev at lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size
BIP
Message-ID:
<CAMBsKS9OS2tA4bG-JG96XNZTiPyuq322Qu=fyJcZ1BtVj3TtxQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
10% say literally never. That seems like a significant disenfranchisement
and lack of consensus.
On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Monday, February 06, 2017 6:19:43 PM you wrote:
>> > >My BIP draft didn't make progress because the community opposes any
>> block
>> > >size increase hardfork ever.
>> >
>> > Luke, how do you know the community opposes that? Specifically, how did
>> you
>> > come to this conclusion?
>>
>> http://www.strawpoll.me/12228388/r
>
>
> That poll shows 63% of votes want a larger than 1 MB block by this summer.
> How do you go from that to "the community opposes any block increase ever"?
> It shows the exact opposite of that.
>
>
>> > >Your version doesn't address the current block size
>> > >issues (ie, the blocks being too large).
>> >
>> > Why do you think blocks are "too large"? Please cite some evidence. I've
>> > asked this before and you ignored it, but an answer would be helpful to
>> the
>> > discussion.
>>
>> Full node count is far below the safe minimum of 85% of economic activity.
>>
>
> Is this causing a problem now? If so, what?
>
>
>> Typically reasons given for people not using full nodes themselves come
>> down
>> to the high resource requirements caused by the block size.
>
>
> The reason people stop running nodes is because there's no incentive to
> counteract the resource costs. Attempting to solve this by making blocks
> *smaller* is like curing a disease by killing the patient. (Incentivizing
> full node operation would fix that problem.)
>
> - t.k.
>
>
> _______________________________________________
> 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/20170208/18d9cda5/attachment-0001.html>
------------------------------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
End of bitcoin-dev Digest, Vol 21, Issue 10
*******************************************

2023-06-07 17:55:29

- reply

📅 Original date posted:2017-01-10
📝 Original message:The adaptive/automatic block size notion has been around for a while--- others would be better able to speak to why it hasn't gotten traction. However my concern with something like that is that it doesn't regard the optimal economic equilibrium for tx fees/size---not that the current limit does either but the concern with an auto-adjusting size limit that ignores this would be the potential to create unforeseen externalities for miners/users. Miners may decide it is more profitable to mine very small blocks to constrict supply and increase marginal fees and with how centralized mining is, where a dozen pools have 85% hashrate, a couple of pools could do this. Then on the other side, maybe the prisoner's dilemma would hold and all miners would have minrelaytxfee set at zero and users would push the blocks to larger and larger sizes causing higher and higher latency and network issues.
Perhaps something like this could work (I can only speak to the economic side anyway) but it would have to have some solid code that has a social benefit model built in to adjust to an equilibrium that is able to optimize---as in maximizes benefit/minimize cost for both sides via a Marshallian surplus model--- for each size point.
To be clear, I'm not saying an auto-adjusting limit is unworkable (again only from an economic standpoint), just that it would need to have these considerations built in.
-Ryan J. Martin
________________________________________
------------------------------
Message: 2
Date: Mon, 9 Jan 2017 14:52:31 -0500
From: "t. khan" <teekhan42 at gmail.com>
To: Bitcoin Protocol Discussion
<bitcoin-dev at lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP - Block75 - Historical and future
projections
Message-ID:
<CAGCNRJpSV9zKxhVvqpMVPyFyXco_ABB9a7_ihaDKEKFPQ9v3sw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Using daily average block size over the past year (source:
https://blockchain.info/charts/avg-block-size?daysAverageString=14&timespan=1year
), here's how Block75 would have altered max block sizes:
[image: Inline image 1]
As of today, the max block size would be 1,135KB.
Looking forward and using the last year's growth rate as a model:
[image: Inline image 2]
This shows the max block size one year from now would be 2,064KB, if
Block75 activated today.
Of course, this is just an estimate, but even accounting for a substantial
increase in transactions in the last quarter of 2017 and changes brought
about by SegWit (hopefully) activating, Block75 alters the max size in such
a way that allows for growth, keeps blocks as small as possible, *and*
maintains transaction fees at a level similar to May/June 2016.
If anyone has an alternate way to model future behavior, please run it
through the Block75 algorithm.
Every 2016 blocks, do this:
new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))
TARGET_CAPACITY = 0.75 //Block75's target of keeping blocks 75% full
AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a
decimal
x = current max block size
Thanks,
- t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Block75 2016.png
Type: image/png
Size: 32088 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Block75 2017.png
Type: image/png
Size: 33176 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170109/b0e0b713/attachment-0001.png>
------------------------------
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
End of bitcoin-dev Digest, Vol 20, Issue 21
*******************************************