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: Wed, 30 Jun 2021 05:21:27 -0700 [thread overview]
Message-ID: <9c15ed5aa08038093565552f27104c54@riseup.net> (raw)
In-Reply-To: <vBVgArAP_YhmuuUtZS9nbrx_JI0B-Sw0x3RdBvc7QJ8s_EvnW6hkNpWyu6MdJJBrV3zv5OxZcMMgooG1yNI4naXvgJbIWIOSyVLdoUwwymM=@protonmail.com>
Dear ZmnSCPxj
Thanks for dedicating time to read carefully the Sabu proposal and many
thanks for your accurate point. So, lets fix it.
I didn’t suppose Alice has only one UTXO, instead I expect every issuer
use hundreds or even millions UTXOs (for optimal benefit each worth
exactly 40,000 Satoshi) in Sabu protocol in order to earn notable
Sabu-transactions-fees daily.
Your scenario is correct and Alice can send a batch transaction which
has higher feeRate, but less fee amount comparing total fees of N number
of GT transaction.
It is true, the batch transaction will win the race and will go to next
block instead of N small GT transactions.
But Alice herself is not the winner, since she paid a huge transaction
fee to miner, while in honest acting didn’t have to pay at all.
Let’s show it by numbers.
Imagine Alice convinced some people to pay her money and accept the MT
and GT transactions in exchange.
Alice issued N transactions and delivered to these guys.
Till now Alice got money equal to N * Maximum debt per transaction,
which is 20,000 N.
A single GT length = length of Critical part of GT (named C) + length of
Redundant part of GT (named R)
Coefficient of Honesty benefits (called H) = C/R
The bigger H means less Redundant part, means less benefit in batch
transaction.
The worst H would be 1 or less than 1. I can guess H in Bitcoin
transaction is 4 or higher, but for now we take it 4. Probably you can
help us and tell what H is exactly.
The N GTs length = N * (C + R)
One batch transaction length = (N * C) + R
The GT feeRate = GTfee / (C + R)
The batch transaction feeRate = batchFee / ((N * C) + R)
We need to batch transaction feeRate be higher than each single GT
feeRate (more or less the feeRate for all GTs are same).
Thus
batchFee / ((N * C) + R) must be bigger or at least equal to GTfee / (C
+ R)
so,
batchFee / ((N * C) + R) >= GTfee / (C + R)
we already knew H = C/R then C = HR
after simplifying
batchFee >= (GTfee * ((N * H) + 1)) / (H + 1)
So, this is the minimum fee that Alice has to pay for her batch
transaction in order to compete with GTs feeRate.
Let’s put the numbers
From my previous example for @Alex Schoof, we already knew that the
GTfee is 25,500 Satoshi
H is 4 (please let me know what is more realistic number)
I think N in max exploitation is 10,000. If Alice takes entire block
space, she won’t be able to put more than 10,000 inputs in a single
transaction in one block.
So,
batchFee must be higher than (25,500 * ((10,000 * 4) + 1)) / (4 + 1)
batchFee must be higher than 2.04 Bitcoins. While if Alice was acting
honestly, she had to pay zero BTC-transaction-fee, since the Sabu
transactions are aimed to be circulated in Sabu network forever.
But how much benefit Alice got? We already knew that Alice had fooled
Some people by 10,000 transactions and got 10,000 transaction * 20,000
Max debt per transaction. She got 2 Bitcoins.
After all, she lost 0.04 BTC. She definitely is a loser, unless she has
conspiracy with miners which is another scenario and I already explained
it.
Note these facts:
H is higher than 4.
It is impossible to fit a batch transaction with 10,000 inputs and one
output in one block.
And after all we can simply hedge batch transaction benefits by fine
tuning the “maximum allowed debt per transaction”.
Finally, the complementary protection to cover 0.01% remind risk of
issuer irrationality, would be the BIPxxx “for flagging/unflagging
promised UTXOs” which is my suggestion.
It will be good for Sabu.
It will be good for adapting wide range of innovative smart contracts on
top of current Bitcoin with no risk and cost.
@James Hilliard
If it implemented wisely, never won't affect on network stability.
> your analysis is based on assuming that miners are perfect rational beings of perfect rationality,
> ***and*** are omniscient.
That’s not true! The proposal just assume miners are looking for more
profit.
The suggested BIPxxx “for flagging/unflagging promised UTXOs” (if
community accept it) would prepare a knowledge about promised UTXOs for
miner.
> Even if Alice is in possession of only a single UTXO, Alice can still feed miners a transaction
> with lower feerate than the MT, then feed the rest of the network with a valid MT.
It is not important in what order Alice propagate which (MT, or whatever
transaction) to Bitcoin network.
The point is, before putting this transaction in next block, the
creditor wallet will be aware of this renege and will send the GT to
network.
The rest is miner’s decision to put transaction with higher fee rate to
next block.
> This attack is essentially costless to Alice,
> especially for big enough transactions where mining fees are a negligible part of the payment.
No, in Sabu we have not big payments. Each big payment must be managed
through N small transactions with each transaction max output less than
20,000 Satoshi.
Regards
Raymo
On 2021-06-29 21:42, ZmnSCPxj wrote:
> Good morning Raymo,
>
>> Hey Alex,
>>
>> Your scenario works perfectly unless we put some restrictions on
>> accepting transaction by creditor (in our case Bob).
>> These are restrictions:
>> Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as
>> transaction input.
>> Alice has to reserve 10,000 Sat as transaction fee (for MT transaction)
>> regardless of transaction length or input/output amounts.
>> Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the
>> 6,000 remined fee must be paid by she and Bob in proportion to their
>> outputs amounts)
>> Alice can issue a transaction the has maximum 20,000 outputs for
>> creditors (Bob and others).
>> The rest (if exist) is change back to Alice address.
>> The GT is formed based on MT.
>> Bob considers a transaction couple (MT, GT) valid only if they respect
>> these rules.
>>
>> Let’s put it in practice using some numbers (although you can find more
>> detailed explanation in paper).
>>
>> The MT would be like that:
>> Input: 40,000 Satoshi
>> Outputs:
>> Bob: 20,000
>> BTC-fee: 10,000
>> Change back to Alice: 10,000
>>
>> Based on this MT the GT will be
>> Input: 40,000 Satoshi
>> Outputs:
>> Bob: 20,000 – 20,00070% = 6,000
>> BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change
>> back) = 25,500
>> Change back to Alice: 10,000 – 10,00015% = 8,500
>>
>> Now if Alice wants to spend UTXO to Charlie with higher fee, she has to
>> pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners
>> to put his fraudulent transaction instead the GT in next block.
>> Alice already got 20,000 Sat profit from Bob. Now she can earn another
>> 14,999 Sat profit from Charlie because of same UTXO worth 40,000
>> Satoshi.
>> Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods
>> or services.
>> Is she a winner?
>> I am not sure!
>> What do you think?
>
> You assume here that Alice the issuer only has a single UTXO and that
> it creates a single transaction spending that UTXO.
>
> It is helpful to remember that miners consider fee*rate*, but your
> security analysis is dependent on *fee* and not fee*rate*.
>
> Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs
> to 1000 different Bobs?
>
> Now, a GT has one input and two outputs.
>
> 1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on),
> 1000 inputs, and 2000 outputs.
>
> Now Alice the issuer, being the sole signer, can create a fraudulent
> transaction that spends all 1000 UTXOs and spends it to a single Carol
> output.
>
> This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output.
>
> Do you think Alice can get a better fee*rate* on that transaction
> while paying a lower aggregate *fee* than all the GTs combined?
> Remember, you based your security analysis on Alice being forced to
> pay a larger *fee*, but neglect that miners judge transactions based
> on fee*rate*, which is subtly different and not what you are relying
> on.
> I am sure that there exists some large enough number of UTXOs where a
> single aggregating fraudulent transaction will be far cheaper than the
> tons of little GTs your security analysis depends on.
>
> This is why we do not use 1-of-1 signers in safe offchain protocols.
> Not your keys, not your coins.
>
> --
>
> In addition, your analysis is based on assuming that miners are
> perfect rational beings of perfect rationality, ***and*** are
> omniscient.
>
> In reality, miners possess bounded knowledge, i.e. they do not know everything.
>
> Even if Alice is in possession of only a single UTXO, Alice can still
> feed miners a transaction with lower feerate than the MT, then feed
> the rest of the network with a valid MT.
> Because transactions propagate through the network but this
> propagation is ***not*** instantaneous, it is possible for the MT to
> reach the miners later than the fraudulent transaction.
> In this window of time, a block may be mined that includes the
> fraudulent transaction, simply because the lucky miner never managed
> to hear of the correct MT.
>
> This attack is essentially costless to Alice, especially for big
> enough transactions where mining fees are a negligible part of the
> payment.
>
> This is why we do not use 1-of-1 signers in safe offchain protocols.
> Not your keys, not your coins.
>
> Regards,
> ZmnSCPxj
next prev parent reply other threads:[~2021-06-30 12:21 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
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 [this message]
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=9c15ed5aa08038093565552f27104c54@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