📅 Original date posted:2018-09-07 📝 Original message:Please help me guide me in ...

Terry McLaughlin [ARCHIVE] /

npub1rts…f7z6

2023-06-07 18:14:38

in reply to nevent1q…42kr

📅 Original date posted:2018-09-07
📝 Original message:Please help me guide me in the direction I need to go

On Thursday, September 6, 2018, Brandon Smith via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I made a similar proposal about 7 months ago, and documented some of the
> discussion points here:
>
> https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz.
> mediawiki
>
> On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev
> wrote:
> > Functionality such as this does not currently exist not because no one
> > thought of it before, but because it has been proposed many times
> > before and determined to be harmful. The existing design of CLTV/CSV
> > were carefully constructed to make it impossible for a transaction to
> > go from valid to invalid based on the time. The most naive
> > construction-- e.g. push the current time/height on the stack-- would
> > have that property and was specifically avoided.
> >
> > When a spend goes from valid to invalid it means that a reorganization
> > will destroy coins even completely absent any dishonest actions of the
> > coins prior owner in the coins recent casual history. Effectively a
> > coin with any kind of non-monotone validity event in its recent
> > history functions like a recently generated coin: a coin that reorgs
> > destroy. Bitcoin addresses the issue for recently generated coins by
> > not permitting their use for 100 blocks. I've yet to see an argument
> > for a use case for non-monotone validity that still sounds useful once
> > the negative effects are addressed (e.g. by subjecting coins that have
> > gone through them to a maturity limitation).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180907/3fc1ce9c/attachment.html>;

Author Public Key

npub1rts7w6ksl8ewm6qchwvr745nly03fpxp4rwhwv8tuaynd5pehq5qw3f7z6

Seen on

wss://relay.noswhere.com wss://relay.nostr.band

Show more details

Published at

2023-06-07 18:14:38

Kind type

1 Short Text Note

Event JSON

{ "id": "62368ea761c2a5ad372fd1f4223cec119308f7eeeb8f8a4e05170886e62368ff", "pubkey": "1ae1e76ad0f9f2ede818bb983f5693f91f1484c1a8dd7730ebe74936d039b828", "created_at": 1686161678, "kind": 1, "tags": [ [ "e", "7426b9200a29d122a0f21fe5a36f46d2495e2e7ba790ae7045a12b6aede9e17c", "", "root" ], [ "e", "86832b902833467530deed215ba01980130dd3453793c817965f5595f3022fe5", "", "reply" ], [ "p", "d2790144ff033bdc832217ff7d810d8894f7d1f81d8a8b232fae95d4915c4f1c" ] ], "content": "📅 Original date posted:2018-09-07\n📝 Original message:Please help me guide me in the direction I need to go\n\nOn Thursday, September 6, 2018, Brandon Smith via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I made a similar proposal about 7 months ago, and documented some of the\n\u003e discussion points here:\n\u003e\n\u003e https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz.\n\u003e mediawiki\n\u003e\n\u003e On 2018-09-06 (Thu) at 15:16:34 +0000, Gregory Maxwell via bitcoin-dev\n\u003e wrote:\n\u003e \u003e Functionality such as this does not currently exist not because no one\n\u003e \u003e thought of it before, but because it has been proposed many times\n\u003e \u003e before and determined to be harmful. The existing design of CLTV/CSV\n\u003e \u003e were carefully constructed to make it impossible for a transaction to\n\u003e \u003e go from valid to invalid based on the time. The most naive\n\u003e \u003e construction-- e.g. push the current time/height on the stack-- would\n\u003e \u003e have that property and was specifically avoided.\n\u003e \u003e\n\u003e \u003e When a spend goes from valid to invalid it means that a reorganization\n\u003e \u003e will destroy coins even completely absent any dishonest actions of the\n\u003e \u003e coins prior owner in the coins recent casual history. Effectively a\n\u003e \u003e coin with any kind of non-monotone validity event in its recent\n\u003e \u003e history functions like a recently generated coin: a coin that reorgs\n\u003e \u003e destroy. Bitcoin addresses the issue for recently generated coins by\n\u003e \u003e not permitting their use for 100 blocks. I've yet to see an argument\n\u003e \u003e for a use case for non-monotone validity that still sounds useful once\n\u003e \u003e the negative effects are addressed (e.g. by subjecting coins that have\n\u003e \u003e gone through them to a maturity limitation).\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180907/3fc1ce9c/attachment.html\u003e", "sig": "d1b8a07074c399a052ca1f56ac95c11da41ad82161c00f758c3c762c18cb994b3428f2d034bfa841fc6935bb5b25b3b04a61ce9a269ddde684141aec954b6bfd" }