I agree this emulation seems sound but also tap out at how the CT stuff
works with this type of covenant as well.
Happy hacking!
On Tue, Feb 1, 2022, 5:29 PM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via
On Wed, Jan 05, 2022 at 02:44:54PM -0800, Jeremy via bitcoin-dev wrote:
> CTV was an output of my personal "research program" on how to make simple
> covenant types without undue validation burdens. It is designed to be the
> simplest and least risky covenant specification you can do that still
>
> On Feb 1, 2022, at 00:32, Bram Cohen wrote:
>
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote:
>>
>>
On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev
wrote:
>>> Is it still verboten to acknowledge that RBF is normal behavior and
>>> disallowing it is the feature,
Hi AJ, Prayank,
> I think that's backwards: we're trying to discourage people from wasting
> the network's bandwidth, which they would do by publishing transactions
> that will never get confirmed -- if they were to eventually get confirmed
> it wouldn't be a waste of bandwith, after all. But if
On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote:
>
>
> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Is it still verboten to acknowledge that RBF is normal behavior and
> disallowing it is the feature, and that feature is mostly
Hi Bastein,
> This work will highly improve the security of any multi-party contract trying
> to build on top of bitcoin
Do you think such multi party contracts are vulnerable by design considering
they rely on policy that cannot be enforced?
> For starters, let me quickly explain why the
