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>
In-Reply-To: <f46159f0286fe48720bc3f3fead1b575@riseup.net>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 1 Jul 2021 16:49:16 -0400
Message-ID: <CAJowKgKELBmLdA-w5ghGoiWe5RQdNkKsV3OGRFbDJCOeA04AWw@mail.gmail.com>
To: raymo@riseup.net, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Boost Bitcoin circulation,
 Million Transactions Per Second with stronger privacy
Precedence: list

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 alternativ=
es (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 no
> one has to close channel and pay another Bitcoin transaction fee. It is
> 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 the
> 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 Sabu
> network (supposed to be over 99%). Thus, no footprint no bottleneck and
> 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 transaction
> (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 their
> email (and/or PGP public key). After that s/he can immediately start to
> send/receive Bitcoin through Sabu network. Entire communications between
> 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 money.
> the issuer creates the debt document (transaction) by which promises to
> 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 and
> 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 pay
> 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 buy
> some Satoshi (whit absolutely no KYC), even 1 Dollar or less, and spend
> 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 between
> an unstoppable, permission less, self-sovereignty and decentralized pure
> peer-to-peer communication network (with some resolvable privacy issues)
> 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 the
> > lightning network, which would be the most likely competitor to this
> > idea. It seems clear that there is more counterparty risk here, so it
> > 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 may
> >> 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 by
> >> 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 transaction
> >> 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 miners
> >> mempool in practice, for bandwidth/network efficiency reasons mining
> >> 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-millio=
n-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