š
Original date posted:2011-08-11
šļø Summary of this message: Discussion on Bitcoin transaction filtering and sequence numbers for replacing transactions. Complexities of contracts and the usefulness of picking different source inputs debated.
š Original message:On Thursday 11 August 2011 17:17:23 Mike Hearn wrote:
> This thread is getting off-topic so I changed the subject.
Fair enough.
> > The benefit I'm aiming at is to imagine a thin client that has done a
> > fast startup and only downloaded the headers.
>
> OK. A better way is tx filtering, as discussed here:
>
> http://bitcointalk.org/?topic=7972.0
>
> The reason is you want to only get the transactions+merkle branches
> relevant to you, otherwise cost is still O(system activity) not O(your
> activity) as blocks get bigger, even if you don't download every
> block.
Well okay; it seems to me that that is considerably bigger task, and I'm not
sure how likely that is to appear. But that sounds workable, since my
feature request is simply this filtering system with the filter set to
"ALL"; so I can hardly complain about that.
> > The sequence number (and perhaps I've misunderstood) allows me to
> > replace a transaction I've already submitted
>
> Yes, but it's more complex than that.
... good stuff removed for brevity ...
> sequence number than mine - so we establish a kind of chain. Nobody
> can rewind the transaction to an earlier point, but anyone can update
> it within the parameters established by the SIGHASH flags on the
> others signatures.
I can't say I see what the point of all that added complexity is, contracts
are usually more than just financial, and the ability to pick a slightly
different set of source inputs doesn't seem like a hugely useful feature;
but I'm willing to accept someone thinks it is a good idea and leave it at
that. I withdraw my "move sequence number" feature request.
> You can't change anything about the inputs beyond scripts this way.
> The transaction still has to connect to the same outputs as before,
> and thus import the same amount of value.
What then allows the contract out of the memory pool into a chain? The
locktime? No, no, forget it... I don't want to open a new can of worms.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nxā¦7wjrv
2023-06-07 02:15:38
in reply to nevent1qā¦d3xd
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvSeen on
wss://relay.nostr.bandPublished at
2023-06-07 02:15:38Event JSON
{
"id": "9d7a929761b8214108462ed10907d16b2bd102ac273c9f5a9c6da8fdf0dc3570",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686104138,
"kind": 1,
"tags": [
[
"e",
"69c43172536e0c20ec7d84a3d3e20ec2c0e8db6913f5514b6d1b07a3212d3b38",
"",
"root"
],
[
"e",
"8254b44bc32edb088fc9b723d23e9ed0d993d42a314f112ba9ed3a7585200f34",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "š
Original date posted:2011-08-11\nšļø Summary of this message: Discussion on Bitcoin transaction filtering and sequence numbers for replacing transactions. Complexities of contracts and the usefulness of picking different source inputs debated.\nš Original message:On Thursday 11 August 2011 17:17:23 Mike Hearn wrote:\n\n\u003e This thread is getting off-topic so I changed the subject.\n\nFair enough.\n\n\u003e \u003e The benefit I'm aiming at is to imagine a thin client that has done a\n\u003e \u003e fast startup and only downloaded the headers.\n\u003e \n\u003e OK. A better way is tx filtering, as discussed here:\n\u003e \n\u003e http://bitcointalk.org/?topic=7972.0\n\u003e \n\u003e The reason is you want to only get the transactions+merkle branches\n\u003e relevant to you, otherwise cost is still O(system activity) not O(your\n\u003e activity) as blocks get bigger, even if you don't download every\n\u003e block.\n\nWell okay; it seems to me that that is considerably bigger task, and I'm not \nsure how likely that is to appear. But that sounds workable, since my \nfeature request is simply this filtering system with the filter set to \n\"ALL\"; so I can hardly complain about that.\n\n\u003e \u003e The sequence number (and perhaps I've misunderstood) allows me to\n\u003e \u003e replace a transaction I've already submitted\n\u003e \n\u003e Yes, but it's more complex than that.\n\n ... good stuff removed for brevity ...\n\n\u003e sequence number than mine - so we establish a kind of chain. Nobody\n\u003e can rewind the transaction to an earlier point, but anyone can update\n\u003e it within the parameters established by the SIGHASH flags on the\n\u003e others signatures.\n\nI can't say I see what the point of all that added complexity is, contracts \nare usually more than just financial, and the ability to pick a slightly \ndifferent set of source inputs doesn't seem like a hugely useful feature; \nbut I'm willing to accept someone thinks it is a good idea and leave it at \nthat. I withdraw my \"move sequence number\" feature request.\n\n\u003e You can't change anything about the inputs beyond scripts this way.\n\u003e The transaction still has to connect to the same outputs as before,\n\u003e and thus import the same amount of value.\n\nWhat then allows the contract out of the memory pool into a chain? The \nlocktime? No, no, forget it... I don't want to open a new can of worms.\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "d2b229c13af088dfda800a0d5afb30f023cd917f1293a53240b53f31d6041d810e610b4cfb576ba7ddb5165906f7cf4684fa6ad3e17089848c40897a9072efad"
}