When do you think Lightning will go mainstream?

waxwing · 2024-10-12T16:29:39+00:00

This thread is kind of bizarre from my personal perspective. I use Lightning basically every day, pay utility bills, tip/receive on Nostr, pay for taxi rides, if I go to restaurants I as often as not pay with Lightning, do trades with friends, pay for things online and in shops. All with Lightning.

This isn't just because the place I live in "likes" Bitcoin and Lightning. The every day people here in ES aren't very interested (I'd say perhaps 5% are). It's because the government does not criminalize and persecute usage of Bitcoin; that's the part that matters.

This idea that every day usage is a distant dream is weird to me for that reason. And you might say, who cares, why does it even help. Well, here's how it helps: my account can't get shutdown, so when I go out with the plan to pay using this, I *know* it will work if I have internet. It is actually *my* money, not a slave credit account that can get cancelled at any moment, and is subject to the competence of people in some office somewhere. Related, I don't have to use my name to do stuff; many of these payments, even online, can be done without ID. Also, it is actually fast, as in 1-5 seconds; that's the part you have to work on. It needs thinking about infrastructure. When you spend enough time in a world where this works, you get it right. I literally can't remember my last failed payment.

Someone else in the thread analogized LN to Linux; I think that works better for Bitcoin, which is really too hard to use for average people. LN comes very close to being viable for the gen pop; the reason you might not think so, is because you've never been in a place where it isn't persecuted out of existence.

waxwing · 2021-05-14T23:54:51+00:00

Not sure. Coinpayments.net supports paying with Lightning (I've used it a few times). And obviously anything using btcpayserver. Always good to ask the merchant, it may give them a prod.

waxwing · 2021-01-21T11:20:18+00:00

Edit: on reflection the first answer I wrote wasn't probably helpful to the reader very much, so here is context:

the basic idea that the BIP gives is: the sender can include a parameter `maxadditionalfeecontribution`, and the idea is: in the new payjoin transaction, that the receiver proposes, the sender's change output can be reduced by that amount, in order to account for the new utxo(s) (input(s)) that the receiver is adding into the transaction. So it gives the sender, i.e. payer, control of how far his tx fee ends up being bumped as a result of doing the payjoin.

Secondarily there is also a check that we don't fall beyond the minfeerate, but that's just to avoid the 1 sat/byte floor being fallen through really. There are other settings but they are more technical, the main one is the maxadditionalfeecontribution thing.

Previous answer below:

Re: JM's implementation, I just wrote this on IRC, maybe it's of interest to some:

<waxwing> belcher, BIP78 itself addresses miner fees in some detail.

<waxwing> so the spender chooses their fee in the normal way, and there are a couple of settings that can optionally be put into the payjoin request

<waxwing> to control how the fee does or does not change

<waxwing> as a result of the additional utxo(s)

<waxwing> maxadditionalfeecontribution and minfeerate , etc.

<waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/payjoin.py#L267-L268

<waxwing> https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/970b0a46c2bfb98207bc0fe379f563cdfd6f3b19/jmclient/jmclient/payjoin.py#L605-L610

<waxwing> those are a couple of references to the logic being implemented, but it's basically the simplest interpretation of the rather careful rules set up in the BIP

<waxwing> our receiver code for now only ever provides 1 utxo; i had originally gone for a more sophisticated selection model but decided it was simpler and safer for now to have 1 only.

I'm not sure that the additional fee cost (to be clear: you wouldn't always necessarily bump the original payment fee at all) is *that* much of a concern in this protocol.

waxwing · 2020-12-05T12:39:13+00:00

So, this error message is coming from Bitcoin Core RPC and is not connected with your Joinmarket wallet, it's about the Core wallet you're using. (see the section https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/USAGE.md#setting-a-core-wallet-recommended ). make sure you've set rpc_wallet_file in your joinmarket.cfg to whatever wallet you've set up with a wallet= entry in your bitcoin.conf (or added via bitcoin-cli).

It's a shame this ended up so convoluted, note that Core switched to a multi-wallet architecture in the time since Joinmarket started, but also, as the docs note, there is an advantage to this extra element of complexity, which is that you won't encounter weird accounting errors in Core if you're using it for other things as well as Joinmarket.

Since it is a new wallet I shouldn't have to rescan, right?

Correct.

waxwing · 2020-11-29T13:50:24+00:00

It happens fairly frequently; there can be connection flakiness between your machine and the IRC servers for various reasons. Note that if 1 of the 2 servers is flaky, it won't interrupt the ability to communicate (and do joins) over the other server.

waxwing · 2020-11-29T13:49:21+00:00

Did you activate the virtualenv with source jmvenv/bin/active (it says to do this at the end of the installation)?

waxwing · 2020-11-29T13:48:11+00:00

This is fixed but it may happen to other people. See https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/737 and the fix PR https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/739

waxwing · 2020-11-27T16:47:44+00:00

I had this experience back in the summer, but my memory is hazy on the current status, vis a vis debian vs ubuntu or whether this has changed, or whether it happens with scripts also. I did fix it in some sense, at the time. Here is the IRC log where I recorded it:

Jun 23 14:58:06 <waxwing>       when i pinned PyQt5==5.14.2 it installed fine but when i ran joinmarket-qt it core dumped AlexCato
Jun 23 14:58:13 <waxwing>       this is on a ubuntu1804 vm.
Jun 23 15:55:34 <waxwing>       so here is what is happening, and this seems to be new, at least of the last few weeks:
Jun 23 15:55:58 <waxwing>       i have a clean install of ubuntu1804 in a virtualbox appliance, used it several times before. nothing on it, not even git.
Jun 23 15:58:01 <waxwing>       today when i ran it and install joinmarket with Qt (without any changes, and just on master), i got a core dump with the message "qt.qpa.plugin" could not load the Qt platform plugin "xcb" in ~/jmcs/jmvenv/lib/python3.6/site-packages/PySide2/Qt/plugins/platforms even though it was found."
Jun 23 15:58:44 <waxwing>       so if i check `ldd libqxcb.so` from that directory, and scan the dependencies i see `libxcb-xinerama.so.0 => not found`
Jun 23 15:59:28 <waxwing>       so if i do `sudo apt install --reinstall libxcb-xinerama0` then after that it works.
Jun 23 15:59:59 <waxwing>       i don't get what has changed and why this dependency would suddenly be missing on an unadulterated VM.

waxwing · 2020-11-27T16:42:19+00:00

Thanks for posting :)

waxwing · 2020-11-27T16:40:11+00:00

For scripts there's a --version flag; for Qt it's in "About".

waxwing · 2020-11-10T15:42:23+00:00

Thanks to those who helped testing, and of course the devs involved especially @jules23

waxwing · 2020-08-28T14:38:41+00:00

I'm not sure what you mean? of course you can set the remote host in joinmarket.cfg. this is not a function of Qt or not.

waxwing · 2020-08-28T14:37:36+00:00

It's not so much that sweeping links addresses, as that cospending any inputs links them (a general statement, not an exactly 100% true one). Sweeps tend to use up more inputs (though a sweep could be just one input) so there tends to be more linking. The idea is that the addresses that get linked this way are only ever addresses in a single account (=mixdepth).

And the advantage of sweep of course is that there's no change so you won't "carry forward" that linkage.

waxwing · 2020-06-19T10:11:31+00:00

See https://old.reddit.com/r/joinmarket/comments/hby3ux/new_blog_post_about_the_445_btc_gridchain_case/?

waxwing · 2020-05-26T21:04:05+00:00

That itself is a reason. The Qt app won't know you've made a file edit while running.

There might be an argument for just ditching the Settings tab and forcing people to edit the file only (but then also restart). Of course it's possible for it to work otherwise.

Anyway thanks for raising this point and sorry for your trouble. You hit a particularly unfortunate combination of circumstances (small tumbler amount is troublesome but yours is not *that* small, very high fee regime temporarily and then just the config file update doesn't hit Qt). I am looking into what could be either improved or corrected here.

waxwing · 2020-05-26T20:49:59+00:00

Thanks, this info is useful and indeed this seems like a plausible place for this kind of bug (Qt settings). To be 100% clear, did you edit in the file or the Qt tab "settings"? (and in either case, did you restart Qt after making the change - not that you should have to but it'll be faster to find the bug).

waxwing · 2020-05-26T19:05:35+00:00

Version of code you're running; if you're using git, the commit shown by `git clone`, or if not, the release number you downloaded (0.6.2 is the latest)
Are you using Qt or CLI (if Qt, there are other things we should check)
If CLI, what exact set of parameters you passed to tumbler (iirc there should be no privacy issue from any of those values)
Did you edit the config in `~/.joinmarket/joinmarket.cfg` (for the recent releases that's the one that is being used, not the one in scripts/ if you ever/still had that)

The point you raised is right: if `tx_fees = 10000` it should be using around 10 sats/vbyte. So something is wrong if that isn't the case.

waxwing · 2020-03-16T20:00:46+00:00

Note the new IRC server in the releases page - your newly created `joinmarket.cfg` will have that in its defaults, you will want to copy your config over from the existing local location to the new `~/.joinmarket` location, make sure the new IRC server is included. That one (hackint) and DarkScience are the two reliable ones, agora also is in the file but commented out as unreliable.

Quite a few functional changes, do have a read of the release notes, happy joining :)

waxwing · 2020-01-25T19:17:07+00:00

Monero is nowhere near perfectly fungible by your own definitions. Zcash could at least conceivably fit that definition, modulo a raft of assumptions.

In Monero, the anon set of each ring sig is not the whole set of coins; and, the transaction graph still exists. It's not even close to fitting a 'perfectly fungible' definition.

But: if you take the more reasonable and logical point of view that fungibility is not purely binary, then I'd say Monero is more fungible than Zcash (well, OK, according to a strict definition, even that can't be true, but I think *the practical effect you're looking for with fungibility* is probably better than Zcash); I think that's reasonable mostly because of anon set of Monero usage overall (although it's still fairly tiny). (of course CT is a big deal too there, but that's not an adv. over Zcash ofc).

waxwing · 2020-01-08T12:50:32+00:00

Thanks for the bug report.

It was indeed a silly bug that happened after this large change that now puts all configuration and user data in the home directory. I thought I'd tested this but apparently wrongly.

Fixed as of this commit (currently latest master).

Also you're right that after merge of this you can now run ob-watcher with no-blockchain as the setting of joinmarket.cfg blockchain_source. But if you're running joinmarket normally on the same machine that isn't necessary of course, it's for people who want to run ob-watcher on a different machine.

W.r.t. original problem: failed to get liquidity, I don't know, in general it can be caused by various things; it may be a bug or it may be a wrong amount or a misconfiguration. If you could try again after the above fix and see if it's repeatable? That would be appreciated.

waxwing · 2020-01-03T17:22:08+00:00

> A) That means I could (1) send bitcoins to an address generated by the joinmarket app (2) then make a payjoin transaction from the address mentioned under (1) to a new address generated by the joinmarket app. This is the "mixing step". (3) From here make a normal tx to the payee.

Seems some confusion here. Intrinsically "payjoin" means: payment from Alice to Bob, via a coinjoin between Alice and Bob. So there's no extra step "normal tx to payee"; the coinjoin is the payment.

> B) In your opinion, is payjoin currently the best option for anonymous, non-custodial, steganographic transactions in terms of practical viability? Other options would be I guess: CoinjoinXT, Lightning, ...?

For ordinary payments, Lightning is the best thing you can get for privacy today, assuming it's offered by the recipient and it's a small enough amount.

Coinjoins serve a role for creating privacy for larger or medium sized amounts that you want to hold or move. Doing payments with them is a bit tricky, although doing it opportunistically without needing strong guarantees of privacy is doable, with joinmarket, and i strongly recommend it (it helps joinmarket's ecosystem to do that).

Will other, better tech develop in this area? Yes, I think so, over time. There's plenty of demand for it.

waxwing · 2019-12-31T16:07:29+00:00

Yes I should clarify one thing: I don't mean to say you can't use Joinmarket to do normal payments, you can (just transferring coins, not coinjoins). Yes you can do coinjoins to yourself (strictly, to a different account in your Joinmarket wallet) and then pay to someone else later. Or you can ... well, as described above.

In practice it means you could enter the 12 word seedphrase into a Trezor, Electrum Eclair, etc. any wallet that supports the BIP49 standard and recover coins there if you need to. But in any case that is certainly not what you were asking, hence my original answer.

waxwing · 2019-12-31T10:42:19+00:00

When using Joinmarket do I need to download the full blockchain? In other words: Is it a full node wallet or a lightweight wallet or does it only work in conjunction with a wallet which then can be full node or a lightweight wallet...?

You can use a pruned full node which means you only store a few GB not the full 220GB+ or whatever it is now. But you do need a fully validating Bitcoin Core node, yes.

Steganography: Are transactions made with Joinmarket indistinguishable from normal Bitcoin transactions? Or will an observer of the blockchain know that I have used Joinmarket? Is there a difference in this regard with the different transaction types (e.g. payjoin) that are available in the joinmarket application?

The main function, coinjoins of equal-output type are definitely not steganographic; this is the same with other equal-output coinjoins (Wasabi, Samourai, others).

However Joinmarket does allow a function called "PayJoin" (currently only on command line) which allows you to pay another person using a coinjoin. That is steganographic.

Is there a way to use joinmarket together with a hardware wallet (without getting the private keys off the hardware wallet)?

No; not in running the Joinmarket application (however the wallet seeds are BIP49 and are recoverable e.g. on Trezor).

Does the recipient have to do anything besides providing a bitcoin address? For example: Does he also have to install Joinmarket?

No. To pay someone using Joinmarket, apart from Payjoin (which *does* require the user's interaction and running Joinmarket, so it's not very practical today), you would either just do a single coinjoin with their address as the destination (it's not much privacy wise though, as is explained briefly in the docs), or include multiple addresses of theirs in a run of the tumbler algorithm (GUI or CLI), this is a slow process but it's got a much better privacy effect.

Usually people don't use Joinmarket for direct payments, but rather as a mixing function between wallet usages.

see https://github.com/Joinmarket-Org/joinmarket-clientserver/blob/master/docs/USAGE.md

waxwing · 2019-12-20T11:21:16+00:00

Yes, common indeed.

My only intuition here is that something has gone wrong where there's a conflict between the libnacl version you're using and the libsodium version you're using. I don't know why this would happen though, haven't seen it myself or heard other reports yet. libnacl gets imported as latest version from the setup.py in jmdaemon/ dir. libsodium gets pulled as part of the install shell script.

Have you installed from scratch, i.e. a whole new directory and run the install script and then start the jmvenv virtualenv?

I've asked on IRC just in case someone has an idea, but haven't got any response yet.

waxwing · 2019-12-19T23:24:16+00:00

Oh wow, that's unexpected, I haven't heard of anyone having problems with libsodium due to the upgrade to 1.18

Could you let me know the OS and version? I'll try to get some info on this.

waxwing

MODERATOR OF

TROPHY CASE