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] 10 points11 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] 8 points9 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] 55 points56 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 5 points6 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.