bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Guest38 has joined #bitcoin-core-dev
Guest38 has quit [Client Quit]
andrewtoth_ has joined #bitcoin-core-dev
andrewtoth has quit [Remote host closed the connection]
ufotofu is now known as grubman9001
mikehu44 has quit [Ping timeout: 256 seconds]
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 240 seconds]
mikehu44 has joined #bitcoin-core-dev
rex4539 has quit [Ping timeout: 276 seconds]
gnaf has quit [Quit: Konversation terminated!]
prayank has joined #bitcoin-core-dev
<prayank>
jeremyrubin: Compiling #21702 branch. BIP 119 mentioned about coinjoin. I want to test this with a setup of 2-3 regtest nodes. I don't understand the code written here: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#detailed-specification however I can test things based on the description that "participants agree on a single output which pays all participants". Do you have any other suggestion to help me in this
<prayank>
testing? I am already working for Wasabi since last few weeks so I can even involve others to review if it helps in coinjoin
<jeremyrubin>
It's hard because the thing I want to show you most works best with taproot, which isn't done in Sapio yet.
<jeremyrubin>
But the idea would be to coinjoin into a payment pool.
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 250 seconds]
mikehu44 has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
<prayank>
jeremyrubin: 1. No. I wish it was in C# anyway I will still do it. Will take some time. 2. Hmm so Sapio isn't updated? 3. Coinjoin into payment pool? This looks confusing to me. So Coinjoin at basic level is just inputs and of different users getting registered, sign transactions, create tx with outputs that would break the links with inputs and make it difficult to analyze. Or in short red green yellow, decide to go to a party
<prayank>
, they wear a dress and do makeup that makes them look similar and lot of other people join party. Finally, when everyone comes out nobody can regognize each other. Where is payment pool in this part? Or where does CTV help?
helo has quit [Remote host closed the connection]
helo has joined #bitcoin-core-dev
jb55 has quit [Ping timeout: 240 seconds]
mikehu44 has quit [Ping timeout: 256 seconds]
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 260 seconds]
gnaf has joined #bitcoin-core-dev
tecnecio has quit [Quit: Leaving]
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 256 seconds]
mikehu44 has joined #bitcoin-core-dev
arythmetic has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 240 seconds]
jb55 has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 256 seconds]
mikehu44 has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 256 seconds]
mikehu44 has joined #bitcoin-core-dev
mikehu44 has quit [Ping timeout: 256 seconds]
mikehu44 has joined #bitcoin-core-dev
arythmetic has quit [Remote host closed the connection]
<prayank>
jeremyrubin: I am done with compiling. Ran two regtest nodes. No Sapio tonight. Do you have any final instructions or I should go on my mission to test things as I want?
<jeremyrubin>
prayank: sapio depends on rust-bitcoin and rust-miniscript. neither have released Taproot support yet -- once they do, i need to rebase Sapio patches and then do a little work to integrate it, then it will be fine (but I need to check and make sure things like PSBTs still work fine).
mikehu44 has quit [Ping timeout: 256 seconds]
yanmaani has joined #bitcoin-core-dev
<jeremyrubin>
The idea is that you'd make a "rolling coin join" where to start it's N inputs 1 output that is N-N or split in half (via CTV) and recurse (n/2-n/2, n/2-n/2) where leaf nodes are single keys.
<jeremyrubin>
You can also, like a normal coin pool, add funds (add input -> N+1-N+1 multisig) or remove funds (N-1 of N-1)
<jeremyrubin>
You can also make payments out of the coin pool directly (e.g, make payment decreasing Bob's balance in the coin pool but not publicly seen) to external (or internal) recipient
<jeremyrubin>
If you don't *want* the rolling style coinjoin then you can ignore the payment pool and directly expand the tree via congestion control. You can mess with parameters, but this ends up being able to be a bit more efficient for locking in the root and expanding via a 2nd txn, especially if your outputs have different 'priority' for being spent (bits
<jeremyrubin>
CJ already leaks)
goatpig has joined #bitcoin-core-dev
<jeremyrubin>
i should probably write these details up somewhere and link to it from the BIP. GMAX has also discussed it in #bitcoin-wizards
<prayank>
gmax should consider becoming a maintainer again, maybe things improve and if he has enough time. anyways thanks for all the info. I am going out now and will try things in few hours. It would be great if it helps cj in anyway. And leaks: bitcoin is many like its the easiest thing to become a privacy researcher in bitcoin.
Guest38 has quit [Client Quit]
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
mikehu44 has joined #bitcoin-core-dev
<jeremyrubin>
prayank fair enough. i just mean if i have a congestion control coinjoin out or just a regular N-out, A spends before B is info that is leaked by virtue of A sending a txn before B regardless of if CTV is used
<jeremyrubin>
the other reason it makes it easier BTW is that if you do want to put all the smart contracts underneath it, like channels, you don't need to do presigned TX exchanges and stuff it suffices to just agree on the outputs and then any outpoints won't affect the program validity
<jeremyrubin>
E.g., if i want to do a coinjoin that opens up N lightnign channels, I first need to agree on what all the inputs are and what order, then agree on the specific CJ tx, then do presigns, then sign the CoinJoin. With CTV it can be just "Agree on the outputs" and then "form any TX that spends the correct amount to those outputs"
<jeremyrubin>
so also an advantage for CTV congestion control tree or no
mikehu44 has quit [Ping timeout: 268 seconds]
mikehu44_ has joined #bitcoin-core-dev
mikehu44 has joined #bitcoin-core-dev
mikehu44_ has quit [Ping timeout: 268 seconds]
mikehu44 has quit [Ping timeout: 268 seconds]
mikehu44 has joined #bitcoin-core-dev
<jb55>
so apparently if you make a batch getblock jsonrpc request with 1000 blocks at verbosity level 2 your node will catch fire and explode
* jb55
aka run out of memory and die :(
___nick___ has quit [Ping timeout: 240 seconds]
ghost43 has quit [Remote host closed the connection]
<prayank>
Kiminuo: since it has no try-catch with empty catch blocks, code review ack. I am not sure about concept though. commits are referenced in knots so ACK I guess.
Yihen has quit [Remote host closed the connection]
Yihen has joined #bitcoin-core-dev
yousser has joined #bitcoin-core-dev
yousser has quit [Client Quit]
yousser has joined #bitcoin-core-dev
goatpig has quit [Ping timeout: 240 seconds]
vysn has quit [Ping timeout: 240 seconds]
Kiminuo has quit [Ping timeout: 256 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
Talkless has quit [Quit: Konversation terminated!]