Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-04 🗒️ Summary of this message: The author ...
📅 Original date posted:2011-08-04
🗒️ Summary of this message: The author discusses the possibility of implementing a new feature in the Bitcoin network and suggests splitting it into two pull requests.
📝 Original message:On Wed, Aug 3, 2011 at 2:10 AM, <bgroff at lavabit.com> wrote:
> Thank you! (I think you mean 319 here)
Correct.
> With Eligius mining !IsStandard transactions and probably other pools open
> to the idea, I am hopeful that we can quickly get 30%+ of mining power to
> upgrade, which means that we could still mine these in a reasonable time
> frame (under 1 hour).
It's not just a matter of mining power, it's also a question of
propagation. Matt and I tried to perform a non-standard transaction
weeks ago and weren't able to get in mined after many hours. (we
eventually double spent the input with a normal transaction in order
to make it go away, interestingly one point about non-propagating txn
is that they're extra vulnerable to double spending by a standard txn,
as the non-standard one won't preclude the propagation of the standard
one)
>From discussion on IRC it seemed clear enough that the current focus
on maturity/bugfixes is probably going to delay your full patch, but
the IsStandard part is uncontroversial and could go in quickly.
Based on that I think it would be very useful to split 319 into two
pull requests: one which does the IsStandard change, and one which
adds the full escrow feature set. This way when the escrow patch does
enter the mainline client it will be meet up with a network which is
happy to handle its transactions.
(and people who are eager to use escrow can use modified clients on
the main network before that point in time)
> I'm not sure I see the problem here. CScript.operator<< currently inserts
> values into scripts using the shortest possible sequence.
Ah for some reason I thought your current code did not always produce
the shortest sequence.
If so, I see no reason to block on the other pull.
Published at
2023-06-07 02:10:19Event JSON
{
"id": "fad7000c06b52eb71c640ad931c33881a981d9701bde7d59f02532cdb4733fee",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686103819,
"kind": 1,
"tags": [
[
"e",
"26d2b12d74cc7eda50d225d370e6d62d72bcd36ed8521a48c7131e351bf9a32f",
"",
"root"
],
[
"e",
"62757c35d579577e192e654886d0ad36355a65e801a0eb213f06faac522d2e1f",
"",
"reply"
],
[
"p",
"fc38630711a8b1bf175abe9b428bbb6dec25a39bf3d75a91a411f204942572a4"
]
],
"content": "📅 Original date posted:2011-08-04\n🗒️ Summary of this message: The author discusses the possibility of implementing a new feature in the Bitcoin network and suggests splitting it into two pull requests.\n📝 Original message:On Wed, Aug 3, 2011 at 2:10 AM, \u003cbgroff at lavabit.com\u003e wrote:\n\u003e Thank you! (I think you mean 319 here)\n\nCorrect.\n\n\u003e With Eligius mining !IsStandard transactions and probably other pools open\n\u003e to the idea, I am hopeful that we can quickly get 30%+ of mining power to\n\u003e upgrade, which means that we could still mine these in a reasonable time\n\u003e frame (under 1 hour).\n\nIt's not just a matter of mining power, it's also a question of\npropagation. Matt and I tried to perform a non-standard transaction\nweeks ago and weren't able to get in mined after many hours. (we\neventually double spent the input with a normal transaction in order\nto make it go away, interestingly one point about non-propagating txn\nis that they're extra vulnerable to double spending by a standard txn,\nas the non-standard one won't preclude the propagation of the standard\none)\n\n\u003eFrom discussion on IRC it seemed clear enough that the current focus\non maturity/bugfixes is probably going to delay your full patch, but\nthe IsStandard part is uncontroversial and could go in quickly.\n\nBased on that I think it would be very useful to split 319 into two\npull requests: one which does the IsStandard change, and one which\nadds the full escrow feature set. This way when the escrow patch does\nenter the mainline client it will be meet up with a network which is\nhappy to handle its transactions.\n\n(and people who are eager to use escrow can use modified clients on\nthe main network before that point in time)\n\n\u003e I'm not sure I see the problem here. CScript.operator\u003c\u003c currently inserts\n\u003e values into scripts using the shortest possible sequence.\n\nAh for some reason I thought your current code did not always produce\nthe shortest sequence.\n\nIf so, I see no reason to block on the other pull.",
"sig": "31839607dea75bd8ebc7da2c540d9485ea29b69fa6c639de724f83afcf5cae3427acbe9f24497adb652b205d4df085036f9ed37d7fd995c88c5e42b55704006c"
}