your protocol should always assume the email system is fully compromised, and only send public information over email:
- public keys / addresses are sent - other routing data encrypted with public keys (not sure how data is routed in sabu) your end user should be able to verify public keys / addresses - use QR-codes - phone calls with users reading BIP words out loud - other in-person information exchange separate the Sabu protocol from the app... allow others to implement desktop version, or other versions that use other routing systems - you can allow direct-entry of a BIP-word-representation of a public key/address to avoid privacy/central system concerns On Thu, Jul 1, 2021 at 4:20 PM raymo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi Billy, > Sorry for late reply. Let’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@lists.linuxfoundation.org> wrote: > > > >> I think you're making a number of assumptions about mining that are > >> not accurate. > >> > >>> First of all, how much chance in finding next block the corrupted > >> miners have? One percent of all Bitcoin hash powers? Or maximum 5 > >> percent or 10? The cheaters must come up in dividing that 1.2 > >> Bitcoin between. After all the risk/reward must fit them. They can > >> not be a big mining pool since there is no benefit, so they will be > >> small miners with low hash rate. If they solve the puzzle and > >> broadcast the block, no one in the entire Bitcoin network has block > >> transactions or seen it before in their mempool! > >> > >> You're making the assumption that miners won't build on top of a > >> block > >> with transactions they have not seen before or transactions that may > >> contain double spends of unconfirmed inputs, this is not how mining > >> works, as long as the block passes the consensus rules effectively > >> all > >> miners will mine on top of it by default, this behavior is > >> fundamental > >> to how mining currently works and is fairly deeply baked into the > >> current mining infrastructure. > >> > >>> Will they accept this block? In theory it is possible and have > >> 0.01 percent chance but we can eliminate this small possibilities by > >> a simple BIP for miners. > >> > >> What would this BIP look like? I don't see how this could work in a > >> decentralized way as you would need another way of reaching > >> consensus > >> on what defines a valid block. Right now the chance is nearly 100 > >> percent that a miner will mine on top of the latest valid block, > >> many > >> pools(most last I checked) will even mine on the next block before > >> they validate the latest block fully(ie validationless mining) to > >> reduce their orphan rates. > >> > >>> We suppose the miners always control transactions with > >> doc-watchers and avoid accepting transaction with same UTXO but > >> different output. > >> > >> Miners have different mempool policy/rules for what transactions > >> they > >> themselves mine but all miners must mine on the most work chain of > >> valid blocks otherwise they risk their own blocks being orphaned, > >> any > >> miner that does not do this is effectively guaranteed to have their > >> block orphaned right now. > >> > >>> Because of high Bitcoin transaction fee, this guarantee > >> transaction will take place in next block, even if other transaction > >> which are using the same UTXO as input existed in mempool. > >> > >> When a new transaction is broadcast miners do not immediately start > >> mining on a block template that includes that transaction, the > >> template won't even be generated immediately when it enters a miners > >> mempool in practice, for bandwidth/network efficiency reasons mining > >> pools batch update the stratum templates/jobs they mine against so > >> there can be significant latency between the time a transaction is > >> actually broadcast and hits the miners mempool and the time the > >> miners > >> actually switch to mining on top it, these batched updates are > >> essentially like point in time snapshots of the mempool and > >> typically > >> remain valid(as in the pool will accept shares submitted against > >> that > >> job as valid) until the bitcoin network finds the next block. I > >> don't > >> think these batch updates are done more often than every 30 seconds > >> typically, while often it is on the order of multiple minutes > >> depending on the pool. > >> > >> Regards, > >> James > >> > >> On Thu, Jun 17, 2021 at 2:14 PM raymo via bitcoin-dev > >> <bitcoin-dev@lists.linuxfoundation.org> wrote: > >>> > >>> Hi, > >>> I have a proposal for improve Bitcoin TPS and privacy, here is the > >> post. > >>> > >> > > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-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@lists.linuxfoundation.org > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev