Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-24 🗒️ Summary of this message: A proposal to ...
📅 Original date posted:2011-08-24
🗒️ Summary of this message: A proposal to replace hard limits with dynamically adapting limits and adjust difficulty every block without limits was deemed too early. Increasing precision was agreed upon, but infinite numerator + denominator was considered insane. Removing the 100 confirmation requirement for spending generated coins was not recommended.
📝 Original message:On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <luke at dashjr.org> wrote:
> - Replace hard limits (like 1 MB maximum block size) with something that can
> dynamically adapt with the times. Maybe based on difficulty so it can't be
> gamed?
Too early for that.
> - Adjust difficulty every block, without limits, based on a N-block sliding
> window. I think this would solve the issue when the hashrate drops
> overnight, but maybe also add a block time limit, or perhaps include the
> "current block" in the difficulty calculation?
The quantized scheme limits the amount of difficulty skew miners can
create by lying about timestamps to about a half a percent. A rolling
window with the same time constant would allow much more skew.
> Replacing the "Satoshi" 64-bit integers with
> "Satoshi" variable-size fractions (ie, infinite numerator + denominator)
Increasing precision I would agree with but, sadly, causing people to
need more than 64 bit would create a lot of bugs.
infinite numerator + denominator is absolutely completely and totally
batshit insane. For one, it has weird consequences that the same value
can have redundant encodings.
Most importantly, it suffers factor inflation: If you spend inputs
1/977 1/983 1/991 1/997 the smallest denominator you can use for the
output 948892238557.
Not to mention that the idiots writing financial software can only
barely manage to not use radix-2 floating point on everything. Asking
them to use arbitrary rational numbers with mixed radix will never
fly.
> - Remove the 100 confirmation requirement for spending generated coins. If
> they are respent before 100 confirmations, clients can/should flag the new
> outputs as also "generated" or "recently generated" so recipients are aware
> of the risk.
Please lets not make bitcoin _less_ trustworthy.
The 100 block maturity on generated coins is good. The generation from
an orphaning is lost forever like the losing side of a double spend,
but far far worse... because orphaning happens all the time on its own
without any malice.
I agree it's obnoxious that you can't pad your generation payouts
without creating more transactions, but I don't see a solution for
that. Repeat the addresses... make up for it by increasing your payout
threshold.
Published at
2023-06-07 02:17:57Event JSON
{
"id": "562cd7ef01bc18c7239e54f1d92879cc938f2b3e0c7f244085ed9eee1b5d3acf",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686104277,
"kind": 1,
"tags": [
[
"e",
"391ebcb8eb3f9b5884cfbf66f4a99b12c015cc93baa9452c114d68f52d1168ec",
"",
"root"
],
[
"e",
"6a25134a7ba8620fba4cf562d360355b28bf914278d47e6ed13a0a1b1d869ef7",
"",
"reply"
],
[
"p",
"6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1"
]
],
"content": "📅 Original date posted:2011-08-24\n🗒️ Summary of this message: A proposal to replace hard limits with dynamically adapting limits and adjust difficulty every block without limits was deemed too early. Increasing precision was agreed upon, but infinite numerator + denominator was considered insane. Removing the 100 confirmation requirement for spending generated coins was not recommended.\n📝 Original message:On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e - Replace hard limits (like 1 MB maximum block size) with something that can\n\u003e dynamically adapt with the times. Maybe based on difficulty so it can't be\n\u003e gamed?\n\nToo early for that.\n\n\u003e - Adjust difficulty every block, without limits, based on a N-block sliding\n\u003e window. I think this would solve the issue when the hashrate drops\n\u003e overnight, but maybe also add a block time limit, or perhaps include the\n\u003e \"current block\" in the difficulty calculation?\n\nThe quantized scheme limits the amount of difficulty skew miners can\ncreate by lying about timestamps to about a half a percent. A rolling\nwindow with the same time constant would allow much more skew.\n\n\u003e Replacing the \"Satoshi\" 64-bit integers with\n\u003e \"Satoshi\" variable-size fractions (ie, infinite numerator + denominator)\n\nIncreasing precision I would agree with but, sadly, causing people to\nneed more than 64 bit would create a lot of bugs.\n\ninfinite numerator + denominator is absolutely completely and totally\nbatshit insane. For one, it has weird consequences that the same value\ncan have redundant encodings.\n\nMost importantly, it suffers factor inflation: If you spend inputs\n1/977 1/983 1/991 1/997 the smallest denominator you can use for the\noutput 948892238557.\n\nNot to mention that the idiots writing financial software can only\nbarely manage to not use radix-2 floating point on everything. Asking\nthem to use arbitrary rational numbers with mixed radix will never\nfly.\n\n\u003e - Remove the 100 confirmation requirement for spending generated coins. If\n\u003e they are respent before 100 confirmations, clients can/should flag the new\n\u003e outputs as also \"generated\" or \"recently generated\" so recipients are aware\n\u003e of the risk.\n\nPlease lets not make bitcoin _less_ trustworthy.\n\nThe 100 block maturity on generated coins is good. The generation from\nan orphaning is lost forever like the losing side of a double spend,\nbut far far worse... because orphaning happens all the time on its own\nwithout any malice.\n\nI agree it's obnoxious that you can't pad your generation payouts\nwithout creating more transactions, but I don't see a solution for\nthat. Repeat the addresses... make up for it by increasing your payout\nthreshold.",
"sig": "4eacf915248af6eeb7c6098733481c3301a6bbf222c84aba1a9182f797fe8177c195b27e133b06444bcc00224182c84db45fe6e9db19c5f4b84e2a3d5555f9fc"
}