đź“… Original date posted:2021-07-17
đź“ť Original message:After introducing Sabu protocol as a solution for Bitcoin scaling
(https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180),
I shared this idea with Bitcoin developers through the bitcoin-dev
mailing list.
I got some constructive feedbacks and critiques leading me to add this
part to the proposal which I was skipped due to brevity of proposal
introduction.
Here I will investigate on more real live scenarios, general usages and
corner cases, and the consequences of some attacks or buggy
implementation of protocol, as well as different actors (malicious,
irrational, profit seeker, griefer, stupid, reckless, incompetent, etc.)
activity effects.
In proposal introduction (previous post), I did not talk about Lightning
deliberately, although it seems that this solution is an alternative to
Lightning.
Most of readers misunderstood Sabu and asking what differs it from
Lightning?
Indeed, Sabu has nothing with Lightning. It has totally different
design, network architecture, security model and implementation. The
only thing in common with Lightning is both are intended to cover micro
payments.
The good thing about Bitcoin is that it does not require any kind of
permission. Consequently, related products do not need to ask permission
too. We are in a permission-less free market. I think Sabu will work
perfectly and if a group of users think like me, we are done. Sabu will
work parallel the other scaling solutions without need to drive them
out.
However, I have made a comparison between Sabu, on-chain and Lightning
transactions to get a clearer understanding of the advantages and
disadvantages of Sabu and answer to “why we should implement and use
Sabu in our day-to-day deals”.
Most probably this paper is not comprehensive document, therefore this
article will be updated.
You will find the complete post here:
https://raymo-49157.medium.com/scaling-bitcoin-by-sabu-protocol-risks-and-benefits-62157f8a664e
Raymo
On 2021-07-07 03:20, Billy Tetrud wrote:
>> As far as I know the “claw back” mechanism doesn’t exist in
> Bitcoin
> system, and probably most Bitcoiners won’t be agree on it.
>
> It certainly doesn't. And it would definitely be a hard sell.
>
>> It looks the miners still can abuse Sabu, but as I told before the
> mineror better say the mining pool must be issuer .. or must be
> creditor .. or collaborate one of them in a
> conspiracy.
>
> Yes. But it certainly incentivizes miners to become creditors and scam
> people. Even if a small miner who mines one block a year does this,
> they can mine all Guarantee Transactions in their possession. Larger
> miners that mine one block every few days can scam that much more
> often. Even with $5 credits, that could be an extra $9000 gained in a
> block. That's pretty substantial when fees are totaling around $45,000
> per block.
>
>> would be resolved by a slightly upgrade in Bitcoin protocol by
> applying the BIPxxx “for flagging/unflagging promised UTXOs”
>
> As others have mentioned tho, doing something like that would be at
> very least quite complex, and at worst impossible to do securely. The
> whole reason why bitcoin's blockchain exists in the first place is to
> be a single source of truth for transactions. The mempool is not a
> source of truth for consensus. The Sabu network could not be a source
> of truth either for consensus, without some serious innovations (that
> may not be possible). It isn't as simple as you seem to be thinking.
>
>> The new transaction will use same 40,000 UTXO as input and the
> outputs will be 6,500 Sat for creditor (he pays 2,500 Sat for
> transaction fee) 4,500 Sat for creditor 2
>
> This is the part I was unable to find/understand quickly enough in the
> original write up. So for creditor 1 to pay creditor 2, a new main
> transaction and guarantee transaction are created that credit the
> appropriate people, right? FYI, the MT and GT acronyms make it harder
> for me to read/understand, so I'm preferring to write them out. But
> that helps. Let me write this out in a different (more compact) way:
>
> 1. Creditor A $5 -> Issuer
>
> 2. Issuer creates and shares transactions:
>
> Main Transaction (40k sats):
> * Issuer: 19k sats
> * Creditor A: 11k sats
> * Fee: 10k sats (4k from creditor, 6k from issuer)
>
> Guarantee Transaction (40k sats):
> * Issuer: 13,300 sats
> * Creditor A: 1650 sats
> * Fee: 25,050 sats
>
> 3. Creditor A, 6k sats -> Creditor B. Issuer creates and shares
> transactions:
>
> Main Transaction (40k sats):
> * Issuer: 19k sats* Creditor A: 6,500 sats
> * Creditor B: 4,500 sats
>
> * Fee: 10k sats (4k from creditor, 6k from issuer)
>
> Guarantee Transaction (40k sats):
> * Issuer: 13300 sats* Creditor A: 975 sats
> * Creditor B: 675 sats
> * Fee: 25050 sats
>
> Is this right?
>
>> The miner attack is just a failed plan as I explained before
>
> I thought you acknowledged that the miner attack is an issue above.
> No?
>
>>> Sabu has slightly greater risk comparing lightning
>> It is not true,
>
> What I mean is that a violation of trust results in more damaging
> effects with Sabu than with lightning. In lightning, if your channel
> partner cheats, at worst you must simply pay a normal transaction fee.
> With Sabu, if a creditor cheats, you will likely pay an abnormally
> large transaction fee. This is what I mean by "greater risk". Some
> attackers are what's known as griefers - these are people willing to
> spend time and money hurting someone else, even if they don't make a
> profit from it (other than schadenfreude). It seems clear there is a
> greater risk of being griefed in Sabu than in lightning.
>
> Furthermore, while in lightning, if you perform the protocol properly,
> your funds can never be stolen except in very extreme circumstances
> (eg widespread long-running network congestion that prevents
> confirming a revoke transaction). By contrast, Sabu has a significant
> likelihood that a cheating transaction could be mined instead of the
> guarantee transaction. Perhaps the likelihood is approximately 2
> seconds / 10 minutes (0.3% chance), but a 0.3% is clearly larger than
> approximately 0% chance in lightning. Again, this is another part of
> what I mean by "higher risk".
>
> These are both real counterparty risks that you shouldn't simply
> ignore. It may be true that no rational actor will attempt an attack,
> however not all actors are rational. People also make mistakes, write
> buggy software, etc etc. The existence of risk doesn't ruin your idea
> - every protocol has risks. But identifying the specific risks is the
> only way to compare the properties against alternatives (like on chain
> transactions or the lightning network). I think its important to
> acknowledge these risks in your write up.
>
>> I explained before this kind of attacks will not happened never
>
> If people use your protocol, some will inevitably use it wrong. Those
> that use it wrong should be the ones that pay the price for it - but
> it is a downside of the protocol if the counter party of the person
> that makes a mistake (or attempts something malicious) is harmed as a
> result. Again, these kinds of trade offs are ok, but you should not be
> assuming that attacks like this will never happen. They will happen
> sometimes. You must assume that. The question is what is the result
> when an attack is attempted? And how will that affect what kinds of
> actors will attempt an attack (malicious, profit seeking, honest,
> stupid, wreckless, incompetent, other types of actors etc etc)?
>
>> I didn’t find any case Lightning can compete with Sabu.
>
> As I explained above related to risk, there are trade offs. I would
> like to see in your write up a clear list of these trade offs. The
> additional risk (as I explained it above) is one trade off. It sounds
> like there are limits in which a creditor or issuer can safely rely on
> incentives to prevent attacks. Did you specify what those limits are?
> The Lightning network also has limits - eg a lightning node can't
> allow its channel partner to spend 100% of their coins without taking
> on additional risk of attack. How do those limits compare in Sabu? For
> example, an issuer couldn't allow any creditor to spend so much of
> their credited bitcoin that their credit goes below the amount they
> would receive in any past Guarantee Transaction without taking on the
> risk that the creditor would post that guarantee transaction and
> receive coins they shouldn't own anymore. I would love to see a more
> detailed comparison of Sabu to lightning.
>
> If your protocol works out, there are obvious benefits: transactions
> that could be done with no on-chain footprint. However, even if the
> protocol works out, there are trade offs and those trade offs should
> be made very clear. Even if the comparative downsides are small.
>
> ~BT
>
>> Hi Billy
>>> high-level overview of how all the pieces (How Sabu protocol
>> works).
>>> how normal transactions happen in their entirety.
>> Ok, lets re-explain Sabu. In Sabu protocol we have two type of
>> actors.
>> The issuers who own Bitcoin (they own UTXOs on Bitcoin blockchain),
>> and
>> the creditors who will own Bitcoins (the UTXOs on Bitcoin
>> blockchain),
>> if the issuer or the creditor sends the prepared transaction to
>> Bitcoin
>> network. But for know creditors have the transaction in their hand.
>> Before sending this transaction to Bitcoin network it acts (in Sabu
>> protocol and Sabu network) as a liability of issuer.
>> The story always starts from issuer, the person who get money or
>> goods
>> or services from a creditor and in exchange creates and sings a
>> valid
>> Bitcoin transaction by which the issuer spends his UTXO and as a one
>> of
>> the outputs of the transaction, there will be an output for
>> creditor’s
>> address equal to the money issuer already get paid.
>> This transaction is a valid transaction which is signed “only”
>> by
>> issuer. The outputs of transaction are just and exact balance of the
>> parties (issuer and creditor).
>> Lets, imagine the creditor payed 5$ (almost equal to 15,000 Sat) to
>> issuer. Thus, issuer will create and sign a transaction by which he
>> spends 40,000 Sat and the outputs will be
>> 11,000 for creditor (the creditor has to pay 4,000 Sat in favor of
>> transaction fee),
>> 10,000 for Bitcoin-transaction-fee (4,000 by creditor and 6,000 by
>> issuer) and
>> 19,000 change back to issuer account address.
>> It is our Main Transaction (MT) which is a pretty normal and valid
>> transaction.
>> Alongside the MT, issuer creates and signs a Guarantee Transaction
>> (GT).
>> In GT issuer spends same 40,000 Sat UTXO as input, and as outputs
>> the creditor will get 15% of his 11,000 Sat in Main Transaction.
>> Thus
>> the creditor output will be 1,650 Sat and the rest of creditor’s
>> money
>> (11,000 – 1,650 = 9,350 Sat) will be added to transaction fee.
>> In GT also issuer will lose a part of his money. New output for
>> issuer
>> will be 19,000 * 70% = 13,300 and the rest will be added to
>> transaction
>> fee (19,000 – 13,300 = 5,700 Sat)
>> Thus, the new transaction fee in GT will be 10,000 + 9,350 + 5,700 =
>> 25,050 Sat
>> Now the creditor has 2 valid transactions (MT and GT) in his hands.
>> He
>> can send either MT or GT or both to Bitcoin Network. But in all
>> cases,
>> he will lose a portion of his money in favor of transaction fee
>> (miner’s
>> income). So, rationally he will never send transactions to Bitcoin
>> network unless he wants consciously hurt himself.
>> The creditor always prefers to spend his credit inside the Sabu
>> protocol. It is “how normal transactions happen in their
>> entirety.”
>> Creditor has equal to 15,000 Sat credit. Say he wants to buy a caffe
>> worth 6,000 Sat. He has to ask the issuer to nullify previous MT and
>> GT,
>> and create and sign new transaction and cut 6,000 Sat from his
>> credit
>> and transfer it to a new creditor (say C2).
>> The new transaction will use same 40,000 UTXO as input and the
>> outputs
>> will be
>> 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee)
>> 4,500 Sat for creditor 2 (he has to pay 1,500 Sat for transaction
>> fee as
>> well)
>> 10,000 for Bitcoin-transaction-fee (4,000 by two creditors and 6,000
>> by
>> issuer) and
>> 19,000 change back to issuer account address.
>> This is the new MT, and as you can see the C1 and C2 have their new
>> credit in transaction.
>> You can calculate the new GT as well.
>> Note: due to simplicity I just rounded the numbers and skipped the
>> Sabu-transaction-fee
>> I just wrote this long story to explain how creditors just transfer
>> money in between.
>> If we take a snapshot of Sabu network, we will see millions of valid
>> transactions flowing in network and none of the issuers or creditors
>> will send these transactions to Bitcoin network due the transaction
>> fee,
>> while in Bitcoin blockchain nothing is changed! The UTXOs are
>> untouched,
>> and no one can say which UTXO is promised to who.
>> It is a pretty secure off-chain protocol.
>> Although I expected more Bitcoiners to react about Sabu proposal and
>> comment for or against it, so far, I have not seen any serious
>> criticism
>> or real threat about protocol.
>> The miner attack is just a failed plan as I explained before.
>>> Sabu has slightly greater risk comparing lightning
>> It is not true, since creditors can manage they risk, and limit
>> their
>> credit to 5, 10 or 20 Dollar or 50$. It is totally up to creditor to
>> accept more liability from issuers or not.
>> The creditor can keep his credit around a fix number. That is, the
>> creditor spends a part of his credit and then again increase its
>> credit.
>> Let imagine you already payed 5$ to a issuer and you got 15,000 Sat
>> credit in your wallet. So, you will spend this 15,000 Sat (buy
>> coffee,
>> ice-cream, etc.) till your wallet run out of Satoshi and again you
>> will
>> pay another 5$ to issuer and get new 15,000 sat credit. Since all of
>> these transactions has near zero cost you are not obliged to charge
>> your
>> wallet 200$ in one shot.
>> It is absolutely low risk deal. In worst case the creditor (you)
>> will
>> lose 5$. And as I explained before this kind of attacks will not
>> happened never. And as you told Sabu provides cheaper and a larger
>> number of transactions.
>>> This would be essentially worse than the lightning network in some
>> ways,
>> Disagree! Please explain the scenario exactly. I didn’t find any
>> case
>> Lightning can compete with Sabu.
>>> ledger of accounts and their balances, along with proof that the
>> entity owns…
>> It is almost what I designed in Sabu. They are doc-watcher servers.
>> They
>> are a set of records of UTXOs and the proper Merkle root hash of
>> related
>> transaction in Sabu network. The intention was stopping issuer from
>> spend and promises same UTXO to different people (that they are not
>> aware of the existence of the other). So, any individual creditor
>> (or
>> their software) could verify that total liabilities (in account
>> balances) are less than the half of the total bitcoins the entity
>> owns.
>> And if something doesn't match up, they won’t yell, instead they
>> refuse
>> the deal in first place, or send the GT to Bitcoin network and hurt
>> the
>> cheater issuer by slashing his money. it is “Tit-for-tat”.
>>> I think it likely has critical security holes. Perhaps you can fix
>> them!
>> There is no critical security hole. Please refer it by facts,
>> numbers
>> and proves.
>> I think I already fixed all critics.
>>
>> Billy! I am actively working on this proposal and if no one cannot
>> show
>> a real problem or security issue in the project, I will start
>> implementing it.
>> Just imagine people regularly using Sabu protocol and send/receive
>> Bitcoin (Satoshi) in billions of small amount transactions every
>> day.
>> This protocol will outspread Bitcoin and will attract a new crowd of
>> penny investors to Bitcoin. The people who can afford 20$ or less
>> monthly to invest on Bitcoin.
>> Sabu brings Bitcoin to a whole new life.
>> It will be the true scalable and mass adaption, and I do not know
>> how to
>> attract more real Bitcoin fans to this proposal!
>> Guys! Here is the Bitcoin renascence.
>> Maybe you can help it.
>> Regards
>> Raymo
>
> On Sat, Jul 3, 2021 at 1:02 AM <raymo at riseup.net> wrote:
>
>> Hi Billy,
>>
>>> What if it was possible for the creditor to claw back the funds
>> As far as I know the “claw back” mechanism doesn’t exist in
>> Bitcoin
>> system, and probably most Bitcoiners won’t be agree on it.
>> Even if we want to add claw back to Bitcoin in general, and Sabu in
>> particular, it would add too complexities and uncertainty to
>> Bitcoin.
>> So, it would be better to not touch that part, instead focusing on
>> reduce the cheating risk by putting some penalty for both issuers,
>> creditors and miners.
>> We already have the penalties for both issuers and creditors.
>> It looks the miners still can abuse Sabu, but as I told before the
>> miner
>> or better say the mining pool must be issuer (to be able to sign the
>> promised UTXO in cheating way) or must be creditor (in order to have
>> a
>> copy of GT and not lose his money in favor of a stranger miner.
>> Remember
>> the fact that creditor will lose 70% of their money in favor of
>> Bitcoin
>> transaction fee in a typical GT) or collaborate one of them in a
>> conspiracy. Otherwise, there will be no economic benefit in this
>> attack.
>>
>> All these 3 cases of the attacks, theoretically could be happened,
>> but
>> the risk to reward ratio is enough high to hinder potential
>> malevolent
>> from a practical act.
>> Even this very small risk of miner attacks (which don’t care the
>> attack
>> costs, since he is not interested in economic benefit, but he wants
>> to
>> ruin Sabu), would be resolved by a slightly upgrade in Bitcoin
>> protocol
>> by applying the BIPxxx “for flagging/unflagging promised UTXOs”.
>>
>> I am not in rush to apply this upgrade on Bitcoin protocol, instead
>> I am
>> actively working in order to realize the Sabu protocol and Gazin
>> wallet.
>> Later the Sabu community will carry the BIPxxx.
>>
>> Best
>>
>> On 2021-07-02 17:57, Billy Tetrud wrote:
>>> 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 [1].
>>>
>>> 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 at 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,…).
>>>> 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 “fully compromised” 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’s public key
>> in
>>>> 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 “central system concerns” is the
>>>> 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 at lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>> Hi Billy,
>>>>>> Sorry for late reply. Let’s 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 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’t 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’t
>>>>>> 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’t 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 “nonproprietary” 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 at 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 at 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=5344020.0
>>>>>>>>> Can you please read it and share your idea about it.
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Raymo
>>>>>>>>> _______________________________________________
>>>>>>>>> bitcoin-dev mailing list
>>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>>>>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>> _______________________________________________
>>>>>>>> bitcoin-dev mailing list
>>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>>>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html
raymo at riseup.net [ARCHIVE] /
npub1ud…v4p33
2023-06-07 22:55:56
in reply to nevent1q…zg0m
Author Public Key
npub1ud4hzyxp4mr66vj2phl4g7f5u3snl9mxfc09q482dzh6qqd5u9es9v4p33Published at
2023-06-07 22:55:56Event JSON
{
"id": "c0ff3fafa7c696d9690686af8e54d3f11bb284d1650d33d97343aaefc88445f7",
"pubkey": "e36b7110c1aec7ad324a0dff547934e4613f97664e1e5054ea68afa001b4e173",
"created_at": 1686178556,
"kind": 1,
"tags": [
[
"e",
"4720aee3968a86b726147c258fd211cdd522f61aebf3f3086363b37b44077bf2",
"",
"root"
],
[
"e",
"9b361ad4d0b2245c00ae0e4450958ed4c5a560ca8554d365751a7f12551a2b9a",
"",
"reply"
],
[
"p",
"3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba"
]
],
"content": "📅 Original date posted:2021-07-17\n📝 Original message:After introducing Sabu protocol as a solution for Bitcoin scaling\n(https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180),\nI shared this idea with Bitcoin developers through the bitcoin-dev\nmailing list.\nI got some constructive feedbacks and critiques leading me to add this\npart to the proposal which I was skipped due to brevity of proposal\nintroduction.\n\nHere I will investigate on more real live scenarios, general usages and\ncorner cases, and the consequences of some attacks or buggy\nimplementation of protocol, as well as different actors (malicious,\nirrational, profit seeker, griefer, stupid, reckless, incompetent, etc.)\nactivity effects.\n\nIn proposal introduction (previous post), I did not talk about Lightning\ndeliberately, although it seems that this solution is an alternative to\nLightning.\nMost of readers misunderstood Sabu and asking what differs it from\nLightning?\nIndeed, Sabu has nothing with Lightning. It has totally different\ndesign, network architecture, security model and implementation. The\nonly thing in common with Lightning is both are intended to cover micro\npayments.\nThe good thing about Bitcoin is that it does not require any kind of\npermission. Consequently, related products do not need to ask permission\ntoo. We are in a permission-less free market. I think Sabu will work\nperfectly and if a group of users think like me, we are done. Sabu will\nwork parallel the other scaling solutions without need to drive them\nout.\nHowever, I have made a comparison between Sabu, on-chain and Lightning\ntransactions to get a clearer understanding of the advantages and\ndisadvantages of Sabu and answer to “why we should implement and use\nSabu in our day-to-day deals”.\nMost probably this paper is not comprehensive document, therefore this\narticle will be updated.\n\nYou will find the complete post here:\nhttps://raymo-49157.medium.com/scaling-bitcoin-by-sabu-protocol-risks-and-benefits-62157f8a664e\n\nRaymo\n\nOn 2021-07-07 03:20, Billy Tetrud wrote:\n\u003e\u003e As far as I know the “claw back” mechanism doesn’t exist in\n\u003e Bitcoin\n\u003e system, and probably most Bitcoiners won’t be agree on it.\n\u003e \n\u003e It certainly doesn't. And it would definitely be a hard sell.\n\u003e \n\u003e\u003e It looks the miners still can abuse Sabu, but as I told before the\n\u003e mineror better say the mining pool must be issuer .. or must be\n\u003e creditor .. or collaborate one of them in a\n\u003e conspiracy.\n\u003e \n\u003e Yes. But it certainly incentivizes miners to become creditors and scam\n\u003e people. Even if a small miner who mines one block a year does this,\n\u003e they can mine all Guarantee Transactions in their possession. Larger\n\u003e miners that mine one block every few days can scam that much more\n\u003e often. Even with $5 credits, that could be an extra $9000 gained in a\n\u003e block. That's pretty substantial when fees are totaling around $45,000\n\u003e per block.\n\u003e \n\u003e\u003e would be resolved by a slightly upgrade in Bitcoin protocol by\n\u003e applying the BIPxxx “for flagging/unflagging promised UTXOs”\n\u003e \n\u003e As others have mentioned tho, doing something like that would be at\n\u003e very least quite complex, and at worst impossible to do securely. The\n\u003e whole reason why bitcoin's blockchain exists in the first place is to\n\u003e be a single source of truth for transactions. The mempool is not a\n\u003e source of truth for consensus. The Sabu network could not be a source\n\u003e of truth either for consensus, without some serious innovations (that\n\u003e may not be possible). It isn't as simple as you seem to be thinking.\n\u003e \n\u003e\u003e The new transaction will use same 40,000 UTXO as input and the\n\u003e outputs will be 6,500 Sat for creditor (he pays 2,500 Sat for\n\u003e transaction fee) 4,500 Sat for creditor 2\n\u003e \n\u003e This is the part I was unable to find/understand quickly enough in the\n\u003e original write up. So for creditor 1 to pay creditor 2, a new main\n\u003e transaction and guarantee transaction are created that credit the\n\u003e appropriate people, right? FYI, the MT and GT acronyms make it harder\n\u003e for me to read/understand, so I'm preferring to write them out. But\n\u003e that helps. Let me write this out in a different (more compact) way:\n\u003e \n\u003e 1. Creditor A $5 -\u003e Issuer\n\u003e \n\u003e 2. Issuer creates and shares transactions:\n\u003e \n\u003e Main Transaction (40k sats):\n\u003e * Issuer: 19k sats\n\u003e * Creditor A: 11k sats\n\u003e * Fee: 10k sats (4k from creditor, 6k from issuer)\n\u003e \n\u003e Guarantee Transaction (40k sats):\n\u003e * Issuer: 13,300 sats\n\u003e * Creditor A: 1650 sats\n\u003e * Fee: 25,050 sats\n\u003e \n\u003e 3. Creditor A, 6k sats -\u003e Creditor B. Issuer creates and shares\n\u003e transactions:\n\u003e \n\u003e Main Transaction (40k sats):\n\u003e * Issuer: 19k sats* Creditor A: 6,500 sats\n\u003e * Creditor B: 4,500 sats\n\u003e \n\u003e * Fee: 10k sats (4k from creditor, 6k from issuer)\n\u003e \n\u003e Guarantee Transaction (40k sats):\n\u003e * Issuer: 13300 sats* Creditor A: 975 sats\n\u003e * Creditor B: 675 sats\n\u003e * Fee: 25050 sats\n\u003e \n\u003e Is this right?\n\u003e \n\u003e\u003e The miner attack is just a failed plan as I explained before\n\u003e \n\u003e I thought you acknowledged that the miner attack is an issue above.\n\u003e No?\n\u003e \n\u003e\u003e\u003e Sabu has slightly greater risk comparing lightning\n\u003e\u003e It is not true,\n\u003e \n\u003e What I mean is that a violation of trust results in more damaging\n\u003e effects with Sabu than with lightning. In lightning, if your channel\n\u003e partner cheats, at worst you must simply pay a normal transaction fee.\n\u003e With Sabu, if a creditor cheats, you will likely pay an abnormally\n\u003e large transaction fee. This is what I mean by \"greater risk\". Some\n\u003e attackers are what's known as griefers - these are people willing to\n\u003e spend time and money hurting someone else, even if they don't make a\n\u003e profit from it (other than schadenfreude). It seems clear there is a\n\u003e greater risk of being griefed in Sabu than in lightning.\n\u003e \n\u003e Furthermore, while in lightning, if you perform the protocol properly,\n\u003e your funds can never be stolen except in very extreme circumstances\n\u003e (eg widespread long-running network congestion that prevents\n\u003e confirming a revoke transaction). By contrast, Sabu has a significant\n\u003e likelihood that a cheating transaction could be mined instead of the\n\u003e guarantee transaction. Perhaps the likelihood is approximately 2\n\u003e seconds / 10 minutes (0.3% chance), but a 0.3% is clearly larger than\n\u003e approximately 0% chance in lightning. Again, this is another part of\n\u003e what I mean by \"higher risk\".\n\u003e \n\u003e These are both real counterparty risks that you shouldn't simply\n\u003e ignore. It may be true that no rational actor will attempt an attack,\n\u003e however not all actors are rational. People also make mistakes, write\n\u003e buggy software, etc etc. The existence of risk doesn't ruin your idea\n\u003e - every protocol has risks. But identifying the specific risks is the\n\u003e only way to compare the properties against alternatives (like on chain\n\u003e transactions or the lightning network). I think its important to\n\u003e acknowledge these risks in your write up.\n\u003e \n\u003e\u003e I explained before this kind of attacks will not happened never\n\u003e \n\u003e If people use your protocol, some will inevitably use it wrong. Those\n\u003e that use it wrong should be the ones that pay the price for it - but\n\u003e it is a downside of the protocol if the counter party of the person\n\u003e that makes a mistake (or attempts something malicious) is harmed as a\n\u003e result. Again, these kinds of trade offs are ok, but you should not be\n\u003e assuming that attacks like this will never happen. They will happen\n\u003e sometimes. You must assume that. The question is what is the result\n\u003e when an attack is attempted? And how will that affect what kinds of\n\u003e actors will attempt an attack (malicious, profit seeking, honest,\n\u003e stupid, wreckless, incompetent, other types of actors etc etc)?\n\u003e \n\u003e\u003e I didn’t find any case Lightning can compete with Sabu.\n\u003e \n\u003e As I explained above related to risk, there are trade offs. I would\n\u003e like to see in your write up a clear list of these trade offs. The\n\u003e additional risk (as I explained it above) is one trade off. It sounds\n\u003e like there are limits in which a creditor or issuer can safely rely on\n\u003e incentives to prevent attacks. Did you specify what those limits are?\n\u003e The Lightning network also has limits - eg a lightning node can't\n\u003e allow its channel partner to spend 100% of their coins without taking\n\u003e on additional risk of attack. How do those limits compare in Sabu? For\n\u003e example, an issuer couldn't allow any creditor to spend so much of\n\u003e their credited bitcoin that their credit goes below the amount they\n\u003e would receive in any past Guarantee Transaction without taking on the\n\u003e risk that the creditor would post that guarantee transaction and\n\u003e receive coins they shouldn't own anymore. I would love to see a more\n\u003e detailed comparison of Sabu to lightning.\n\u003e \n\u003e If your protocol works out, there are obvious benefits: transactions\n\u003e that could be done with no on-chain footprint. However, even if the\n\u003e protocol works out, there are trade offs and those trade offs should\n\u003e be made very clear. Even if the comparative downsides are small.\n\u003e \n\u003e ~BT\n\u003e \n\u003e\u003e Hi Billy\n\u003e\u003e\u003e high-level overview of how all the pieces (How Sabu protocol\n\u003e\u003e works).\n\u003e\u003e\u003e how normal transactions happen in their entirety.\n\u003e\u003e Ok, lets re-explain Sabu. In Sabu protocol we have two type of\n\u003e\u003e actors.\n\u003e\u003e The issuers who own Bitcoin (they own UTXOs on Bitcoin blockchain),\n\u003e\u003e and\n\u003e\u003e the creditors who will own Bitcoins (the UTXOs on Bitcoin\n\u003e\u003e blockchain),\n\u003e\u003e if the issuer or the creditor sends the prepared transaction to\n\u003e\u003e Bitcoin\n\u003e\u003e network. But for know creditors have the transaction in their hand.\n\u003e\u003e Before sending this transaction to Bitcoin network it acts (in Sabu\n\u003e\u003e protocol and Sabu network) as a liability of issuer.\n\u003e\u003e The story always starts from issuer, the person who get money or\n\u003e\u003e goods\n\u003e\u003e or services from a creditor and in exchange creates and sings a\n\u003e\u003e valid\n\u003e\u003e Bitcoin transaction by which the issuer spends his UTXO and as a one\n\u003e\u003e of\n\u003e\u003e the outputs of the transaction, there will be an output for\n\u003e\u003e creditor’s\n\u003e\u003e address equal to the money issuer already get paid.\n\u003e\u003e This transaction is a valid transaction which is signed “only”\n\u003e\u003e by\n\u003e\u003e issuer. The outputs of transaction are just and exact balance of the\n\u003e\u003e parties (issuer and creditor).\n\u003e\u003e Lets, imagine the creditor payed 5$ (almost equal to 15,000 Sat) to\n\u003e\u003e issuer. Thus, issuer will create and sign a transaction by which he\n\u003e\u003e spends 40,000 Sat and the outputs will be\n\u003e\u003e 11,000 for creditor (the creditor has to pay 4,000 Sat in favor of\n\u003e\u003e transaction fee),\n\u003e\u003e 10,000 for Bitcoin-transaction-fee (4,000 by creditor and 6,000 by\n\u003e\u003e issuer) and\n\u003e\u003e 19,000 change back to issuer account address.\n\u003e\u003e It is our Main Transaction (MT) which is a pretty normal and valid\n\u003e\u003e transaction.\n\u003e\u003e Alongside the MT, issuer creates and signs a Guarantee Transaction\n\u003e\u003e (GT).\n\u003e\u003e In GT issuer spends same 40,000 Sat UTXO as input, and as outputs\n\u003e\u003e the creditor will get 15% of his 11,000 Sat in Main Transaction.\n\u003e\u003e Thus\n\u003e\u003e the creditor output will be 1,650 Sat and the rest of creditor’s\n\u003e\u003e money\n\u003e\u003e (11,000 – 1,650 = 9,350 Sat) will be added to transaction fee.\n\u003e\u003e In GT also issuer will lose a part of his money. New output for\n\u003e\u003e issuer\n\u003e\u003e will be 19,000 * 70% = 13,300 and the rest will be added to\n\u003e\u003e transaction\n\u003e\u003e fee (19,000 – 13,300 = 5,700 Sat)\n\u003e\u003e Thus, the new transaction fee in GT will be 10,000 + 9,350 + 5,700 =\n\u003e\u003e 25,050 Sat\n\u003e\u003e Now the creditor has 2 valid transactions (MT and GT) in his hands.\n\u003e\u003e He\n\u003e\u003e can send either MT or GT or both to Bitcoin Network. But in all\n\u003e\u003e cases,\n\u003e\u003e he will lose a portion of his money in favor of transaction fee\n\u003e\u003e (miner’s\n\u003e\u003e income). So, rationally he will never send transactions to Bitcoin\n\u003e\u003e network unless he wants consciously hurt himself.\n\u003e\u003e The creditor always prefers to spend his credit inside the Sabu\n\u003e\u003e protocol. It is “how normal transactions happen in their\n\u003e\u003e entirety.”\n\u003e\u003e Creditor has equal to 15,000 Sat credit. Say he wants to buy a caffe\n\u003e\u003e worth 6,000 Sat. He has to ask the issuer to nullify previous MT and\n\u003e\u003e GT,\n\u003e\u003e and create and sign new transaction and cut 6,000 Sat from his\n\u003e\u003e credit\n\u003e\u003e and transfer it to a new creditor (say C2).\n\u003e\u003e The new transaction will use same 40,000 UTXO as input and the\n\u003e\u003e outputs\n\u003e\u003e will be\n\u003e\u003e 6,500 Sat for creditor (he pays 2,500 Sat for transaction fee)\n\u003e\u003e 4,500 Sat for creditor 2 (he has to pay 1,500 Sat for transaction\n\u003e\u003e fee as\n\u003e\u003e well)\n\u003e\u003e 10,000 for Bitcoin-transaction-fee (4,000 by two creditors and 6,000\n\u003e\u003e by\n\u003e\u003e issuer) and\n\u003e\u003e 19,000 change back to issuer account address.\n\u003e\u003e This is the new MT, and as you can see the C1 and C2 have their new\n\u003e\u003e credit in transaction.\n\u003e\u003e You can calculate the new GT as well.\n\u003e\u003e Note: due to simplicity I just rounded the numbers and skipped the\n\u003e\u003e Sabu-transaction-fee\n\u003e\u003e I just wrote this long story to explain how creditors just transfer\n\u003e\u003e money in between.\n\u003e\u003e If we take a snapshot of Sabu network, we will see millions of valid\n\u003e\u003e transactions flowing in network and none of the issuers or creditors\n\u003e\u003e will send these transactions to Bitcoin network due the transaction\n\u003e\u003e fee,\n\u003e\u003e while in Bitcoin blockchain nothing is changed! The UTXOs are\n\u003e\u003e untouched,\n\u003e\u003e and no one can say which UTXO is promised to who.\n\u003e\u003e It is a pretty secure off-chain protocol.\n\u003e\u003e Although I expected more Bitcoiners to react about Sabu proposal and\n\u003e\u003e comment for or against it, so far, I have not seen any serious\n\u003e\u003e criticism\n\u003e\u003e or real threat about protocol.\n\u003e\u003e The miner attack is just a failed plan as I explained before.\n\u003e\u003e\u003e Sabu has slightly greater risk comparing lightning\n\u003e\u003e It is not true, since creditors can manage they risk, and limit\n\u003e\u003e their\n\u003e\u003e credit to 5, 10 or 20 Dollar or 50$. It is totally up to creditor to\n\u003e\u003e accept more liability from issuers or not.\n\u003e\u003e The creditor can keep his credit around a fix number. That is, the\n\u003e\u003e creditor spends a part of his credit and then again increase its\n\u003e\u003e credit.\n\u003e\u003e Let imagine you already payed 5$ to a issuer and you got 15,000 Sat\n\u003e\u003e credit in your wallet. So, you will spend this 15,000 Sat (buy\n\u003e\u003e coffee,\n\u003e\u003e ice-cream, etc.) till your wallet run out of Satoshi and again you\n\u003e\u003e will\n\u003e\u003e pay another 5$ to issuer and get new 15,000 sat credit. Since all of\n\u003e\u003e these transactions has near zero cost you are not obliged to charge\n\u003e\u003e your\n\u003e\u003e wallet 200$ in one shot.\n\u003e\u003e It is absolutely low risk deal. In worst case the creditor (you)\n\u003e\u003e will\n\u003e\u003e lose 5$. And as I explained before this kind of attacks will not\n\u003e\u003e happened never. And as you told Sabu provides cheaper and a larger\n\u003e\u003e number of transactions.\n\u003e\u003e\u003e This would be essentially worse than the lightning network in some\n\u003e\u003e ways,\n\u003e\u003e Disagree! Please explain the scenario exactly. I didn’t find any\n\u003e\u003e case\n\u003e\u003e Lightning can compete with Sabu.\n\u003e\u003e\u003e ledger of accounts and their balances, along with proof that the\n\u003e\u003e entity owns…\n\u003e\u003e It is almost what I designed in Sabu. They are doc-watcher servers.\n\u003e\u003e They\n\u003e\u003e are a set of records of UTXOs and the proper Merkle root hash of\n\u003e\u003e related\n\u003e\u003e transaction in Sabu network. The intention was stopping issuer from\n\u003e\u003e spend and promises same UTXO to different people (that they are not\n\u003e\u003e aware of the existence of the other). So, any individual creditor\n\u003e\u003e (or\n\u003e\u003e their software) could verify that total liabilities (in account\n\u003e\u003e balances) are less than the half of the total bitcoins the entity\n\u003e\u003e owns.\n\u003e\u003e And if something doesn't match up, they won’t yell, instead they\n\u003e\u003e refuse\n\u003e\u003e the deal in first place, or send the GT to Bitcoin network and hurt\n\u003e\u003e the\n\u003e\u003e cheater issuer by slashing his money. it is “Tit-for-tat”.\n\u003e\u003e\u003e I think it likely has critical security holes. Perhaps you can fix\n\u003e\u003e them!\n\u003e\u003e There is no critical security hole. Please refer it by facts,\n\u003e\u003e numbers\n\u003e\u003e and proves.\n\u003e\u003e I think I already fixed all critics.\n\u003e\u003e \n\u003e\u003e Billy! I am actively working on this proposal and if no one cannot\n\u003e\u003e show\n\u003e\u003e a real problem or security issue in the project, I will start\n\u003e\u003e implementing it.\n\u003e\u003e Just imagine people regularly using Sabu protocol and send/receive\n\u003e\u003e Bitcoin (Satoshi) in billions of small amount transactions every\n\u003e\u003e day.\n\u003e\u003e This protocol will outspread Bitcoin and will attract a new crowd of\n\u003e\u003e penny investors to Bitcoin. The people who can afford 20$ or less\n\u003e\u003e monthly to invest on Bitcoin.\n\u003e\u003e Sabu brings Bitcoin to a whole new life.\n\u003e\u003e It will be the true scalable and mass adaption, and I do not know\n\u003e\u003e how to\n\u003e\u003e attract more real Bitcoin fans to this proposal!\n\u003e\u003e Guys! Here is the Bitcoin renascence.\n\u003e\u003e Maybe you can help it.\n\u003e\u003e Regards\n\u003e\u003e Raymo\n\u003e \n\u003e On Sat, Jul 3, 2021 at 1:02 AM \u003craymo at riseup.net\u003e wrote:\n\u003e \n\u003e\u003e Hi Billy,\n\u003e\u003e \n\u003e\u003e\u003e What if it was possible for the creditor to claw back the funds\n\u003e\u003e As far as I know the “claw back” mechanism doesn’t exist in\n\u003e\u003e Bitcoin\n\u003e\u003e system, and probably most Bitcoiners won’t be agree on it.\n\u003e\u003e Even if we want to add claw back to Bitcoin in general, and Sabu in\n\u003e\u003e particular, it would add too complexities and uncertainty to\n\u003e\u003e Bitcoin.\n\u003e\u003e So, it would be better to not touch that part, instead focusing on\n\u003e\u003e reduce the cheating risk by putting some penalty for both issuers,\n\u003e\u003e creditors and miners.\n\u003e\u003e We already have the penalties for both issuers and creditors.\n\u003e\u003e It looks the miners still can abuse Sabu, but as I told before the\n\u003e\u003e miner\n\u003e\u003e or better say the mining pool must be issuer (to be able to sign the\n\u003e\u003e promised UTXO in cheating way) or must be creditor (in order to have\n\u003e\u003e a\n\u003e\u003e copy of GT and not lose his money in favor of a stranger miner.\n\u003e\u003e Remember\n\u003e\u003e the fact that creditor will lose 70% of their money in favor of\n\u003e\u003e Bitcoin\n\u003e\u003e transaction fee in a typical GT) or collaborate one of them in a\n\u003e\u003e conspiracy. Otherwise, there will be no economic benefit in this\n\u003e\u003e attack.\n\u003e\u003e \n\u003e\u003e All these 3 cases of the attacks, theoretically could be happened,\n\u003e\u003e but\n\u003e\u003e the risk to reward ratio is enough high to hinder potential\n\u003e\u003e malevolent\n\u003e\u003e from a practical act.\n\u003e\u003e Even this very small risk of miner attacks (which don’t care the\n\u003e\u003e attack\n\u003e\u003e costs, since he is not interested in economic benefit, but he wants\n\u003e\u003e to\n\u003e\u003e ruin Sabu), would be resolved by a slightly upgrade in Bitcoin\n\u003e\u003e protocol\n\u003e\u003e by applying the BIPxxx “for flagging/unflagging promised UTXOs”.\n\u003e\u003e \n\u003e\u003e I am not in rush to apply this upgrade on Bitcoin protocol, instead\n\u003e\u003e I am\n\u003e\u003e actively working in order to realize the Sabu protocol and Gazin\n\u003e\u003e wallet.\n\u003e\u003e Later the Sabu community will carry the BIPxxx.\n\u003e\u003e \n\u003e\u003e Best\n\u003e\u003e \n\u003e\u003e On 2021-07-02 17:57, Billy Tetrud wrote:\n\u003e\u003e\u003e Thanks for the details Raymo. A thought occurred to me. Given the\n\u003e\u003e fact\n\u003e\u003e\u003e that miners can abuse this system without penalty, it would be\n\u003e\u003e useful\n\u003e\u003e\u003e to be able to fix this. What if it was possible for the creditor\n\u003e\u003e to\n\u003e\u003e\u003e claw back the funds even if the cheating transaction was mined\n\u003e\u003e instead\n\u003e\u003e\u003e of the guarantee transaction? Let's say there was a way to sign a\n\u003e\u003e\u003e transaction that gives the receiver of that transaction the\n\u003e\u003e ability to\n\u003e\u003e\u003e override any other transaction that uses the UTXO? If this were\n\u003e\u003e\u003e possible, the issuer could give the creditor this kind of\n\u003e\u003e transaction\n\u003e\u003e\u003e as the guarantee transaction, and in the case a cheat was done,\n\u003e\u003e the\n\u003e\u003e\u003e creditor could still use the GT to reallocate that UTXO to\n\u003e\u003e themselves.\n\u003e\u003e\u003e \n\u003e\u003e\u003e Now there are issues with this. First of all, it could give anyone\n\u003e\u003e the\n\u003e\u003e\u003e ability to double spend. So it would be prudent to limit this in\n\u003e\u003e some\n\u003e\u003e\u003e way. The revocation probably should only be valid for up to 6\n\u003e\u003e blocks,\n\u003e\u003e\u003e such that if the transaction has 6 confirmations, it can no longer\n\u003e\u003e be\n\u003e\u003e\u003e reallocated (thus preserving the 6 block finality rule). It could\n\u003e\u003e also\n\u003e\u003e\u003e be required that the UTXO be marked as opting into this behavior\n\u003e\u003e (so\n\u003e\u003e\u003e receivers would know about the possibility it could get revoked).\n\u003e\u003e This\n\u003e\u003e\u003e second requirement would require Sabu issuers to make an on-chain\n\u003e\u003e\u003e transaction to set themselves up as an issuer.\n\u003e\u003e\u003e \n\u003e\u003e\u003e Another issue is that this would make it possible for transactions\n\u003e\u003e to\n\u003e\u003e\u003e expire. Any claw-back transaction would expire 6 blocks after the\n\u003e\u003e\u003e initial transaction happened. This has been generally avoided in\n\u003e\u003e\u003e bitcoin, but I think the relevant issues are solvable. You can\n\u003e\u003e find\n\u003e\u003e\u003e additional discussion of that in this thread [1].\n\u003e\u003e\u003e \n\u003e\u003e\u003e I would imagine this kind of ability would be pretty\n\u003e\u003e controversial,\n\u003e\u003e\u003e but since it can close out the possibility for miners to escape\n\u003e\u003e\u003e punishment, it could make this protocol viable.\n\u003e\u003e\u003e \n\u003e\u003e\u003e On Thu, Jul 1, 2021 at 3:15 PM \u003craymo at riseup.net\u003e wrote:\n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Hi Erik\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Please correct me if I misunderstood.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e email is fully compromised.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e What I got is:\n\u003e\u003e\u003e\u003e Email is not good because the sender and receiver are\n\u003e\u003e compromised.\n\u003e\u003e\u003e\u003e Email is not good because the message content is revealed.\n\u003e\u003e\u003e\u003e I can claim same argue about any other client/server model. Since\n\u003e\u003e\u003e\u003e the\n\u003e\u003e\u003e\u003e server (website) service provider will ask some sort of KYC. And\n\u003e\u003e\u003e\u003e even if\n\u003e\u003e\u003e\u003e the server uses end-to-end encryption, the provider company still\n\u003e\u003e\u003e\u003e can\n\u003e\u003e\u003e\u003e read the packets content.\n\u003e\u003e\u003e\u003e In my model the passive listener only can discover who is\n\u003e\u003e\u003e\u003e communicate to\n\u003e\u003e\u003e\u003e whom and make a graph of connections. Although it is a threat for\n\u003e\u003e\u003e\u003e privacy but the server/client model has this flaw inherently,\n\u003e\u003e since\n\u003e\u003e\u003e\u003e provider already knew everything about everyone. In my model at\n\u003e\u003e\u003e\u003e least\n\u003e\u003e\u003e\u003e users can make some fake connections and send some fake emails in\n\u003e\u003e\u003e\u003e order\n\u003e\u003e\u003e\u003e to inject noise to communications.\n\u003e\u003e\u003e\u003e Please note the fact that entire communication between mobile\n\u003e\u003e\u003e\u003e wallets\n\u003e\u003e\u003e\u003e (via emails) are asymmetric PGP encrypted. The PGP keys are\n\u003e\u003e\u003e\u003e controlled\n\u003e\u003e\u003e\u003e by end users unlike ALL pretending secure messengers (e.g\n\u003e\u003e whatsApp,\n\u003e\u003e\u003e\u003e signal, zoom,…).\n\u003e\u003e\u003e\u003e If you are worried about the way of exchanging PGP public key,\n\u003e\u003e you\n\u003e\u003e\u003e\u003e are\n\u003e\u003e\u003e\u003e right. The most secure way is in-person PGP key exchanging.\n\u003e\u003e\u003e\u003e After that for payments the wallets communicate in pgp encrypted\n\u003e\u003e\u003e\u003e messages and they can transfer Bitcoin address through an PGP\n\u003e\u003e\u003e\u003e encrypted\n\u003e\u003e\u003e\u003e cipher, thus no revealing Bitcoin address to public would occur.\n\u003e\u003e\u003e\u003e Neither\n\u003e\u003e\u003e\u003e the amounts of transactions will be reviled.\n\u003e\u003e\u003e\u003e There for it would be a good practice for shops to put their\n\u003e\u003e email\n\u003e\u003e\u003e\u003e and\n\u003e\u003e\u003e\u003e PGP public key on shop website and/or PGP public key servers,\n\u003e\u003e\u003e\u003e instead of\n\u003e\u003e\u003e\u003e putting Bitcoin address on website or using 3rd parties services\n\u003e\u003e to\n\u003e\u003e\u003e\u003e hide\n\u003e\u003e\u003e\u003e their Bitcoin payment addresses.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e If I missed some points about “fully compromised” please\n\u003e\u003e write\n\u003e\u003e\u003e\u003e it to me.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e public keys / addresses are sent\n\u003e\u003e\u003e\u003e As I told before ALL communication in Sabu are PGP encrypted.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e other routing data encrypted with public keys\n\u003e\u003e\u003e\u003e\u003e (not sure how data is routed in sabu)\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Sabu is not responsible for routing at all. It simply sends\n\u003e\u003e emails.\n\u003e\u003e\u003e\u003e Indeed the wallets peer-to-peer network in Sabu is pretty\n\u003e\u003e straight\n\u003e\u003e\u003e\u003e forward. Each mobile wallet has one email address as its handler\n\u003e\u003e and\n\u003e\u003e\u003e\u003e identifier in mobile-wallets-network. Each mobile can send\n\u003e\u003e message\n\u003e\u003e\u003e\u003e to\n\u003e\u003e\u003e\u003e another mobile by knowing its email address and the PGP public\n\u003e\u003e key.\n\u003e\u003e\u003e\u003e This information can be prepared in first face-to-face contact of\n\u003e\u003e\u003e\u003e mobile\n\u003e\u003e\u003e\u003e owners, or later (something like signing the other’s public key\n\u003e\u003e in\n\u003e\u003e\u003e\u003e web\n\u003e\u003e\u003e\u003e of trust) when a creditor wants to spend his money and transfer\n\u003e\u003e it\n\u003e\u003e\u003e\u003e to\n\u003e\u003e\u003e\u003e another creditor. The creditor1 send the signed money transfer\n\u003e\u003e\u003e\u003e request\n\u003e\u003e\u003e\u003e alongside the email and public key of creditor2 all in a PGP\n\u003e\u003e\u003e\u003e encrypted\n\u003e\u003e\u003e\u003e message to issuer.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e separate the Sabu protocol from the app... allow others to\n\u003e\u003e\u003e\u003e implement\n\u003e\u003e\u003e\u003e\u003e desktop version, or other versions that use other routing\n\u003e\u003e systems\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Indeed, it is my approach too. As I told before users will decide\n\u003e\u003e\u003e\u003e between an unstoppable, permission less, self-sovereignty and\n\u003e\u003e\u003e\u003e decentralized pure peer-to-peer communication network (with some\n\u003e\u003e\u003e\u003e resolvable privacy issues) or some efficient, privacy-mimic\n\u003e\u003e central\n\u003e\u003e\u003e\u003e limited network.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e you can allow direct-entry of a BIP-word-representation\n\u003e\u003e\u003e\u003e\u003e of a public key/address to avoid privacy/central system concerns\n\u003e\u003e\u003e\u003e Agree. Actually, I was thinking about an easy mechanism to share\n\u003e\u003e\u003e\u003e your\n\u003e\u003e\u003e\u003e public key like what you suggested here.\n\u003e\u003e\u003e\u003e But what I consider for a “central system concerns” is the\n\u003e\u003e\u003e\u003e ability of\n\u003e\u003e\u003e\u003e communication without dependency to any company.\n\u003e\u003e\u003e\u003e As an example, what can you do if the twitter bans your account?\n\u003e\u003e\u003e\u003e Nothing! Your content and entire connections will be lost.\n\u003e\u003e\u003e\u003e But if you form your friends list in your mobile (or computer)\n\u003e\u003e and\n\u003e\u003e\u003e\u003e have\n\u003e\u003e\u003e\u003e their PGP public keys and they have yours, and use email as a\n\u003e\u003e dual\n\u003e\u003e\u003e\u003e purpose tool. First as a handler (the tool for finding and to be\n\u003e\u003e\u003e\u003e found\n\u003e\u003e\u003e\u003e in internet) and second as a communication tool.\n\u003e\u003e\u003e\u003e Thus, no one can stop you, ban you or limit you to send/receive\n\u003e\u003e\u003e\u003e transaction to/from anyone.\n\u003e\u003e\u003e\u003e What I am trying to say is using email is far better than account\n\u003e\u003e\u003e\u003e (username) in a limited central service like twitter, Facebook,\n\u003e\u003e\u003e\u003e telegram... or even in future Sabu servers!\n\u003e\u003e\u003e\u003e You have your connections under your control in your phone. You\n\u003e\u003e can\n\u003e\u003e\u003e\u003e easily change your email and use a new email or even a new\n\u003e\u003e service\n\u003e\u003e\u003e\u003e provider without losing your connections and your control over\n\u003e\u003e it.\n\u003e\u003e\u003e\u003e You just sign your new email address and send it to your friends\n\u003e\u003e\u003e\u003e circle\n\u003e\u003e\u003e\u003e and notify them about changes.\n\u003e\u003e\u003e\u003e Of course, email is not good for millions of followers but it is\n\u003e\u003e\u003e\u003e obviously good for managing your payment network of hundreds of\n\u003e\u003e\u003e\u003e people\n\u003e\u003e\u003e\u003e (either issuers or creditors).\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Best\n\u003e\u003e\u003e\u003e Raymo\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e On 2021-07-01 20:49, Erik Aronesty wrote:\n\u003e\u003e\u003e\u003e\u003e your protocol should always assume the email system is fully\n\u003e\u003e\u003e\u003e\u003e compromised, and only send public information over email:\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e - public keys / addresses are sent\n\u003e\u003e\u003e\u003e\u003e - other routing data encrypted with public keys (not sure how\n\u003e\u003e data\n\u003e\u003e\u003e\u003e is\n\u003e\u003e\u003e\u003e\u003e routed in sabu)\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e your end user should be able to verify public keys / addresses\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e - use QR-codes\n\u003e\u003e\u003e\u003e\u003e - phone calls with users reading BIP words out loud\n\u003e\u003e\u003e\u003e\u003e - other in-person information exchange\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e separate the Sabu protocol from the app... allow others to\n\u003e\u003e\u003e\u003e implement\n\u003e\u003e\u003e\u003e\u003e desktop version, or other versions that use other routing\n\u003e\u003e systems\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e - you can allow direct-entry of a BIP-word-representation of a\n\u003e\u003e\u003e\u003e public\n\u003e\u003e\u003e\u003e\u003e key/address to avoid privacy/central system concerns\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e Hi Billy,\n\u003e\u003e\u003e\u003e\u003e\u003e Sorry for late reply. Let’s jump in proposal.\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e Some more information about the benefits of this approach vs\n\u003e\u003e\u003e\u003e alternatives (mainly lightning)\n\u003e\u003e\u003e\u003e\u003e\u003e The most important different is unlike the lightning, in Sabu\n\u003e\u003e no\n\u003e\u003e\u003e\u003e one\n\u003e\u003e\u003e\u003e\u003e\u003e have to open a channel and pay Bitcoin transaction fee,\n\u003e\u003e\u003e\u003e subsequently no\n\u003e\u003e\u003e\u003e\u003e\u003e one has to close channel and pay another Bitcoin transaction\n\u003e\u003e fee.\n\u003e\u003e\u003e\u003e It is\n\u003e\u003e\u003e\u003e\u003e\u003e the huge improvement since it drops the overhead cost of\n\u003e\u003e\u003e\u003e transactions.\n\u003e\u003e\u003e\u003e\u003e\u003e So, it will be more convenience to trade under Sabu protocol.\n\u003e\u003e\u003e\u003e\u003e\u003e In Sabu none of parties of a transaction are obliged to block\n\u003e\u003e\u003e\u003e money in\n\u003e\u003e\u003e\u003e\u003e\u003e any kind of smart contract or any other m of n signature\n\u003e\u003e accounts\n\u003e\u003e\u003e\u003e\u003e\u003e on-chain, so it provides more privacy.\n\u003e\u003e\u003e\u003e\u003e\u003e Since Sabu protocol is designed to motivate people to circulate\n\u003e\u003e\u003e\u003e\u003e\u003e transactions (AKA debt documents) in Sabu network, if every\n\u003e\u003e actor\n\u003e\u003e\u003e\u003e act\n\u003e\u003e\u003e\u003e\u003e\u003e rationally no one will aware how much money transferred from\n\u003e\u003e who\n\u003e\u003e\u003e\u003e to\n\u003e\u003e\u003e\u003e\u003e\u003e whom.\n\u003e\u003e\u003e\u003e\u003e\u003e In case of fraudulent activity by issuer, the creditor will\n\u003e\u003e send\n\u003e\u003e\u003e\u003e\u003e\u003e Guarantee Transaction (GT) to Bitcoin network in order to\n\u003e\u003e\u003e\u003e recapture the\n\u003e\u003e\u003e\u003e\u003e\u003e part of his credit. So, in this case the transaction is\n\u003e\u003e literally\n\u003e\u003e\u003e\u003e\u003e\u003e recorded on bitcoin blockchain.\n\u003e\u003e\u003e\u003e\u003e\u003e There is only one another reason to recording transaction on\n\u003e\u003e\u003e\u003e Bitcoin\n\u003e\u003e\u003e\u003e\u003e\u003e blockchain. Where one creditor eager to pay Bitcoin transaction\n\u003e\u003e\u003e\u003e fee in\n\u003e\u003e\u003e\u003e\u003e\u003e order to aggregate thousands or even millions different small\n\u003e\u003e\u003e\u003e amount\n\u003e\u003e\u003e\u003e\u003e\u003e debt-documents in a single transaction on Bitcoin blockchain.\n\u003e\u003e\u003e\u003e\u003e\u003e despite these two cases, the rest of transactions all occur in\n\u003e\u003e\u003e\u003e the Sabu\n\u003e\u003e\u003e\u003e\u003e\u003e network (supposed to be over 99%). Thus, no footprint no\n\u003e\u003e\u003e\u003e bottleneck and\n\u003e\u003e\u003e\u003e\u003e\u003e no over process.\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e Another important power point of Sabu is its pure-peer-to-peer\n\u003e\u003e\u003e\u003e network\n\u003e\u003e\u003e\u003e\u003e\u003e architecture. In Sabu the mobile wallets communicating to each\n\u003e\u003e\u003e\u003e other\n\u003e\u003e\u003e\u003e\u003e\u003e directly without any central server. There is no centralization\n\u003e\u003e\u003e\u003e at all.\n\u003e\u003e\u003e\u003e\u003e\u003e As a result, there will be no routing as well.\n\u003e\u003e\u003e\u003e\u003e\u003e Since only issuer and creditors are aware of the content of\n\u003e\u003e\u003e\u003e transaction\n\u003e\u003e\u003e\u003e\u003e\u003e (who pay how much to whom) it is a huge privacy improvement,\n\u003e\u003e\u003e\u003e which\n\u003e\u003e\u003e\u003e\u003e\u003e doesn’t exist in other layer 2 solutions.\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e About the usability of Sabu, although the protocol based on the\n\u003e\u003e\u003e\u003e\u003e\u003e collaborating 2 different peer-to-peer network and 3 classic\n\u003e\u003e\u003e\u003e\u003e\u003e server/client networks, but the end user (mobile wallet user)\n\u003e\u003e\u003e\u003e doesn’t\n\u003e\u003e\u003e\u003e\u003e\u003e see any of these complexities.\n\u003e\u003e\u003e\u003e\u003e\u003e The end user simply installs the mobile/desktop wallet and add\n\u003e\u003e\u003e\u003e her/his\n\u003e\u003e\u003e\u003e\u003e\u003e friends to his phonebook by adding their email address or\n\u003e\u003e\u003e\u003e scanning their\n\u003e\u003e\u003e\u003e\u003e\u003e email (and/or PGP public key). After that s/he can immediately\n\u003e\u003e\u003e\u003e start to\n\u003e\u003e\u003e\u003e\u003e\u003e send/receive Bitcoin through Sabu network. Entire\n\u003e\u003e communications\n\u003e\u003e\u003e\u003e between\n\u003e\u003e\u003e\u003e\u003e\u003e wallets are PGP encrypted.\n\u003e\u003e\u003e\u003e\u003e\u003e Another good point in Sabu design is, the 12 seed words are\n\u003e\u003e using\n\u003e\u003e\u003e\u003e for\n\u003e\u003e\u003e\u003e\u003e\u003e both Bitcoin wallet private key and the PGP private key. So, it\n\u003e\u003e\u003e\u003e is the\n\u003e\u003e\u003e\u003e\u003e\u003e key of user wealth and its identity as well. For more details,\n\u003e\u003e\u003e\u003e please\n\u003e\u003e\u003e\u003e\u003e\u003e read my previous answer to Alex Schoof.\n\u003e\u003e\u003e\u003e\u003e\u003e The issuer, by using his UTXOs and selling them to creditors\n\u003e\u003e earn\n\u003e\u003e\u003e\u003e money.\n\u003e\u003e\u003e\u003e\u003e\u003e the issuer creates the debt document (transaction) by which\n\u003e\u003e\u003e\u003e promises to\n\u003e\u003e\u003e\u003e\u003e\u003e creditor an amount of satoshi. These debt documents are valid\n\u003e\u003e\u003e\u003e Bitcoin\n\u003e\u003e\u003e\u003e\u003e\u003e transaction. The only difference is these transactions are\n\u003e\u003e\u003e\u003e intended to\n\u003e\u003e\u003e\u003e\u003e\u003e circulate in Sabu protocol instead of sending to Bitcoin\n\u003e\u003e\u003e\u003e blockchain.\n\u003e\u003e\u003e\u003e\u003e\u003e Each transaction is a small money transfer. 40,000 Satoshi as\n\u003e\u003e\u003e\u003e input and\n\u003e\u003e\u003e\u003e\u003e\u003e maximum 20,000 Satoshi as credit and minimum 10,000 Satoshi as\n\u003e\u003e\u003e\u003e Bitcoin\n\u003e\u003e\u003e\u003e\u003e\u003e transaction fee.\n\u003e\u003e\u003e\u003e\u003e\u003e The creditors will use these received transactions as money and\n\u003e\u003e\u003e\u003e will pay\n\u003e\u003e\u003e\u003e\u003e\u003e it in exchange of goods or services. For each transaction the\n\u003e\u003e\u003e\u003e creditor\n\u003e\u003e\u003e\u003e\u003e\u003e pays 10 Satoshi as Sabu-transaction-fee to issuer.\n\u003e\u003e\u003e\u003e\u003e\u003e Sabu is not custodial service and the UXTOs are always under\n\u003e\u003e\u003e\u003e issuer\n\u003e\u003e\u003e\u003e\u003e\u003e control, unless issuer or creditor send the signed transaction\n\u003e\u003e to\n\u003e\u003e\u003e\u003e\u003e\u003e Bitcoin network. When the transaction was recorded in Bitcoin\n\u003e\u003e\u003e\u003e\u003e\u003e blockchain, the creditor can spend proper UTXO in Bitcoin\n\u003e\u003e\u003e\u003e network.\n\u003e\u003e\u003e\u003e\u003e\u003e Imagine million people use their UTXOs in Sabu, they are issuer\n\u003e\u003e\u003e\u003e and\n\u003e\u003e\u003e\u003e\u003e\u003e issue/update/cancel million transactions per second. All they\n\u003e\u003e\u003e\u003e need is a\n\u003e\u003e\u003e\u003e\u003e\u003e mobile wallet. On the other hand, every one by knowing an\n\u003e\u003e issuer\n\u003e\u003e\u003e\u003e can buy\n\u003e\u003e\u003e\u003e\u003e\u003e some Satoshi (whit absolutely no KYC), even 1 Dollar or less,\n\u003e\u003e and\n\u003e\u003e\u003e\u003e spend\n\u003e\u003e\u003e\u003e\u003e\u003e it, this time Alice really can buy caffe by Bitcoin ;)\n\u003e\u003e\u003e\u003e\u003e\u003e The Bar can install the mobile wallet and every day receives\n\u003e\u003e\u003e\u003e thousands\n\u003e\u003e\u003e\u003e\u003e\u003e of debt documents (transactions), each worth maximum 20,000\n\u003e\u003e\u003e\u003e Satoshi in\n\u003e\u003e\u003e\u003e\u003e\u003e exchange of coffee. And every evening aggregates those small\n\u003e\u003e\u003e\u003e\u003e\u003e transactions to one single transaction and send it to Bitcoin\n\u003e\u003e\u003e\u003e network.\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e The security model of Sabu is pretty straight forward.\n\u003e\u003e\u003e\u003e\u003e\u003e Issuer is the owner of UTXO(s) which will be used in\n\u003e\u003e\u003e\u003e transactions. The\n\u003e\u003e\u003e\u003e\u003e\u003e issuer is and will the only person who creates transactions and\n\u003e\u003e\u003e\u003e sign\n\u003e\u003e\u003e\u003e\u003e\u003e them. The transactions are valid transaction which either\n\u003e\u003e issuer\n\u003e\u003e\u003e\u003e or\n\u003e\u003e\u003e\u003e\u003e\u003e creditor can send them to Bitcoin network, but they will never\n\u003e\u003e\u003e\u003e send\n\u003e\u003e\u003e\u003e\u003e\u003e these transactions to Bitcoin network, because of the high\n\u003e\u003e\u003e\u003e Bitcoin\n\u003e\u003e\u003e\u003e\u003e\u003e transaction fee for each single transaction.\n\u003e\u003e\u003e\u003e\u003e\u003e Since issuer is the only one who can sign transaction (spend\n\u003e\u003e\u003e\u003e UTXOs),\n\u003e\u003e\u003e\u003e\u003e\u003e there is a risk of issuer cheating. And no one can stop issuer\n\u003e\u003e\u003e\u003e from\n\u003e\u003e\u003e\u003e\u003e\u003e cheating, because these are his UTXOs and he has the proper\n\u003e\u003e\u003e\u003e private\n\u003e\u003e\u003e\u003e\u003e\u003e keys.\n\u003e\u003e\u003e\u003e\u003e\u003e The Sabu solution is Guarantee transaction. It is a valid\n\u003e\u003e\u003e\u003e transaction\n\u003e\u003e\u003e\u003e\u003e\u003e that issuer has to sign it alongside the Main transaction. In\n\u003e\u003e GT\n\u003e\u003e\u003e\u003e both\n\u003e\u003e\u003e\u003e\u003e\u003e issuer and creditor cut a part of their output in favor of\n\u003e\u003e\u003e\u003e Bitcoin\n\u003e\u003e\u003e\u003e\u003e\u003e transaction fee.\n\u003e\u003e\u003e\u003e\u003e\u003e We suppose miners always seeking for more profit, thus in a\n\u003e\u003e case\n\u003e\u003e\u003e\u003e there\n\u003e\u003e\u003e\u003e\u003e\u003e are 2 or more transaction are spending same UTXO as input,\n\u003e\u003e miner\n\u003e\u003e\u003e\u003e will\n\u003e\u003e\u003e\u003e\u003e\u003e choose transaction with highest feeRate. There is no\n\u003e\u003e economically\n\u003e\u003e\u003e\u003e\u003e\u003e benefit for issuer to cheat creditors and pay less transaction\n\u003e\u003e\u003e\u003e fee\n\u003e\u003e\u003e\u003e\u003e\u003e simultaneously. So rationally the issuer won’t cheat\n\u003e\u003e creditor.\n\u003e\u003e\u003e\u003e\u003e\u003e It was the simplest explanation of Sabu security model.\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e I agree with others that using email is probably not\n\u003e\u003e\u003e\u003e appropriate for a protocol like this. I would highly recommend\n\u003e\u003e\u003e\u003e making your protocol transport-agnostic, allowing users of your\n\u003e\u003e\u003e\u003e protocol to use any transport they want.\n\u003e\u003e\u003e\u003e\u003e\u003e Indeed, the protocol is transparent-agnostic, if I insist of\n\u003e\u003e\u003e\u003e email as a\n\u003e\u003e\u003e\u003e\u003e\u003e user identifier and communicating tool is because of the idea\n\u003e\u003e of\n\u003e\u003e\u003e\u003e\u003e\u003e reforming part of internet architecture and make it more\n\u003e\u003e\u003e\u003e decentralized.\n\u003e\u003e\u003e\u003e\u003e\u003e The wallet users can choose classic architecture. In this case\n\u003e\u003e\u003e\u003e mobile\n\u003e\u003e\u003e\u003e\u003e\u003e wallets will connect to a central server and communicate\n\u003e\u003e through\n\u003e\u003e\u003e\u003e that\n\u003e\u003e\u003e\u003e\u003e\u003e server (pretty much like all existed mobile wallets). While\n\u003e\u003e some\n\u003e\u003e\u003e\u003e users\n\u003e\u003e\u003e\u003e\u003e\u003e decide to use a pure peer-to-peer communication. I knew email\n\u003e\u003e has\n\u003e\u003e\u003e\u003e some\n\u003e\u003e\u003e\u003e\u003e\u003e privacy issues but as always it is a tradeoff. Users can decide\n\u003e\u003e\u003e\u003e between\n\u003e\u003e\u003e\u003e\u003e\u003e an unstoppable, permission less, self-sovereignty and\n\u003e\u003e\u003e\u003e decentralized pure\n\u003e\u003e\u003e\u003e\u003e\u003e peer-to-peer communication network (with some resolvable\n\u003e\u003e privacy\n\u003e\u003e\u003e\u003e issues)\n\u003e\u003e\u003e\u003e\u003e\u003e or some efficient central limited network.\n\u003e\u003e\u003e\u003e\u003e\u003e Let me know the critics about email. Hopefully this would lead\n\u003e\u003e us\n\u003e\u003e\u003e\u003e to\n\u003e\u003e\u003e\u003e\u003e\u003e improve email instead of letting it die. I strongly suggest\n\u003e\u003e email\n\u003e\u003e\u003e\u003e\u003e\u003e because it is the ONLY neutral, free “nonproprietary” and\n\u003e\u003e\u003e\u003e open\n\u003e\u003e\u003e\u003e\u003e\u003e protocol/technology for communication in the world that its\n\u003e\u003e\u003e\u003e\u003e\u003e infrastructure is well-established and is accessible all over\n\u003e\u003e the\n\u003e\u003e\u003e\u003e glob.\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e I tried to explain it more, hope was useful. By the way the\n\u003e\u003e\u003e\u003e complete\n\u003e\u003e\u003e\u003e\u003e\u003e explanation is here\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e \n\u003e https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e Regards\n\u003e\u003e\u003e\u003e\u003e\u003e Raymo\n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e On 2021-06-22 18:20, Billy Tetrud wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e I would be interested in seeing some more information about\n\u003e\u003e the\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e benefits of this approach vs alternatives up front in this\n\u003e\u003e\u003e\u003e write up.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e Eg how does the security, cost, usability, and privacy compare\n\u003e\u003e\u003e\u003e to the\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e lightning network, which would be the most likely competitor\n\u003e\u003e to\n\u003e\u003e\u003e\u003e this\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e idea. It seems clear that there is more counterparty risk\n\u003e\u003e here,\n\u003e\u003e\u003e\u003e so it\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e would probably also be very helpful to compare against\n\u003e\u003e\u003e\u003e traditional\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e custodial solutions as well. If you have specific claims on\n\u003e\u003e how\n\u003e\u003e\u003e\u003e this\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e system is better than eg lightning in certain contexts, it\n\u003e\u003e\u003e\u003e would be\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e far easier to evaluate the protocol against those claims, and\n\u003e\u003e\u003e\u003e would\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e also be a lot easier for readers to be motivated to read the\n\u003e\u003e\u003e\u003e whole\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e protocol and do a more full analysis.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e I agree with others that using email is probably not\n\u003e\u003e\u003e\u003e appropriate for a\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e protocol like this. I would highly recommend making your\n\u003e\u003e\u003e\u003e protocol\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e transport-agnostic, allowing users of your protocol to use any\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e transport they want.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e On Sat, Jun 19, 2021 at 7:00 PM James Hilliard via bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e I think you're making a number of assumptions about mining\n\u003e\u003e\u003e\u003e that are\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e not accurate.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e First of all, how much chance in finding next block the\n\u003e\u003e\u003e\u003e corrupted\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e miners have? One percent of all Bitcoin hash powers? Or\n\u003e\u003e\u003e\u003e maximum 5\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e percent or 10? The cheaters must come up in dividing that 1.2\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Bitcoin between. After all the risk/reward must fit them.\n\u003e\u003e They\n\u003e\u003e\u003e\u003e can\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e not be a big mining pool since there is no benefit, so they\n\u003e\u003e\u003e\u003e will be\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e small miners with low hash rate. If they solve the puzzle and\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e broadcast the block, no one in the entire Bitcoin network has\n\u003e\u003e\u003e\u003e block\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e transactions or seen it before in their mempool!\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e You're making the assumption that miners won't build on top\n\u003e\u003e of\n\u003e\u003e\u003e\u003e a\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e block\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e with transactions they have not seen before or transactions\n\u003e\u003e\u003e\u003e that may\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e contain double spends of unconfirmed inputs, this is not how\n\u003e\u003e\u003e\u003e mining\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e works, as long as the block passes the consensus rules\n\u003e\u003e\u003e\u003e effectively\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e all\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e miners will mine on top of it by default, this behavior is\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e fundamental\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e to how mining currently works and is fairly deeply baked into\n\u003e\u003e\u003e\u003e the\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e current mining infrastructure.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Will they accept this block? In theory it is possible and\n\u003e\u003e\u003e\u003e have\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e 0.01 percent chance but we can eliminate this small\n\u003e\u003e\u003e\u003e possibilities by\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e a simple BIP for miners.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e What would this BIP look like? I don't see how this could\n\u003e\u003e work\n\u003e\u003e\u003e\u003e in a\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e decentralized way as you would need another way of reaching\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e consensus\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e on what defines a valid block. Right now the chance is nearly\n\u003e\u003e\u003e\u003e 100\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e percent that a miner will mine on top of the latest valid\n\u003e\u003e\u003e\u003e block,\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e many\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e pools(most last I checked) will even mine on the next block\n\u003e\u003e\u003e\u003e before\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e they validate the latest block fully(ie validationless\n\u003e\u003e mining)\n\u003e\u003e\u003e\u003e to\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e reduce their orphan rates.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e We suppose the miners always control transactions with\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e doc-watchers and avoid accepting transaction with same UTXO\n\u003e\u003e\u003e\u003e but\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e different output.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Miners have different mempool policy/rules for what\n\u003e\u003e\u003e\u003e transactions\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e they\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e themselves mine but all miners must mine on the most work\n\u003e\u003e\u003e\u003e chain of\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e valid blocks otherwise they risk their own blocks being\n\u003e\u003e\u003e\u003e orphaned,\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e any\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e miner that does not do this is effectively guaranteed to have\n\u003e\u003e\u003e\u003e their\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e block orphaned right now.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Because of high Bitcoin transaction fee, this guarantee\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e transaction will take place in next block, even if other\n\u003e\u003e\u003e\u003e transaction\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e which are using the same UTXO as input existed in mempool.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e When a new transaction is broadcast miners do not immediately\n\u003e\u003e\u003e\u003e start\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e mining on a block template that includes that transaction,\n\u003e\u003e the\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e template won't even be generated immediately when it enters a\n\u003e\u003e\u003e\u003e miners\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e mempool in practice, for bandwidth/network efficiency reasons\n\u003e\u003e\u003e\u003e mining\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e pools batch update the stratum templates/jobs they mine\n\u003e\u003e\u003e\u003e against so\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e there can be significant latency between the time a\n\u003e\u003e\u003e\u003e transaction is\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e actually broadcast and hits the miners mempool and the time\n\u003e\u003e\u003e\u003e the\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e miners\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e actually switch to mining on top it, these batched updates\n\u003e\u003e are\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e essentially like point in time snapshots of the mempool and\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e typically\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e remain valid(as in the pool will accept shares submitted\n\u003e\u003e\u003e\u003e against\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e that\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e job as valid) until the bitcoin network finds the next block.\n\u003e\u003e\u003e\u003e I\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e don't\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e think these batch updates are done more often than every 30\n\u003e\u003e\u003e\u003e seconds\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e typically, while often it is on the order of multiple minutes\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e depending on the pool.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Regards,\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e James\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e I have a proposal for improve Bitcoin TPS and privacy, here\n\u003e\u003e\u003e\u003e is the\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e post.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e \n\u003e https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e https://bitcointalk.org/index.php?topic=5344020.0\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Can you please read it and share your idea about it.\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Cheers\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e Raymo\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e Links:\n\u003e\u003e\u003e ------\n\u003e\u003e\u003e [1]\n\u003e\u003e \n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html",
"sig": "37bcb31abc32ef95de12fe27860729b807c6468a65b121a4adc52ca6c6a7fc2785c28a866b3c20b92461ff9d62a24db0da303c2aef65bf9b29b2b8028360324f"
}