@supertestnet
stacking since: #96
0 sats \ 0 replies \ @supertestnet 27 Oct \ on: Issue Using Phoenixd on Ubuntu AskSN
Make sure to run those commands in a separate terminal
Some terminals let you right click the terminal and select New Window or New Tab
Then enter the commands there
If you see an error message, let me know
Jules Verne
Three of his novels contain incredible insights into the future trajectory of mechanical science:
-
20,000 Leagues Under the Sea
- Mostly-accurately describes how submarines would work
- Including how they expel air to sink
- And how they decompress air to rise
- And how they refill their compressed air tanks while surfaced
- And how they use giant rotating "fans" to move forward and backward
- Mostly-accurately describes the flora and fauna of sea animals in various parts of the world
- Bonus: great characters, motivations, and plot
-
Robur the Conqueror
- Accurately describes three methods for controlled flight before the invention of airplanes
- Accurately describes the principles of operation of gas-filled aircraft like airships and hot-air balloons (but this is not surprising because they were a regular part of scientific experiments in Verne's time)
- Accurately describes how rotational motion induces lift (if the motor is placed horizontally) and can be used to design helicopters
- Accurately describes how an airfoil induces lift when air is passed over it and can be used to design airplanes
-
From the Earth to the Moon
- Accurately predicts that American space exploration would begin with launch facilities in Florida and Texas
- Accurately explains why, namely, because Earth's rotation can assist with the launch and this rotation is relatively faster in the south
- Accurately describes the quantity of propellant needed to get a spacecraft to leave earth's pull
- Accurately describes the effects of gravity reduction as the ship leaves earth's pull
It wasn't just that Jules Verne imagined the future. He figured out how his mental inventions could work in reality, with mechanical descriptions and sometimes precise instrumentation. In many cases he described potential future equipment and technology in great detail, including mathematical formulae for how much lift could be generated by a submarine or an airfoil or an explosion, including environmental factors as influences on his calculations, and the stuff he described often came to fruition.
Basically, he was doing "hard science fiction" over a hundred years before it was cool. Or anyway he tried. He was also not always super careful, and drew about as many "wrong" inferences as right ones. But when he was right, his precision astounds me.
There is a seven step procedure to run the backend and connect it to the frontend, so I will go over them here
First step
The first step is something I have to say after the second step
Second step
The second step is to install LNDK according to the instructions on this page: https://github.com/lndk-org/lndk
But notice that the page tells you that first you "need a LND node running at least LND v0.18.0...with the peersrpc, signerrpc, and walletrpc sub-servers enabled"
First step again
So that's the real first step: compile LND with those sub-servers enabled by following the guide they link to
Note on the first two steps
Don't run LND and LNDK as two different linux users like a "good" programmer would do. To control LNDK I opted not to use its api, because I was running out of time, so instead I use the
exec command to spin up a terminal inside nodejs and interact with it via stdin and stdout. And for one specific LND command ("trackpayment") the LND API wouldn't work for me (I was probably using it wrong) so I use exec for that too. Which means you must run the server, LND, and LNDK all on the same linux user -- if you separate them, the terminal won't have the lndk-cli and lncli commands available, so the program will fail.Third step
To run the server, first clone the github and run
npm init -y.Fourth step
Then install the dependencies:
npm i crypto noble-secp256k1 ws browserify-cipher requestAlso, modify the first few lines of the server.js file so that they contain your LND node's invoice macaroon, admin macaroon (both in hexadecimal format), your LND Rest api endpoint (this is usually https://127.0.0.1:8080), and you can ignore the other four fields -- I intended to use them to let users modify their fee settings and a few other things, but I don't actually use them anywhere in the code, the fees are just hard coded to 10 sats.
Fifth step
Then run
node server.jsIt should spit out a nostr public key and then wait for incoming messages
We opted to use nostr for communication between the frontend and the backend so that anyone can run this without needing to expose ports
We intended to make it so that people running the backend would announce themselves on nostr, as well as a fee structure (e.g. do they charge a flat fee for forwarding bolt11 payments to a bolt12? A percentage fee? How much?) and the frontend would listen for those announcements and display them to the user. But we ran out of time so we hard coded the nostr pubkey of my backend into the frontend, which is why it stopped working when I turned off my laptop.
Sixth step
To make sure your service is working, edit the index.html file in my github repo and find the line `welder = "<nostr_pubkey>" and change it to yours. Then open up the index.html file, open up its browser console, enter a bolt12 invoice into the form, and hit enter. You should see a message pop up in your nodejs terminal and you should see the frontend and backend interact. Watch the browser console -- eventually you should see a bolt11 invoice in there. (I don't "pop it up" on the page, it only appears in the console.)
Note about the sixth step
As @justin_shocknet has always warned, I have found that the onion messaging aspect of bolt12 is very unreliable. About 2/3 of the time, the server will use the lightning network's onion messaging transport layer to reach out to whatever node issued the bolt12 and something goes wrong: the message does not reach the destination or the reply does not reach my node.
Consequently, most of the time, the service does not work. I find that if, after hitting the "Submit" button on the form, you don't see a bolt11 in your browser console after about 10 seconds, try hitting submit again; and occasionally try restarting all four services: LND, LNDK, and the nodejs file, and the web browser (after entering in your "new" nostr pubkey -- the nodejs service doesn't save it so a new pubkey is created every time you restart the nodejs service).
Eventually it should work and you should see a bolt11 invoice in your browser console.
Seventh step
Pay the bolt11 invoice and you should see a corresponding payment show up in your bolt12-supporting wallet.
Note about the seventh step
I've only tested this with phoenix wallet so it might not work with other wallets. Also, my frontend hard-codes an invoice of 15 sats, and since the server charges a 10 sat flat fee, the bolt11 will be for 25 sats. So don't be surprised when your phoenixd only receives 15 sats even though you paid 25.
This was the hackathon project Alex Lewin and I submitted for btc++ last week
We made an atomic swap service similar to lnproxy.org, except for bolt12-to-bolt11 instead of bolt11-to-bolt11
After the hackathon I turned off my server (it was running on my laptop) which is why the frontend doesn't do anything
The frontend is hosted on github pages so it doesn't need my help to start running, but it can't do anything without my backend (anyone can run the backend though
The server code is here: https://github.com/supertestnet/weld
The frontend code is here: https://github.com/alexlwn123/lightning-welder)
No, they're different
Interesting comment. When two things compete in the same category ("store of value"), they are either equal, or one is worse. I say stablecoins are worse in this category. You say "No." I am surprised.
They're a better short term value for people who need to store fiat.
I do not admit the existence of people who "need" to store fiat. If they exist, blockchains and lightning channels are a worse place to do that than other systems like sql databases
a lot of people have fiat-denominated obligations that they need to be able to reliably pay
They do not need to create these fiat-denominated obligations, and once entered, they usually have escape clauses
The volatility of BTC relative to their fiat currencies is expensive to deal with
True, sometimes. But its volatility trend is helpful over time. Patience fixes this.
something like USDT is not a bad first step.
If they don't trust bitcoin yet why would they trust USDT? It has more trust assumptions, not less
A good first step toward trusting bitcoin is trying it
I hope someone builds this product because I love people to have options
Unchained had a product like this, but they deposited the fiat directly into your bank account, and they recently shut it down
Hodlhodl still has a product like this, but they give you stablecoins instead of "normal" money, and they don't accept US-based customers
Making a version that works in the USA would give more people access, which is good
That said, I would not use this
I don't want to give someone 2 of my bitcoins to get a fiat card worth 1 of them
How am I supposed to get my bitcoins back? Normally in schemes like this you get your bitcoins back by paying back the fiat over time, plus interest. If bitcoin's price falls too much, they can keep your 2 bitcoins. If you show up on the OFAC list, they can keep your 2 bitcoins. If they get hacked, bye bye bitcoins. If they turn malicious, bye bye bitcoins. If you miss a payment, bye bye bitcoins. If you lose your job, or get sick for a while, that's a real risk.
I would rather find merchants who do accept bitcoin and pay them directly, without a fiat middleman
And don't underestimate Grandma. Your grandma lived during the Vietnam War. You think she doesn't know about hardships? You think she can't handle learning how to type a command on a terminal? She's stronger and more capable than you think.
The chances of BTC dropping 75% in one year are much higher. Get real.
I don't think so. The dollar's value is propped up by people who are not trustworthy. It could easily drop 75% in a year. It's not a matter of chance; it's a matter of who makes the decisions.
Trust assumption is better with bitcoin vs. stablecoins
Agreed
in many cases yes: BTC has worse UX and worse fees vs. stablecoins.
If the cases are many, surely you can name one
Volatility clauses vs. what, the dollar? AKA unit of account
Good point
when bitcoin is down 75%, sadly, patience doesn't heal mortgage payments and grocery bills
also true of fiat currency
maybe use the better money since both have the risk of dropping by 75%
not true, wildly different problems, trust assumptions, UX, and fees
Thank you for naming three specific problems, trust assumptions, UX, and fees. I assume you are saying bitcoin is worse than stablecoins and stablechannels in these three categories. Is that correct? And are you willing to defend that statement against my criticisms? I think bitcoin has better trust assumptions, better UX, and better fees than stablecoins and stablechannels. If you think it's worse, why?
Unit of account is more than prices in stores. For example contracts and financial assets. Tech hasn't solved that.
Seems like volatility clauses fix that
Partially true, but not all of a merchant's expenses come directly from manufacturers. Merchants could accept bitcoin and use part of it to pay for expenses on things that aren't from manufacturers. There are travel websites that accept bitcoin like cheapair and travala, and things like uber and amazon are easy to use bitcoin for thanks to btc-accepting gift card sites like bitrefill and the bitcoin company.
For manufacturer stuff, the merchant could get a quote from the manufacturer, sell enough bitcoin to pay that bill, and then pay it with the fiat -- all while petitioning them to start accepting bitcoin too. And seek out manufacturers that do accept bitcoin. I would like to start assembling a list of such. I saw one advertising at btc++ in Berlin last week, but unfortunately I forgot their name.
putting your transaction on the timechain instead of doing it on superscalar defeats the point
it means superscalar didn't save you any time or money for that transaction
is this the summary of Duplex Micro Payment Channels && Time out Tress?
Yes
Does this render ARK useless?
I don't think so, no. I think its decrementing timelock mechanism would make it cheaper than Ark if your peers were reliably online, but I am not enthusiastic about that assumption. I think it mostly wouldn't work due to someone being offline.
How does boltz interact with this?
I don't know
also important IIUC, SuperScalar doesn't require any softfork
Yes, I should have mentioned that as another example of how it is like Ark
the relay owners can find comfort in knowing that...this content is likely still accessible
how would that comfort them? I thought they wanted to delete that content
Do new OP codes need to be activated to allow this to work?
No, it can work right now if someone builds it. And Zman wrote that he composed this in part because he thinks bitcoin has ossified and no more soft forks will happen (with caveats for "small" fixes):
We must [scale bitcoin] without any blockchain consensus changes... The Bitcoin blockchain has ossified in practice. Due to the scheduled halvening every 4 years causing a sudden increase in Bitcoin price, leading to a sudden increase in interest in Bitcoin, large batches of new users join the set of entities with an interest in Bitcoin consensus. As the previous batch becomes convinced of some consensus change, the new batch enters Bitcoin, which must itself be convinced of the same consensus change. If a consensus change cannot achieve practical consensus within a time shorter than a halvening period, it will not ever happen... OP_CTV was largely finalized in 2020, and has not achieved consensus in 2024, thus will never achieve consensus due to exceeding the halvening period; SIGHASH_NOINPUT has even worse prognosis... source
I don't think bitcoin satisfies any of these qualities, not according to the definitions given in the article.
Consistency
If we are discussing the mempool, it is definitely not consistent. You can quickly ascertain this experimentally by sending a transaction only to peer 1 and then immediately requesting a copy of the mempool from from peer 1 and peer 2. What will happen? They will very probably give you back different copies of the mempool. This is not consistent per the article's definition: "In a consistent system, once a client writes a value to any server and gets a response, it expects to get that value (or a fresher value) back from any server it reads from."
But of course, the mempool isn't technically "part of" bitcoin's consensus rules -- the blockchain is. But the same thing applies there. If you find a block in bitcoin and send it to peer 1, then immediately request a copy of the latest block from peer 2, peer 2 may not know about it yet. So you "[wrote] a value to [one] server...[got] a response...[and got an older value]...back from [another] server." This violates their definition of consistent, so bitcoin, per their definitions, is not an example of a consistent system.
Availability
This one I'm less sure of. Your bitcoin client can craft a "write" request intended to be added to the blockchain (i.e. you can craft a transaction) and send it to a peer, but pay a fee of 0. The peer will then probably drop the request. If your client then makes a "read" request, the peer will likely reply with either the same chain it had before or a different one, but still without the user's transaction in it. So I think, in bitcoin, write requests are sometimes ignored. I think this violates their definition of availability: "The server is not allowed to ignore the client's requests."
I'm not sure though because I think bitcoin might satisfy their definition of "not ignoring requests" as long as the peer sends back an error message. If he sends back an error message, he didn't "ignore" your message, he replied. But even there, I don't think peers in bitcoin have to return error messages. I haven't checked the codebase, but I doubt you would ban a peer for a single ignored message. I think you would ban them if they ignored "multiple" requests, but not for a single one. So I'm not entirely sure. You might say "but if they ignore a message that means the peer crashed, and the article says it doesn't count as an ignored message if it was due to a crash." And that might be true -- I'm not sure -- but Bitcoin also doesn't exactly have a "spec" so if a node "chose" to literally ignore 1% of messages I don't think this would count as a node "crashing." It would just be a slightly jerk-ish node, and I don't think there's anything in bitcoin that forbids that.
Partition tolerance
This is defined as "the network will be allowed to lose arbitrarily many messages sent from one node to another."
This is what I was talking about just a moment ago: I really don't think any bitcoin client bans peers just for dropping one message. But I do suspect they ban peers who drop "arbitrarily many" messages -- e.g. all of them. So per this definition I actually don't think bitcoin qualifies as partition tolerant. I think you will ban peers if they drop a certain number of messages, and that seems inconsistent with the article's definition of a partition tolerant system, which is supposed to permit nodes to lose "arbitrarily many messages" without issue. But again, I'm not entirely sure -- "the network" is fine even if you ban one peer, since you have seven others. So I just don't know for this one, but I don't think bitcoin satisfies it.