<unnamed>

Public Key

npub1j7cm657crpk3y4jkvm7hk0le3c8c4x8yuqflk5dvzuyxn8k845lsfvmlg6

Profile Code

nprofile1qqsf0vda20vpsmgj2etxdltm8lucuru2nrjwqylm2xkpwzrfnmr660cpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg49hj9s

Publishing to

relay.primal.net

Last Notes

2023-06-07 17:49:29 UTC

- reply

📅 Original date posted:2016-03-02
📝 Original message:> BtcDrak tells me he has well-tested code for this in his altcoin
Could you be more explicit, which altcoin is that?
> I am unaware of any reason this would be controversial
Probably not until you get to the details of any proposal. What is
your exact proposal here? Algorithm? Parameters?
As you likely know a too short time window would be dangerous for
other reasons. Getting to an agreement as to what is reasonable or not
is not necessarily trivial.
Jeremie
2016-03-02 16:14 GMT+01:00 Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org>:
> On Wednesday, March 02, 2016 3:05:08 PM Pavel Janík wrote:
>> > the network. This would result in a significantly longer block interval,
>> > which also means a higher per-block transaction volume, which could
>> > cause the block size limit to legitimately be hit much sooner than
>> > expected.
>>
>> If this happens at all (the exchange rate of the coin can accomodate such
>> expectation),
>
> The exchange rate is not significantly influenced by these things.
> Historically, it seems fairly obvious that the difficulty has followed value,
> not value following difficulty.
>
>> the local fee market will develop, fees will raise and complement mined
>> coins, thus bringing more miners back to the game (together with expected
>> higher exchange rate).
>
> Depends on the hashrate drop, and tolerance for higher fees, both of which are
> largely unknown at this time. At least having code prepared for the negative
> scenarios in case of an emergency seems reasonable, even if we don't end up
> needing to deploy it.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:33:14 UTC

- reply

📅 Original date posted:2015-05-07
📝 Original message:> I have written up an explanation of what I think will happen if we run out
> of capacity:
>
> https://medium.com/@octskyward/crash-landing-f5cc19908e32
Looks like a solid description of what would happen.
I fail to see how this description wouldn't be applicable also to a
20MB-network in some time in the future, say ~3 years from now, if
Bitcoin keeps taking off.
If you agree that it will be harder in the future to change the block
limit again, and we switch to hardcoded 20MB, then aren't we just
going from an immediate relief to a future larger blockage?
>
> Now I'm going to go eat some dinner :)
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:33:13 UTC

- reply

📅 Original date posted:2015-05-07
📝 Original message:Any proposal to switch to a new hardcorded value so we have time to
*really* figure out later what's next and all implications, is a road
to a gigantic issue later when we want to switch to that "next".
Sure we would have more time to think about, research all
implications, simulate, discuss, etc. But the ability then to agree
enough on a change to roll it out successfully will be much smaller,
because of the economy being built on top of Bitcoin being much larger
and the technical specifications of Bitcoin being closer to a complete
freeze.
What I'm trying to say is that we should look at long term lasting
solutions even if it takes more effort and time right now and puts the
network into some "troubles" for a while, because they're short term
"troubles". (You define "troubles", depending on which side you stand
at the moment...).
I personally believe in adaptive block size mechanisms, because:
(i) common sense tells me harcoding is never a solution for a system
whose usage is for many aspects unpredictable
(ii) we can't rely on human consensus to adapt it (seeing the mess
it is already this time).
It would have the advantage to place this block size issue entirely as
part of the algorithmic contract you agree on when you use Bitcoin,
similar to the difficulty adapation or the block reward.
Jérémie
2015-05-07 21:37 GMT+02:00 Mike Hearn <mike at plan99.net>:
>
>> These statements may even be true, but they're no logical conclusions
>> even if they seem obvious to you.
>> I don't think those claims are strictly true, specially because they
>> involve predictions about what people will do.
>> But if they're true they require some proof or at least some explanation.
>
>
> Thank you for your patience, Jorge.
>
> I have written up an explanation of what I think will happen if we run out
> of capacity:
>
> https://medium.com/@octskyward/crash-landing-f5cc19908e32
>
> Now I'm going to go eat some dinner :)
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>