path: root/d9/f3f3d729cd2ab309582f19ed7aff6a7ed148e6

Return-Path: <raymo@riseup.net>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CF69DC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:54:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B233283083
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:54:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.4
X-Spam-Level: 
X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 
 DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
 DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, 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=riseup.net
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 q8W2Qsv1pZD3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:54:27 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 by smtp1.osuosl.org (Postfix) with ESMTPS id A30BC83077
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 21:54:27 +0000 (UTC)
Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
 by mx1.riseup.net (Postfix) with ESMTPS id 4GC71v0jfVzDqLw;
 Sat, 26 Jun 2021 14:54:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1624744467; bh=LzSbrO7SmDs8ddSGgliGHBbEptnVE/ZXV0TBqZHffQ4=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=gyORx2zOEs0OJUS2+IjOo3E+oolF7ZNkO/slCFrSEm+PAUjY17jD5XfMkCKxsp3Tu
 0n6JEVPaxIH/52VHHY4czJ/ny7p0+sHW47xdV2LU/whZwFe9IVXdazePDwAYu5O1GS
 /t38mz+ynRA8Piecg69GWFdCJumQ/ZC1vqCC+BTY=
X-Riseup-User-ID: 71F8A218864BF2FEFF5D55FEBA2A8BDE084CD406F8732BE7281A04C1F8A45F9C
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews2.riseup.net (Postfix) with ESMTPSA id 4GC71t6fC3z20ZS;
 Sat, 26 Jun 2021 14:54:26 -0700 (PDT)
MIME-Version: 1.0
Date: Sat, 26 Jun 2021 14:54:26 -0700
From: raymo@riseup.net
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com>
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com>
Message-ID: <9c2cec326adee1f4d4152e2195da0e7b@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Sat, 26 Jun 2021 21:58:51 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2021 21:54:29 -0000

Good morning ZmnSCPxj
Sorry for late reply.
> Guarantee Transactions (GT) being higher-fee is ***not*** assured.
The question is “assuring what?”. 
The whole point of my proposal is the fact that issuers and creditors
act rationally and won't harm their selves. The numbers (input and
output amounts), the relation between inputs and outputs amounts, the
minimum and maximum of inputs and outputs amounts, and conditions of a
valid trans-action in Sabu protocol are all designed precisely to
leading the rational users toward the making profit from the system. And
irrationals (either issuer or creditor) can harm the others and
inevitably in con-sequence will hurt themselves too. So, there is a fair
and just transaction (MT). 
The creditor can send the GT to Bitcoin network and lose 70% of his
money and damage 15% of is-suer money!
Vice versa the issuer can send GT to Bitcoin network and harm itself 15%
in cost of hurt creditors 70% which is none sense. Or issuer can pay
even more money directly to miner and hurt itself even more which is
even more irrational! Or the miner will ignore the transaction fees of a
GT and put the fraudulent transaction in next block, which I cannot
imagine a miner that pass up his legal and legiti-mate income in favor
of a greedy issuer!
Please write me a scenario (preferably with clear amount of inputs and
outputs) by which the cheater (either issuer or creditor) gains more
profit than playing honestly. 
Only in this case we can accept your claim about weakness of protocol.

> Every offchain protocol needs *the receiver* as a signatory to any unconfirmed transaction. the receiver **must** be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does *not* have the receiver as a signatory.

I intentionally decided to not using 2 of 2 signature, because I didn't
want to fall in same trap as Light-ening. I wanted to avoid this long
drilling 2 of 2 signings and routing. Instead, I just proposed to
cre-ate and sign a valid Bitcoin transaction between only 2 people in a
pure-peer-to-peer communication. The only signer is the issuer (the UTXO
owner).
Again, same logic. Please write me a scenario by which the cheater
(issuer or creditor) can cheat this only-issuer-signed transactions and
gains more profit than playing honest. Due to numbers and trans-action
restrictions and the insignificance of the amount of each transaction
this scenario of fraud will fail too. 

Looking forward to hearing from you
Raymo


On 2021-06-20 00:53, ZmnSCPxj wrote:
> 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=5344020.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
> atomically make that fee offer to miners --- but miners and issuers
> can always communicate 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
> --- including MTs and GTs --- as potentially replaceable, i.e.
> RBFable.
> There is no such thing as "RBF disabled", all transactions are
> inherently RBF-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
> unconfirmed transaction.
> 
> Or more strongly, the receiver **must** be a signatory --- the
> receiver cannot 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 is 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 sovereign 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
> across 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 to 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
> systems, 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 cryptocurrency systems (channels), and uses HTLCs to atomically
> transfer value across them (routing).
> 
> 
> Of course, having larger n is better as we need to splinter Bitcoin
> into fewer funds with larger participant sets.
> And we can mitigate the offline-problem by using a two-layer system:
> we have a n-of-n system (n > 2) that itself splits into multiple
> smaller 2-of-2 systems.
> That way, the Bitcoin layer is split into fewer UTXOs, reducing
> blockchain resource consumption further.
> 
> Thus, Channel Factories hosting Lightning Channels.
> 
> Regards,
> ZmnSCPxj