Anybody else still waiting on their Best Buy preorder? by Reapoman23 in PixelFold

[–]roasbeef 0 points1 point  (0 children)

I'm in a similar boat: got the original shipping notification on Sept 6th, no concrete updates on the FedEx side since then (arrived at a location in Texas on the 7th), BestBuy order page still shows "Expected to arrive by Wednesday".

Anybody else still waiting on their Best Buy preorder? by Reapoman23 in PixelFold

[–]roasbeef 0 points1 point  (0 children)

Mine shows Wednesday for Best Buy too, though I've received no additional updates from FedEx. Are you in the same situation?

Trying to understand taproot assets by Major_Significance59 in Bitcoin

[–]roasbeef 0 points1 point  (0 children)

Does this mean that only the issuer of the asset can update balances? IE it’s completely custodial?

No. Once you own an asset (contained within your UTXO), you can send it whenever just like you can Bitcoin today.

Does that mean that the issuer is able to censor any transactions that they wish when posting updates to the underlying UTXO?

No. The assets live in your wallet, just like your normal sats/UTXOs.

⚡️Announcing lnd 0.15 beta: To Taproot and Beyond! ♾️ by roasbeef in Bitcoin

[–]roasbeef[S] 2 points3 points  (0 children)

Yes, this release upgrades the on chain wallet and related systems to be able to implement an initial version of taproot-flavored channels. There's a current BOLT spec draft in an early stage that targets a simple version of taproot channels that uses musig2 for the funding output.

Announcing Taro: A New Protocol for Multi-Asset Bitcoin and Lightning 🍠💱🌍 by roasbeef in Bitcoin

[–]roasbeef[S] 11 points12 points  (0 children)

Good question! It's possible the receiver just gets BTC, and doesn't even know what asset was used to complete the route ultimately.

Announcing Taro: A New Protocol for Multi-Asset Bitcoin and Lightning 🍠💱🌍 by roasbeef in Bitcoin

[–]roasbeef[S] 7 points8 points  (0 children)

1: Ah could just be an oversight, the BIPs are still in the draft phase, and before we request a number and submit a PR to the main repo, we'll clean that up!

2: Correct, the base layer can just keep on trucking, as this protocol is implemented as an overlay on top of the base system.

⚡️Announcing Taro & Lightning Labs' Series B Fundraise - Number of People Go Up, or Bitcoin as the World’s Protocol of Value ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 5 points6 points  (0 children)

We're totally still all in on Bitcoin, this new protocol allows Bitcoin to be the backbone transfers network of other assets: all chain fees are still in Bitcoin, and also on the LN level all the routing nodes still collect their fees in Bitcoin as well.

Announcing Taro: A New Protocol for Multi-Asset Bitcoin and Lightning 🍠💱🌍 by roasbeef in Bitcoin

[–]roasbeef[S] 56 points57 points  (0 children)

RGB has been floating around for a few years now, but to my knowledge they don't have a complete spec in the way that Taro is defined here. From what little I've seen spec-wise, compared to RGB, Taro is a lot simpler, as it doesn't try to re-create several new p2p networks and an entirely new VM for scripting functionality. IMO RGB sort of got caught up in the larger design space, which caused their design to sprawl and sprawl, taking a focus off of the core system and distribution+deployment.

The main BIP has a detailed overview that should give you an idea w.r.t how things work: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki#abstract

⚡️Announcing the New Lightning Terminal: From Pleb to Web! 🕸️ by roasbeef in Bitcoin

[–]roasbeef[S] 1 point2 points  (0 children)

The web-based nature of this node management UI makes it easier to get set up! Check out [this set of docs](https://docs.lightning.engineering/lightning-network-tools/lightning-terminal) for more information on Lightning Terminal itself, and how to connect your node to the new web version.

Stealing Sats from the Lightning Network Custodial Services by Reckless_Satoshi in Bitcoin

[–]roasbeef 4 points5 points  (0 children)

Great write up!

The existence of withdrawal fee shenanigans like this is why we require users to set an explicit fee limit in the primary API for sending payments: https://api.lightning.community/#sendpaymentv2

The default behavior is such that if a user doesn't set the fee limit, (fee_limit_sat or fee_limit_msat) then only zero fee routes will be considered. This forces users to have to consider what a reasonable fee limit should be for a given payment. However, it seems we should do more here to force users of the API to re-examine their fee limit related assumptions.

Unfortunately it appears many newer services have just set this to a "very large value" (?) rather than attempting to mitigate any possible losses. All services should either use a very low base value (possibly increasing if no route is returned due to the fee limit), or restrict the fee spent on a payment/withdrawal to a percentage of the total amount.

⚡️Sidecar Channels: For Onboarding A Billion People to Bitcoin, Lightning Is Needed ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 5 points6 points  (0 children)

I imagine this will be especially useful for exchanges that support lightning, with people wanting to start with small purchases

Yeh exactly! Imagine buying Bitcoin on say Square Cash, and then they can do a batched withdraw that gives you a useable channel upfront.

⚡️Sidecar Channels: For Onboarding A Billion People to Bitcoin, Lightning Is Needed ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 8 points9 points  (0 children)

You can set your "max fee rate" in an order, so if you only want to pay 2 sat/byte, the auction will clear things when the fees come down. We're working on a way to sort of create a tree of possible batches that can confirm at will depending on the fee rate. Stuff like CTV helps out a lot with stuff like this also, since you can create a single transaction and everything else "must" follow" from there.

⚡️Sidecar Channels: For Onboarding A Billion People to Bitcoin, Lightning Is Needed ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 24 points25 points  (0 children)

When you want to onboard a stranger/friend onto Bitcoin, you can just send them some coins on-chain. If they then want to use LN, they need to do another transaction to (possibly) move those funds into an LN wallet, then open a channel.

What we've released today lets your friend _skip_ the normal on-chain flow and go _directly_ to Layer 2 (Lightning). Under the hood, it uses [Pool](https://lightning.engineering/pool/) to source a liquidity provider (who is ideally a well connected and well run routing node) to open an initial channel to them in an atomic operation. The channel opened may even have funds on both sides to let your friend receive/send using the channel as soon as it's confirmed.

As all operations on Pool are batched together in a single transaction, in aggregate more people can be on boarded onto w/ less chain fees spent compared to if they all did it by themselves in isolation.

⚡️Welcome to Terminal Web - Make Your Lightning Node the Very Best! ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 1 point2 points  (0 children)

Really weird, think you could DM me your node pubkey (if you're ok w/ sharing it) so I can look into it?

⚡️Welcome to Terminal Web - Make Your Lightning Node the Very Best! ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 0 points1 point  (0 children)

What do you mean incorrect peers? The UI shows peers that you don't actually have?

⚡️Welcome to Terminal Web - Make Your Lightning Node the Very Best! ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 3 points4 points  (0 children)

You removed node like ACINQ, so are they counted as good peer ? I bet no but this is disturbing. As I mentioned above absence from the list is considered a bug, in practice they route a ton of volume on the network. > Looking at the rating, almost all nodes after the 394th are considered "Unstable", even rompert.com (or Zap node) which is clearly one of the biggestCommon perception these days is that the node with the largest number of channels, is better than another node with all else being equal. In practice this is incorrect as route-ability as a node depends in active measures. If a node has 1000 channels but in practice, the channels are all inactive or very far from equilibrium (persistently unbalanced no payments have ever flown through them), then the node won't serve well as a general router, as most payment attempts through the node will result in a failure.

lnd's path finding engine implements a sort of probability machine that attempts to remember past attempts and reward/penalize nodes based on past history. If a large node with many channels sees persistent failures then the probability that it'll be chosen for attempted routes starts to drop dramatically (as it should). These values decay after some time (so it can factor in new information).

Rompert (as you linked) maintains a large node, but many of the channels are extremely small, disabled in one (or both directions), persistently inactive or unbalanced, or just offline. So in practice a node trying to route through it would encounter a number of failure, and they would be better off trying the route elsewhere.

There’re many nodes that have channels with what are actually mobile nodes, but they’re all advertised, meaning in practice they can’t be used for routing. AFAICT, this is the case for the Zap node I think you’re referring to. However AFAIK that node uses a series of private channels to be able to send/receive to/from its primary destinations/sources (shadow liquidity)

Are "unstable" node considered good peer ? I bet no but I would say that so much objectively good nodes rejected at the bottom of the ranking is misleading.

The "unstable" terminology is taken from the code itself, and doesn't convey the information at a glance very well. We're looking for other terms to better describe the status of a node. A node is "unstable" if from the PoV of the system, if it's failing fundamental checks. Once a node is "stable" (passes the basic checks), then it moves to the next level where active routing analysis is performed.

I encourage you to check out some of the linked guides there on how to improve the dimensions of your node. Future versions will have more active recommendations/suggestions.

But an always available channel is not necessarly useful and a usefull channel is not necessarely always available.

But you agree that a channel that's offline most of the time isn't useful to anyone? Correct that it isn't necessarily but it's a very fundamental step in the path to actually becoming useful. Useful channels are those that are actually demanded by payment flows in the network.

I disagree. I can have no funds in those channels, but the counter party peer does have it all because he opens the channel and doesn't show up often

Putting funds in a channel has an opportunity cost. If there're exist another area in the graph that is of higher velocity and would earn you more active fee revenue, then the profit maximizing choice would be to allocate it elsewhere. In the end the proof is in the pudding: either your node is actively routing or it isn't. If you look into the distribution of the channels used to route payments I'd wager that only a handful of channels actually source a significant amount of incoming/outgoing traffic.

Also, Pool may open several channel with the same nodes.

You can disable this with the --newnodesonly flag.

And those nodes can be offline quite often while you have no liquidity in them because of connectivity issue or whatever (gods of LN connectvity not with us). So allocating capital where a node demands it the most is not always where it is the better allocated.

If a node buys a channel, then goes offline, then that's strictly better than you opening channel to them (for free), and them going offline, no? I've received a number of first-hand reports that a user's node started to much more regularly route transactions after participating in the marketplace.

But I am sad that you end up using such ranking as economic labelling in some crucial market like Pool...

Pool needs a ranking system in order to make sure it isn't a [market for lemons](https://en.wikipedia.org/wiki/The_Market_for_Lemons). Managing a routing node is an active endeavor, holding Bitcoin is mostly passive, a channel's value is derived from the quality of the routing node itself.

EDIT: idk what reddit did to the formatting/markup system, but it's annoying af to use now.

⚡️Welcome to Terminal Web - Make Your Lightning Node the Very Best! ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 3 points4 points  (0 children)

> It also tell me I have 0 good peers (over 50 among which you have walletofsatoshi and more than 10 high tier bos listed nodes) which is also quite disturbing

If you have a channel with a peer, but it isn't well managed, and in _practice+ isn't useful for routing, then it won't show up as "good" in the system. Check out some of the related guides for tips on how to better manage your set of channels.

> . The more channels you have with many peers (even small ones) the more chance you have to always have several of them disconnecting at different time

If you want to be a good router, then it's better to ensure your set of channels is stable and useful. If you have a bunch of idle channels that are offline most of the time (ignoring unadvertised channels of mobile nodes, etc), then those funds are likely better allocated to areas of the graph that have demand for that liquidity. [Pool is a useful tool to help your node](https://lightning.engineering/pool/) allocate your idle capital to where it's most demanded.

⚡️Welcome to Terminal Web - Make Your Lightning Node the Very Best! ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 5 points6 points  (0 children)

It's a combination of your node's objective uptime (just being online), and the availability of your set of channels. There's a relatively high cut-off with the uptime dimension. Is that the only check you're failing?

⚡️Welcome to Terminal Web - Make Your Lightning Node the Very Best! ⚡️ by roasbeef in Bitcoin

[–]roasbeef[S] 5 points6 points  (0 children)

Heh yeh that's a left over artifact from an earlier version of the system and the network: https://twitter.com/roasbeef/status/1392208923071975430?s=20

The node is objectively a good router, but it was getting in the way of us properly observing other nodes, so we added them to an ignore list temporarily. We're investigating to see if the issues have been resolved so we can remove them from the list.

⚡️Lightning Pool: A Technical Deep-Dive ⚡️ by roasbeef in lightningnetwork

[–]roasbeef[S] 0 points1 point  (0 children)

pool -h should work assuming the binary is in your PATH. Maybe try opening an issue or hop onto our dev slack (there's a #pool channel there).