<unnamed>

Public Key

npub1ljzgtn8d26racfzv8gv2srj7063hqe97jms6klzgvttc9w8mex4qr8knn6

Profile Code

nprofile1qqs0epy9enk4dp7uy3xr5x9gpe08agmsvjlfdcdt03yx94uzhraun2sprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqz0f7mm

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:58:15 CEST

- 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 19:55:29 CEST

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