[bitcoin-dev] Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks

2022-03-21 Thread ZmnSCPxj via bitcoin-dev
Good morning list, It is entirely possible that I have gotten into the deep end and am now drowning in insanity, but here goes Subject: Beyond Jets: Microcode: Consensus-Critical Jets Without Softforks Introduction Recent (Early 2022) discussions on the bitcoin-dev mailing lis

Re: [bitcoin-dev] Speedy Trial

2022-03-21 Thread vjudeu via bitcoin-dev
> I don't quite understand this part. I don't understand how this would make > your signature useless in a different context. Could you elaborate? It is simple. If you vote by making transactions, then someone could capture that and broadcast to nodes. If your signature is "useless in a differen

Re: [bitcoin-dev] Covenants and feebumping

2022-03-21 Thread darosior via bitcoin-dev
Hi ZmnSCPxj, Thanks for the feedback. The DLC idea is interesting but you are centralizing the liveness requirements, effectively creating a SPOF: in order to bypass the revocation clause no need to make sure to down each and every watchtower anymore, just down the oracle and you are sure no rev

Re: [bitcoin-dev] OP_RETURN inside TapScript

2022-03-21 Thread Kostas Karasavvas via bitcoin-dev
Hi vjudeu, There are use cases where your following assumption is wrong: ".. and that kind of data is useful only to the transaction maker." No one really publishes the actual data with an OP_RETURN. They publish the hash (typically merkle root) of that 1.5 GB of data. So the overhead is just 32

Re: [bitcoin-dev] Speedy Trial

2022-03-21 Thread Billy Tetrud via bitcoin-dev
Good Evening ZmnSCPxj, > I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request. You're right that there's some nuance there. You could add a block hash into the poll message and define things so any subsequent poll message sent with a