From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "raymo@riseup•net" <raymo@riseup•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
Date: Sun, 27 Jun 2021 04:53:52 +0000 [thread overview]
Message-ID: <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com> (raw)
In-Reply-To: <9c2cec326adee1f4d4152e2195da0e7b@riseup.net>
Good morning Raymo,
> 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.
As the issuer is the only one signing, it can trivially create a self-paying 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 back to me.
After you hand over the equivalent of 1 BTC in other resources, I then create an alternative transaction, signed only by myself, paying 0.5 BTC to miners and 1.5 BTC to myself, and since the fee is so high, the miners have every incentive to mine it.
Yes, that is not a valid MT or GT, but nothing in the Bitcoin blockchain layer requires that the *single* signer follow the protocol.
The point here is that a single signer can sign anything, including a transaction that is not an MT or a GT, but has arbitrary numbers that are neither 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 *not* directly on the blockchain.
The blockchain only cares about signature and timelock validity; it does not care about (and check for validity) MTs and GTs.
In essence, this is a trusted system where every creditor trusts every issuer to *only* sign GTs and MTs, thus uninteresting --- you might as well just 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 payments and thus the fee for this non-MT non-GT clawback can approach the security 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 will be fairly awful.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-06-27 4:54 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-16 13:44 raymo
2021-06-18 1:42 ` Erik Aronesty
2021-06-18 13:44 ` Alex Schoof
2021-06-18 20:00 ` raymo
2021-06-19 21:14 ` Erik Aronesty
2021-06-18 13:37 ` Erik Aronesty
2021-06-18 20:22 ` raymo
2021-06-20 0:53 ` ZmnSCPxj
2021-06-26 21:54 ` raymo
2021-06-27 4:53 ` ZmnSCPxj [this message]
2021-06-27 11:05 ` raymo
2021-06-28 5:20 ` ZmnSCPxj
2021-06-28 6:29 ` raymo
2021-06-28 8:23 ` James Hilliard
2021-06-28 9:52 ` raymo
2021-06-28 11:28 ` James Hilliard
2021-06-28 16:33 ` raymo
2021-06-28 15:28 ` ZmnSCPxj
2021-06-28 16:58 ` raymo
2021-06-28 17:58 ` Alex Schoof
2021-06-28 19:07 ` raymo
2021-06-29 21:42 ` ZmnSCPxj
2021-06-30 12:21 ` raymo
2021-06-28 17:29 ` Tao Effect
2021-06-28 17:38 ` raymo
2021-06-28 18:05 ` Ricardo Filipe
2021-06-20 1:59 ` James Hilliard
2021-06-22 18:20 ` Billy Tetrud
2021-07-01 20:11 ` raymo
2021-07-01 20:49 ` Erik Aronesty
2021-07-01 22:15 ` raymo
2021-07-02 17:57 ` Billy Tetrud
2021-07-03 8:02 ` raymo
2021-07-07 3:20 ` Billy Tetrud
2021-07-17 15:50 ` raymo
2021-07-17 18:54 ` Tao Effect
2021-08-08 9:11 ` raymo
2021-08-09 0:03 ` s7r
2021-08-09 16:22 ` raymo
[not found] ` <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>
2021-08-09 20:22 ` raymo
2022-11-02 17:30 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=raymo@riseup$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox