📅 Original date posted:2015-12-08
📝 Original message:On Dec 9, 2015, at 7:48 AM, Luke Dashjr <luke at dashjr.org> wrote:
> How about we pursue the SegWit softfork, and at the same time* work on a
> hardfork which will simplify the proofs and reduce the kludgeyness of merge-
> mining in general? Then, if the hardfork is ready before the softfork, they
> can both go together, but if not, we aren't stuck delaying the improvements of
> SegWit until the hardfork is completed.
So that all our code that parses the blockchain needs to be able to find the sigwit data in both places? That doesn't really sound like an improvement to me. Why not just do it as a hard fork? They're really not that hard to do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/96a8d6a7/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/96a8d6a7/attachment.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 19:45:39
in reply to nevent1q…juat
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 19:45:39Event JSON
{
"id": "9b4d62810e5ad106b647df60ee92fe80c6ed5b9d519163e736a707c557a61ea8",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686159939,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"4d2ca85d95e0935516061cedc09b2339b8a18569f5702e9db5f602069265c4ca",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:On Dec 9, 2015, at 7:48 AM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e How about we pursue the SegWit softfork, and at the same time* work on a\n\u003e hardfork which will simplify the proofs and reduce the kludgeyness of merge-\n\u003e mining in general? Then, if the hardfork is ready before the softfork, they\n\u003e can both go together, but if not, we aren't stuck delaying the improvements of\n\u003e SegWit until the hardfork is completed.\n\nSo that all our code that parses the blockchain needs to be able to find the sigwit data in both places? That doesn't really sound like an improvement to me. Why not just do it as a hard fork? They're really not that hard to do.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/96a8d6a7/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/96a8d6a7/attachment.sig\u003e",
"sig": "f7c2a555056f0bfc9edc90f8783739732656e04759837353350a323ae1ecaf95d09ea28faa29096fa5011a0518d00e88a37d0c302027c0b7918ee6f5129a8bf4"
}