path: root/48/dad44461066c203e3e8f155bcd35c4e99ca6af

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A75F0C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 17:58:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8BB2083C50
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 17:58:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.047
X-Spam-Level: 
X-Spam-Status: No, score=0.047 tagged_above=-999 required=5
 tests=[ADVANCE_FEE_3_NEW=2.145, BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 w4H-om_HcGJU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 17:58:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 9B7D783C04
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  2 Jul 2021 17:58:14 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id i24so14346683edx.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 02 Jul 2021 10:58:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=RjrSwFrq5QcrHN3w3PqCt2E0NjIN8Ov3NaknvpY/G34=;
 b=AJ3bouMVx87LskgJVLzmbOQE72U5AJPH64UWM7R2dQ7S9fE6BVLeGQxeYWKeDWrGBb
 XzFdmUnkmJUY/oOeqt3qHxIj/WGPeavh5P5CLvNp2Ur1XGnGjkK5kdor20sKvTduSSJp
 3Yheaj/Zvek/Z6aiJpIWb7yBCn7rihge06EuKClp1WJ1EnMi+kBzuWAes3oFfq1k91+f
 dnv/ryy/LXtAk8KclPwtSuGOXa1KkSLxBIwf2azhOw2wqCE0KgxXq29UvQ2xu8SskkiC
 DUmHxNb6Fb8VoclVlyUzeEWzs+eGyfCvNl/YHB4jWP8Hfn4/glBVKMWKOaNE4cuJKuPT
 HnDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=RjrSwFrq5QcrHN3w3PqCt2E0NjIN8Ov3NaknvpY/G34=;
 b=jZAkAbykyNApIt6if7IZ17oacbJp+MV2zfb6TTw4WR8FNqO3QLlJ2Aa638XuTcbn6L
 GZRXxk/ktGhADp+Ny14Uw/xVcCXM6wG0ugyv6ZVMXFu2fSSvKrNUdSG2nvWaCvp8E8sY
 CZVbUX22CbK3WEXLtOad4VHVzWQFhf2J0TyfImNOjTsGBW5a6xLwGy20r1LdL4X5Y74+
 qw3uGH7dhcivi3RiK9hXE8oEpFXZecyiRB9gN4y94pJFEIIbHmg9Fud4C7qcbhTp3PSw
 b9EafNZXtN0N4IJs6GQMOGidQMx5nCkeXie+RcFNI7RSPXfYxIuv1Q5yD2FlzgECH4ld
 NDTQ==
X-Gm-Message-State: AOAM532YnTwG1qzKZpxB5KAQEOWCUZ7rPvQPrBhqKhQ9qVeFPYjjUCtg
 VFlKDsGfAVnnR2Lb2uX700aXq1NFeyf8jhWA8zM=
X-Google-Smtp-Source: ABdhPJzrwX/hhN8IWbpt1Fg6YIV2BKW/ECIv43OjQ7RE9VQuZhsfDYhWIK/tJdMpeJMXv7of3MY07YYB8mC06RZCFIQ=
X-Received: by 2002:a05:6402:1d55:: with SMTP id
 dz21mr888954edb.338.1625248692665; 
 Fri, 02 Jul 2021 10:58:12 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <d8b3ba5b940473165ad72d689a01602a@riseup.net>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 2 Jul 2021 10:57:54 -0700
Message-ID: <CAGpPWDYAJE4jh=G2g=KSRuLLucEAyZGAD+r4XMpcmw6nk4+Wbg@mail.gmail.com>
To: raymo@riseup.net
Content-Type: multipart/alternative; boundary="000000000000ff814005c627b248"
X-Mailman-Approved-At: Fri, 02 Jul 2021 19:23:18 +0000
Cc: Bitcoin Protocol Discussion <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: Fri, 02 Jul 2021 17:58:17 -0000

--000000000000ff814005c627b248
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the details Raymo. A thought occurred to me. Given the fact that
miners can abuse this system without penalty, it would be useful to be able
to fix this. What if it was possible for the creditor to claw back the
funds even if the cheating transaction was mined instead of the guarantee
transaction? Let's say there was a way to sign a transaction that gives the
receiver of that transaction the ability to override any other transaction
that uses the UTXO? If this were possible, the issuer could give the
creditor this kind of transaction as the guarantee transaction, and in the
case a cheat was done, the creditor could still use the GT to reallocate
that UTXO to themselves.

Now there are issues with this. First of all, it could give anyone the
ability to double spend. So it would be prudent to limit this in some way.
The revocation probably should only be valid for up to 6 blocks, such that
if the transaction has 6 confirmations, it can no longer be reallocated
(thus preserving the 6 block finality rule). It could also be required that
the UTXO be marked as opting into this behavior (so receivers would know
about the possibility it could get revoked). This second requirement would
require Sabu issuers to make an on-chain transaction to set themselves
up as an issuer.

Another issue is that this would make it possible for transactions to
expire. Any claw-back transaction would expire 6 blocks after the initial
transaction happened. This has been generally avoided in bitcoin, but I
think the relevant issues are solvable. You can find additional discussion
of that in this thread
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.h=
tml>
.

I would imagine this kind of ability would be pretty controversial, but
since it can close out the possibility for miners to escape punishment, it
could make this protocol viable.

On Thu, Jul 1, 2021 at 3:15 PM <raymo@riseup.net> wrote:

>
> Hi Erik
>
> Please correct me if I misunderstood.
>
> > email is fully compromised.
>
> What I got is:
> Email is not good because the sender and receiver are compromised.
> Email is not good because the message content is revealed.
> I can claim same argue about any other client/server model. Since the
> server (website) service provider will ask some sort of KYC. And even if
> the server uses end-to-end encryption, the provider company still can
> read the packets content.
> In my model the passive listener only can discover who is communicate to
> whom and make a graph of connections. Although it is a threat for
> privacy but the server/client model has this flaw inherently, since
> provider already knew everything about everyone. In my model at least
> users can make some fake connections and send some fake emails in order
> to inject noise to communications.
> Please note the fact that entire communication between mobile wallets
> (via emails) are asymmetric PGP encrypted. The PGP keys are controlled
> by end users unlike ALL pretending secure messengers (e.g whatsApp,
> signal, zoom,=E2=80=A6).
> If you are worried about the way of exchanging PGP public key, you are
> right. The most secure way is in-person PGP key exchanging.
> After that for payments the wallets communicate in pgp encrypted
> messages and they can transfer Bitcoin address through an PGP encrypted
> cipher, thus no revealing Bitcoin address to public would occur. Neither
> the amounts of transactions will be reviled.
> There for it would be a good practice for shops to put their email and
> PGP public key on shop website and/or PGP public key servers, instead of
> putting Bitcoin address on website or using 3rd parties services to hide
> their Bitcoin payment addresses.
>
> If I missed some points about =E2=80=9Cfully compromised=E2=80=9D please =
write it to me.
>
>
> > public keys / addresses are sent
> As I told before ALL communication in Sabu are PGP encrypted.
>
> > other routing data encrypted with public keys
> >(not sure how data is routed in sabu)
>
> Sabu is not responsible for routing at all. It simply sends emails.
> Indeed the wallets peer-to-peer network in Sabu is pretty straight
> forward. Each mobile wallet has one email address as its handler and
> identifier in mobile-wallets-network. Each mobile can send message to
> another mobile by knowing its email address and the PGP public key.
> This information can be prepared in first face-to-face contact of mobile
> owners, or later (something like signing the other=E2=80=99s public key i=
n web
> of trust) when a creditor wants to spend his money and transfer it to
> another creditor. The creditor1 send the signed money transfer request
> alongside the email and public key of creditor2 all in a PGP encrypted
> message to issuer.
>
>
>
> > separate the Sabu protocol from the app... allow others to implement
> > desktop version, or other versions that use other routing systems
>
> Indeed, it is my approach too. As I told before users will decide
> between an unstoppable, permission less, self-sovereignty and
> decentralized pure peer-to-peer communication network (with some
> resolvable privacy issues) or some efficient, privacy-mimic central
> limited network.
>
>
> > you can allow direct-entry of a BIP-word-representation
> > of a public key/address to avoid privacy/central system concerns
> Agree. Actually, I was thinking about an easy mechanism to share your
> public key like what you suggested here.
> But what I consider for a =E2=80=9Ccentral system concerns=E2=80=9D is th=
e ability of
> communication without dependency to any company.
> As an example, what can you do if the twitter bans your account?
> Nothing! Your content and entire connections will be lost.
> But if you form your friends list in your mobile (or computer) and have
> their PGP public keys and they have yours, and use email as a dual
> purpose tool. First as a handler (the tool for finding and to be found
> in internet) and second as a communication tool.
> Thus, no one can stop you, ban you or limit you to send/receive
> transaction to/from anyone.
> What I am trying to say is using email is far better than account
> (username) in a limited central service like twitter, Facebook,
> telegram... or even in future Sabu servers!
> You have your connections under your control in your phone. You can
> easily change your email and use a new email or even a new service
> provider without losing your connections and your control over it.
> You just sign your new email address and send it to your friends circle
> and notify them about changes.
> Of course, email is not good for millions of followers but it is
> obviously good for managing your payment network of hundreds of people
> (either issuers or creditors).
>
> Best
> Raymo
>
> On 2021-07-01 20:49, Erik Aronesty wrote:
> > your protocol should always assume the email system is fully
> > compromised, and only send public information over email:
> >
> > - public keys / addresses are sent
> > - other routing data encrypted with public keys (not sure how data is
> > routed in sabu)
> >
> > your end user should be able to verify public keys  / addresses
> >
> >  - use QR-codes
> >  - phone calls with users reading BIP words out loud
> >  - other in-person information exchange
> >
> > separate the Sabu protocol from the app... allow others to implement
> > desktop version, or other versions that use other routing systems
> >
> > -  you can allow direct-entry of a BIP-word-representation of a public
> > key/address to avoid privacy/central system concerns
> >
> > On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Hi Billy,
> >> Sorry for late reply. Let=E2=80=99s jump in proposal.
> >>
> >> > Some more information about the benefits of this approach vs
> alternatives (mainly lightning)
> >> The most important different is unlike the lightning, in Sabu no one
> >> have to open a channel and pay Bitcoin transaction fee, subsequently n=
o
> >> one has to close channel and pay another Bitcoin transaction fee. It i=
s
> >> the huge improvement since it drops the overhead cost of transactions.
> >> So, it will be more convenience to trade under Sabu protocol.
> >> In Sabu none of parties of a transaction are obliged to block money in
> >> any kind of smart contract or any other m of n signature accounts
> >> on-chain, so it provides more privacy.
> >> Since Sabu protocol is designed to motivate people to circulate
> >> transactions (AKA debt documents) in Sabu network, if every actor act
> >> rationally no one will aware how much money transferred from who to
> >> whom.
> >> In case of fraudulent activity by issuer, the creditor will send
> >> Guarantee Transaction (GT) to Bitcoin network in order to recapture th=
e
> >> part of his credit. So, in this case the transaction is literally
> >> recorded on bitcoin blockchain.
> >> There is only one another reason to recording transaction on Bitcoin
> >> blockchain. Where one creditor eager to pay Bitcoin transaction fee in
> >> order to aggregate thousands or even millions different small amount
> >> debt-documents in a single transaction on Bitcoin blockchain.
> >> despite these two cases, the rest of transactions all occur in the Sab=
u
> >> network (supposed to be over 99%). Thus, no footprint no bottleneck an=
d
> >> no over process.
> >>
> >> Another important power point of Sabu is its pure-peer-to-peer network
> >> architecture. In Sabu the mobile wallets communicating to each other
> >> directly without any central server. There is no centralization at all=
.
> >> As a result, there will be no routing as well.
> >> Since only issuer and creditors are aware of the content of transactio=
n
> >> (who pay how much to whom) it is a huge privacy improvement, which
> >> doesn=E2=80=99t exist in other layer 2 solutions.
> >>
> >> About the usability of Sabu, although the protocol based on the
> >> collaborating 2 different peer-to-peer network and 3 classic
> >> server/client networks, but the end user (mobile wallet user) doesn=E2=
=80=99t
> >> see any of these complexities.
> >> The end user simply installs the mobile/desktop wallet and add her/his
> >> friends to his phonebook by adding their email address or scanning the=
ir
> >> email (and/or PGP public key). After that s/he can immediately start t=
o
> >> send/receive Bitcoin through Sabu network. Entire communications betwe=
en
> >> wallets are PGP encrypted.
> >> Another good point in Sabu design is, the 12 seed words are using for
> >> both Bitcoin wallet private key and the PGP private key. So, it is the
> >> key of user wealth and its identity as well. For more details, please
> >> read my previous answer to Alex Schoof.
> >> The issuer, by using his UTXOs and selling them to creditors earn mone=
y.
> >> the issuer creates the debt document (transaction) by which promises t=
o
> >> creditor an amount of satoshi. These debt documents are valid Bitcoin
> >> transaction. The only difference is these transactions are intended to
> >> circulate in Sabu protocol instead of sending to Bitcoin blockchain.
> >> Each transaction is a small money transfer. 40,000 Satoshi as input an=
d
> >> maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as Bitcoin
> >> transaction fee.
> >> The creditors will use these received transactions as money and will p=
ay
> >> it in exchange of goods or services. For each transaction the creditor
> >> pays 10 Satoshi as Sabu-transaction-fee to issuer.
> >> Sabu is not custodial service and the UXTOs are always under issuer
> >> control, unless issuer or creditor send the signed transaction to
> >> Bitcoin network. When the transaction was recorded in Bitcoin
> >> blockchain, the creditor can spend proper UTXO in Bitcoin network.
> >> Imagine million people use their UTXOs in Sabu, they are issuer and
> >> issue/update/cancel million transactions per second. All they need is =
a
> >> mobile wallet. On the other hand, every one by knowing an issuer can b=
uy
> >> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and spen=
d
> >> it, this time Alice really can buy caffe by Bitcoin ;)
> >> The Bar can install the mobile wallet and every day receives thousands
> >> of debt documents (transactions), each worth maximum 20,000 Satoshi in
> >> exchange of coffee. And every evening aggregates those small
> >> transactions to one single transaction and send it to Bitcoin network.
> >>
> >>
> >> The security model of Sabu is pretty straight forward.
> >> Issuer is the owner of UTXO(s) which will be used in transactions. The
> >> issuer is and will the only person who creates transactions and sign
> >> them. The transactions are valid transaction which either issuer or
> >> creditor can send them to Bitcoin network, but they will never send
> >> these transactions to Bitcoin network, because of the high Bitcoin
> >> transaction fee for each single transaction.
> >> Since issuer is the only one who can sign transaction (spend UTXOs),
> >> there is a risk of issuer cheating. And no one can stop issuer from
> >> cheating, because these are his UTXOs and he has the proper private
> >> keys.
> >> The Sabu solution is Guarantee transaction. It is a valid transaction
> >> that issuer has to sign it alongside the Main transaction. In GT both
> >> issuer and creditor cut a part of their output in favor of Bitcoin
> >> transaction fee.
> >> We suppose miners always seeking for more profit, thus in a case there
> >> are 2 or more transaction are spending same UTXO as input, miner will
> >> choose transaction with highest feeRate. There is no economically
> >> benefit for issuer to cheat creditors and pay less transaction fee
> >> simultaneously. So rationally the issuer won=E2=80=99t cheat creditor.
> >> It was the simplest explanation of Sabu security model.
> >>
> >> > I agree with others that using email is probably not appropriate for
> a protocol like this. I would highly recommend making your protocol
> transport-agnostic, allowing users of your protocol to use any transport
> they want.
> >> Indeed, the protocol is transparent-agnostic, if I insist of email as =
a
> >> user identifier and communicating tool is because of the idea of
> >> reforming part of internet architecture and make it more decentralized=
.
> >> The wallet users can choose classic architecture. In this case mobile
> >> wallets will connect to a central server and communicate through that
> >> server (pretty much like all existed mobile wallets). While some users
> >> decide to use a pure peer-to-peer communication. I knew email has some
> >> privacy issues but as always it is a tradeoff. Users can decide betwee=
n
> >> an unstoppable, permission less, self-sovereignty and decentralized pu=
re
> >> peer-to-peer communication network (with some resolvable privacy issue=
s)
> >> or some efficient central limited network.
> >> Let me know the critics about email. Hopefully this would lead us to
> >> improve email instead of letting it die. I strongly suggest email
> >> because it is the ONLY neutral, free =E2=80=9Cnonproprietary=E2=80=9D =
and open
> >> protocol/technology for communication in the world that its
> >> infrastructure is well-established and is accessible all over the glob=
.
> >>
> >> I tried to explain it more, hope was useful. By the way the complete
> >> explanation is here
> >>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-=
transactions-per-second-and-privacy-1eef8568d180
> >>
> >>
> >>
> >> Regards
> >> Raymo
> >>
> >>
> >>
> >> On 2021-06-22 18:20, Billy Tetrud wrote:
> >> > I would be interested in seeing some more information about the
> >> > benefits of this approach vs alternatives up front in this write up.
> >> > Eg how does the security, cost, usability, and privacy compare to th=
e
> >> > lightning network, which would be the most likely competitor to this
> >> > idea. It seems clear that there is more counterparty risk here, so i=
t
> >> > would probably also be very helpful to compare against traditional
> >> > custodial solutions as well. If you have specific claims on how this
> >> > system is better than eg lightning in certain contexts, it would be
> >> > far easier to evaluate the protocol against those claims, and would
> >> > also be a lot easier for readers to be motivated to read the whole
> >> > protocol and do a more full analysis.
> >> >
> >> > I agree with others that using email is probably not appropriate for=
 a
> >> > protocol like this. I would highly recommend making your protocol
> >> > transport-agnostic, allowing users of your protocol to use any
> >> > transport they want.
> >> >
> >> > On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev
> >> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >
> >> >> I think you're making a number of assumptions about mining that are
> >> >> not accurate.
> >> >>
> >> >>> First of all, how much chance in finding next block the corrupted
> >> >> miners have? One percent of all Bitcoin hash powers? Or maximum 5
> >> >> percent or 10? The cheaters must come up in dividing that 1.2
> >> >> Bitcoin between. After all the risk/reward must fit them. They can
> >> >> not be a big mining pool since there is no benefit, so they will be
> >> >> small miners with low hash rate. If they solve the puzzle and
> >> >> broadcast the block, no one in the entire Bitcoin network has block
> >> >> transactions or seen it before in their mempool!
> >> >>
> >> >> You're making the assumption that miners won't build on top of a
> >> >> block
> >> >> with transactions they have not seen before or transactions that ma=
y
> >> >> contain double spends of unconfirmed inputs, this is not how mining
> >> >> works, as long as the block passes the consensus rules effectively
> >> >> all
> >> >> miners will mine on top of it by default, this behavior is
> >> >> fundamental
> >> >> to how mining currently works and is fairly deeply baked into the
> >> >> current mining infrastructure.
> >> >>
> >> >>> Will they accept this block? In theory it is possible and have
> >> >> 0.01 percent chance but we can eliminate this small possibilities b=
y
> >> >> a simple BIP for miners.
> >> >>
> >> >> What would this BIP look like? I don't see how this could work in a
> >> >> decentralized way as you would need another way of reaching
> >> >> consensus
> >> >> on what defines a valid block. Right now the chance is nearly 100
> >> >> percent that a miner will mine on top of the latest valid block,
> >> >> many
> >> >> pools(most last I checked) will even mine on the next block before
> >> >> they validate the latest block fully(ie validationless mining) to
> >> >> reduce their orphan rates.
> >> >>
> >> >>> We suppose the miners always control transactions with
> >> >> doc-watchers and avoid accepting transaction with same UTXO but
> >> >> different output.
> >> >>
> >> >> Miners have different mempool policy/rules for what transactions
> >> >> they
> >> >> themselves mine but all miners must mine on the most work chain of
> >> >> valid blocks otherwise they risk their own blocks being orphaned,
> >> >> any
> >> >> miner that does not do this is effectively guaranteed to have their
> >> >> block orphaned right now.
> >> >>
> >> >>> Because of high Bitcoin transaction fee, this guarantee
> >> >> transaction will take place in next block, even if other transactio=
n
> >> >> which are using the same UTXO as input existed in mempool.
> >> >>
> >> >> When a new transaction is broadcast miners do not immediately start
> >> >> mining on a block template that includes that transaction, the
> >> >> template won't even be generated immediately when it enters a miner=
s
> >> >> mempool in practice, for bandwidth/network efficiency reasons minin=
g
> >> >> pools batch update the stratum templates/jobs they mine against so
> >> >> there can be significant latency between the time a transaction is
> >> >> actually broadcast and hits the miners mempool and the time the
> >> >> miners
> >> >> actually switch to mining on top it, these batched updates are
> >> >> essentially like point in time snapshots of the mempool and
> >> >> typically
> >> >> remain valid(as in the pool will accept shares submitted against
> >> >> that
> >> >> job as valid) until the bitcoin network finds the next block. I
> >> >> don't
> >> >> think these batch updates are done more often than every 30 seconds
> >> >> typically, while often it is on the order of multiple minutes
> >> >> depending on the pool.
> >> >>
> >> >> Regards,
> >> >> James
> >> >>
> >> >> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev
> >> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >>>
> >> >>> Hi,
> >> >>> I have a proposal for improve Bitcoin TPS and privacy, here is the
> >> >> post.
> >> >>>
> >> >>
> >> >
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-=
transactions-per-second-and-privacy-1eef8568d180
> >> >>> https://bitcointalk.org/index.php?topic=3D5344020.0
> >> >>> Can you please read it and share your idea about it.
> >> >>>
> >> >>> Cheers
> >> >>> Raymo
> >> >>> _______________________________________________
> >> >>> bitcoin-dev mailing list
> >> >>> bitcoin-dev@lists.linuxfoundation.org
> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> >> _______________________________________________
> >> >> bitcoin-dev mailing list
> >> >> bitcoin-dev@lists.linuxfoundation.org
> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000ff814005c627b248
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the details Raymo. A thought occurred=C2=A0to m=
e. Given the fact that miners can abuse this system without penalty, it wou=
ld be useful to be able to fix this. What if it was possible for the credit=
or to claw back the funds even if the cheating transaction was mined instea=
d of the guarantee transaction? Let&#39;s say there was a way to sign a tra=
nsaction that gives the receiver of that transaction the ability to overrid=
e any other transaction that uses the UTXO? If this were possible, the issu=
er could give the creditor this kind of transaction as the guarantee transa=
ction, and in the case a cheat was done, the creditor could still use the G=
T to reallocate that UTXO to themselves.<div><br></div><div>Now there are i=
ssues with this. First of all, it could give anyone the ability to double s=
pend. So it would be prudent to limit this in some way. The revocation prob=
ably should only be valid for up to 6 blocks, such that if the transaction =
has 6 confirmations, it can no longer be reallocated (thus preserving the 6=
 block finality rule). It could also be required that the UTXO be marked as=
 opting into this behavior (so receivers would know about the possibility i=
t could get revoked). This second requirement would require Sabu issuers to=
 make an on-chain transaction to set themselves up=C2=A0as an issuer.=C2=A0=
</div><div><br></div><div>Another issue is that this would make it possible=
 for transactions to expire. Any claw-back transaction would expire 6 block=
s after the initial transaction happened. This has been generally avoided i=
n bitcoin, but I think the relevant issues are solvable. You can find addit=
ional discussion of that <a href=3D"https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2021-June/019050.html">in this thread</a>.</div><div><br><=
/div><div>I would imagine this kind of ability would be pretty controversia=
l, but since it can close out the possibility for miners to escape punishme=
nt, it could make this protocol viable.=C2=A0</div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 1, 2021 at 3=
:15 PM &lt;<a href=3D"mailto:raymo@riseup.net">raymo@riseup.net</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi Erik<br>
<br>
Please correct me if I misunderstood.<br>
<br>
&gt; email is fully compromised. <br>
<br>
What I got is:<br>
Email is not good because the sender and receiver are compromised.<br>
Email is not good because the message content is revealed.<br>
I can claim same argue about any other client/server model. Since the<br>
server (website) service provider will ask some sort of KYC. And even if<br=
>
the server uses end-to-end encryption, the provider company still can<br>
read the packets content.<br>
In my model the passive listener only can discover who is communicate to<br=
>
whom and make a graph of connections. Although it is a threat for<br>
privacy but the server/client model has this flaw inherently, since<br>
provider already knew everything about everyone. In my model at least<br>
users can make some fake connections and send some fake emails in order<br>
to inject noise to communications.<br>
Please note the fact that entire communication between mobile wallets<br>
(via emails) are asymmetric PGP encrypted. The PGP keys are controlled<br>
by end users unlike ALL pretending secure messengers (e.g whatsApp,<br>
signal, zoom,=E2=80=A6).<br>
If you are worried about the way of exchanging PGP public key, you are<br>
right. The most secure way is in-person PGP key exchanging.<br>
After that for payments the wallets communicate in pgp encrypted<br>
messages and they can transfer Bitcoin address through an PGP encrypted<br>
cipher, thus no revealing Bitcoin address to public would occur. Neither<br=
>
the amounts of transactions will be reviled. <br>
There for it would be a good practice for shops to put their email and<br>
PGP public key on shop website and/or PGP public key servers, instead of<br=
>
putting Bitcoin address on website or using 3rd parties services to hide<br=
>
their Bitcoin payment addresses.<br>
<br>
If I missed some points about =E2=80=9Cfully compromised=E2=80=9D please wr=
ite it to me.<br>
<br>
<br>
&gt; public keys / addresses are sent<br>
As I told before ALL communication in Sabu are PGP encrypted.<br>
<br>
&gt; other routing data encrypted with public keys <br>
&gt;(not sure how data is routed in sabu)<br>
<br>
Sabu is not responsible for routing at all. It simply sends emails.<br>
Indeed the wallets peer-to-peer network in Sabu is pretty straight<br>
forward. Each mobile wallet has one email address as its handler and<br>
identifier in mobile-wallets-network. Each mobile can send message to<br>
another mobile by knowing its email address and the PGP public key. <br>
This information can be prepared in first face-to-face contact of mobile<br=
>
owners, or later (something like signing the other=E2=80=99s public key in =
web<br>
of trust) when a creditor wants to spend his money and transfer it to<br>
another creditor. The creditor1 send the signed money transfer request<br>
alongside the email and public key of creditor2 all in a PGP encrypted<br>
message to issuer.<br>
<br>
<br>
<br>
&gt; separate the Sabu protocol from the app... allow others to implement <=
br>
&gt; desktop version, or other versions that use other routing systems<br>
<br>
Indeed, it is my approach too. As I told before users will decide<br>
between an unstoppable, permission less, self-sovereignty and<br>
decentralized pure peer-to-peer communication network (with some<br>
resolvable privacy issues) or some efficient, privacy-mimic central<br>
limited network. <br>
<br>
<br>
&gt; you can allow direct-entry of a BIP-word-representation <br>
&gt; of a public key/address to avoid privacy/central system concerns<br>
Agree. Actually, I was thinking about an easy mechanism to share your<br>
public key like what you suggested here. <br>
But what I consider for a =E2=80=9Ccentral system concerns=E2=80=9D is the =
ability of<br>
communication without dependency to any company. <br>
As an example, what can you do if the twitter bans your account?<br>
Nothing! Your content and entire connections will be lost. <br>
But if you form your friends list in your mobile (or computer) and have<br>
their PGP public keys and they have yours, and use email as a dual<br>
purpose tool. First as a handler (the tool for finding and to be found<br>
in internet) and second as a communication tool.<br>
Thus, no one can stop you, ban you or limit you to send/receive<br>
transaction to/from anyone. <br>
What I am trying to say is using email is far better than account<br>
(username) in a limited central service like twitter, Facebook,<br>
telegram... or even in future Sabu servers!<br>
You have your connections under your control in your phone. You can<br>
easily change your email and use a new email or even a new service<br>
provider without losing your connections and your control over it. <br>
You just sign your new email address and send it to your friends circle<br>
and notify them about changes. <br>
Of course, email is not good for millions of followers but it is<br>
obviously good for managing your payment network of hundreds of people<br>
(either issuers or creditors).<br>
<br>
Best<br>
Raymo<br>
<br>
On 2021-07-01 20:49, Erik Aronesty wrote:<br>
&gt; your protocol should always assume the email system is fully<br>
&gt; compromised, and only send public information over email:<br>
&gt; <br>
&gt; - public keys / addresses are sent<br>
&gt; - other routing data encrypted with public keys (not sure how data is<=
br>
&gt; routed in sabu)<br>
&gt; <br>
&gt; your end user should be able to verify public keys=C2=A0 / addresses<b=
r>
&gt; <br>
&gt;=C2=A0 - use QR-codes<br>
&gt;=C2=A0 - phone calls with users reading BIP words out loud<br>
&gt;=C2=A0 - other in-person information exchange<br>
&gt; <br>
&gt; separate the Sabu protocol from the app... allow others to implement<b=
r>
&gt; desktop version, or other versions that use other routing systems<br>
&gt; <br>
&gt; -=C2=A0 you can allow direct-entry of a BIP-word-representation of a p=
ublic<br>
&gt; key/address to avoid privacy/central system concerns<br>
&gt; <br>
&gt; On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi Billy,<br>
&gt;&gt; Sorry for late reply. Let=E2=80=99s jump in proposal.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Some more information about the benefits of this approach vs =
alternatives (mainly lightning)<br>
&gt;&gt; The most important different is unlike the lightning, in Sabu no o=
ne<br>
&gt;&gt; have to open a channel and pay Bitcoin transaction fee, subsequent=
ly no<br>
&gt;&gt; one has to close channel and pay another Bitcoin transaction fee. =
It is<br>
&gt;&gt; the huge improvement since it drops the overhead cost of transacti=
ons.<br>
&gt;&gt; So, it will be more convenience to trade under Sabu protocol.<br>
&gt;&gt; In Sabu none of parties of a transaction are obliged to block mone=
y in<br>
&gt;&gt; any kind of smart contract or any other m of n signature accounts<=
br>
&gt;&gt; on-chain, so it provides more privacy.<br>
&gt;&gt; Since Sabu protocol is designed to motivate people to circulate<br=
>
&gt;&gt; transactions (AKA debt documents) in Sabu network, if every actor =
act<br>
&gt;&gt; rationally no one will aware how much money transferred from who t=
o<br>
&gt;&gt; whom.<br>
&gt;&gt; In case of fraudulent activity by issuer, the creditor will send<b=
r>
&gt;&gt; Guarantee Transaction (GT) to Bitcoin network in order to recaptur=
e the<br>
&gt;&gt; part of his credit. So, in this case the transaction is literally<=
br>
&gt;&gt; recorded on bitcoin blockchain.<br>
&gt;&gt; There is only one another reason to recording transaction on Bitco=
in<br>
&gt;&gt; blockchain. Where one creditor eager to pay Bitcoin transaction fe=
e in<br>
&gt;&gt; order to aggregate thousands or even millions different small amou=
nt<br>
&gt;&gt; debt-documents in a single transaction on Bitcoin blockchain.<br>
&gt;&gt; despite these two cases, the rest of transactions all occur in the=
 Sabu<br>
&gt;&gt; network (supposed to be over 99%). Thus, no footprint no bottlenec=
k and<br>
&gt;&gt; no over process.<br>
&gt;&gt;<br>
&gt;&gt; Another important power point of Sabu is its pure-peer-to-peer net=
work<br>
&gt;&gt; architecture. In Sabu the mobile wallets communicating to each oth=
er<br>
&gt;&gt; directly without any central server. There is no centralization at=
 all.<br>
&gt;&gt; As a result, there will be no routing as well.<br>
&gt;&gt; Since only issuer and creditors are aware of the content of transa=
ction<br>
&gt;&gt; (who pay how much to whom) it is a huge privacy improvement, which=
<br>
&gt;&gt; doesn=E2=80=99t exist in other layer 2 solutions.<br>
&gt;&gt;<br>
&gt;&gt; About the usability of Sabu, although the protocol based on the<br=
>
&gt;&gt; collaborating 2 different peer-to-peer network and 3 classic<br>
&gt;&gt; server/client networks, but the end user (mobile wallet user) does=
n=E2=80=99t<br>
&gt;&gt; see any of these complexities.<br>
&gt;&gt; The end user simply installs the mobile/desktop wallet and add her=
/his<br>
&gt;&gt; friends to his phonebook by adding their email address or scanning=
 their<br>
&gt;&gt; email (and/or PGP public key). After that s/he can immediately sta=
rt to<br>
&gt;&gt; send/receive Bitcoin through Sabu network. Entire communications b=
etween<br>
&gt;&gt; wallets are PGP encrypted.<br>
&gt;&gt; Another good point in Sabu design is, the 12 seed words are using =
for<br>
&gt;&gt; both Bitcoin wallet private key and the PGP private key. So, it is=
 the<br>
&gt;&gt; key of user wealth and its identity as well. For more details, ple=
ase<br>
&gt;&gt; read my previous answer to Alex Schoof.<br>
&gt;&gt; The issuer, by using his UTXOs and selling them to creditors earn =
money.<br>
&gt;&gt; the issuer creates the debt document (transaction) by which promis=
es to<br>
&gt;&gt; creditor an amount of satoshi. These debt documents are valid Bitc=
oin<br>
&gt;&gt; transaction. The only difference is these transactions are intende=
d to<br>
&gt;&gt; circulate in Sabu protocol instead of sending to Bitcoin blockchai=
n.<br>
&gt;&gt; Each transaction is a small money transfer. 40,000 Satoshi as inpu=
t and<br>
&gt;&gt; maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as Bit=
coin<br>
&gt;&gt; transaction fee.<br>
&gt;&gt; The creditors will use these received transactions as money and wi=
ll pay<br>
&gt;&gt; it in exchange of goods or services. For each transaction the cred=
itor<br>
&gt;&gt; pays 10 Satoshi as Sabu-transaction-fee to issuer.<br>
&gt;&gt; Sabu is not custodial service and the UXTOs are always under issue=
r<br>
&gt;&gt; control, unless issuer or creditor send the signed transaction to<=
br>
&gt;&gt; Bitcoin network. When the transaction was recorded in Bitcoin<br>
&gt;&gt; blockchain, the creditor can spend proper UTXO in Bitcoin network.=
<br>
&gt;&gt; Imagine million people use their UTXOs in Sabu, they are issuer an=
d<br>
&gt;&gt; issue/update/cancel million transactions per second. All they need=
 is a<br>
&gt;&gt; mobile wallet. On the other hand, every one by knowing an issuer c=
an buy<br>
&gt;&gt; some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and =
spend<br>
&gt;&gt; it, this time Alice really can buy caffe by Bitcoin ;)<br>
&gt;&gt; The Bar can install the mobile wallet and every day receives thous=
ands<br>
&gt;&gt; of debt documents (transactions), each worth maximum 20,000 Satosh=
i in<br>
&gt;&gt; exchange of coffee. And every evening aggregates those small<br>
&gt;&gt; transactions to one single transaction and send it to Bitcoin netw=
ork.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The security model of Sabu is pretty straight forward.<br>
&gt;&gt; Issuer is the owner of UTXO(s) which will be used in transactions.=
 The<br>
&gt;&gt; issuer is and will the only person who creates transactions and si=
gn<br>
&gt;&gt; them. The transactions are valid transaction which either issuer o=
r<br>
&gt;&gt; creditor can send them to Bitcoin network, but they will never sen=
d<br>
&gt;&gt; these transactions to Bitcoin network, because of the high Bitcoin=
<br>
&gt;&gt; transaction fee for each single transaction.<br>
&gt;&gt; Since issuer is the only one who can sign transaction (spend UTXOs=
),<br>
&gt;&gt; there is a risk of issuer cheating. And no one can stop issuer fro=
m<br>
&gt;&gt; cheating, because these are his UTXOs and he has the proper privat=
e<br>
&gt;&gt; keys.<br>
&gt;&gt; The Sabu solution is Guarantee transaction. It is a valid transact=
ion<br>
&gt;&gt; that issuer has to sign it alongside the Main transaction. In GT b=
oth<br>
&gt;&gt; issuer and creditor cut a part of their output in favor of Bitcoin=
<br>
&gt;&gt; transaction fee.<br>
&gt;&gt; We suppose miners always seeking for more profit, thus in a case t=
here<br>
&gt;&gt; are 2 or more transaction are spending same UTXO as input, miner w=
ill<br>
&gt;&gt; choose transaction with highest feeRate. There is no economically<=
br>
&gt;&gt; benefit for issuer to cheat creditors and pay less transaction fee=
<br>
&gt;&gt; simultaneously. So rationally the issuer won=E2=80=99t cheat credi=
tor.<br>
&gt;&gt; It was the simplest explanation of Sabu security model.<br>
&gt;&gt;<br>
&gt;&gt; &gt; I agree with others that using email is probably not appropri=
ate for a protocol like this. I would highly recommend making your protocol=
 transport-agnostic, allowing users of your protocol to use any transport t=
hey want.<br>
&gt;&gt; Indeed, the protocol is transparent-agnostic, if I insist of email=
 as a<br>
&gt;&gt; user identifier and communicating tool is because of the idea of<b=
r>
&gt;&gt; reforming part of internet architecture and make it more decentral=
ized.<br>
&gt;&gt; The wallet users can choose classic architecture. In this case mob=
ile<br>
&gt;&gt; wallets will connect to a central server and communicate through t=
hat<br>
&gt;&gt; server (pretty much like all existed mobile wallets). While some u=
sers<br>
&gt;&gt; decide to use a pure peer-to-peer communication. I knew email has =
some<br>
&gt;&gt; privacy issues but as always it is a tradeoff. Users can decide be=
tween<br>
&gt;&gt; an unstoppable, permission less, self-sovereignty and decentralize=
d pure<br>
&gt;&gt; peer-to-peer communication network (with some resolvable privacy i=
ssues)<br>
&gt;&gt; or some efficient central limited network.<br>
&gt;&gt; Let me know the critics about email. Hopefully this would lead us =
to<br>
&gt;&gt; improve email instead of letting it die. I strongly suggest email<=
br>
&gt;&gt; because it is the ONLY neutral, free =E2=80=9Cnonproprietary=E2=80=
=9D and open<br>
&gt;&gt; protocol/technology for communication in the world that its<br>
&gt;&gt; infrastructure is well-established and is accessible all over the =
glob.<br>
&gt;&gt;<br>
&gt;&gt; I tried to explain it more, hope was useful. By the way the comple=
te<br>
&gt;&gt; explanation is here<br>
&gt;&gt; <a href=3D"https://raymo-49157.medium.com/time-to-boost-bitcoin-ci=
rculation-million-transactions-per-second-and-privacy-1eef8568d180" rel=3D"=
noreferrer" target=3D"_blank">https://raymo-49157.medium.com/time-to-boost-=
bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d18=
0</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Regards<br>
&gt;&gt; Raymo<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 2021-06-22 18:20, Billy Tetrud wrote:<br>
&gt;&gt; &gt; I would be interested in seeing some more information about t=
he<br>
&gt;&gt; &gt; benefits of this approach vs alternatives up front in this wr=
ite up.<br>
&gt;&gt; &gt; Eg how does the security, cost, usability, and privacy compar=
e to the<br>
&gt;&gt; &gt; lightning network, which would be the most likely competitor =
to this<br>
&gt;&gt; &gt; idea. It seems clear that there is more counterparty risk her=
e, so it<br>
&gt;&gt; &gt; would probably also be very helpful to compare against tradit=
ional<br>
&gt;&gt; &gt; custodial solutions as well. If you have specific claims on h=
ow this<br>
&gt;&gt; &gt; system is better than eg lightning in certain contexts, it wo=
uld be<br>
&gt;&gt; &gt; far easier to evaluate the protocol against those claims, and=
 would<br>
&gt;&gt; &gt; also be a lot easier for readers to be motivated to read the =
whole<br>
&gt;&gt; &gt; protocol and do a more full analysis.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I agree with others that using email is probably not appropri=
ate for a<br>
&gt;&gt; &gt; protocol like this. I would highly recommend making your prot=
ocol<br>
&gt;&gt; &gt; transport-agnostic, allowing users of your protocol to use an=
y<br>
&gt;&gt; &gt; transport they want.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-de=
v<br>
&gt;&gt; &gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; I think you&#39;re making a number of assumptions about m=
ining that are<br>
&gt;&gt; &gt;&gt; not accurate.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; First of all, how much chance in finding next block t=
he corrupted<br>
&gt;&gt; &gt;&gt; miners have? One percent of all Bitcoin hash powers? Or m=
aximum 5<br>
&gt;&gt; &gt;&gt; percent or 10? The cheaters must come up in dividing that=
 1.2<br>
&gt;&gt; &gt;&gt; Bitcoin between. After all the risk/reward must fit them.=
 They can<br>
&gt;&gt; &gt;&gt; not be a big mining pool since there is no benefit, so th=
ey will be<br>
&gt;&gt; &gt;&gt; small miners with low hash rate. If they solve the puzzle=
 and<br>
&gt;&gt; &gt;&gt; broadcast the block, no one in the entire Bitcoin network=
 has block<br>
&gt;&gt; &gt;&gt; transactions or seen it before in their mempool!<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; You&#39;re making the assumption that miners won&#39;t bu=
ild on top of a<br>
&gt;&gt; &gt;&gt; block<br>
&gt;&gt; &gt;&gt; with transactions they have not seen before or transactio=
ns that may<br>
&gt;&gt; &gt;&gt; contain double spends of unconfirmed inputs, this is not =
how mining<br>
&gt;&gt; &gt;&gt; works, as long as the block passes the consensus rules ef=
fectively<br>
&gt;&gt; &gt;&gt; all<br>
&gt;&gt; &gt;&gt; miners will mine on top of it by default, this behavior i=
s<br>
&gt;&gt; &gt;&gt; fundamental<br>
&gt;&gt; &gt;&gt; to how mining currently works and is fairly deeply baked =
into the<br>
&gt;&gt; &gt;&gt; current mining infrastructure.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Will they accept this block? In theory it is possible=
 and have<br>
&gt;&gt; &gt;&gt; 0.01 percent chance but we can eliminate this small possi=
bilities by<br>
&gt;&gt; &gt;&gt; a simple BIP for miners.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; What would this BIP look like? I don&#39;t see how this c=
ould work in a<br>
&gt;&gt; &gt;&gt; decentralized way as you would need another way of reachi=
ng<br>
&gt;&gt; &gt;&gt; consensus<br>
&gt;&gt; &gt;&gt; on what defines a valid block. Right now the chance is ne=
arly 100<br>
&gt;&gt; &gt;&gt; percent that a miner will mine on top of the latest valid=
 block,<br>
&gt;&gt; &gt;&gt; many<br>
&gt;&gt; &gt;&gt; pools(most last I checked) will even mine on the next blo=
ck before<br>
&gt;&gt; &gt;&gt; they validate the latest block fully(ie validationless mi=
ning) to<br>
&gt;&gt; &gt;&gt; reduce their orphan rates.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; We suppose the miners always control transactions wit=
h<br>
&gt;&gt; &gt;&gt; doc-watchers and avoid accepting transaction with same UT=
XO but<br>
&gt;&gt; &gt;&gt; different output.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Miners have different mempool policy/rules for what trans=
actions<br>
&gt;&gt; &gt;&gt; they<br>
&gt;&gt; &gt;&gt; themselves mine but all miners must mine on the most work=
 chain of<br>
&gt;&gt; &gt;&gt; valid blocks otherwise they risk their own blocks being o=
rphaned,<br>
&gt;&gt; &gt;&gt; any<br>
&gt;&gt; &gt;&gt; miner that does not do this is effectively guaranteed to =
have their<br>
&gt;&gt; &gt;&gt; block orphaned right now.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Because of high Bitcoin transaction fee, this guarant=
ee<br>
&gt;&gt; &gt;&gt; transaction will take place in next block, even if other =
transaction<br>
&gt;&gt; &gt;&gt; which are using the same UTXO as input existed in mempool=
.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; When a new transaction is broadcast miners do not immedia=
tely start<br>
&gt;&gt; &gt;&gt; mining on a block template that includes that transaction=
, the<br>
&gt;&gt; &gt;&gt; template won&#39;t even be generated immediately when it =
enters a miners<br>
&gt;&gt; &gt;&gt; mempool in practice, for bandwidth/network efficiency rea=
sons mining<br>
&gt;&gt; &gt;&gt; pools batch update the stratum templates/jobs they mine a=
gainst so<br>
&gt;&gt; &gt;&gt; there can be significant latency between the time a trans=
action is<br>
&gt;&gt; &gt;&gt; actually broadcast and hits the miners mempool and the ti=
me the<br>
&gt;&gt; &gt;&gt; miners<br>
&gt;&gt; &gt;&gt; actually switch to mining on top it, these batched update=
s are<br>
&gt;&gt; &gt;&gt; essentially like point in time snapshots of the mempool a=
nd<br>
&gt;&gt; &gt;&gt; typically<br>
&gt;&gt; &gt;&gt; remain valid(as in the pool will accept shares submitted =
against<br>
&gt;&gt; &gt;&gt; that<br>
&gt;&gt; &gt;&gt; job as valid) until the bitcoin network finds the next bl=
ock. I<br>
&gt;&gt; &gt;&gt; don&#39;t<br>
&gt;&gt; &gt;&gt; think these batch updates are done more often than every =
30 seconds<br>
&gt;&gt; &gt;&gt; typically, while often it is on the order of multiple min=
utes<br>
&gt;&gt; &gt;&gt; depending on the pool.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regards,<br>
&gt;&gt; &gt;&gt; James<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev<br>
&gt;&gt; &gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Hi,<br>
&gt;&gt; &gt;&gt;&gt; I have a proposal for improve Bitcoin TPS and privacy=
, here is the<br>
&gt;&gt; &gt;&gt; post.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt; <a href=3D"https://raymo-49157.medium.com/time-to-boost-bitco=
in-circulation-million-transactions-per-second-and-privacy-1eef8568d180" re=
l=3D"noreferrer" target=3D"_blank">https://raymo-49157.medium.com/time-to-b=
oost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef85=
68d180</a><br>
&gt;&gt; &gt;&gt;&gt; <a href=3D"https://bitcointalk.org/index.php?topic=3D=
5344020.0" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/ind=
ex.php?topic=3D5344020.0</a><br>
&gt;&gt; &gt;&gt;&gt; Can you please read it and share your idea about it.<=
br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Cheers<br>
&gt;&gt; &gt;&gt;&gt; Raymo<br>
&gt;&gt; &gt;&gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; &gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; &gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/=
listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; &gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; &gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/list=
info/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ff814005c627b248--