pull down to refresh
110 sats \ 10 replies \ @anon 13 May \ parent \ on: Lyn Alden On Scaling bitcoin
Nope. Don't touch L1 :
Perpetually KYC’d Coins Using Evil Covenants
https://delvingbitcoin.org/t/perpetually-kycd-coins-using-evil-covenants/556
This is FUD that I've already dealt with
"Perpetually KYC'd coins using Multi-sig" its simpler, cheaper and exists in Bitcoin today.
Not only that, but custodians can just say you own Bitcoin in their account and leave it at that. "No withdrawl policy" We have shown that our resilience against such a policy typically results in the exchange allowing withdraws (no one buys from them if they don't)
In order to even have a CTV address, you need to generate one on your device, the same way you have to generate a taproot address.
This is the kind of FUD the educational push for LNHance will need to deal with for the next 5 years, but I'm strapped in for it because the alternative is to give up and that's not my style.
reply
Also, the author of the article (for the previous link) answers your reply about multisig (please see below).
"There are significant differences.
First, the covenant model requires only a single signature every two weeks. That’s 26 signatures per year. In contrast, the cosigner model requires to co-sign every single transaction, which could be millions per year if there are thousands of institutions.
Second, the covenant model tolerates a slow signing process (e.g., it can take a week and use some threshold scheme) because that doesn’t affect transaction speeds. In contrast, in the cosigner model without a hot key you have to wait for the government to complete their cold signing process before you can transact. The longer the waiting time the higher is your opportunity cost. The shorter the waiting time the more complex and fragile is the air-gapped signing."
reply
First, the covenant model requires only a single signature every two weeks. That’s 26 signatures per year. In contrast, the cosigner model requires to co-sign every single transaction, which could be millions per year if there are thousands of institutions.
CISA (cross input signature aggregation). We have it in some form with musig2, but musig2 by itself isn't the full CISA of the future.
As far as the time argument goes, don't you know that our system relies on credit. If you're just waiting on the government sign off, then any business would just credit you until the settlement can go through. Since all your PSBTs would be sent to the government, the risk of a full RBF tx is nil as the government would apply a first seen first signed policy.
Anyway, that's all much more complicated than what governments and businesses are doing today, which is just not letting you withdraw unless you're sending to another whitelisted service.
reply
More CISA nuance
https://cisaresearch.org/
reply
Thank you for your reply but that makes no sense to me. I wouldn't want to be in a position of having a payment in a sort of limbo for two weeks. I'll take my chances with the current risks with multisig rather than potentially make it even worse.
As for the system being based on credit : ... not really. If I sell a product, I want to get the btc before and I want to ship now. I won't be waiting around for two weeks. If I sell my house, I want the btc now, and no limbo.
reply
Sorry, when I said "our system" I meant the banking system, which you're right is not our system, but a government entity or any modern business would not have an issue with it at all.
Here's something to consider. Why do we have a merkle tree secured by hash cash? One of the reasons is so that there is no transaction reversibility. If a government database (or more likely an exchange or other custodian database) is the transaction state, is the authority on whether a tx gets reversed or not, (their signature is required afterall), and your custodian trusts this other custodian not to sign a second tx made by you (as they all do these days), your custodian (which I say custodian because this is a 2 of 2 multi-sig and you don't have enough signatures to spend and you don't have unilateral exit) could sign the unconfirmed on the utxo to allow you to spend it elsewhere.
Here's this put in more simple terms how I could put it on my own.
"What Is A Child Transaction In The Bitcoin Network?
A child transaction can be best understood in relation to its parent transaction. In the Bitcoin network, transactions are linked together in a chain-like structure called a blockchain. When a parent transaction occurs, it creates an unspent output that can be used as an input for subsequent transactions.
These subsequent transactions that spend these unspent outputs are referred to as child transactions."
So, when you receive a tx that is only signed by one signature, your wallet will query the government's node, see the tx in their custom mempool, and it will say its confirmed. Still in the mempool, the wallet will say its confirmed. Its not possible to reverse this tx, because the government mempool won't allow it to be replaced and because it doesn't have the governments signature, its not consensus valid to be mined yet.
(In both a CTV perpetual KYC scheme and this multi-sig perpetual KYC scheme, you'd need a wallet that even complies with this scheme)
In order to even have a CTV address, you need to generate one on your device, the same way you have to generate a taproot address.
You may remember me saying that.
So then your wallet would sign the child transaction of that tx and so and and so forth until the government signer wakes up and signs all of them at once and broadcasts that to be mined.
(p.s. I had to double check with some people I know that you could sign a child transaction of a multi-sig utxo before its parent is fully signed lol)
reply
Looking online, I see Greg Maxwell mentioning that same possible use of multi-sig.
How current do you think this quote from Greg Maxwell (2022) still is with the currrent proposals? :
"Simultaneously, there are plenty of extremely useful, pro-security, pro-privacy, pro-autonomy ways people could conceivably temporarily encumber their own coins… sadly almost none of them are enabled by bip119."
reply
With current proposals? Do you mean the 3 proposals in LNHance?
Yeah its very current. Jeremy (the BIP author) sucks and he did try to push it through without the whole getting node runners to understand what's going on and why its wanted thing. I'd be interested to hear why Greg Maxwell thought it was a poor proposal though. If its because of the BIP author, well can we talk about it without the BIP author? lol.
reply
I was rather asking if Greg Maxwell's criticisms are still current? :
"there are plenty of extremely useful, pro-security, pro-privacy, pro-autonomy ways people could conceivably temporarily encumber their own coins… sadly almost none of them are enabled by bip119"
There's no reason to rush anything. Which is apparently still what the proponents of those changes are doing : https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/2
Michael Folkson : "This should be opened to bitcoin-inquisition rather than this repo at this stage? I thought that was the whole point of bitcoin-inquisition. I can summarize why bitcoin-inquisition was introduced in the first place if that helps. It might seem overly finicky but having all proposed consensus changes (especially if they are new) discussed in the Core repo just adds too much noise to all the work that is being done on non consensus changes in Core (imo). "
and further down, still Michael :
"[...] if everyone takes your approach we get tens of different PRs in the Core repo from different authors all with different combinations of their favorite opcodes and sighash flags and supposedly that helps review and makes progress towards activation. In a repo that already suffers from being unnecessarily noisy. [...]"
I don't like people to push for rushed changes to my only savings plan.
Again, if people just want low fees, they can use any of thousands of shitcoins. We can also just use second layers and even e-cash mints too (which I do).
Bitcoin inflation goes down every four years, so we need high transaction fees if we plan on having a secure bitcoin (hashing power). So having lower fees doesn't feel like either a necessity nor even a good thing, tbh.
More privacy? Now, that will always be good, as long as it doesn't hurt auditability and that the necessitated changes don't increase the attack surface.
Otherwise, I prefer to have everything else on second or third layers.
And if there's going to be any changes, I wouldn't want that to happen while bigly respected bitcoin developers like Greg Maxwell expressing concerns.
reply
I think BIP119 is a poor proposal being pushed through in an ill advised way, but I think the concern you’re raising isn’t a legitimate one.
That's the only concern he raised. The entirety of what you sent me was Maxwell debunking FUD about perpetual KYC via CTV except for this one blurb where he says he doesn't like it and doesn't specify why.
And when asked, his only response was
Sorry, I don't work on Bitcoin anymore. You'll have to ask someone else.
There's no reason to rush anything. Which is apparently still what the proponents of those changes are doing : https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/2
In what conceivable way is this rushing anything? Do you know what inquisition net is? Its a test network to test and build with proposed op_codes. Its has nothing to do with mainline activation. A better example would have been O'Beirne publishing MASF code with no activation date.
So when Maxwell says its being pushed through in an ill advised way perhaps he would be referring to things like that.
You're not talking to O'Beirne or Folkson for that matter though, you're talking to me and I think the educational awareness campaign for node runners to grok what CTV (as part of LNHance) implications and applications are will likely take 5 years. I'm not rushing.
And so then what you're talking about usecases? That's why you bring up fees and privacy and all that right? All of this to finally get to that point eh. Would have loved to start there.
So John Law wrote this paper on scaling lightning using covenants https://github.com/JohnLaw2/ln-scaling-covenants
This method for scaling lightning involves a multi-party channel giving timeout trees to users who are 99% of the time offline. Please read the paper.
This is not about making fees cheaper, this is about dealing with high fees in a sane way.
It should not come as a surprise to you to read me telling you that Bitcoin is also my only savings plan. I'm not rushing anything. I just think its a good BIP.
reply