Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
On 2/28/2022 1:49 AM, ZmnSCPxj wrote: ... ... Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes. If so, a "rich man" could open a LN channel, and gradually transfer it to new people. Such a technique would need to meet two requirements (or, so it seems to me): #1: The layer1 UTXO (that defines the channel) can never change (ie, the 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-they-were when the channel was opened). #2: The new part-owners (who are getting coins from the rich man), will have new pubkeys which are NOT known, until AFTER the channel is opened and confirmed on the blockchain. Not sure how you would get both #1 and #2 at the same time. But I am not up to date on the latest LN research. Yes, using channel factories. I think you may be wrong about this. ... I am not wrong about this. Well, let's take a closer look then. The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new layer1 bytes". By which I meant, that I could generate a new pubkey right now, and add it to the LN, without any onchain action. I can shorten and restate the two requirements (and reorder them) as: #2: Can later add a new public key to the membership set. #1: Without an onchain action. And yet you yourself say, very clearly: ... That is why I said changing the membership set requires onchain action. Which would seem to directly contradict what you say about channel factories. Unless you can show me how to add my new pubkey_4, to a 3-of-3 channel factory opened last year. Without using an onchain action. You seem to want to instead change the subject. (To something like: 'we can do better the rate (32 bytes per 5 onboards), from your footnote'.) Which is fine. But it is not what I bought up. *** In general, you seem to have a future in mind, where new users onboard via factory. For example, 50,000 new users want to onboard in the next block. These strangers, spontaneously organize into 1000 factories of 55 people each, (50 newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then broadcast into the block and join Bitcoin. And this one factory provides them with many channels, so it can meet most/all of their needs. I am not here to critique factories. I was simply observing that your logic "sidechains don't scale, because you have to share your messages" is not quite airtight, because in the case of onboarding the situation is reversed and so supports the exact opposite conclusion. I believe I have made my point by now. It should be easy for people to see what each of us has in mind, and the strengths and weaknesses. I am curious about something, though. Maybe you can help me. Presumably there are risks to large factories. Perhaps an attacker could join each new factory with just $1 of BTC, spend this $1, and then refuse to cooperate with the factory any further. Thus they can disable the factory at a cost of $1 rented dollar. If 1000 factories are opened per block, this would be 52.5 M factories per year, $52.5 million USD per year to disable all the factories out of spite. (All of which they would eventually get back.) I can think of a few people who might try it. I mean, like, LN ... has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock. I don't see the relevance of this. We are talking about the future (theoretical), not the past (empirical). For example, someone could say "Ethereum has a lot more onboarding activity than LN ..." but this would also make no difference to anything. ...The onboarding rate only needs to be as fast as the rate at which people want to join Bitcoin. ... As I pointed out in the other thread: * LN: * Funds can be stolen IF: * There is a 51% miner, AND * The 51% miner is a member of a channel/channel factory you are in. * Drivechains: * Funds can be stolen IF: * There is a 51% miner. ... So there is a real degradation of security in Drivechains, and if you compute the numbers, I am reasonably sure that 33% of the world is unlikely to want to use Bitcoin within one month. I mean we already had a pandemic and everyone going online and so on, and yet Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS that came up only due to hitting the minimum feerate, so no --- people are not joining Bitcoin at a rate faster than Bitcoin + LN can handle it, even with a pretty good reason to move payments online. Worse, once 100% of the world is onboarded, the extra onboarding capacity is useless since the onboarding rate can only match the birth rate (including birth of legal persons such as corporations), which we expect is much lower than 33% increase per ***month***. You are buying too much capacity at a real degradation in security, and I am not convinced the extra capacity is worth the loss of security. Separating the onboarding rate from the payment rate
Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
> Continuous operation of the sidechain then implies a constant stream of > 32-byte commitments, whereas continuous operation of a channel factory, in > the absence of membership set changes, has 0 bytes per block being published. The sidechain can push zero bytes on-chain, just by placing a sidechain hash in OP_RETURN inside TapScript. Then, every sidechain node can check that "this sidechain hash is connected with this Taproot address", without pushing 32 bytes on-chain. On 2022-02-28 08:13:03 user ZmnSCPxj via bitcoin-dev wrote: > Good morning Paul, > On 2/26/2022 9:00 PM, ZmnSCPxj wrote: > > > ... > > > > > Such a technique would need to meet two requirements (or, so it seems to > > > me): > > > #1: The layer1 UTXO (that defines the channel) can never change (ie, the > > > 32-bytes which define the p2sh/tapscript/covenant/whatever, must stay > > > what-they-were when the channel was opened). > > > #2: The new part-owners (who are getting coins from the rich man), will > > > have new pubkeys which are NOT known, until AFTER the channel is opened > > > and confirmed on the blockchain. > > > > > > Not sure how you would get both #1 and #2 at the same time. But I am not > > > up to date on the latest LN research. > > > > Yes, using channel factories. > > I think you may be wrong about this. > Channel factories do not meet requirement #2, as they cannot grow to onboard > new users (ie, new pubkeys). > The factory-open requires that people pay to (for example), a 5-of-5 > multisig. So all 5 fixed pubkeys must be known, before the factory-open is > confirmed, not after. I am not wrong about this. You can cut-through the closure of one channel factory with the opening of another channel factory with the same 5 fixed pubkeys *plus* an additional 100 new fixed pubkeys. With `SIGHASH_ANYPREVOUT` (which we need to Decker-Russell-Osuntokun-based channel factories) you do not even need to make new signatures for the existing channels, you just reuse the existing channel signatures and whether or not the *single*, one-input-one-output, close+reopen transaction is confirmed or not, the existing channels remain usable (the signatures can be used on both pre-reopen and post-reopen). That is why I said changing the membership set requires onchain action. But the onchain action is *only* a 1-input-1-output transaction, and with Taproot the signature needed is just 64 bytes witness (1 weight unit per byte), I had several paragraphs describing that, did you not read them? Note as well that with sidechains, onboarding also requires action on the mainchain, in the form of a sideblock merge-mined on the mainchain. > > > We assume that onboarding new members is much rarer than existing members > > actually paying each other > > Imagine that Bitcoin could only onboard 5 new users per millennium, but once > onboarded they had payment nirvana (could transact hundreds of trillions of > times per second, privately, smart contracts, whatever). > Sadly, the payment nirvana would not matter. The low onboarding rate would > kill the project. Fortunately even without channel factories the onboarding rate of LN is much much higher than that. I mean, like, LN *is* live and *is* working, today, and (at least where I have looked, but I could be provincial) has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock. > The difference between the two rates [onboarding and payment], is not > relevant. EACH rate must meet the design goal. > It is akin to saying: " Our car shifts from park to drive in one-millionth of > a second, but it can only shift into reverse once per year; but that is OK > because 'we assume that going in reverse is much rarer than driving forward' > ". Your numbers absolutely suck and have no basis in reality, WTF. Even without batched channel openings and a typical tranaction of 2 inputs, 1 LN channel, and a change output, you can onboard ~1250 channels per mainchain block (admittedly, without any other activity). Let us assume every user needs 5 channels on average and that is still 250 users per 10 minutes. I expect channel factories to increase that by about 10x to 100x more, and then you are going to hit the issue of getting people to *use* Bitcoin rather than many users wanting to get in but being unable to due to block size limits. > > > Continuous operation of the sidechain then implies a constant stream of > > 32-byte commitments, whereas continuous operation of a channel factory, in > > the absence of membership set changes, has 0 bytes per block being > > published. > > That's true, but I think you have neglected to actually take out your > calculator and run the numbers. > > Hypothetically, 10 largeblock-sidechains would be 320 bytes per block > (00.032%, essentially nothing). > Those 10, could onboard 33% of the planet in a single month [footnote], even > if each sc-onboard required an average of 800 sc-bytes. > >
[bitcoin-dev] Decentralized BIP 47 payment code directory
Hello World, There was some discussion about BIP 47 on twitter recently: https://twitter.com/BitcoinQ_A/status/1356177927285714946 BIP 47 improves privacy however there are a few reasons why its less used: 1.Some developers consider it spams Bitcoin without improving anything: https://twitter.com/LukeDashjr/status/1280475865827151878 2.Paynym (a centralized directory managed by Samourai) and Samourai wallet is the only implementation used for BIP 47 right now. Centralized payment code directory isn't good for privacy and security. There can be few other important issues which I missed in this email. I have few ideas to solve these 2 problems with the use of TXT records and domains. Since buying domain, managing DNS etc. is mostly centralized I won't share the example using normal DNS. Below proof of concept uses GNS (GNU Name Service): ``` Payment code for Alice: PM8TJggVVXFKAmfkjnA1CQcrSbGScUKRsVohpfMpSM56f6jg5uQTPJvNS1wKDGV17d9NWLqoVzsJ8qURqpUECmSFLcUuC4g3aMtoXp2fChY1ZEqzG16f Start GNUnet: gnunet-arm -s Create identity: gnunet-identity -C alice Check public key: gnunet-identity -d alice - 000G005XCTRJ0DJGPVPNY66GAY52C61KA8A7CA92PKT51PHNVWY9JF8WB4 - ECDSA Add payment code as TXT record which expires in 90 days: gnunet-namestore -z alice -a -e "90 d" -p -t TXT -n pay -V "PM8TJTLJbPRGxSbc8EJi42Wrr6QbNSaSSVJ5Y3E4pbCYiTHUskHg13935Ubb7q8tx9GVbh2UuRnBc3WSyJHhUrw8KhprKnn9eDznYGieTzFcwQRya4GA" Check payment code: gnunet-gns -t TXT -u pay.alice pay.alice: Got `TXT' record: PM8TJTLJbPRGxSbc8EJi42Wrr6QbNSaSSVJ5Y3E4pbCYiTHUskHg13935Ubb7q8tx9GVbh2UuRnBc3WSyJHhUrw8KhprKnn9eDznYGieTzFcwQRya4GA ``` Similarly notification transaction can be replaced with `gnunet-publish`. Nostr is still a work in progress and I think it could also be used for such things in future. Everything looks achievable and involves basic things but we still see people posting their bitcoin address on social media to get donations. Related: Q: https://bitcoin.stackexchange.com/questions/106971/how-to-accept-donation-correctly/ New proposal: https://gist.github.com/Kixunil/0ddb3a9cdec33342b97431e438252c0a -- Prayank A3B1 E430 2298 178F ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Teleport: a CoinSwap implementation alpha release, provides invisible private transactions
Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B. But in reality her coins end up in address Z which is entirely unconnected to either A or B. Now imagine another user, Carol, who isn't too bothered by privacy and sends her bitcoin using a regular wallet which exists today. But because Carol's transaction looks exactly the same as Alice's, anybody analyzing the blockchain must now deal with the possibility that Carol's transaction actually sent her coins to a totally unconnected address. So Carol's privacy is improved even though she didn't change her behavior, and perhaps had never even heard of this software. In a world where advertisers, social media and other institutions want to collect all of Alice's and Carol's data, such privacy improvement would be incredibly valuable. If even a small percentage of transactions were actually created by this software, anybody doing analysis on the blockchain would always have a niggle in the back of their mind: "what if this transaction I'm looking at was actually a CoinSwap? How would I know? What if these coins have actually disappeared into the mist?". The doubt and uncertainty added to every transaction would greatly boost the fungibility of bitcoin and so make it a better form of money. Over a year ago I wrote to this list[1] about how undetectable privacy can be developed today by implementing CoinSwap. Today I release the first alpha version of this software: https://github.com/bitcoin-teleport/teleport-transactions/ The project is almost completely decentralized and available for all to use for free (baring things like miner fees). So far it is only really usable by developers and power-users to play around with. It doesnt have all the necessary features yet, but from now on I'll be doing new releases very often as soon as every new feature gets added. It is possible to run it on mainnet, but only the brave will attempt that, and only with small amounts. I've personally made many coinswaps on the testnet and signet networks, and I'll be running market makers on signet which will be available for anyone to create coinswaps with. Right now it just uses 2of2 multisig for the coinswap addresses. Those address types are rare on the blockchain so the coinswaps stand out a fair amount (although protocols like lightning also use 2of2 multisig). However the next really big task on my todo list is to use ECDSA-2p which would make these multisig addresses look like regular single-sig addresses, which are overwhelmingly common out there and so provide an enormous anonymity set. My aim is that the Teleport project will develop into a practical and secure project on the bitcoin mainnet, usable either standalone as a kind of bitcoin mixing app, or as a library that existing wallets will implement allowing their users with the touch of a button to send bitcoin coinswap transactions with much greater privacy than as possible before. I want to thank everyone who has supported me financially over the last several months, without them this project simply would not have been possible. If bitcoin privacy and coinswap is something you find important, please consider supporting my work with a donation: https://bitcoinprivacy.me/coinswap-donations [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
