path: root/d1/de628fc4a1cd77e13a8db64eaa4320f64ea819

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 86B45C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 20:23:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 75E9A8250B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 20:23:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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]
 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 6eEiR-TzY5bC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 20:22:58 +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 1509E8243B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Aug 2021 20:22:57 +0000 (UTC)
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83])
 (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 4Gk6w14l5vzDs9K;
 Mon,  9 Aug 2021 13:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1628540577; bh=1Jl0tkEkhiME/Uez/BcP0cLnHP8IwWS9BzOXapxiUUo=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=XPWaQZ9eP3WbCcJGsL+Sf3SqCc22ogg0NnU86VNY/f2z4ugiMenrgNeqgia6cK02j
 BJto0VtoNbZK7iLaV6UvZl/YTnjsNR8qUzDxPG68lCoQFusrP85+GbkMYdSRxmXYTd
 /dVpwd90lrphIGKYePAeDBIvLT6YBPPUEjabddWI=
X-Riseup-User-ID: 71E3FD88A7BDB9DD1BB2AEDCB54F8C85BA27E6EB5F216B605B450F8B750F394E
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews1.riseup.net (Postfix) with ESMTPSA id 4Gk6w13XZdz5vh4;
 Mon,  9 Aug 2021 13:22:57 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 09 Aug 2021 13:22:57 -0700
From: raymo@riseup.net
To: Chris Riley <criley@gmail.com>
In-Reply-To: <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <CADvTj4q42bQ0mTWwdMyJM9UpW57pV0feZk-vYynPu91N_aZSZw@mail.gmail.com>
 <CAGpPWDZtRnnv-Hinn4x=9ukJcuHkZv-6Yt32AK-9e+BJ=6r-kA@mail.gmail.com>
 <f46159f0286fe48720bc3f3fead1b575@riseup.net>
 <CAJowKgKELBmLdA-w5ghGoiWe5RQdNkKsV3OGRFbDJCOeA04AWw@mail.gmail.com>
 <d8b3ba5b940473165ad72d689a01602a@riseup.net>
 <CAGpPWDYAJE4jh=G2g=KSRuLLucEAyZGAD+r4XMpcmw6nk4+Wbg@mail.gmail.com>
 <e843b5c28690557402b72fcd158dc1c2@riseup.net>
 <CAGpPWDYPutiURUtenkU_zr4nW_tZVe5oWykXxWCDyROwqTdW5Q@mail.gmail.com>
 <6016816a7ea36b8a88f48d69462d0308@riseup.net>
 <0555e82561666007e7ce367e3a204f53@riseup.net>
 <f5720b0e-d660-473e-00fa-aa275d062e30@sky-ip.org>
 <9403a01d93b3fe2e871517304b552194@riseup.net>
 <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>
Message-ID: <392a21eef848045f827990a5044b1c94@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 09 Aug 2021 20:34:20 +0000
Cc: 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: Mon, 09 Aug 2021 20:23:02 -0000

Hi Chris,

Thanks for your detailed answer. So, as you answered there is an
uncertainty about this case. For me, even this uncertainty would be a
good point to start. Because if the miners realize the potentiality for
increasing revenue under Sabu protocol, very soon they will want to
update their transaction selecting mechanism priorities, even before
occurring the first real attack on the protocol in “production
software”. This upgrade in Bitcoin protocol will eliminate uncertainty
totally.

How hard do you think it will be this upgrade on protocol?
IMO the most important thing will be the consensus on the implementation
of these changes, while the code upgrading won't be a difficult
technical issue.
If it were difficult to agree on a Bitcoin core protocol change, we
might be able to achieve our goals by changing the Stratum protocol.
Unlike miners who would welcome that offer, full-nodes without hash
power would probably not be interested in upgrading the software. Maybe
because they do not want to disrupt the broadcasting of transactions by
relying double-spend transactions.
I'm not sure if the normal full nodes (without hash power) use the same
software that miners use. If not, we have to fight on two fronts to
upgrade the software.

Again, thanks for your fast and flourish reply :-)
Raymo


On 2021-08-09 18:03, Chris Riley wrote:
>> I'm not sure how miners will react to the two double-spend
> transactions and which one they will prefer.
>> Will they use the first seen transaction for block pre-image, or will
> use the transaction with higher transaction fee?
>> We need the help of Bitcoin core developers to clarify this
> transaction selection mechanism.  If miners
>> prefer the highest fee my scenario still is valid. But if miners
> always keep the first transaction received
>> and drop subsequent transactions,
> Hi,
> 
> Miners have the incentive to accept the highest fee transaction
> whenever they see it.  That does not imply that miners _will_ accept
> the highest fee transaction they see for a variety of reasons.  If a
> transaction does not signal RBF (BIP 125) then in general a "first
> seen" rule is applied, if a transaction does signal RBF, then in
> general the highest fee is prefered.  Since this is an untrusted
> network, a miner could use RBF even for transactions that don't signal
> it, since she could claim she saw it first, assuming the miner was
> aware of it which might imply it was submitted directly since the
> network might not relay a higher fee transaction for a non-RBF
> transaction.  Or a miner could see the first transaction and include
> it in a block just after the RBF transaction is broadcast but before
> the block is propagated. etc
> 
> So there is only a question of probabilities:  in general miners
> prefer the highest fee for RBF transactions and in general, miners
> will not replace a non-RBF transaction with a later one.  However,
> nothing is guaranteed given it is an untrusted network and people
> could use non-standard rules for selection of what transactions are
> included in a block.
> 
> :-)
> 
> On Mon, Aug 9, 2021 at 12:57 PM raymo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> Hi s7r,
>> I already answered to ZmnSCPxj's comments.
>> 
>> Let’s go to yours.
>> 
>>> If it is a child transaction of the Main Transaction
>> Sorry for my shortcoming in English, because it caused the
>> misunderstanding of proposal.
>> There is not any relation between Main Transaction and Guarantee
>> transaction. when I said “the Guarantee Transaction is created
>> based on
>> Main Transaction” I was intended only the numbers. I mean the
>> output
>> amounts of Guarantee Transaction are calculated relatively based on
>> Main
>> Transaction output amounts, in order to make a Guarantee Transaction
>> with relatively higher transaction fee. So, either of MT or GT can
>> be
>> broadcasted or toke place in next block independently.
>> 
>>> When Bob tries to broadcast the "guarantee transaction" he will
>> get an error:
>>> REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT
>> Here is the part which I am not sure you are right about it. I do
>> not
>> know in detail and I'm not sure how miners will react to the two
>> double-spend transactions and which one they will prefer.
>> Will they use the first seen transaction for block pre-image, or
>> will
>> use the transaction with higher transaction fee?
>> We need the help of Bitcoin core developers to clarify this
>> transaction
>> selection mechanism.
>> If miners prefer the highest fee my scenario still is valid. But if
>> miners always keep the first transaction received and drop
>> subsequent
>> transactions, I have three different solution to solve that I will
>> explain in later posts.
>> 
>>> 2. The creditor (Bob) has to leave his wallet running 24x7 and
>> ensure he is connected
>>> to the internet, otherwise if he loses connection to the internet
>> or energy supply,
>>> Alice attack will succeed entirely with 100% chances.
>>> So this means Bob needs to always be online like forever and ever.
>> Somehow you are right. Definitely Bob can delegate this task to a
>> doc-watcher, pretty much like watch-tower in Lightning, but due to
>> the
>> small amount of creditor's credits and the fact that this amount is
>> scattered among many different issuers, I removed this part from the
>> original design of Sabu architecture.
>> BTW major creditors, such as stores that receives debt-documents
>> worth
>> thousands of dollars a day, should (and better say must) always be
>> online to protect their money. This job also creates a safe margin
>> for
>> other creditors.
>> IMHO at the moment the protocol is good enough to start, but we can
>> always talk about improving the protocol.
>> 
>>> The 3rd one is hypothetical and you don't even have to answer it:
>>> 3. How does Bob (first creditor) spend the coins received /
>>> how does Bob become an issuer himself in relation to Dave (another
>> creditor)?
>>> What happens if Alice tries to fraud Bob after Bob spent its Sabu
>> credit to Dave?
>>> Dave has to hold all parent "guarantee transactions" and watch the
>> network for
>>> any potential fraudulent transactions that cancels his credit?
>> I already explained it in response of Billy here
>> 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019271.html
>> 
>> just look for “how normal transactions happen in their
>> entirety.”
>> 
>> Looking forward to hear from core developers about “how miners
>> will
>> react to the two double-spend transactions and which one they will
>> prefer”.
>> 
>> Regards
>> Raymo
>> 
>> On 2021-08-09 00:03, s7r wrote:
>>> raymo via bitcoin-dev wrote:
>>> 
>>> TL,DR: you were explained by ZmnSCPxj why this protocol will not
>> work.
>>> The possibility for just one party to sign will not work. I will
>>> explain again why but in much more simpler description.
>>> 
>>> 
>>>> Check out this simple transaction to learn more about how the
>> system
>>>> works.
>>>> Consider Alice as an issuer. She owns a UTXO worth 20,000
>> Satoshi. So,
>>>> she can spend it by create a transaction and sign it and
>> broadcast it to
>>>> Bitcoin network.
>>>> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys
>> 12,000
>>>> Satoshi from Alice in exchange.
>>>> Alice gets this 5$ and prepare a Main transaction that represents
>> this
>>>> liability of Alice to Bob.
>>>> 
>>>> Main Transaction (20,000 Sat input):
>>>> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000,
>> but Bob
>>>> has to pay 3,000 as BTC fee)
>>>> * Alice (issuer): 6,000 Sat
>>>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob)
>>>> This is a valid transaction and both Bob and/or Alice can send it
>> to
>>>> Bitcoin network, but none of them are interested in doing so.
>> Because
>>>> they will lose 5,000 Satoshi of their own money as Bitcoin
>> transaction
>>>> fee.
>>>> 
>>>> Alongside this transaction Alice (the issuer) has to create the
>>>> Guarantee Transaction as well and deliver it to Bob. Otherwise,
>> Bob will
>>>> not consider the deal completed. The Guarantee Transaction is
>> another
>>>> valid Bitcoin transaction. It is created based on Main
>> Transaction and
>>>> will cut a part of Bob and Alice money in favor of transaction
>> fee.
>>>> 
>>>> Guarantee Transaction (20,000 Sat input):
>>>> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 =
>> 1,740 Sat
>>>> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520
>> Sat
>>>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260
>> (from
>>>> Bob) + 3,480 (from Al-ice) = 15,739 Sat
>>>> 
>>>> The Guarantee Transaction applies when the issuer does not live
>> up to
>>>> its promise and intends to spend the promised UTXO(s) in a way
>> other
>>>> than that agreed upon. We already knew the fact that Sabu is not
>> a
>>>> custodial solution, neither a M of N signature schema. As a
>> result, the
>>>> UTXO owner always can spend the already promised UTXO(s) in Sabu
>>>> protocol or out of Sabu on Bitcoin blockchain, Contrary to what
>> was
>>>> promised.
>>>> When the Alice (issuer) breaks such a promise and sends the
>> fraudulent
>>>> transaction to the Bitcoin network, Bob's wallet realizes that
>> she
>>>> (issuer) is spending the promised UTXO(s) and it sends the
>> Guarantee
>>>> Transaction(s) to the network as a last resort. The miners will
>> face two
>>>> (or more) transactions which are spending same UTXO(s), but one
>> of them
>>>> is paying notably higher Bitcoin transaction fee, thus they chose
>> the
>>>> highest fee payer transaction, which is the Guarantee
>> Transaction. The
>>>> miner will put the Guarantee Transaction in next block and reject
>> the
>>>> rest double-spend transactions. Certainly, poor Bob cannot recoup
>> all
>>>> his Satoshis. But he can retrieve a portion of his money and
>> forces
>>>> Alice to lose some of her money as well. tit for tat!
>>>> Because of this mechanism, the issuer will try to not cheat on
>> creditor.
>>>> 
>>>> By the way there are some attacks that have very small chance to
>> succeed
>>>> but the risk to reward ratio for these scenarios are too high to
>> be
>>>> considered as a real possible attack threat. I will review them a
>> little
>>>> later in this post.
>>>> 
>>>> 
>>> 
>>> You said that the guarantee transaction is created based on Main
>>> Transaction, how do you mean? If it is a child transaction of the
>> Main
>>> Transaction it already doesn't work because Alice needs to
>> broadcast
>>> the *Main Transaction* to the blockchain in order for the
>> Guarantee
>>> transaction to be accepted, and of she does this, Bob doesn't care
>>> because the transaction pays to him already the correct agreed
>> amount.
>>> If you did not mean this, still it won't work, because
>>> 
>>> Simple:
>>> 1. Alice will create transaction #3, or call it
>>> Sabu-killing-transaction (20,000 Sat input):
>>> * Alice (issuer): 15,000 Sat
>>> * BTC Fee: 5,000 Sat
>>> 
>>> PERIOD.
>>> 
>>> When Bob tries to broadcast the "guarantee transaction" he will
>> get an
>>> error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The
>> much
>>> larger fee in the guarantee transaction will not matter. You have
>> to
>>> assume a miner will violate the Bitcoin protocol and somehow drop
>>> Sabu-killing-transaction from mempool and consider the Guarantee
>>> transaction only. This is very unlikely to happen and you might
>> also
>>> need connection direct with the miners because most full nodes
>> will
>>> not even accept the Guarantee transaction to their mempools in
>> order
>>> to further broadcast it until it reaches the miners.
>>> 
>>> With the simple attack described above Alice's chance to fraud Bob
>>> are, from my point of view, 99%.
>>> 
>>> (the only way to replace a transaction is Replace-By-Fee but this
>>> implies the transaction that IS TO BE REPLACED has a certain flag
>> set,
>>> and it is optional).
>>> 
>>> Given the Sabu-Killing-transaction comes first, Alice will of
>> course
>>> create it without this flag set so even if you add to Sabu the
>>> requirement of RBF enabled to the Guarantee transaction it will
>> not
>>> work, because it's the other way around.
>>> 
>>> 
>>> The second question is just for an observation that it has no real
>>> benefits over Lightning even if #1 wasn't true:
>>> 
>>> 2. The creditor (Bob) has to leave his wallet running 24x7 and
>> ensure
>>> he is connected to the internet, otherwise if he loses connection
>> to
>>> the internet or energy supply, Alice attack will succeed entirely
>> with
>>> 100% chances. So this means Bob needs to always be online like
>> forever
>>> and ever.
>>> 
>>> The 3rd one is hypothetical and you don't even have to answer it:
>>> 3. How does Bob (first creditor) spend the coins received / how
>> does
>>> Bob become an issuer himself in relation to Dave (another
>> creditor)?
>>> What happens if Alice tries to fraud Bob after Bob spent its Sabu
>>> credit to Dave? Dave has to hold all parent "guarantee
>> transactions"
>>> and watch the network for any potential fraudulent transactions
>> that
>>> cancels his credit?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev