From: raymo@riseup•net
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
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:05:04 -0700 [thread overview]
Message-ID: <edee179d873eb9db551204561db17e90@riseup.net> (raw)
In-Reply-To: <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com>
On 2021-06-27 04:53, ZmnSCPxj wrote:
Good evening ZmnSCPxj
It looks you already missed the entire design of Sabu and its
restrictions. First of all, the Gazin wallet always controls the Sabu
restrictions for every transaction in order to consider it as a valid
transaction in a valid deal. That is, the creditor wallet controls the
MT and GT in first place. Then if the transactions are valid the
creditor consider entire process as a valid deal and give the services
or goods in exchange of received Satoshis.
So, in this scenario the issuer has to sign a MT transaction in which
the issuer spends a UTXO worth at least 40,000 Sat, and issuer can issue
maximum 20,000 Sat debt-document. So, the transaction can have One or
more outputs for creditor(s), they must worth in total less than 20,000
Sat.
Each transaction has to pay fixed 10,000 Sat as BTC-transaction-fee
regardless the transaction length or the inputs/outputs amounts. The
issuer always pays at least 4,000 Sat of BTC-transaction-fee, and the
6,000 remined fee must be paid by issuer and creditors in proportion to
their outputs amounts)
Finally, the transaction can have one change-back output to issuer
address (same as input address) worth less than (40,000 – 4,000=36,000)
Sat to issuer. This value depends on the debt amount and the issuer
BTC-transaction-fee portion. The maximum issuer change back could be
(40,000 -10,000 = 30,000) Sat for a transaction with no debt issuance.
The minimum amount of change back would be (40,000 – 10,000 – 19,999 =
10,001 Sat). For more details, please take a look at figure 3.
(Transaction in detail) in article
https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
also investigate on code
https://github.com/raymaot/transaction-numbers-and-coefficients .
The creditor controls all these criteria and after passing all these
tests the creditor accept transaction as a valid transaction. Now
creditor has 2 MT and GT transaction in his hand.
Because of these number limitations, no arbitrary UTXO spending by
issuer nor self-paying transaction can make more output and more
benefits to him than respecting the already issued MT. please
investigate on figure 1.0. (Security checks) for more details.
Now show me a case (with precise amounts of inputs and outputs) that
fits in Sabu restrictions AND issuer can make an arbitrary transaction
with more benefit than MT!
> 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.
All these transactions are formed relatively (the numbers in GT are
calculated based on MT), so they are relative, so no matter how much
mempool is full or empty. The only consideration for mempool is the
propagation delay which is another story and has its own solution as
well.
> I think your UX will be fairly awful.
All validations and communications are behind the scene, so the UX will
be enough smooth and friendly except the latency of email-based
communications, which needs to be considered in details. BTW this is not
a big deal considering the sovereignty and the freedom are bringing to
our financial activities.
> 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 11:05 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
2021-06-27 11:05 ` raymo [this message]
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=edee179d873eb9db551204561db17e90@riseup.net \
--to=raymo@riseup$(echo .)net \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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