Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-24 🗒️ Summary of this message: Gavin Andresen ...
📅 Original date posted:2011-08-24
🗒️ Summary of this message: Gavin Andresen suggests implementing or enabling opcodes to enable smaller bitcoin addresses and scheduling a blockchain split to fix various issues.
📝 Original message:On Wednesday, August 24, 2011 11:12:10 AM Gavin Andresen wrote:
> So, if we are going to have new releases that are incompatible with
> old clients why not do things right in the first place, implement or
> enable opcodes so the new bitcoin addresses can be small, and schedule
> a block chain split for N months from now.
If a block chain split is to occur, it makes sense to try to fix as many
problems as possible:
- 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?
- 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?
- 21 million really isn't enough if Bitcoin ever takes off, even with
100,000,000 units per BTC. Replacing the "Satoshi" 64-bit integers with
"Satoshi" variable-size fractions (ie, infinite numerator + denominator)
would create infinite possibilities of future divison, allowing people to
not only do nBTC and pBTC, but also exact 1/3 of any quantity. Transaction
size would go up based on the number of primes involved in an amount, which
would encourage discarding annoying primes in transaction fees.
- Standardize everything on network (big) endian.
I'm sure others can think of other chain-splitting fixes that wouldn't be too
much work to fix.
Published at
2023-06-07 02:17:54Event JSON
{
"id": "6a25134a7ba8620fba4cf562d360355b28bf914278d47e6ed13a0a1b1d869ef7",
"pubkey": "6ac6a519b554d8ff726a301e3daec0b489f443793778feccc6ea7a536f7354f1",
"created_at": 1686104274,
"kind": 1,
"tags": [
[
"e",
"391ebcb8eb3f9b5884cfbf66f4a99b12c015cc93baa9452c114d68f52d1168ec",
"",
"root"
],
[
"e",
"5c308d368175b625e5f77647896913b1c891013e43c8ff4f5e9d936c116cd480",
"",
"reply"
],
[
"p",
"304641dbb49ee6a600bce6ea04cb0cb25b3c969f8f11581aedb62736f2bce6b2"
]
],
"content": "📅 Original date posted:2011-08-24\n🗒️ Summary of this message: Gavin Andresen suggests implementing or enabling opcodes to enable smaller bitcoin addresses and scheduling a blockchain split to fix various issues.\n📝 Original message:On Wednesday, August 24, 2011 11:12:10 AM Gavin Andresen wrote:\n\u003e So, if we are going to have new releases that are incompatible with\n\u003e old clients why not do things right in the first place, implement or\n\u003e enable opcodes so the new bitcoin addresses can be small, and schedule\n\u003e a block chain split for N months from now.\n\nIf a block chain split is to occur, it makes sense to try to fix as many \nproblems as possible:\n- Replace hard limits (like 1 MB maximum block size) with something that can\n dynamically adapt with the times. Maybe based on difficulty so it can't be\n gamed?\n- Adjust difficulty every block, without limits, based on a N-block sliding\n window. I think this would solve the issue when the hashrate drops\n overnight, but maybe also add a block time limit, or perhaps include the\n \"current block\" in the difficulty calculation?\n- 21 million really isn't enough if Bitcoin ever takes off, even with\n 100,000,000 units per BTC. Replacing the \"Satoshi\" 64-bit integers with\n \"Satoshi\" variable-size fractions (ie, infinite numerator + denominator)\n would create infinite possibilities of future divison, allowing people to\n not only do nBTC and pBTC, but also exact 1/3 of any quantity. Transaction\n size would go up based on the number of primes involved in an amount, which \n would encourage discarding annoying primes in transaction fees.\n- Standardize everything on network (big) endian.\n\nI'm sure others can think of other chain-splitting fixes that wouldn't be too \nmuch work to fix.",
"sig": "1a0f96b7e3bee587c627caeeaf77cc48d33ff06f0fc5eb21845f90e263e6643fd2ed28cfe8fd69edf57e4636d4465efe7e1c05af406fc5bd5a4b4390d4b2b1a9"
}