From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 24A3EC000C for ; Sun, 20 Jun 2021 00:55:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 19407837B6 for ; Sun, 20 Jun 2021 00:55:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekJoUS_vdEyO for ; Sun, 20 Jun 2021 00:54:59 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-41104.protonmail.ch (mail-41104.protonmail.ch [185.70.41.104]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9CD48837AC for ; Sun, 20 Jun 2021 00:54:59 +0000 (UTC) Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by mail-41104.protonmail.ch (Postfix) with ESMTPS id 4G6vMP2b2hz5XGKB for ; Sun, 20 Jun 2021 00:54:57 +0000 (UTC) Authentication-Results: mail-41104.protonmail.ch; dkim=pass (1024-bit key) header.d=protonmail.com header.i=@protonmail.com header.b="ZkIMQx6/" Date: Sun, 20 Jun 2021 00:53:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1624150448; bh=cTfoQ3oeu6FwwhpVWDKlLA2PYk2uiaxGRhWMSq6Ab8Q=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=ZkIMQx6/IrXSEmNDbMm0t4ok10Gt81vfJEopRsmgicv2kXe7gZJnFS9vW9xBT1FKe DOPBmDeeLA+iEMJ/t/evoqBQreHtOE6L1blZOd8K/XcOGgYwPgloAdII6chQVODFpv LzYMY59wSZnGV+MKALym7auW8P2PXhy4cJgeOhAg= To: "raymo@riseup.net" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2021 00:55:01 -0000 Good morning Raymo, > Hi, > I have a proposal for improve Bitcoin TPS and privacy, here is the post. > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-= transactions-per-second-and-privacy-1eef8568d180 > https://bitcointalk.org/index.php?topic=3D5344020.0 > Can you please read it and share your idea about it. Guarantee Transactions (GT) being higher-fee is ***not*** assured. Feerates are always bumpable --- the sender of a transaction only needs to = directly contact a miner and offer a fee to take a specific transaction on = the next block proposal, conditional on the transaction *actually* getting = into a block. Such "side fees" are always possible. Indeed, the in-transaction fees are "just" a way to anonymously and atomica= lly make that fee offer to miners --- but miners and issuers can always com= municate directly without using Bitcoin transaction to arrange a higher fee= for a fraudulent Main Transaction (MT). because of this, you should really treat all unconfirmed transactions --- i= ncluding MTs and GTs --- as potentially replaceable, i.e. RBFable. There is no such thing as "RBF disabled", all transactions are inherently R= BF-able due to side fees --- it is simply a matter of anonymity, atomicity,= and ease-of-use. --- Every offchain protocol needs *the receiver* as a signatory to any unconfir= med transaction. Or more strongly, the receiver **must** be a signatory --- the receiver can= not trust an unconfirmed transaction where the spent UTXO has an alternate = branch that does *not* have the receiver as a signatory. See: https://zmnscpxj.github.io/offchain/safety.html Thus, all safe offchain schemes need to use an n-of-n signing set. The smallest n-of-n that is still useful is 2-of-2, where one participant i= s a sender and the other is a receiver. (1-of-1 is not useful since there is no possible receiver who can sign). This requires Bitcoin to splinter into lots of 2-of-2 funds, each one a sov= ereign sub-money (that is *eventually* convertible to Bitcoin), each one a = cryptocurrency system in its own right. However, it so happens that we have a mechanism for transferring value acro= ss multiple cryptocurrency systems: the HTLC. 2-of-2 is also the most stable. This is because *all* signatories of an n-of-n cryptocurrency system need t= o be online at the same time in order for *any* of them to use the funds in= the system. If any one of them is offline, then the system is unusable. With 2 participants, there is some probability that one of them is offline = and the individual 2-of-2 system is unusable. With 3 participants, the probability is higher (there are more participants= that can be offline). With 4 participants, higher still. Thus, the most stable is to split Bitcoin into lots of little 2-of-2 system= s, and use HTLCs to transfer funds across the little 2-of-2 systems. Thus, Lightning Network, which splits Bitcoin into lots of little 2-of-2 cr= yptocurrency systems (channels), and uses HTLCs to atomically transfer valu= e across them (routing). Of course, having larger n is better as we need to splinter Bitcoin into fe= wer funds with larger participant sets. And we can mitigate the offline-problem by using a two-layer system: we hav= e a n-of-n system (n > 2) that itself splits into multiple smaller 2-of-2 s= ystems. That way, the Bitcoin layer is split into fewer UTXOs, reducing blockchain = resource consumption further. Thus, Channel Factories hosting Lightning Channels. Regards, ZmnSCPxj