yep, i mentioned that



strangely, Taproot re-defines what "the script" actually means. In your example, which is the script? The whole tree, paying to any pubkey of every californian, or the script that gets redeemed on the blockchain? A taproot script is potentially an entire litter of Schrodingers scripts, only one of which becomes an observable cat on the blockchain o_O

the answer is, of course, that there is a "script tree" and an executed "script leaf", where the script tree is never publicly known.

The only downside is that you must leave the channel reserve in a channel.


Workflow is as follows:

1. Open 2 Lightning nodes; one with outgoing liquidity and the other with an equal amount of incoming liquidity (minus the 1% reserve + ln fees)
2. Send everything from the node with 100% outgoing to the 100% incoming node

You just did an ad-hoc Coinswap over lightning.

n.b. I think eltoo channels remove the reserve requirement, so that would mean you could perform this without the "loose end" constituted by the reserve balance left over on one node


However, a 'real' coinswap is better. It's probably less traceable (at least than HTLC based Coinswap-over-LN) and the LN technnique might spark a trend of people closing both channels and both nodes once they finish the swap (which is a little anti-social, payment channels are intended to be long lived).

this case is overstated


it's only going to be the 'base case'/'cooperative case' that will become indistinguishable, e.g. Lightning channel opening transactions and cooperatively closed channels, because Schnorr "additivity" (which is not a real word ) makes such transactions appear the same as a regular [1 (or more) inputs -> 2 outputs] tx, because there is only 1 aggregated signature (because additive signatures, despite 2 parties signing the tx). Currently, spending outputs from that kind of transaction reveals it to be a 2 of 2 multisig that had alternate script paths, not so with the same tx script using Taproot/schnorr.

But, uncooperative closes are still distinguishable from regular [1+ in -> 2 out] transactions, because of the atypical script they use will (necessarily) be revealed if they are broadcast/confirmed in a block. I know, uncooperative channel closures are not common, but they will still sometimes happen when using Taproot/schnorr based channels/contracts.

And so, all other atypical scripts will still be distinguishable from regular transactions too. It's just nice that the construction of many contracts involve using the [1+ in -> 2 out] regular pattern as their base case.

I agreed (in the end) that the "good faith gesture" opening move of deploying Speedy Trial was the best option to start off BIP340-2 activation.

I'm kind of taking the same view on luke's alternative activation client; he thinks giving miners any mechanism to delay activation is a mistake. I'm sympathetic, but disagree.

Not going to get into a discussion about this though, as we've already got people attempting to create hype around it.

nice

bitcoincore.org Bittorrent link for 0.21.1: magnet:?xt=urn:btih:205b0189271c50a02fe966491e15737a01f94e08

the most dramatic thing to happen since the last time you brought this up was... you trying to stoke tensions, just now. which was less dramatic (and more boring), because it's the umpteenth time you've tried

in brief, "discrete log contracts" is the new shiny. well, it's actually old-ish as Bitcoin concepts go (Tadge Dryja described the initial idea more than 200,000 blocks ago! ), but I don't think anyone was working on an implementation until... 2019? I'm guessing. There's still work to do before it's usable, but there seems to be quite a bit of activity on the project.

not only those things, but also:  transactions on off-chain networks would continue as if nothing had happened. Looking at the logs on my c-lightning node, it seems that's exactly what's been happening throughout this "shutdown"

there's also the PGP "Web of Trust"

it's like an ID system, but where you control the system.


Basically, you prove that you are really yourself by having alot of other people vouching for you with their PGP ID (they do so cryptographicaly, by signing a statement saying how they know you, e.g. "he's my brother", "went to school together 98-08", "work colleague" etc)

It's more powerful than typical ID systems, because in typical ID systems there is only 1 entity who is vouching for who the person really is (the company or government that issues the IDs). Especially with government issued ID's, this is a problem: corrupt employees can issue fake ID's to friends or paying customers. Examples of such corruption are many. In the Web of Trust model, that's not so easy to do successfully, or convincingly (and anyone using their real-world ID to sign fake ID's will leave behind an evidence trail).

Mostly only computer programmers use PGP Web of Trust right now.

No, that's really been resolved with the Speedy Trial initiative (it was one of the reasons to take that route).

(note: I'm not entering into a conversation with you, please don't reply)

there's always some angle to be had for a committed axe-grinder, but no-one's made any credible claims that taproot/schnorr will be detrimental to Bitcoin.

the DLC project will eventually attract that type of use (referencing oracles to make contracts that respond to events external to bitcoin's blockchain; enables all possible types of betting, in essence). But to do this kind of thing, improving the scalability is a prerequisite; taproot and signature aggregation are (for me) only half of that picture. Really, it would all work much better off-chain, and I think that would mean conducting the transactions in channel factories (which needs another soft-fork: a no-input bitcoin script opcode, or some other way to create Bitcoin transactions that don't commit to the inputs)

---

great news IMO, I hope the miners are equally enthusiastic if not, fork 'em

try settting listenonion=0 in bitcoin.conf, then deleting the onion_private_key file from your .bitcoin config directory (then shutdown/restart bitcoind)

yeah, that's what I meant

I kinda agree that some people will use these LN-wallet phone apps that take care of all the balancing stuff for them, at least initially. I expect a significant slice of people will end up setting up their own node, because it's cheaper cutting out middlemen, and because people are more motivated to learn tech that involves managing their own money (it's the Bitcoin ethos, after all)

even if Phoenix/Breez etc begin to use these new cheaper dual-funded channels (which is also a lighter burden on the blockchain & utxo set...), they will still presumably charge a small premium to do so. Some people won't want to pay that.

it's a cheap way to get incoming capacity, it doesn't make a difference if you already have other channels.

And it means the in/out ratio can be balanced right from the outset, instead of paying even more sending fees to rebalance unbalanced channels

i.e. two channels, one 100% inbound and one 100% outbound could be opened instead as 1 on-chain opening tx in just one channel, with 50% inbound and 50% outbound



no it doesn't.

It's called "Lightning Network" because... it's a network. It doesn't make any difference who you have in/out bound channel capacity from/to, you can use it to pay or receive from anybody on the network (aggregate capacity needs to be enough sats for the payment, obviously)

only 1 party provides funds to open the channel.

There's a new feature in c-lightning 0.10.0 that allows both parties to provide some funds to open a new channel (called "dual-funding"), which would be quite useful to create more balanced liquidity across the channels of the lightning network. Not sure if this is a part of the Lightning specification, or whether it's a c-lightning feature.

er, because the politicians want all the BTC for themselves, and want to use lies and (threats of) violence to do so?


and because (unlike the above-mentioned Indian computer programmers), the politicians don't have any skills to sell outside of India, they already sold every last little thing they could get their thieving little hands on.


Stand tall Indians, the government are scared of how powerful Indian bitcoiners are

New proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018590.html

(based on this bitcoin ML post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html)


Essentially:

• 3 months BIP 9 activation (no activation lock-in when it ends), starting April 14th 2021 (so soon), ending July 14th
• 3 month delay till the actual soft-fork after activation (October 1st 2021 would be the date of the soft-fork, regardless of when it is activated)

So miners/pools get a chance to demonstrate their goodwill, but don't have to update their nodes in a big rush (potentially pushed on them by their rivals' signalling for the soft-fork)

In the meantime, the discussion about what to do if the opportunity is missed can continue, including anyone preparing unilateral activation movements fashioned on BIPs 148 and 91.


Sounds ok to me. FWIW, people in the #taproot-activation channel seemed to like it too.


Rules: No trolls, no trolling

No, not quite

It's making LOT changeable that luke is regretting. He thinks it should be set in the code, and not changeable unless you edit the code (which is not easy for everybody)



someone (Matt Corallo, a Bitcoin dev) suggested that. But his proposal was just to activate the fork the simplest way: Bitcoin 0.21.1 would just start enforcing the fork after August 1st 2022. No signals, no percentages. Either you're running the new code or you're not.

That's not such a terrible compromise, all discussion will be pretty simple afterwords, chain forking risks are minimized, at the expense of a long wait for using Taproot.