Date: Sun, 27 Jun 2021 04:53:52 +0000
To: "raymo@riseup.net" <raymo@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com>
In-Reply-To: <9c2cec326adee1f4d4152e2195da0e7b@riseup.net>
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com>
 <9c2cec326adee1f4d4152e2195da0e7b@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Boost Bitcoin circulation,
	Million Transactions Per Second with stronger privacy
Precedence: list

Good morning Raymo,


> Good morning ZmnSCPxj
> Sorry for late reply.
>
> > Guarantee Transactions (GT) being higher-fee is not assured.
>
> The question is =E2=80=9Cassuring what?=E2=80=9D.
> 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 unconf=
irmed transaction. the receiver must be a signatory --- the receiver cannot=
 trust an unconfirmed transaction where the spent UTXO has an alternate bra=
nch 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.

As the issuer is the only one signing, it can trivially create a self-payin=
g transaction by itself that is neither a valid MT nor a valid GT.

Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change output b=
ack to me.
After you hand over the equivalent of 1 BTC in other resources, I then crea=
te an alternative transaction, signed only by myself, paying 0.5 BTC to min=
ers and 1.5 BTC to myself, and since the fee is so high, the miners have ev=
ery incentive to mine it.

Yes, that is not a valid MT or GT, but nothing in the Bitcoin blockchain la=
yer requires that the *single* signer follow the protocol.
The point here is that a single signer can sign anything, including a trans=
action that is not an MT or a GT, but has arbitrary numbers that are neithe=
r a valid GT nor a valid MT.
That is the reason why every trust-minimized offchain system requires 2-of-=
2, somebody else has to countercheck the validity of a protocol that is *no=
t* directly on the blockchain.
The blockchain only cares about signature and timelock validity; it does no=
t care about (and check for validity) MTs and GTs.

In essence, this is a trusted system where every creditor trusts every issu=
er to *only* sign GTs and MTs, thus uninteresting --- you might as well jus=
t use Coinbase as your offchain if you are going to inject trust.

Now you can counterargue that you intend this system to be used for small p=
ayments and thus the fee for this non-MT non-GT clawback can approach the s=
ecurity levels you so carefully computed for GT and MT, but again --- the *=
largest* safe payment will vary depending on onchain mempool state, and if =
the mempool is almost empty, the largest safe payment will be much smaller =
than at other times.
This uncertainty is not handled well by most users, thus I think your UX wi=
ll be fairly awful.

Regards,
ZmnSCPxj