<unnamed>

Public Key

npub1fvd9jpjgn33ry4tt663e3fpsw5zysxzuacumergtweqhsa6ac9gqred8pr

Profile Code

nprofile1qqsykxjeqeyfcc3j244adguc5sc82pzgrpwwuwdu359hvstcwawuz5qpzpmhxue69uhkummnw3ezuamfdejsmkwktz

Publishing to

nostr.wine

Last Notes

2023-06-07 19:48:04 CEST

- reply

📅 Original date posted:2016-01-23
📝 Original message:> On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I would extend this to say that the technical explanation also should
> contribute uniquely to the conversation; a +1 with an explanation
> the last +1 gave isn't useful.
Yes, comments should contribute to the discussion, with either technical discussion or additional relevant data. I think a +1 like the following should be encouraged:
"+1: we had eleven customer support tickets in just the last week that would have been prevented if XYZ.
Jane Doe, CTO CoinBitChainBasely.com"

2023-06-07 19:37:51 CEST

- reply

📅 Original date posted:2015-08-28
📝 Original message:With this proposal, how much would it cost a miner to include an 'extra' 500-byte transaction if the average block size is 900K and it costs the miner 20BTC in electricity/capital/etc to mine a block?
If my understanding of the proposal is correct, it is:
500/900000 * 20 = 0.11111 BTC
... Or $2.50 at today's exchange rate.
That seems excessive.
--
Gavin Andresen
> On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> This is the best proposal I've seen yet. Allow me to summarize:
>
> • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their block-size votes.
> • It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to predict future market needs versus future technological capacities.
> • It avoids a large step discontinuity in the block-size limit by starting with a 1-MB limit.
> • It throttles changes to ±10% every 2016 blocks.
> • It imposes a tangible cost (higher difficulty) on miners who vote to raise the block-size limit.
> • It avoids incentivizing miners to vote to lower the block-size limit.
>
> However, this proposal currently fails to answer a very important question:
>
> • What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
>
>
> https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>
>
>> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
>> Pull request: https://github.com/bitcoin/bips/pull/187
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:49:15 CEST

- reply

2023-06-07 17:43:47 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:> On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
>
> and a number of the people most intimately familiar with the inner workings of the system (some of whom are in this thread) think that given what we now today about the Bitcoin network, increasing block size externalizes costs in dangerous ways. Remember that total cost includes not just equipment costs but also things like block propagation latency and specifically identified security risks. Some of these security risks were only appreciated relatively recently and were completely unknown in 2009.
I would like (and have been asking) those people to take the time to quantify those costs and write up those risks in a careful way.
I believe the costs and risks of 8MB blocks are minimal, and that the benefits of supporting more transaction FAR outweigh those costs and risks, but it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.

2023-06-07 17:08:08 CEST

- reply

📅 Original date posted:2013-10-25
📝 Original message:On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
> Would it make sense to use either fixed length strings or maybe even enums?
No. Enums or fixed length strings just make it harder to extend, for no benefit (bandwidth of 'reject' messages doesn't matter, they will be rare and are not relayed).