> why he doesn't like comparing bitcoin (onchain) to monero (onchain) !
I do like comparing them, and I often do so
I'll do it again here:
Monero's ring signatures offer similar privacy protections as coinjoins do, with a few caveats:
(1) monero's ring signatures are non-interactive, which is way better than a coinjoin
(2) monero's ring signatures are limited to 16 people in the current protocol, which is way worse than a coinjoin
> doing your challenge to compare LN to monero requires a LN-monero
No it doesn't. I'm comparing LN to "on-chain" monero and I'm saying LN -- as a well-designed off-chain protocol -- offers superior privacy features than "on-chain" monero. I look forward to LN-monero existing maybe someday in the future, but the nice thing is, you don't have to wait! You can have LN-like privacy "right now." Use lightning. It exists and works.
> why does [monero] have [so much less] spam?
I don't know but if I had to guess it's because no one cares to spam it
> monero...forces blocks to be small, but **punishes** increase
This is a contradiction. If they are allowed to increase, they are not forced to be small.
> never ask a bitcoiner what is a "p2pool" and why is it increasing
I don't know what p2pool is or why it is increasing. Care to share?
> this wasn't just about privacy
Figures -- he'd like to compare monero to bitcoin on every metric except the one it's for.
> Here's a challenge
I recommend doing my challenge before you issue a counter-challenge. Looks a bit sus.
> the OP was talking about spam
Your post contradicted itself on this point. The statement "spam exists [on monero]" is incompatible with the statement "only monetary transactions." The fact that few people bother to bypass your filters is probably just because few people care about monero.
The statement "small, 300kb blocks" is incompatible with the statement "dynamic to increase." Imagine if I pointed to a block like this one from two days ago (https://mempool.space/block/000000000000000000000463103ac48ed3c8887e59ba7d0078683c4fa4913e7b) and said it proves that bitcoin has "small, 500kb blocks" but that they are "dynamic to increase to 4mb." The statements are incompatible because the first implies they can't increase and the second explicitly says they can.
The reason why the first sentence implies they can't increase is this: if you don't adopt that implication, then you're just commenting on the lack of usage in a particular block. Which is a pointless observation. Just because a particular block doesn't take up the max size doesn't mean the max size is temporarily lower. Monero's blocks do not have a max size, which is a centralizing force, and as for the "penalty" for creating large blocks, that's what fees are for. If monero had any volume, huge blocks would make it even more centralized than it is today.
> no mining centralization
Very funny
it's just a meme, I don't think that will actually happen
we say "Monero is what noobs think they bought"
but it's also what bitcoiners think they bought
> small, 300kb blocks (dynamic to increase but with a miner reward punishment)
> resistant to spam (spam exists: https://github.com/mooonero/mordinals but we use and enforce filters)
> only monetary transactions
> cost effective to be fungible and anonymous money (that means txs are slightly bigger with added privacy, but not as expensive as bitcoin's coinjoins source: https://sethforprivacy.com/posts/comparing-private-spends/)
> it may get LN-like payment channels in the next network upgrade
> no mining centralization
nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s would LOVE monero if it wasn't a separate coin but was made by the hands of Satoshi himself
Pitiful.
I challenge you to pay this lightning invoice and trace your payment to its destination:
lnbc10104970p1p5rpd26pp5hdcxfsd4esv23xlkhnrfvgz3h8xnakjfktp24tqvsg9ygn5uet4qdqqcqzdyxqyz5zzsp5pk7t9n6z83zdl65ls3kfc6vptnml7n8an4kgluyzv553tya26wps9qxpqysgqh6qwhk7rag2tuufwy2y69ws67jmqcwpvr6hd9wcu4jm4hzgzumvq680g5m2s4f0f66lzvydpmxpt79derf4w9phs2eazhr67p8ctrzgpjtc2nk
Tell me what pubkey controls the funds and what balance it holds.
I will pay a monero address of your choice and I will yell you what pubkey controls the funds and what balance it holds.
Deal? If you think monero's privacy holds a candle to LN let's put it to the test.
Same story at coindance
Knotsiz control 10% of the bitcoin network according to bitnodes
Time to repurpose some old slogans
Inscriptions Out!
Bitcoin for Bitcoiners!
The Jpegs are Our Misfortune!
2015 Ethereum: Code is law
2016 Ethereum: Code is more like guidelines
I am so conservative their name triggers me
When libertarian web apps?
Cypherpunks run nodes
Coinpools don't need a consensus change. They are usable right now, if a good coder writes the code. (My proof of concept code is only "usable" in a very loose sense of the term, because I am not a good coder.)
Someone on twitter asked, "What downsides does it have compared to Ark?"
Here is my answer.
There are three things people have objected to:
(1) Inbound payments require inbound capacity, similar to Lightning. I believe @bergealex4 thinks this is reason enough to dismiss my software as completely unusable, and even ridiculous to compare it with Ark. But I don't think so.
Inbound capacity mostly sucks on Lightning because it causes payment failures when you don't have enough. But coinpool payments are asynchronous: if you don't have enough inbound capacity, the payment doesn't fail, it just stays pending until you get more. And your wallet can even automatically get more inbound capacity for you by just registering to be in another coinpool and deducting a liquidity fee from the inbound payment itself.
I think that compares favorably with Ark; its similar to receiving an out-of-round payment in Ark and then waiting for the next round to settle it. Both require waiting and paying a fee. But a difference is, an out-of-round Ark payment can still be spent even before you settle it, but a pending coinpool payment cannot.
So Ark has an advantage on this particular metric: Ark out-of-round payments are more useful than pending payments on Coinpool because you can start using out-of-round payments immediately. But I don't think this one advantage outweighs the other advantages I spoke of in favor of my software.
(2) You have to do an interactive group signing ceremony to get into a coinpool with my software, and if you use this method to increase your inbound capacity, you have to do it whenever you need more inbound capacity too. But I think this is an "advantage" compared to Ark because Ark *also* requires an interactive group signing ceremony during onboarding, and it *additionally* requires one whenever you want to settle an out-of-round payment *and* whenever your vtxos are about to expire. The more signing ceremonies required, the worse the software, imo, and while my software requires it sometimes, I think Ark requires it far more.
(3) In the failure case where the server completely disappears, my software is less efficient than Ark in terms of the number of transactions required to get everyone out. In Ark, their tree-method scales quadratically, meaning if you have 100 users, they can all get out in no more than 10 transactions apiece, and most of these transactions are "shared" by several users, so some users (the poorest) might get lucky and only have to broadcast 1 transaction.
Whereas my exit ladder method only scales linearly: each user must broadcast 4 transactions, so with 100 users, that's 400 transactions in total. However, I think there's another side to this story: in an Ark with 100 people, each user must store all of the 10 txs necessary to exit, and be prepared to broadcast and pay for them, because there is no guarantee that anyone "higher" than them in the tree will do it for them. So even poor people might have to broadcast 10 txs to exit Ark, and must be prepared to do so, even though they will *probably* only have to pay for a few of them.
Whereas in my software each user always has to broadcast precisely 4 or 5 transactions to exit unilaterally, unless you put more than 100 people in the same pool. I think it's worth a lot to have an exact, static number of txs to thunk about, and I'm not sure if that's better or worse than Ark.
So in summary, the disadvantages of Coinpool are:
- in Coinpool, if you dont have enough inbound capacity, you can't start spending your pending payments immediately, whereas the equivalent type of payment in Ark is *always* spendable immediately
- you might have to do an interactive signing ceremony for a thing tha Ark doesn't need one for (inbound capacity), but I still think Coinpool wins on this front by eliminating them in most of the other cases where Ark needs them
- Ark has more efficient unilateral exits "in total," and, in many cases (e.g. for most poor users), "per user" as well, but Coinpool requires an exact, small number of exit transactions per user, and I'm not sure which model is better on this metric.
And in terms of Coinpool advantages:
- The server does not need to regularly create and fund new multisigs because Coinpool multisigs last indefinitely, they mostly don't expire unless everyone leaves that pool. This means fewer costs for the server, and thus fewer costs for users.
- Users do not need to do a signing ceremony to settle their inbound payments, except in the case where they have insufficient inbound capacity. Since these ceremonies, in Ark *and* Coinpool, require users to wait for them to happen and then pay a fee, it is good to reduce them, which Coinpool does.
- Coinpool users do not need to "refresh" their coins on a regular basis. This costs money and time for the same reasons given in the point above, it's another signing ceremony and it's annoying. By almost entirely eliminating it, Coinpool is superior in this respect.
I don't think we will discuss monero at all
I like Ark, but it has three characteristics that I don't like:
1. The server regularly creates and funds new ark multisigs, and must pass the cost of doing so onto users
2. Users regularly "refresh" their coins by exiting an expiring ark multisig and boarding into a new one, and they bear the cost of doing so plus the annoyance of needing to get online regularly to do it in an interactive group signing session
3. Users pay one another in "out of round" payments that are free to initiate but cost money to settle, which encourages users to keep the funds unsettled, which effectively transforms Ark into a statechain model
The two teams (x.com/ArkLabsHQ and x.com/2ndbtc) have spent a lot of time and money making these characteristics work and optimizing their software so that those pain points are as painless as possible. But my coinpool software eliminates all of those characteristics, so if they switched now, they'd have to throw away a lot of their work.
Still, I recommend they do. I think my model is better and I hope they take a closer look.
I doubt it, I suspect we will discuss recent bitcoin privacy tech improvements and cutting edge research in that space without comparing LN privacy to monero. I don't plan to bring up monero and I doubt Seth does either, though I suppose it could happen if Wirdum or Spacebear want to provoke a bit of drama.
One of the proposals ("Erk") reduces the need for users to regularly come online to refresh their vtxos, which is a laudable goal. The other proposal ("Hark") simplifies how Erk's atomic swaps work at the expense of reintroducing "regular refreshes." I like Erk better.
Erk doesn't "technically" reduce the need for regular refreshes, it just outsources them to the server. If a user stays offline for 5 years, the server can just constantly refresh their vtxos for them, deducting a pre-agreed fee each time. I like that. And if the server "doesn't" do the refreshes, the user can either hire a watchtower to rescue their funds or broadcasting their exit txs for them, or they can do it themselves.
In my coinpool implementation, I also tried to improve upon Ark by eliminating the need for regular refreshes. My method was to replace the absolute timelock on user funds with a relative timelock whose 2-week countdown only starts when the admin broadcasts a "notification tx." During the 2 weeks, the user can broadcast his exits txs (or a watchtower can do it for him), but when the time is up, the admin gets the user's funds, just like in Ark.
My hope is that the admin wouldn't need to ever use the notification tx. Instead, I think users should pay a monthly fee to the admin to stay in the coinpool if they are benefiting from it, and my model allows the admin to kick any user(s) out of the coinpool e.g. if they stop paying their bills, so if a user disappears, that seems like a more appropriate remedy in most cases than broadcasting the notification tx, which basically threatens to take everyone's money unless they exit within the next two weeks.
I only think the latter option makes sense if all the "responsive" users have left (e.g. maybe the admin decided not to do it anymore and asked everyone to leave) and there are still multiple unresponsive users, and the admin is getting impatient. Rather than kick each unresponsive user out individually, it's more efficient to give them a final 2-week notice (by broadcasting the notification tx) and then take their money if they still don't come back. Of course, like with Ark, these users can hire a watchtower to rescue them if this scenario arises, or they can broadcast their exit txs themselves.
I'm not sure which method I like better, Erk or my own. But mine has this advantage: it works right now, with no soft fork, and achieves a similar goal, namely, users do not need to regularly come online to refresh their coins. They do need to pay their monthly bill, but since my coinpool supports async payments and uses relative timelocks, I can ease this by repurposing the absolute timelock field: the user can make a series of "bill payment" txs to the admin that are each "absolutely" timelocked til a different month in the future arrives, and send them all to the admin right at the beginning. Now the admin can claim each payment one by one as the months tick by, and the user doesn't need to come online for that because payments in my coinpool are asynchronous. This also incentivizes the admin to keep that user around; until his bill payment txs are all used up, he's a paying customer.
I think the Ark teams should give my coinpool model a closer look. I think it accomplishes without a soft fork a lot of the things they want to accomplish "with" one.
My definition of an L2 is this:
- you can send btc to it
- you can do some transactions on it without touching btc's blockchain
- you can withdraw your btc from it
- no person or group can censor your withdrawal without controlling 51% of btc hashrate
If they bring a frivolous lawsuit I suppose Ocean will win the case and win some money
Per binance, we hit 109,588 in mid January of this year 
Also, payjoins technically *are* coinjoins so we are discussing coinjoins anyway
Correct. I don't think it's a put-down on coinjoins, it's just a way to highlight other tools too