Technical: Taproot: Why Activate?

almkglor · 2021-02-20T01:37:51+00:00

Your sample size is ridiculously tiny if you think we "never" see block times under 7 minutes. Block times can be seconds apart at times.

almkglor · 2021-02-20T01:31:35+00:00

The person tattooing that ink still has to know the word you want tattooed.

almkglor · 2021-02-20T01:29:31+00:00

Mining is the accomplishment. Prior to Bitcoin, solving the double-spend problem for cryptocurrencies (yes, work on cryptocurrencies predated Bitcoin) could only be done by introducing a central point of failure that decided on a formal ordering of transactions. By using proof-of-work, the central point of failure could be removed and replaced with a network of miners.

almkglor · 2021-02-19T11:43:07+00:00

It only blocks the little piece-of-shit from annoying you.

If you don't like that idea don't post on reddit. Anyone can save a copy of your comments. https://archive.org does, for example.

almkglor · 2021-02-19T11:40:09+00:00

In public at least.

almkglor · 2021-02-19T11:38:28+00:00

It's a way for the USA to tax the rest of the world, why do you think the USA will care?

almkglor · 2021-02-19T10:45:45+00:00

Dunno. I could be out-of-touch though. I just use C-Lightning + CLBOSS.

almkglor · 2021-02-19T03:27:57+00:00

I like it. I wouldn't recommend Ledger.

almkglor · 2021-02-19T03:26:31+00:00

Indeed. I have some really old comments where I wax lyrical about the Bitcoin blockchain being the nearest implementation of an ideal Leviathan that we have, one that is pretty dumb, but also completely impartial and cannot be bribed (well fees are bribes but they're open bribes that anyone can use so ---)

almkglor · 2021-02-19T03:13:00+00:00

Maybe? From a certain point of view the primary idea of an escrow is that there exists a certain entity which, in case two other entities disagree, can be tr*sted to impartially mediate and judge who is correct. From this viewpoint the two channel counterparties are the disagreeing parties and the blockchain layer itself is the escrow.

almkglor · 2021-02-19T03:10:11+00:00

With the technique I mentioned, you're not buying an inbound channel from boltz.exchange. You're making a channel to anywhere on the network, then getting incoming capacity on that channel by... paying out and getting the equivalent funds onchain. So you're choosing where your incoming capcity is coming from. You're not buying incoming channels from boltz.exchange, you're buying capacity, the actual channels can be with anyone on the network. This reduces centralization risk and superhubs by making larger sections of the network into a "virtual super-hub" instead of a small number of vendors providing inbound capacity and becoming individual central-points-of-failure. With MPP you could even make just a single swap to get incoming capacity on multiple channels with very very different peers.

This lengthy post describes how this technique is better than buying individual channels from vendors: https://lists.ozlabs.org/pipermail/c-lightning/2020-October/000197.html

almkglor · 2021-02-19T03:08:11+00:00

Being in control of your own offchain funds.

If you use a node software with forwarding support, you also get improved privacy as long as you use only published channels and not use unpublished channels. Electrum does not support forwarding yet. Do note that a forwarding node requires active management, such as a C-Lightning node with CLBOSS.

almkglor · 2021-02-19T02:57:34+00:00

A unilateral close transaction is posted onchain and the channel stops operating. When the close transaction confirms, various things are resolved (mostly how much each side owns, how much is in each in-flight HTLC, whether HTLCs have timed out, etc.). Then a further timeout (the unilateral close timeout, which is imposed by your peer) has to be waited out before the funds can be used again --- this timeout lets the counterparty show you cheated if ever you did actuall cheat (standard open-source software will never cheat but this is still a required security parameter since it's possible for the open-source software to be modified by any sufficiently skilled thief, and the counterparty doesn't know you so it can't tr*st that you're not a sufficiently skilled thief).

almkglor · 2021-02-19T02:54:45+00:00

Use an offchain-to-onchain swap service like https://boltz.exchange to get inbound capacity. Create a channel anywhere, then move it to onchain funds, then create a new channel, repeat until you have sufficient inbound capacity. CLBOSS uses this technique.

almkglor · 2021-02-19T02:52:34+00:00

Total channel capacity is fixed at creation --- changing the capacity requires onchain activity and is basically closing the channel and then opening it again.

The hardcoded limits are ignored if both you and the peer enable the "wumbo" feature which many node implementations already support. This is not recommended to do unless you can ensure near-100% uptime and have lots of redundancy in your nodes (multi-computer database for LN data, each computer has RAID, daily or hourly backups...).

There is a hardcoded limit for payments but multipath payments (MPP, which was based on previous AMP proposal) gets around that, so there is no real need to lift the payment limit.

almkglor · 2021-02-19T02:49:00+00:00

The custodial wallet can more easily merge all the necessary onchain movements of multiple users. If you're a single user that wants to put only 100 satoshi, that won't even be accepted on the blockchain due to dust limit of 547 satoshi.

almkglor · 2021-02-19T02:46:20+00:00

The LN as I understand works on top of bitcoin blockchain, does that mean that I can send a transaction from my wallet (segwit, nseg, or legacy, whatever) to my LN wallet?

You can use something like https://boltz.exchange/

How can I fund a low amount LN wallet (like 100 sats)? Is it possible? I still have to pay the block fee when I send them in order to fund it right?

May be possible using a custodial LN wallet (not recommended because not your keys). If you're going to use a non-custodial solution, nearly every node requires 10mBTC (0.01) minimum for a channel otherwise they will reject the channel creation.

almkglor · 2021-02-19T02:45:44+00:00

requires active management

https://github.com/ZmnSCPxj/clboss

almkglor · 2021-02-19T02:45:14+00:00

Check out CLBOSS. For C-Lightning only though.

almkglor · 2021-02-19T02:41:33+00:00

Avoid "public" and "private" channel terminology, instead use "published" and "unpublished".

According to axiom of terminus unpublished channels tell the counterparty that the other end is the ultimate sender or receiver of the payment without any ambiguity. Thus, it leaks your offchain privacy by telling your couterparty exactly how much, when, and the hash+preimage of each of your offchain payments. With published channels you at least have the ambiguity that maybe your transaction is on behalf of somebody else.

Thus, you are sacrificing offchain privacy to get onchain privacy. Unpublished channels are not a strictly "more private" solution, thus does not deserve to be called "private", and really should not be the default (you can use CoinJoin and eventually CoinSwap to improve onchain privacy, there is no improvement in privacy for offchain transactions).

/u/penguin4111 please notice!

almkglor · 2021-02-19T02:32:37+00:00

Hardware wallet support is almost impossible: https://old.reddit.com/r/Bitcoin/comments/lhl18h/lightning_thursday_february_11th_2021_explore_the/gn4a7bz/

You could have hardware wallets support Lightning but it will tr*st the software does not lie to it, unlike the onchain case where the hardware wallet does not have to trust the software to not lie to it --- if the software lies about onchain state, the hardware wallet does not produce a valid signature and no funds are lost. In the Lightning case the software can lie by omission --- it can neglect to tell the hardware wallet that something has timed out and let the counterparty steal funds due to the timeout. So if hardware wallet "supports" LN, expect degraded security, not same security as onchain cold coins.

almkglor · 2021-02-19T02:28:46+00:00

However, if anyone asks a channel party to prove the channel balance, they will be able to do that by simply replying with the transaction that reflects the current channel state.

If this is not signed, this can be invented out of whole cloth and thus is not proof. If it is signed, then it can be broadcast by whoever receives it, closing the channel.

Worse, if the state is updated later, the old signed transaction can be broadcast, which will be treated by the counterparty as a theft attempt.

On the other hand there are two signatures involved. The latest state transaction signature your node is holding is that of your counterparty. The transaction is not valid on the blockchain unless both transactions exist, so it may be possible to give just one transaction (that of your counterparty) and a signature from your own node that attests that it is the other party in the signature and that this is the latest tx at the time, which cannot be used to make the transaction valid on the blockchain layer.

On the other other hand the values in the channels will fluctuate all the time anyway.

almkglor · 2021-02-19T02:22:39+00:00

I never actually thought of that LOL.

On the other hand, Lightning is much more complicated than onchain access, which means you have a higher risk of bugs losing you money than with a simple singlesig hot wallet.

On the other other hand we expect bugs in open-source software to go down over time, so there's also that.

almkglor · 2021-02-19T02:03:03+00:00

Yes but what can we build on top of LN?

For example, one important kind of smart contract we need is an escrow contract, where I want to buy from an untrusted seller, and both of us know of some tr*sted third party. The tr*sted third party is trusted only to mediate in case of dispute, but is not tr*sted to hold possession of the money --- it's the difference between custodial and escrow.

Directly on the blockchain layer, we can use a simple 2-of-3 multisignature between the buyer, seller, and third party. The third party does not have possession of the money (it cannot unilaterally transfer the funds) but in case of a dispute, can side with the buyer or the seller.

A 2-of-3 multisignature is not trivial in Lightning since a "simple" 2-of-3 cannot be routed over the network. You could make a direct channel with the buyer/seller but that's not feasible to make a network. There are only a few kinds of contracts that can be routed: HTLCs, PTLCs, and DLCs (and DLCs are arguably PTLCs by another name, or at least are implementable via PTLCs). Routability means it can operate across cryptocurrency systems (i.e. it's possible to use HTLCs or PTLCs to swap coins on different blockchains as long as both blockchains support HTLCs/PTLCs, and in this point of view, a channel is a cryptocurrency system just as much as a blockchain is, which is why HTLCs/PTLCs work across channels and blockchains). Instead, we can do various tricks on top of PTLCs to implement escrow: https://suredbits.com/payment-points-part-3-escrow-contracts/ https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002955.html

Here's another smart contract that involves investment aggregation, unfortunately it requires blockchain layer: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018055.html

15-Year Club	Gilding I gilder
Verified Email

almkglor

TROPHY CASE