📅 Original date posted:2016-10-02
📝 Original message:On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote:
> Is this particular proposal encumbered by a licensing type, patent, or
> pending patent which would preclude it from being used in the bitcoin
> project? If not, you're wildly off topic.
I think that's the concern: we don't - and *can't* - know. Pending patents are
not publicly visible, as far as I am aware, and the BIP process does not
(presently) require any patent disclosure.
Of course, it is entirely possible to voluntarily provide a disclosure of
patents in the BIP (and ideally a free license to such patents, at least those
for the BIP). This is an alternative possibility to resolve patent concerns if
Rootstock is not prepared to adopt a defensive patent strategy in general
(yet?).
On Sunday, October 02, 2016 6:17:12 PM Russell O'Connor via bitcoin-dev wrote:
> If I understand this BIP correctly, the values pushed onto the stack by the
> OP_COUNT_ACKS operation depends on the ack and nack counts relative to the
> block that this happens to be included in.
>
> This isn't going to be acceptable. The validity of a transaction should
> always be monotone in the sense that if a transaction was acceptable in a
> given block, it must always be acceptable in any subsequent block, with the
> only exception being if one of the transaction's inputs get double spent.
I don't know if it's possible to implement decentralised sidechains without
"breaking" this rule. But I would argue that in this scenario, the only way it
would become invalid is the equivalent of a double-spend... and therefore it
may be acceptable in relation to this argument.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:53:42
in reply to nevent1q…fcx5
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:53:42Event JSON
{
"id": "7b0c5640c967bb6842658e7618c9ef085094ffcc13eb5d4fdd07ce386a7d979e",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160422,
"kind": 1,
"tags": [
[
"e",
"a0719e105373a31b19331be2ab9915ba509ea0ec8469edd3808978e2d85d8297",
"",
"root"
],
[
"e",
"94ca33599e888dc77ebbdcb491892aab3b08c78e8bd986a5e8ed59274f4439d6",
"",
"reply"
],
[
"p",
"fa69268781de33f116b423cab175d976820851d6b074d0873c920c6983eb4713"
]
],
"content": "📅 Original date posted:2016-10-02\n📝 Original message:On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote:\n\u003e Is this particular proposal encumbered by a licensing type, patent, or\n\u003e pending patent which would preclude it from being used in the bitcoin\n\u003e project? If not, you're wildly off topic.\n\nI think that's the concern: we don't - and *can't* - know. Pending patents are \nnot publicly visible, as far as I am aware, and the BIP process does not \n(presently) require any patent disclosure.\n\nOf course, it is entirely possible to voluntarily provide a disclosure of \npatents in the BIP (and ideally a free license to such patents, at least those \nfor the BIP). This is an alternative possibility to resolve patent concerns if \nRootstock is not prepared to adopt a defensive patent strategy in general \n(yet?).\n\nOn Sunday, October 02, 2016 6:17:12 PM Russell O'Connor via bitcoin-dev wrote:\n\u003e If I understand this BIP correctly, the values pushed onto the stack by the\n\u003e OP_COUNT_ACKS operation depends on the ack and nack counts relative to the\n\u003e block that this happens to be included in.\n\u003e \n\u003e This isn't going to be acceptable. The validity of a transaction should\n\u003e always be monotone in the sense that if a transaction was acceptable in a\n\u003e given block, it must always be acceptable in any subsequent block, with the\n\u003e only exception being if one of the transaction's inputs get double spent.\n\nI don't know if it's possible to implement decentralised sidechains without \n\"breaking\" this rule. But I would argue that in this scenario, the only way it \nwould become invalid is the equivalent of a double-spend... and therefore it \nmay be acceptable in relation to this argument.\n\nLuke",
"sig": "fe4e2652f0af0602626c9cdd35a941ca3dfea282a08606eb72ab90715697c4240f1051a9ffa699392f4f9f9ccc3050418c206410fa89e42b285192b1b2874e8d"
}