Avatar
Super Testnet
2183e94758481d0f124fbd93c56ccaa45e7e545ceeb8d52848f98253f497b975
Open source dev w/ bitcoin focus | supertestnet.org bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

It's worse on monero than on LN. On monero, if I send coins to pubkey X, I know that pubkey has unilateral control over them for about 20 minutes (10 monero blocks) before they can possibly forward them to some other destination. If they do forward them to someone else, I can credibly accuse them of knowingly doing so and I can provide cryptographic proof that they had the coins at some point.

Not so with LN. Thanks to atomic swaps, if I send coins to invoice X, I don't know if the pubkey therein ever has control of those coins. If he is a routing node, the amount of time he has control of those coins is 0. I cannot credibly accuse him of knowingly forwarding those coins to someone else, because he too does not know the destination, and moreover, once the swap was entered into there was no way he could possibly stop it. Once you create an htlc, you no longer control whether it gets settled.

So it's very different. On LN, intermediaries have plausible deniability. On monero, mixers have no plausible deniability.

Replying to Avatar Hanshan

ffs

this is why nostr:nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpz4mhxue69uhkummnw3ezummcw3ezuer9wchszyrhwden5te0dehhxarj9ekk7mf0qy88wumn8ghj7mn0wvhxcmmv9uynmh4h insists on calling the sender of a tx knowing the destination "tracing."

because people unfamiliar with the nuances just think "apparently monero is traceable."

and FUD increases and he apparently gets off on that intellectually dishonest bullshit.

the sender knows where the #monero goes. there is no tracing involved.

its not ideal. but it isnt fucking "tracing monero"

nostr:nevent1qqsvvgedpcgnrrknv5p0wf75yn2d7vg3w4gs05envt0w2579y0atckqpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczyr3p0zvhs5zgac2a5e4tr3rr8wr8n52pa9k9ycqh6hnmrxguukztjqcyqqqqqqgwfv0h4

Yes, you have identified precisely why I use the term tracing : so that people unfamiliar with the nuances will learn that monero is tracable by design. The designers wanted the sender to be able to follow his payment all the way to its destination, so they gave him a view key for his transactions. This design flaw is completely unnecessary and harms privacy by making the first step of a trace easy: send someone coins, or find someone who already sent coins to them, and bam, you have cryptographic proof of the possession of those coins by a particularpubkey, and can watch the blockchain to see where that pubkey shows up next. That is traceability. Built into monero by design.

Replying to Avatar Hanshan

lol

nostr:nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpz4mhxue69uhkummnw3ezummcw3ezuer9wchszyrhwden5te0dehhxarj9ekk7mf0qy88wumn8ghj7mn0wvhxcmmv9uynmh4h and I have an ongoing discussion

he likes to call it "tracing" because saying

"the sender of a transaction knows the destination"

doesnt sound very impressive.

but that all that stupid "challenge" of his shows.

it isnt "tracing monero."

he just thinks its funny to make work for other people.

> doesn't sound very impressive

What it sounds like to me a serious privacy flaw that lands people in jail

> it isn't tracing

It clearly is. Tracing a cryptocurrency payment is following it from its source to its destination. Monero makes this trivial for the sender, it provides him with a cryptographic proof-of-trace in every transaction (the view key). Lightning makes it impossible under some circumstances.

Anyone in Vegas a day early and wanna hang out?

Ah, I never saw that, it's a very cool design and now I want to implement a proof of concept

It looks like an advantage of my design is that any participant can get their channel on the blockchain by broadcasting only 2 transaction packages, and from there, an additional 2 transaction packages allow them to force close their channel (so 4 total).

By contrast, based on your 6th diagram it looks like Alice has to broadcast 5 transaction packages to do the equivalent: the first package creates state0 and state0.0, the second makes commitmentA, the third puts her channel AB on the blockchain, the fourth spends from the channel AB plus state0.0 to make commitmentA.A, and the fifth puts the latest state on the blockchain.

It looks like Law's design has one advantages that my protocol does not have: parties within Law's factory can cooperatively rebalance their channels without any onchain transactions -- which I don't know how to do in my design.

Law's design also alerted me to this idea, which I had not thought of but which sounds possible with both of our designs: if 2 or more pool users have near-constant uptime, but they have channel counterparties that are frequently offline, they can create channels with *each other* that are *funded by* the outputs of their channels with the frequently-offline users -- and this allows them to use that money for routing payments even when their counterparties are offline

I did not consider that design when making my coinpool model because I figured only Reginald would have near-constant uptime and the other users would have phone wallets that are usually off. But if I modify my assumptions so that other users can serve as routing nodes within the pool too, I can let them do the thing you described in your article and thus free up more liquidity within the pool.

Thank you for showing me this!

yeah, he partnered with a popular PoS provider such that all Chipotles could "turn on" bitcoin supports, and a bunch of other stores could do it too -- but almost none did, because it wasn't "on by default"

the Steak n Shakes are supposedly different because the higher-ups made the decision and are imposing it from the top down -- it's less optional (though there are clearly some exceptions, or at least some of them don't have to do it *yet*)

Pro tip from Vegas: the Steak n Shake at Oyo hotel knows they are *supposed* to accept bitcoin but the new PoS terminals haven't arrived yet. The guy at the counter said you can pay with bitcoin at all the other Steak n Shakes in the city though.

A lot of bad things started with putting pictures on the money

Big problem with the monero community:

When a flaw like this is pointed out that exemplifies a huge hole in monero's vaunted receiver privacy, many monero bros play a semantic game and focus on whether it counts as tracing or not. Which, by the way: shiw me a definition of tracing where this doesn't count.

That's Timeout Trees, right? I'm not aware of a non-fork version of Timeout Trees. Do you have a link? The attached article by shinobi says Timeout Trees rely on CTV.

It also says the admin must regularly kick everyone out of the current channel factory and put them in a new one. My design tries to make that optional and atypical rather than required.

It sounds like another main difference is that Timeout Trees would use CTV to allow the admin to open channels for his users noninteractively. My design assumes we don't have CTV, so opening the channels happens during a signing ceremony scheduled by the people who want to enter a coinpool together.

https://bitcoinmagazine.com/technical/timeout-trees-a-solution-to-scaling-lightning-network-lsps

Why is it okay for the sender to know the destination? Why not hide that information from the sender? Why needlessly make the recipient vulnerable?

the current iteration of Knots has the same set of consensus rules as bitcoin

the only differences are what you allow into the mempool, not what you allow into blocks

but my hope is that a big switch to knots serves as an indicator that the people are ready for a soft fork to fight spam, e.g. a blocksize decrease, or prohibiting op_returns with a datacarrier value, or prohibiting OP_0 OP_IF in a script

I wrote an implementation that seems to work fine with any LN backend that supports NWC -- I've run it on top of cashu mints, for example. So Reginald doesn't even really node a lightning "node" -- just a wallet that can send and receive LN payments.

No. Also, it's just a meme, I don't think Knots will become dominant.

Today I published what I think is a decent channel factory or coinpool design that requires no soft forks. Let me know what you think:

https://supertestnet.github.io/scewl/