andytoshi changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | This channel is logged. | For logs and more information, visit https://bitcoin.ninja
Guyver2 has quit [Read error: Connection reset by peer]
Guyver2 has joined #bitcoin-wizards
davidfetter1 has quit [Remote host closed the connection]
Barras2 has joined #bitcoin-wizards
parazyd has joined #bitcoin-wizards
parazyd has left #bitcoin-wizards [#bitcoin-wizards]
proofofkeags has joined #bitcoin-wizards
luke-jr has quit [Ping timeout: 246 seconds]
luke-jr has joined #bitcoin-wizards
luke-jr has quit [Excess Flood]
luke-jr has joined #bitcoin-wizards
EndFiat has quit [Ping timeout: 240 seconds]
EndFiat has joined #bitcoin-wizards
fiatjaf has joined #bitcoin-wizards
fiatjaf has quit [Ping timeout: 260 seconds]
Guyver2_ has joined #bitcoin-wizards
Guyver2 has quit [Ping timeout: 265 seconds]
fiatjaf has joined #bitcoin-wizards
sr_gi has joined #bitcoin-wizards
fkinglag has quit [Ping timeout: 252 seconds]
jonahg has quit [Quit: Connection closed for inactivity]
fkinglag has joined #bitcoin-wizards
patriot2939 has joined #bitcoin-wizards
smartineng has quit [Quit: smartineng]
rusty has joined #bitcoin-wizards
Guyver2_ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
rubikputer has joined #bitcoin-wizards
rubikputer has joined #bitcoin-wizards
rubikputer has quit [Changing host]
fkinglag has quit [Ping timeout: 246 seconds]
fkinglag has joined #bitcoin-wizards
robot-dreams has quit [Read error: Connection reset by peer]
Galvas has quit [Ping timeout: 250 seconds]
amiti has quit [Ping timeout: 250 seconds]
dburkett has quit [Ping timeout: 250 seconds]
glozow has quit [Ping timeout: 250 seconds]
moneyball has quit [Ping timeout: 245 seconds]
schmidty has quit [Ping timeout: 245 seconds]
s0ph1a has quit [Read error: Connection reset by peer]
b-itcoinssg____ has quit [Read error: Connection reset by peer]
nikuhodai has quit [Read error: Connection reset by peer]
nejon has quit [Read error: Connection reset by peer]
gazab has quit [Ping timeout: 260 seconds]
Herka has quit [Ping timeout: 260 seconds]
zmanian_ has quit [Ping timeout: 260 seconds]
prosodyC has quit [Ping timeout: 248 seconds]
wpalczynski has quit [Ping timeout: 250 seconds]
s0ph1a has joined #bitcoin-wizards
robot-dreams has joined #bitcoin-wizards
glozow has joined #bitcoin-wizards
b-itcoinssg____ has joined #bitcoin-wizards
nejon has joined #bitcoin-wizards
Galvas has joined #bitcoin-wizards
amiti has joined #bitcoin-wizards
nikuhodai has joined #bitcoin-wizards
wallet42____ has quit [Ping timeout: 260 seconds]
endogenic has quit [Ping timeout: 260 seconds]
elichai2 has quit [Ping timeout: 260 seconds]
rodarmor has quit [Ping timeout: 248 seconds]
dburkett has joined #bitcoin-wizards
wpalczynski has joined #bitcoin-wizards
moneyball has joined #bitcoin-wizards
wallet42____ has joined #bitcoin-wizards
rodarmor has joined #bitcoin-wizards
schmidty has joined #bitcoin-wizards
nioc has quit [Ping timeout: 258 seconds]
jamesob has quit [Ping timeout: 258 seconds]
endogenic has joined #bitcoin-wizards
elichai2 has joined #bitcoin-wizards
prosodyC has joined #bitcoin-wizards
jamesob has joined #bitcoin-wizards
gazab has joined #bitcoin-wizards
nioc has joined #bitcoin-wizards
Herka has joined #bitcoin-wizards
zmanian_ has joined #bitcoin-wizards
jadi has joined #bitcoin-wizards
jadi has quit [Ping timeout: 246 seconds]
TheoStorm has joined #bitcoin-wizards
<nothingmuch_>
waxwing: CoinParty is kind of interesting too... i think it was ignored because it's got a significant theft risk (MPC), and the terminology was really confusing, but there are some cool ideas that i think are ripe for iteration
<jeremyrubin>
whats coinparty
rusty has quit [Ping timeout: 240 seconds]
nothingmuch_ is now known as nothingmuch
<nothingmuch>
jeremyrubin: the setting is n users and k mixing peers ("servers" would have been a clearer term IMO), the users deposit the funds in n mp-ecdsa addresses controlled by the peers, and then the peers send back to the users. IIRC if a super-majority of peers are honest then there's no theft concern, and if a single mixing peer is honest then it is unlinkable
<jeremyrubin>
ah
<nothingmuch>
it's sort of half way between a coinjoin and a coinswap, the individual transactions are disjoint on chain which i think is the appealing thing
<jeremyrubin>
+ you can make it work in a more efficient way today than what sapio outputs with specific CTVEmulator trait impls
<nothingmuch>
no, in coinpool there is no theft concern at all, and the users' individual outputs share a common ancestor
<jeremyrubin>
Not how I spec'd it
<jeremyrubin>
I use a arbitrary vec Clauses
<jeremyrubin>
and a dif vec payouts
<jeremyrubin>
so you can have a n of m host server
<nothingmuch>
hmm, interesting...what use cases did you have in mind for that?
<jeremyrubin>
well what'
<jeremyrubin>
sorry
<jeremyrubin>
I engineered it so that it can non-interactively be paid into by an untrusted third party with CTV
<jeremyrubin>
Each payout can actually be a non interactively created channel
<nothingmuch>
although the main appeal of CoinParty is that there is no single txo at the root, so arguably the anonymity set is as large as coinswap (and afaik it is the first such privacy protocol that was designed to blend in with normal 1 addresses)
<jeremyrubin>
the N of N can only signoff on full tree updates with agreement by all parties
<jeremyrubin>
and the parent of each tree could also be (with more work) a channel too
<jeremyrubin>
so you essentially get the ability to create unbounded channels and have a system for cooperatively closing
<jeremyrubin>
The untrusted third party could be coinbase
<jeremyrubin>
Or, more fun, it could be the last N miners creating an on chain mining pool
<jeremyrubin>
and then they "swap" their returns across trees
<jeremyrubin>
but for now you have to run some customizable oracle signing server
<nothingmuch>
i really need to find more time to play with it, at the moment i'm a little too busy with wasabi stuff, but i would really like to have a high confidence that sapio could be integrated into that in the longer term
<jeremyrubin>
it's designed to be integrated with very little work
<nothingmuch>
after i'm done fighting C# a rust implementation of the credential scheme is a high priority
<jeremyrubin>
if you can run WASM blobs you can run sapio contracts
<nothingmuch>
hmm, i have no clue about C#/wasm interop... but i expect the challenges are likely to be more conceptual, i.e. if we structure the coordinator in a way that makes it prohibitively complicated
<jeremyrubin>
Yeah. there are diff ways of integrating, depending on target environ
<jeremyrubin>
most likely for e.g. desktop apps you'd want an isolated sapio server that hooks in to the contract pretty deeply
<jeremyrubin>
This is still an open area of research
<jeremyrubin>
Sapio does have pretty awesome output types, but it's essentially like Verilog outputting a netlist for an FPGA
<jeremyrubin>
firmare Coming Soon (tm)
<jeremyrubin>
figuring out the right way to do this is hard, because I can make a first class experience for sapio contracts that always live in a rust memory space, but i want to load them in many contexts
<jeremyrubin>
There's going to be a lot of work coming up with standard library contract components
<jeremyrubin>
but I'm optimistic that sapio can be super useful even before that
<jeremyrubin>
Worst case can use it to rapid prototype something before converting to a one-off e.g. C++ implmentation. And then for user inputs (e.g., subcontracts) you can run WASM sapio modules
<nothingmuch>
a one off implementation of a specific contract?
<jeremyrubin>
I've done it before (and I hope to never do it again)
<nothingmuch>
TBH that doesn't look too bad if thinking of a specific use case and the constraints justify not using the tooling
<jeremyrubin>
Absolutely. The catch is that I plan to have a *lot* of tooling around sapio output formats. So folks will prolly expect to use those. That said, the formats are well spec'd so can always replicate
<nothingmuch>
i mean, i'm assuming you'd use the tooling to develop & interact with it, it's just that certain implementations might need to "compile" a specific instance by hand so to speak, right?
patriot2939 has quit [Ping timeout: 240 seconds]
<jeremyrubin>
not sure what that means
<jeremyrubin>
TBH i think it would be easier to port a rudimentary version of Sapio to host language than to make one off contracts
<jeremyrubin>
The *actual* compiler has a lot of bells and whistles that you don't need for most contracts
patriot2939 has joined #bitcoin-wizards
<jeremyrubin>
so if you just wanted minimum sapio you could get it trivially and not support some of the safety features or conveniences
<jeremyrubin>
I think it'd be doable if you made it a file in bitcoin core in e.g. a weekend.
<jeremyrubin>
If someone wants to work on that I'd be excited to help with it
<jeremyrubin>
but am mostly focused on building a complete Sapio rust ecosystem foremost
<nothingmuch>
i meant that most of the work of designing/developing the contracts would benefit from the tooling even if the target environment can't for some reason, but a rudimentary compiler does make more sense
<jeremyrubin>
yes correct. you can use whatever features you like during development, and then transform it to a simpler version feature wise, and then port it to host w/ a simple compiler that just supports the most basic set of features
<jeremyrubin>
E.g. all the conditional compilation and stuff can just be if/else clauses and more concrete types