Ah you already did it, many thanks

A few million would be appreciated. Only reason i need a bit more is that i want to do some experiments with a couple of friends tomorrow and it'll be easier if i can give them a couple of million each, say.

Here is an example.

Participant 0 sent the coin (value 100k sats) to Participant 1 with a file. They validated it, and the fidelity bond.

Then Participant 0 illegally spent the pathcoin:

https://mempool.space/signet/tx/7389220f82b9fc4a1db3d219373a13e6b50d267885361fa5a0901db3e09fb3b8

Then, P1 noticed, and broadcast the first stage penalty:

https://mempool.space/signet/tx/17959099cd0f3dbf47e9e233ce2eee60cda7815e1735c837b588c5753bdc23c1

Look at P2TrScript under 'Details' to see how OP_CTV as OP_NOP4, is used. Then, the second stage penalty was broadcast, which sent it to P1's wallet:

https://mempool.space/signet/tx/2961129e987a4de1bbf3d03b975fa8856764a5dde49203319d2d5a2c7a06f99d#vin=0

Worked first time! After testing 1000 times on regtest 😄

(Btw i forgot to update the CTV blockheight from regtest, but whatever.)

Are the signers/miners validating BIP119 on that?

I think there's only one operational, for the 'default' signet. 1 mill at a time. I don't see the point of testnet3, way too large and unstable.

Even moreso when the faucet shouts angrily at me for asking for more than 1 million 😆

Anybody can spare me a few million signet sats?

tb1q0ddxffgy36xm9k4hl34suqfy8xlhe4kgpsqxvs

Need some for testing and 1 mill at a time from the faucet is a bit slow.

I will zap you in response even though I'm literally breaking the Laws of Bitcoin by doing so 😄

Still very much 'under development' but:

https://github.com/AdamISZ/pathcoin-poc

Next is to check that python-bitcointx installation with libsecp dependency can work on another machine (can't use release+wheel because taproot).

Apart from that, depencies are very light. But as noted in readme, if you want to test it with OP_CTV you need to be running Inquisition, i believe.

I've always been doubtful about the idea of having larger groups regularly coordinating over the network.

Current coinjoin has very big coordination groups, but it's one and done, and i think that matters a lot.

If you just look at Greg's explanation of joinpool in that chat, it's clear that it represents a way better kind of wallet, in privacy terms - *if* you ignore the first above sentence.

Riard and Naumenko's coinpool concept was a lot more ambitious in trying to be a full off chain protocol, but iirc they proposed 2 or 3 new opcodes within their scheme.

Funny, while looking up info about coinpool, I was reminded of joinpool, found Harding's writeup on optech here: https://gist.github.com/harding/a30864d0315a0cebd7de3732f5bd88f0

which referred to a discussion by gmax on IRC here:

https://gnusha.org/bitcoin-wizards/2019-05-21.log

... only to discover that I was the guy he was discussing it with, and I had 100% forgotten having that conversation 😆

Is it just me that gets "Code 55% faster with github copilot" for every single repo you upload to github ... even if it's just the text of a pdf? 😆

They definitely recorded the main stages last year. Might have to check about my second talk.

I've only just noticed that Rusty Russell has been writing about covenants on his blog recently. I particularly liked this taxonomy one, though I haven't actually read the one he posted yesterday, yet.

https://rusty.ozlabs.org/2023/07/09/covenant-taxonomy.html

I think you can 'reset' pathcoins, i.e. send them back to the original owner, staying offchain. Explained in detail in this comment ... would love to know what others think:

https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da?permalink_comment_id=4731881#gistcomment-4731881

First is slow going indeed, for the first half, especially if you're not familiar with Chinese culture. Second book is the true masterpiece imo.

Seconding Greg Egan. For the cypherpunk (like calle) I'd particularly recommend Permutation City. Diaspora is also a favourite. Agree on Schild's ladder also.

I didn't really understand how what you're saying is different? Isn't your function f here, just signature adaptors?

Bitcoin is like those ripoff calculators that schools force students to buy for hundreds of dollars :)

So the students organize themselves, buy only one expensive calculator, and do most of their working on their cheap chinese knockoffs, very occasionally going back to school to double check they have the same answer :)

Re tap leaf per case, I realised while coding it that it makes most sense to just have 5 musig signing sessions, on the same aggregated key, rather than 5 tapleafs.

Re: jumping steps, look at my recent post history. With a minir relaxation of 'offlineness', hopping steps on the path is pretty viable.

Oh that part is for sure a thing, i.e. using adaptors specifically in a musig setting (it works better that way because the adaptor owner is forced to use the pre agreed aggregated nonce). That's how adaptors are used here and in adaptor based atomic swaps etc. Unless maybe I misunderstood what you're saying.

You meant the latest one right?

Sheesh this is more like a book than a blog post 😅. But very relevant, indeed.