pull down to refresh
@aftermath
stacking since: #163372longest cowboy streak: 16
67 sats \ 1 reply \ @aftermath OP 16 Apr \ parent \ on: Hydrus v0.2.0 is out! lightning
I'm not familiar with the OS, but as long as you can download and run a Linux binary you should be able to use it without issues.
If they have restrictions on what can be executed or run as a service, I may need to apply to get an app for Hydrus.
Mine doesn't really reflect the work because I've been working on the latest project without publishing any commits until recently, but I'm starting to pick up pace :)
134 sats \ 0 replies \ @aftermath 13 Apr \ parent \ on: Liquidity squeezing from your node lightning
Well, you could theoretically set positive inbound fees in that channel to disincentivize routing (in LND, enabling the experimental configuration accept-positive-inbound-fees).
However, this seems to be causing some issues because peers that do not support inbound fees may be unaware of the added cost and will therefore fail to route through that channel without ever noticing why.
Another thing you could do is use the HtlcInterceptor RPC to intercept the HTLC and let it through only if you are happy with the fees you will earn from the outgoing channel.
Can you add also the valve system, as described by Rene Pickhardt ?
Interesting posts!
AcceptLND is just a gate for new incoming channels, it doesn't modify any policies or take any actions of that kind.
However, I have another project called Hydrus that does something similar. I didn't implement the algorithm Rene proposes, but I took a more simplistic approach, which is updating the max HTLC value to 80% the local balance to avoid routing failures and to leave some room until the next update.
I would say higher fees is a better protection against drainage though, the other node could still drain all your liquidity with smaller payments.
Yes to both.
You can reject or accept channels based on any conditions you want (in LND you can do this with the ChannelAcceptor RPC).
On the fees side, you could theoretically mirror the fees of any node of the network in almost real-time. This can be achieved by subscribing to the channel graph events (in LND, using the SubscribeChannelGraph RPC) and updating your local channels fees based on the updates you see.
To give you another example of dynamic fees, in Hydrus, fee rates are set based on the forwards amount ratio. If the amount of incoming forwards is higher than the outgoing, the fee rate is decreased to incentivize routing. If it is the other way around, the fee rate is increased to disincentivize routing.
I think they are taking advantage of the low on-chain fees to relocate their liquidity and arbitrage with routing fees. They could be probing the victim's channels and detecting that there is liquidity available to do so.
They might have so much of demand from some of their peers that it is profitable to open a new channel and use it purely to rebalance others.
However, I do not think this attack makes economical sense in a different fee environment or to medium-sized nodes, as you would need to open a channel with the almost the same liquidity as the entire node.
As far as the fees goes, they are probably setting a high fee rate to avoid having the liquidity locked in their side of the new channel. Given that the victim node is considerably smaller, this is quite possible.
To overcome this, I think the best approach is to set initial fee rate to something like 500ppm and then gradually lower it as you see the channel is not routing, this will make the operation longer or more expensive, and will give you some sats to relocate your liquidity after the "attack".
Another option, as the post says, is to block incoming channels based on some policies. I have created acceptlnd specifically for this, there are multiple parameters that you can use to decide whether you are happy with the new channel or not.
I don't think it is bad to have a defined set of requirements for accepting new peers, your liquidity and time are limited, so you may not have it with certain peers that you know or consider they won't perform as well based on their metrics.
- What are the biggest challenges you have faced while maintaining your Lightning nodes?
- What characteristics do you look for when selecting nodes to open new channels? Do you open channels at all or do you balance liquidity via swaps?
- Your nodes were accessible through the Tor network in the past, but not anymore, what has led you to change this?
You also mentioned centrality vs channel fees in determining which nodes to open channels to. But I thought channel fees were not public info?
Routing policies are public, otherwise your node wouldn't be able to construct a route. You get all the network nodes routing policies using the
lncli describegraph command, it will display all edges and two fields node1_policy and node2_policy indicating how much fees they charge, HTLC ranges, etc.As long as the other tools do not open/close channels I think it should be fine.
Hydrus in particular will base its decisions based on the current node and network states, and will try to be between the configured number of channels. It currently does not make changes to routing policies, although I might change that to facilitate things even more.
So the worst case scenario is that the other automation tool is opening/closing channels to keep the node in a certain state different than Hydrus. That would cause a conflict and both agents would keep making changes one after the other.
How often does it decide to open/close channels and how does it decide when is a good time? I assume it looks at on-chain fees, but what's the decision rule?
That is up to the user to decide, you can run Hydrus daily, once a week, once a month, etc. This is typically configured in the systemd service timer or in a cronjob.
Once executed, the agent gathers information from the local node to decide whether it should open new channels (num_channels < max_channels) or potentially close some (num_channels > min_channels). So in some scenarios it may not do any changes.
Apart from that, there's a configuration called
agent.channel_manager.max_sat_vb which is the maximum number of satoshis per virtual byte that you are willing to spend. If transaction fee is estimated to be higher than that value, no changes will be made.So yeah, the agent can be scheduled to execute at anytime but it may do nothing depending on certain factors.
Hi @npub1q67p49masrcjf__d7qaq6mwh0q, sorry for the delayed response.
Indeed, the coinos node it's hard to reach because there aren't many routes to it and the ones that do have liquidity are charging high fees (it seems that there's way more demand for sending sats to it than from it), sometimes making the swap uneconomical.
I think opening a private channel to it is probably the best option, it will require receiving/balancing to that channel to send the funds and coinos will know that you are the one sending the funds, but other than that there's no drawbacks.
An alternative could be opening a public channel, helping others to reach the node and charging a fee for it. The caveat with this last option is that you depend on the coinos node to send funds through your channel to refill the liquidity. May be profitable if the fees are chosen correctly.
I agree it would be useful to have that field, I'll add it in the next release.
Running it with systemd is pretty straightforward, simply download the binary or compile it yourself (give it execution permissions) and create the following service with
sudo nano /etc/systemd/system/acceptlnd.service[Unit]
Description=AcceptLND
Wants=network.target
Wants=lnd.service
[Service]
WorkingDirectory=/home/<user>
Type=simple
ExecStart=/home/<user>/acceptlnd
User=<user>
Restart=always
RestartSec=60
KillMode=process
[Install]
WantedBy=multi-user.target
And then
sudo systemctl enable acceptlnd and sudo systemctl start acceptlnd.Doing a guide for Minibolt and Raspibolt is a great idea, I'll open an issue on their repositories to see if they are ok with it.
Thanks!
Yes,
alias and color would be trivial to add because they are in the GetNodeInfo RPC method response. I didn't add them because I thought they had no value and could be easily changed, do you think they should be added?Regarding
min_node_age, that kind of information is not provided by the LND RPC but can be obtained by checking that the node's oldest channel is at least 103,680 blocks old (not complex neither).There is a worth mentioning workaround that requires no changes and uses the
node.channels.block_height field. For example:policies:
-
request:
channel_capacity:
min: 3_000_000
node:
hybrid: true
channels:
block_height:
operation: range
min: 103_680 # 720 days * 144 blocks per day
However, that would be true only if the oldest and newest channels were created 103,680 blocks from each other.
100 sats \ 0 replies \ @aftermath OP 16 Nov 2023 freebie \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
Thank you for your questions, perhaps I wasn't clear enough in the second part of the post but I will try to explain all your doubts.
it seems like the winner is chosen by the server completely at random. How is that verifiable?
When I mentioned provably fair random numbers I was referring to the Battles implementation, which is a completely different service.
As you said, the winning numbers are generated using an RNG (
/dev/random in linux).However, I did create an issue https://github.com/aftermath2/btry/issues/20 which changes the way in which lotteries duration are measured.
Switching to block-based lotteries would allow the numbers to be generated using the last block hash as an entropy source and that way the users would be able to verify that the numbers are fair.
Even though the source code is honest, the actual deployed server might be colluding to award prizes to specific player(s).
You are right, users have to trust BTRY that the deployed source-code is the one in the repository, unfortunately, I'm not sure it's possible to guarantee that the binary is not tampered.
I did include the current commit at the bottom of the page to make it harder for the server to cheat.
the server could abstain from distributing prizes at all, keeping all the money paid into a lottery for itself. How can players tell if a prize was paid correctly, or paid at all?
Prizes withdrawals are not listed because I wanted to avoid showcasing any information that could be considered sensitive.
However, you could listen to the SSE stream at
{url}/api/events?stream=events to the messages of type "payments" and receive updates every time a user makes a withdraw. All you will be able to see is the payment_id and status though.It would make more sense to me if the winner was selected by hashing some undisputable but unpredictable future data, like the hash of a yet-to-be-mined block
I'm not sure I understood this completely. If the data is unpredictable how can users verify it? A hash of a yet-to-be-mined block can be whatever the server wants to, so we wouldn't solve the problem.
As I mentioned before, we could use the latest block hash as a source of entropy because picking the numbers the server wants in that short period of time would be nearly impossible.
With BitVM, you might even be able to set up a contract to punish the server if someone can prove the wrong winner was chosen. With a well-designed n-of-n multisig contract, the server could commit money to revealing a winner before a given date (or else be punished by players).
That's a great idea! I haven't digged into BitVM much yet, but I would love to learn more about it and to implement something like that.
Happy to chat anytime if you find these ideas interesting. My github is here if you wanna tag me in any issues.
I'll tag you in the ones I mentioned above. I'm really interested in having technical conversations and discussing about any Bitcoin topic or even contributing to any projects you may have. I'm open to chatting if you want to!
101 sats \ 0 replies \ @aftermath OP 15 Nov 2023 \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
Thanks! I pronounce it "bee-try" because it sounds better to me, but initially the name was "Bittery" so I guess both ways are valid.
500 sats \ 1 reply \ @aftermath OP 15 Nov 2023 \ parent \ on: BTRY - Lottery powered by Bitcoin bitcoin
I opted to use Telegram because there are many Bitcoin communities there, it can be proxied over tor and was super simple to integrate.
But I agree with you and will take into consideration the options you suggested. I have created the following issue to fix this https://github.com/aftermath2/btry/issues/23.
Thank you for the feedback!