đź“… Original date posted:2012-04-15
đź“ť Original message:2012/4/15 Jorge TimĂłn <timon.elviejo at gmail.com>:
> On 4/12/12, Jeff Garzik <jgarzik at exmulti.com> wrote:
>> 1. Â N = 1 or 2 or whatever the community prefers. Â Ideally enough time
>> for a third-tier miner, mining strange TXs, finds a block.
>> 2. Â H1 = height of block chain, when a TX is received
>> 3. Â H2 = H1 + (144 * N)
>> 4. Â If block chain height reaches H2, and TX has not made it into a
>> block, drop TX from memory pool
>
> Why not just adding a field expiration_block = H2?
> It seems more explicit and flexible than using a 144 * N constant.
> You're changing the protocol anyway, right?
No, not changing the protocol.
Further, adding a field to TX would imply the client needed to rewrite
the TX for each retransmit, changing the hash. Not good at all.
> Another question, aren't different peers going to get different H1 for
> the same tx?
Typically no, because 99.9% of TX's make it throughout the network in
seconds. But yes it is possible, just like it is possible today to
receive a TX at various times.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 10:04:36
in reply to nevent1q…8lxz
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 10:04:36Event JSON
{
"id": "f43e339b333335c758f318ef888e574640c2835c1cb588e3c5312a1af38c7fa4",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686132276,
"kind": 1,
"tags": [
[
"e",
"5f0cc6578a9ca4b7b0857c070ede1826db3227f161e70524c04566da5c5a56a8",
"",
"root"
],
[
"e",
"49b79a9b48a1d9f421dfb250697620edcb4677bc93b0d891bddd8cb76ec6bc9a",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "đź“… Original date posted:2012-04-15\nđź“ť Original message:2012/4/15 Jorge TimĂłn \u003ctimon.elviejo at gmail.com\u003e:\n\u003e On 4/12/12, Jeff Garzik \u003cjgarzik at exmulti.com\u003e wrote:\n\u003e\u003e 1. Â N = 1 or 2 or whatever the community prefers. Â Ideally enough time\n\u003e\u003e for a third-tier miner, mining strange TXs, finds a block.\n\u003e\u003e 2. Â H1 = height of block chain, when a TX is received\n\u003e\u003e 3. Â H2 = H1 + (144 * N)\n\u003e\u003e 4. Â If block chain height reaches H2, and TX has not made it into a\n\u003e\u003e block, drop TX from memory pool\n\u003e\n\u003e Why not just adding a field expiration_block = H2?\n\u003e It seems more explicit and flexible than using a 144 * N constant.\n\u003e You're changing the protocol anyway, right?\n\nNo, not changing the protocol.\n\nFurther, adding a field to TX would imply the client needed to rewrite\nthe TX for each retransmit, changing the hash. Not good at all.\n\n\u003e Another question, aren't different peers going to get different H1 for\n\u003e the same tx?\n\nTypically no, because 99.9% of TX's make it throughout the network in\nseconds. But yes it is possible, just like it is possible today to\nreceive a TX at various times.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "3611cbdba73c3d989104eb4fdbd8c19c4ca907f9a0d5856984ad3bb1c0adf7cafcee59ec6fbee1ecaa14b782eaff52af6f4ff1f38579e6f02d54caaeae619a84"
}