* [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
@ 2021-06-16 13:44 raymo
2021-06-18 1:42 ` Erik Aronesty
` (3 more replies)
0 siblings, 4 replies; 41+ messages in thread
From: raymo @ 2021-06-16 13:44 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo @ 2021-06-18 1:42 ` Erik Aronesty 2021-06-18 13:44 ` Alex Schoof 2021-06-18 13:37 ` Erik Aronesty ` (2 subsequent siblings) 3 siblings, 1 reply; 41+ messages in thread From: Erik Aronesty @ 2021-06-18 1:42 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion for very small transactions, this seems to make a hell of a lot of sense. it's like lightning, but with no limits, no routing protocols... everything is guaranteed by relative fees and the cost-of-theft. pretty cool. On Thu, Jun 17, 2021 at 4: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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-18 1:42 ` Erik Aronesty @ 2021-06-18 13:44 ` Alex Schoof 2021-06-18 20:00 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: Alex Schoof @ 2021-06-18 13:44 UTC (permalink / raw) To: Bitcoin Protocol Discussion, Erik Aronesty [-- Attachment #1: Type: text/plain, Size: 2617 bytes --] A few questions/comments: Why is there a 10 sat fee on each tx? Where does that fee go? I don’t think this design sufficiently protects against double spends by the “issuer” (the person who actually has the UTXO). Your guarantee tx mechanism only really covers the case where someone tries to double spend part of a UTXO balance (in other words, if the penalty lost is less than the value gained by doing a double spend, its worth it to double spend, and in a world where you’re passing around digital IOUs, it’s easy to make it worth it). Later in the post, you mention that there will be a p2p network to gossip fund transfers and that will prevent an issuer from double spending. The problem there is that network latency is non-zero, large network partitions are both real and common, and nodes can come and go anytime (hardware failure, power failure, network partition healing, just because they feel like it, etc). Different nodes on the network might hear about different, conflicting transactions. Nodes will need a way to all come to consensus on what the right set of “sent notes” is. I think you will end up reinventing a lot of the problems solved by bitcoin. Why did you pick email as the RPC mechanism to transfer these notes? Email is going to add variable amounts of latency and things like spam filters will cause issues. Alex On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > for very small transactions, this seems to make a hell of a lot of sense. > > it's like lightning, but with no limits, no routing protocols... > everything is guaranteed by relative fees and the cost-of-theft. > > pretty cool. > > On Thu, Jun 17, 2021 at 4: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 > -- Alex Schoof [-- Attachment #2: Type: text/html, Size: 3962 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-18 13:44 ` Alex Schoof @ 2021-06-18 20:00 ` raymo 2021-06-19 21:14 ` Erik Aronesty 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-06-18 20:00 UTC (permalink / raw) To: Alex Schoof; +Cc: Bitcoin Protocol Discussion Hi Alex, The 10 Sat fee is Sabu-transaction-fee and goes to issuers to incentivize UTXO owners to put their money in system and prepare money transfer service for the Creditors. pretty much like banks. This number is my suggestion, but can be changed to something higher or lesser or even being customized for each issuer(Banks with high fee and more speed/reliability or less fee and less speed but more distributed). Typically Issuers put an UTXOs worth 40,000 Sat and issue a debt-document(transaction) worth 20,000 or less. So issuer can use thousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document (worth 20,000,000 debit) and earn significant Sabu-transaction-fee daily. No need to say the issuer also dictates the fiat to BTC exchange rate in first step, and can earn even more benefits by selling BTC a little higher than market price. The target would be penny savers which potentially buy very small amount each time(teenagers or people with low income specially). About your double-spend scenario please write a clear scenario and use the conventional terms such as issuer, creditor, MT, GT, CT etc... to study its feasibility. Maybe there are corner cases which I missed. So we will fix it as well. About p2p Gossiping, you are right. There is latency but it doesn't hurt the consensus on Sabu protocol. Please consider figure 7. inter creditors Bitcoin transfer as an example. By the way in all money transactions between issuer -> creditor or creditor->creditor, the receiver wallet "always" controls the doc-watcher client to be ensure the fact that the delivered debt-document(aka transaction) to receiver wallet, already exist on the doc-watcher sites. If that particular document exist in doc-watcher , the wallet consider it as a valid transaction, otherwise creditor won't accept the deal as a settled deal. >I think you will end up reinventing a lot of the problems solved by bitcoin. No, that's not true. Because I proposed a complementary tool for Bitcoin which came from a different point of view. Note the fact that Sabu protocol realizes a different model of decentralization. In Sabu there is no DLT at all and all consensus are between small set of users (most of time between an issuer and a creditor). In Sabu there is no obligation for everyone know everything about every transaction. Each participant only knows about its interest. Alongside there is a gossip mirroring of all transaction that flood to the clients a light weight information of a tuple [UTXO, transaction-Merkle-root]. These gossip nodes (doc-watchers) are not corruptible since it works in a simple proof-of-existance (true-positive) model. And no one can mutilate it by censor transactions. >Why did you pick email as the RPC mechanism to transfer these notes? First of all I have to explain a part of design spec. Each mobile wallet has to have a fresh email address which is dedicated to Sabu protocol activities. The wallet has access to this email address and read, delete inbox or send emails. So the spam or spam filter problem is not the case. In my opinion email is the ONLY neutral, free (non proprietary) and open protocol/technology for communication in the world that its infrastructure is well-established and is accessible all over the glob. Even in countries with low internet speed. I intentionally chose email as main communication mean. Because non technical people can easily make an email address or change it (comparing establish a website or use an static IP) and notify the friends about new address and they can easily send and receive Bitcoin just by knowing email addresses. Once the user install the Sabu-supporter-wallet (called Gazin), he will config and record his 12 seed words. The wallet also creates the PGP Pub/Priv key pair based on these 12 words seeds and signs the wallet email address too. All are take place behind the scene and user only sees its wallet is ready. So these 12 worlds are users wealth protector and identity sovereignty as well. User adds friends wallet email address or scan its QR code. The rest is PGP encrypted emails(handshake, agreement and transactions) between two wallets. No one needs to ask a central service to have an account. Pure Cypher punk users can run their personal email server or even better their freedombox https://freedomboxfoundation.org. So no one can stop user from using this system(Bitcoin + Sabu + Gazin) or ban his account. The wallet owner can easily and fast immigrate to new email address (or even different email service provider) and sign new address and notify to his friends circle with no real barrier. While these are all benefits of using email as a user identifier in system, there could be some privacy issue in some levels. For example most email service provider impose some sort of KYC or ask user mobile number, but there are other providers which are respecting users privacy. implicitly prevalence of Sabu users creates more demands for this privacy-respector-companies, so these companies will be increased. Another issue would be global passive spying or full-pipe project will find who do transaction with who. Since communications are PGP encrypted it won't be clear who is sender or receiver or how much is transferred or even if they are really parties in a transaction or it is just a fake noise connection! The forward secrecy also would be another issues. although these are mostly the privacy issues rather than Sabu intrinsic problems. Some other disadvantage of email is latency, so some third parties would easily provide the optional alternate communication services for wallet, e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to compensate the speed and/or privacy issues. These are all communication means and the wallet can simply use one or more methods in parallel. Later we will see the wallet users will choose which solution. Speed vs privacy, sovereignty and independence. Regards Raymo On 2021-06-18 13:44, Alex Schoof wrote: > A few questions/comments: > > Why is there a 10 sat fee on each tx? Where does that fee go? > > I don’t think this design sufficiently protects against double > spends by the “issuer” (the person who actually has the UTXO). > Your guarantee tx mechanism only really covers the case where someone > tries to double spend part of a UTXO balance (in other words, if the > penalty lost is less than the value gained by doing a double spend, > its worth it to double spend, and in a world where you’re passing > around digital IOUs, it’s easy to make it worth it). Later in the > post, you mention that there will be a p2p network to gossip fund > transfers and that will prevent an issuer from double spending. The > problem there is that network latency is non-zero, large network > partitions are both real and common, and nodes can come and go anytime > (hardware failure, power failure, network partition healing, just > because they feel like it, etc). Different nodes on the network might > hear about different, conflicting transactions. Nodes will need a way > to all come to consensus on what the right set of “sent notes” is. > I think you will end up reinventing a lot of the problems solved by > bitcoin. > > Why did you pick email as the RPC mechanism to transfer these notes? > Email is going to add variable amounts of latency and things like spam > filters will cause issues. > > Alex > > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> for very small transactions, this seems to make a hell of a lot of >> sense. >> >> it's like lightning, but with no limits, no routing protocols... >> everything is guaranteed by relative fees and the cost-of-theft. >> >> pretty cool. >> >> On Thu, Jun 17, 2021 at 4: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 > -- > > Alex Schoof ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-18 20:00 ` raymo @ 2021-06-19 21:14 ` Erik Aronesty 0 siblings, 0 replies; 41+ messages in thread From: Erik Aronesty @ 2021-06-19 21:14 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 9879 bytes --] There is no solution to preventing the fraud proofs. This is a known issue for Bitcoin in general. It basically caps your protocol at the cost of performing a fraud proof attack. Also I would ditch email in the core protocol, and use QR codes and device-to-device linking. client a shows QR client b scans QR (which is a pubkey) client b publishes his pubkey (gossip network), with POSK proof Then you add to your contact list. Email to be an optional clearly less secure layer but not part of the core protocol. It is vulnerable to mitm (how do you know who you're paying), but again for small values and known risks it's not terrible. On Fri, Jun 18, 2021 at 4:00 PM <raymo@riseup•net> wrote: > > > Hi Alex, > > The 10 Sat fee is Sabu-transaction-fee and goes to issuers to > incentivize UTXO owners to put their money in system and prepare money > transfer service for the Creditors. pretty much like banks. > This number is my suggestion, but can be changed to something higher or > lesser or even being customized for each issuer(Banks with high fee and > more speed/reliability or less fee and less speed but more distributed). > > Typically Issuers put an UTXOs worth 40,000 Sat and issue a > debt-document(transaction) worth 20,000 or less. So issuer can use > thousand UTXOs(each worth 40,000 Sat) and issue thousand debt-document > (worth 20,000,000 debit) and earn significant Sabu-transaction-fee > daily. > No need to say the issuer also dictates the fiat to BTC exchange rate in > first step, and can earn even more benefits by selling BTC a little > higher than market price. The target would be penny savers which > potentially buy very small amount each time(teenagers or people with low > income specially). > > About your double-spend scenario please write a clear scenario and use > the conventional terms such as issuer, creditor, MT, GT, CT etc... to > study its feasibility. Maybe there are corner cases which I missed. So > we will fix it as well. > > About p2p Gossiping, you are right. There is latency but it doesn't hurt > the consensus on Sabu protocol. Please consider figure 7. inter > creditors Bitcoin transfer as an example. By the way in all money > transactions between issuer -> creditor or creditor->creditor, the > receiver wallet "always" controls the doc-watcher client to be ensure > the fact that the delivered debt-document(aka transaction) to receiver > wallet, already exist on the doc-watcher sites. If that particular > document exist in doc-watcher , the wallet consider it as a valid > transaction, otherwise creditor won't accept the deal as a settled deal. > > >I think you will end up reinventing a lot of the problems solved by bitcoin. > > No, that's not true. Because I proposed a complementary tool for Bitcoin > which came from a different point of view. Note the fact that Sabu > protocol realizes a different model of decentralization. In Sabu there > is no DLT at all and all consensus are between small set of users (most > of time between an issuer and a creditor). In Sabu there is no > obligation for everyone know everything about every transaction. Each > participant only knows about its interest. Alongside there is a gossip > mirroring of all transaction that flood to the clients a light weight > information of a tuple [UTXO, transaction-Merkle-root]. These gossip > nodes (doc-watchers) are not corruptible since it works in a simple > proof-of-existance (true-positive) model. And no one can mutilate it by > censor transactions. > > >Why did you pick email as the RPC mechanism to transfer these notes? > > First of all I have to explain a part of design spec. Each mobile wallet > has to have a fresh email address which is dedicated to Sabu protocol > activities. The wallet has access to this email address and read, delete > inbox or send emails. So the spam or spam filter problem is not the > case. > > In my opinion email is the ONLY neutral, free (non proprietary) and open > protocol/technology for communication in the world that its > infrastructure is well-established and is accessible all over the glob. > Even in countries with low internet speed. > I intentionally chose email as main communication mean. Because non > technical people can easily make an email address or change it > (comparing establish a website or use an static IP) and notify the > friends about new address and they can easily send and receive Bitcoin > just by knowing email addresses. Once the user install the > Sabu-supporter-wallet (called Gazin), he will config and record his 12 > seed words. The wallet also creates the PGP Pub/Priv key pair based on > these 12 words seeds and signs the wallet email address too. All are > take place behind the scene and user only sees its wallet is ready. So > these 12 worlds are users wealth protector and identity sovereignty as > well. User adds friends wallet email address or scan its QR code. The > rest is PGP encrypted emails(handshake, agreement and transactions) > between two wallets. No one needs to ask a central service to have an > account. Pure Cypher punk users can run their personal email server or > even better their freedombox https://freedomboxfoundation.org. So no one > can stop user from using this system(Bitcoin + Sabu + Gazin) or ban his > account. The wallet owner can easily and fast immigrate to new email > address (or even different email service provider) and sign new address > and notify to his friends circle with no real barrier. > While these are all benefits of using email as a user identifier in > system, there could be some privacy issue in some levels. For example > most email service provider impose some sort of KYC or ask user mobile > number, but there are other providers which are respecting users > privacy. implicitly prevalence of Sabu users creates more demands for > this privacy-respector-companies, so these companies will be increased. > Another issue would be global passive spying or full-pipe project will > find who do transaction with who. Since communications are PGP encrypted > it won't be clear who is sender or receiver or how much is transferred > or even if they are really parties in a transaction or it is just a fake > noise connection! The forward secrecy also would be another issues. > although these are mostly the privacy issues rather than Sabu intrinsic > problems. > Some other disadvantage of email is latency, so some third parties would > easily provide the optional alternate communication services for wallet, > e.g Matrix, Nym network, Onion, I2P, classic central servers, etc to > compensate the speed and/or privacy issues. These are all communication > means and the wallet can simply use one or more methods in parallel. > Later we will see the wallet users will choose which solution. Speed vs > privacy, sovereignty and independence. > > Regards > Raymo > > On 2021-06-18 13:44, Alex Schoof wrote: > > A few questions/comments: > > > > Why is there a 10 sat fee on each tx? Where does that fee go? > > > > I don’t think this design sufficiently protects against double > > spends by the “issuer” (the person who actually has the UTXO). > > Your guarantee tx mechanism only really covers the case where someone > > tries to double spend part of a UTXO balance (in other words, if the > > penalty lost is less than the value gained by doing a double spend, > > its worth it to double spend, and in a world where you’re passing > > around digital IOUs, it’s easy to make it worth it). Later in the > > post, you mention that there will be a p2p network to gossip fund > > transfers and that will prevent an issuer from double spending. The > > problem there is that network latency is non-zero, large network > > partitions are both real and common, and nodes can come and go anytime > > (hardware failure, power failure, network partition healing, just > > because they feel like it, etc). Different nodes on the network might > > hear about different, conflicting transactions. Nodes will need a way > > to all come to consensus on what the right set of “sent notes” is. > > I think you will end up reinventing a lot of the problems solved by > > bitcoin. > > > > Why did you pick email as the RPC mechanism to transfer these notes? > > Email is going to add variable amounts of latency and things like spam > > filters will cause issues. > > > > Alex > > > > On Fri, Jun 18, 2021 at 4:23 AM Erik Aronesty via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > >> for very small transactions, this seems to make a hell of a lot of > >> sense. > >> > >> it's like lightning, but with no limits, no routing protocols... > >> everything is guaranteed by relative fees and the cost-of-theft. > >> > >> pretty cool. > >> > >> On Thu, Jun 17, 2021 at 4: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 > > -- > > > > Alex Schoof [-- Attachment #2: Type: text/html, Size: 12832 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo 2021-06-18 1:42 ` Erik Aronesty @ 2021-06-18 13:37 ` Erik Aronesty 2021-06-18 20:22 ` raymo 2021-06-20 0:53 ` ZmnSCPxj 2021-06-20 1:59 ` James Hilliard 3 siblings, 1 reply; 41+ messages in thread From: Erik Aronesty @ 2021-06-18 13:37 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1268 bytes --] It is vulnerable to sybil attacks or where the recipient is a victim of a proxy attack. If the recipient is not connected to a valid Network, then double spends could be allowed. as long as this protocol is intended for use of transactions around a dollar or so I don't see that being a financially lucrative attack. However consider a large department store. If I put a "fence" around that store and control all of its outbound peer connections, I can then allow double spends for the duration of my visit at the store. In order to defend against this large retailers would have to use distributed / trusted nodes and certificates. On Thu, Jun 17, 2021, 4: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 > [-- Attachment #2: Type: text/html, Size: 2489 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-18 13:37 ` Erik Aronesty @ 2021-06-18 20:22 ` raymo 0 siblings, 0 replies; 41+ messages in thread From: raymo @ 2021-06-18 20:22 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion I think I respond to sybil attack implicitly in Max response. Since the only consensus must be between issuer and creditor and they already are in a kind of web of trust connection. By the way it would be great if you explain the attack scenario in more detail and our conventional terms such as issuer, creditor, MT, GT, CT, etc... definitely we can solve it as well. On 2021-06-18 13:37, Erik Aronesty wrote: > It is vulnerable to sybil attacks or where the recipient is a victim > of a proxy attack. If the recipient is not connected to a valid > Network, then double spends could be allowed. > > as long as this protocol is intended for use of transactions around a > dollar or so I don't see that being a financially lucrative attack. > > However consider a large department store. If I put a "fence" around > that store and control all of its outbound peer connections, I can > then allow double spends for the duration of my visit at the store. > > In order to defend against this large retailers would have to use > distributed / trusted nodes and certificates. > > On Thu, Jun 17, 2021, 4: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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo 2021-06-18 1:42 ` Erik Aronesty 2021-06-18 13:37 ` Erik Aronesty @ 2021-06-20 0:53 ` ZmnSCPxj 2021-06-26 21:54 ` raymo 2021-06-20 1:59 ` James Hilliard 3 siblings, 1 reply; 41+ messages in thread From: ZmnSCPxj @ 2021-06-20 0:53 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion Good morning Raymo, > 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. Guarantee Transactions (GT) being higher-fee is ***not*** assured. Feerates are always bumpable --- the sender of a transaction only needs to directly contact a miner and offer a fee to take a specific transaction on the next block proposal, conditional on the transaction *actually* getting into a block. Such "side fees" are always possible. Indeed, the in-transaction fees are "just" a way to anonymously and atomically make that fee offer to miners --- but miners and issuers can always communicate directly without using Bitcoin transaction to arrange a higher fee for a fraudulent Main Transaction (MT). because of this, you should really treat all unconfirmed transactions --- including MTs and GTs --- as potentially replaceable, i.e. RBFable. There is no such thing as "RBF disabled", all transactions are inherently RBF-able due to side fees --- it is simply a matter of anonymity, atomicity, and ease-of-use. --- Every offchain protocol needs *the receiver* as a signatory to any unconfirmed transaction. Or more strongly, the receiver **must** be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does *not* have the receiver as a signatory. See: https://zmnscpxj.github.io/offchain/safety.html Thus, all safe offchain schemes need to use an n-of-n signing set. The smallest n-of-n that is still useful is 2-of-2, where one participant is a sender and the other is a receiver. (1-of-1 is not useful since there is no possible receiver who can sign). This requires Bitcoin to splinter into lots of 2-of-2 funds, each one a sovereign sub-money (that is *eventually* convertible to Bitcoin), each one a cryptocurrency system in its own right. However, it so happens that we have a mechanism for transferring value across multiple cryptocurrency systems: the HTLC. 2-of-2 is also the most stable. This is because *all* signatories of an n-of-n cryptocurrency system need to be online at the same time in order for *any* of them to use the funds in the system. If any one of them is offline, then the system is unusable. With 2 participants, there is some probability that one of them is offline and the individual 2-of-2 system is unusable. With 3 participants, the probability is higher (there are more participants that can be offline). With 4 participants, higher still. Thus, the most stable is to split Bitcoin into lots of little 2-of-2 systems, and use HTLCs to transfer funds across the little 2-of-2 systems. Thus, Lightning Network, which splits Bitcoin into lots of little 2-of-2 cryptocurrency systems (channels), and uses HTLCs to atomically transfer value across them (routing). Of course, having larger n is better as we need to splinter Bitcoin into fewer funds with larger participant sets. And we can mitigate the offline-problem by using a two-layer system: we have a n-of-n system (n > 2) that itself splits into multiple smaller 2-of-2 systems. That way, the Bitcoin layer is split into fewer UTXOs, reducing blockchain resource consumption further. Thus, Channel Factories hosting Lightning Channels. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-20 0:53 ` ZmnSCPxj @ 2021-06-26 21:54 ` raymo 2021-06-27 4:53 ` ZmnSCPxj 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-06-26 21:54 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion Good morning ZmnSCPxj Sorry for late reply. > Guarantee Transactions (GT) being higher-fee is ***not*** assured. The question is “assuring what?”. The whole point of my proposal is the fact that issuers and creditors act rationally and won't harm their selves. The numbers (input and output amounts), the relation between inputs and outputs amounts, the minimum and maximum of inputs and outputs amounts, and conditions of a valid trans-action in Sabu protocol are all designed precisely to leading the rational users toward the making profit from the system. And irrationals (either issuer or creditor) can harm the others and inevitably in con-sequence will hurt themselves too. So, there is a fair and just transaction (MT). The creditor can send the GT to Bitcoin network and lose 70% of his money and damage 15% of is-suer money! Vice versa the issuer can send GT to Bitcoin network and harm itself 15% in cost of hurt creditors 70% which is none sense. Or issuer can pay even more money directly to miner and hurt itself even more which is even more irrational! Or the miner will ignore the transaction fees of a GT and put the fraudulent transaction in next block, which I cannot imagine a miner that pass up his legal and legiti-mate income in favor of a greedy issuer! Please write me a scenario (preferably with clear amount of inputs and outputs) by which the cheater (either issuer or creditor) gains more profit than playing honestly. Only in this case we can accept your claim about weakness of protocol. > Every offchain protocol needs *the receiver* as a signatory to any unconfirmed transaction. the receiver **must** be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does *not* have the receiver as a signatory. I intentionally decided to not using 2 of 2 signature, because I didn't want to fall in same trap as Light-ening. I wanted to avoid this long drilling 2 of 2 signings and routing. Instead, I just proposed to cre-ate and sign a valid Bitcoin transaction between only 2 people in a pure-peer-to-peer communication. The only signer is the issuer (the UTXO owner). Again, same logic. Please write me a scenario by which the cheater (issuer or creditor) can cheat this only-issuer-signed transactions and gains more profit than playing honest. Due to numbers and trans-action restrictions and the insignificance of the amount of each transaction this scenario of fraud will fail too. Looking forward to hearing from you Raymo On 2021-06-20 00:53, ZmnSCPxj wrote: > Good morning Raymo, > >> 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. > > > Guarantee Transactions (GT) being higher-fee is ***not*** assured. > > Feerates are always bumpable --- the sender of a transaction only > needs to directly contact a miner and offer a fee to take a specific > transaction on the next block proposal, conditional on the transaction > *actually* getting into a block. > Such "side fees" are always possible. > Indeed, the in-transaction fees are "just" a way to anonymously and > atomically make that fee offer to miners --- but miners and issuers > can always communicate directly without using Bitcoin transaction to > arrange a higher fee for a fraudulent Main Transaction (MT). > > because of this, you should really treat all unconfirmed transactions > --- including MTs and GTs --- as potentially replaceable, i.e. > RBFable. > There is no such thing as "RBF disabled", all transactions are > inherently RBF-able due to side fees --- it is simply a matter of > anonymity, atomicity, and ease-of-use. > > --- > > Every offchain protocol needs *the receiver* as a signatory to any > unconfirmed transaction. > > Or more strongly, the receiver **must** be a signatory --- the > receiver cannot trust an unconfirmed transaction where the spent UTXO > has an alternate branch that does *not* have the receiver as a > signatory. > > See: https://zmnscpxj.github.io/offchain/safety.html > > Thus, all safe offchain schemes need to use an n-of-n signing set. > > The smallest n-of-n that is still useful is 2-of-2, where one > participant is a sender and the other is a receiver. > (1-of-1 is not useful since there is no possible receiver who can sign). > > This requires Bitcoin to splinter into lots of 2-of-2 funds, each one > a sovereign sub-money (that is *eventually* convertible to Bitcoin), > each one a cryptocurrency system in its own right. > However, it so happens that we have a mechanism for transferring value > across multiple cryptocurrency systems: the HTLC. > > 2-of-2 is also the most stable. > This is because *all* signatories of an n-of-n cryptocurrency system > need to be online at the same time in order for *any* of them to use > the funds in the system. > If any one of them is offline, then the system is unusable. > With 2 participants, there is some probability that one of them is > offline and the individual 2-of-2 system is unusable. > With 3 participants, the probability is higher (there are more > participants that can be offline). > With 4 participants, higher still. > > Thus, the most stable is to split Bitcoin into lots of little 2-of-2 > systems, and use HTLCs to transfer funds across the little 2-of-2 > systems. > > Thus, Lightning Network, which splits Bitcoin into lots of little > 2-of-2 cryptocurrency systems (channels), and uses HTLCs to atomically > transfer value across them (routing). > > > Of course, having larger n is better as we need to splinter Bitcoin > into fewer funds with larger participant sets. > And we can mitigate the offline-problem by using a two-layer system: > we have a n-of-n system (n > 2) that itself splits into multiple > smaller 2-of-2 systems. > That way, the Bitcoin layer is split into fewer UTXOs, reducing > blockchain resource consumption further. > > Thus, Channel Factories hosting Lightning Channels. > > Regards, > ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-26 21:54 ` raymo @ 2021-06-27 4:53 ` ZmnSCPxj 2021-06-27 11:05 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: ZmnSCPxj @ 2021-06-27 4:53 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion Good morning Raymo, > Good morning ZmnSCPxj > Sorry for late reply. > > > Guarantee Transactions (GT) being higher-fee is not assured. > > The question is “assuring what?”. > The whole point of my proposal is the fact that issuers and creditors > act rationally and won't harm their selves. The numbers (input and > output amounts), the relation between inputs and outputs amounts, the > minimum and maximum of inputs and outputs amounts, and conditions of a > valid trans-action in Sabu protocol are all designed precisely to > leading the rational users toward the making profit from the system. And > irrationals (either issuer or creditor) can harm the others and > inevitably in con-sequence will hurt themselves too. So, there is a fair > and just transaction (MT). > The creditor can send the GT to Bitcoin network and lose 70% of his > money and damage 15% of is-suer money! > Vice versa the issuer can send GT to Bitcoin network and harm itself 15% > in cost of hurt creditors 70% which is none sense. Or issuer can pay > even more money directly to miner and hurt itself even more which is > even more irrational! Or the miner will ignore the transaction fees of a > GT and put the fraudulent transaction in next block, which I cannot > imagine a miner that pass up his legal and legiti-mate income in favor > of a greedy issuer! > Please write me a scenario (preferably with clear amount of inputs and > outputs) by which the cheater (either issuer or creditor) gains more > profit than playing honestly. > Only in this case we can accept your claim about weakness of protocol. > > > Every offchain protocol needs the receiver as a signatory to any unconfirmed transaction. the receiver must be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does not have the receiver as a signatory. > > I intentionally decided to not using 2 of 2 signature, because I didn't > want to fall in same trap as Light-ening. I wanted to avoid this long > drilling 2 of 2 signings and routing. Instead, I just proposed to > cre-ate and sign a valid Bitcoin transaction between only 2 people in a > pure-peer-to-peer communication. The only signer is the issuer (the UTXO > owner). > Again, same logic. Please write me a scenario by which the cheater > (issuer or creditor) can cheat this only-issuer-signed transactions and > gains more profit than playing honest. Due to numbers and trans-action > restrictions and the insignificance of the amount of each transaction > this scenario of fraud will fail too. As the issuer is the only one signing, it can trivially create a self-paying transaction by itself that is neither a valid MT nor a valid GT. Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change output back to me. After you hand over the equivalent of 1 BTC in other resources, I then create an alternative transaction, signed only by myself, paying 0.5 BTC to miners and 1.5 BTC to myself, and since the fee is so high, the miners have every incentive to mine it. Yes, that is not a valid MT or GT, but nothing in the Bitcoin blockchain layer requires that the *single* signer follow the protocol. The point here is that a single signer can sign anything, including a transaction that is not an MT or a GT, but has arbitrary numbers that are neither a valid GT nor a valid MT. That is the reason why every trust-minimized offchain system requires 2-of-2, somebody else has to countercheck the validity of a protocol that is *not* directly on the blockchain. The blockchain only cares about signature and timelock validity; it does not care about (and check for validity) MTs and GTs. In essence, this is a trusted system where every creditor trusts every issuer to *only* sign GTs and MTs, thus uninteresting --- you might as well just use Coinbase as your offchain if you are going to inject trust. Now you can counterargue that you intend this system to be used for small payments and thus the fee for this non-MT non-GT clawback can approach the security levels you so carefully computed for GT and MT, but again --- the *largest* safe payment will vary depending on onchain mempool state, and if the mempool is almost empty, the largest safe payment will be much smaller than at other times. This uncertainty is not handled well by most users, thus I think your UX will be fairly awful. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-27 4:53 ` ZmnSCPxj @ 2021-06-27 11:05 ` raymo 2021-06-28 5:20 ` ZmnSCPxj 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-06-27 11:05 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion On 2021-06-27 04:53, ZmnSCPxj wrote: Good evening ZmnSCPxj It looks you already missed the entire design of Sabu and its restrictions. First of all, the Gazin wallet always controls the Sabu restrictions for every transaction in order to consider it as a valid transaction in a valid deal. That is, the creditor wallet controls the MT and GT in first place. Then if the transactions are valid the creditor consider entire process as a valid deal and give the services or goods in exchange of received Satoshis. So, in this scenario the issuer has to sign a MT transaction in which the issuer spends a UTXO worth at least 40,000 Sat, and issuer can issue maximum 20,000 Sat debt-document. So, the transaction can have One or more outputs for creditor(s), they must worth in total less than 20,000 Sat. Each transaction has to pay fixed 10,000 Sat as BTC-transaction-fee regardless the transaction length or the inputs/outputs amounts. The issuer always pays at least 4,000 Sat of BTC-transaction-fee, and the 6,000 remined fee must be paid by issuer and creditors in proportion to their outputs amounts) Finally, the transaction can have one change-back output to issuer address (same as input address) worth less than (40,000 – 4,000=36,000) Sat to issuer. This value depends on the debt amount and the issuer BTC-transaction-fee portion. The maximum issuer change back could be (40,000 -10,000 = 30,000) Sat for a transaction with no debt issuance. The minimum amount of change back would be (40,000 – 10,000 – 19,999 = 10,001 Sat). For more details, please take a look at figure 3. (Transaction in detail) in article https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180 also investigate on code https://github.com/raymaot/transaction-numbers-and-coefficients . The creditor controls all these criteria and after passing all these tests the creditor accept transaction as a valid transaction. Now creditor has 2 MT and GT transaction in his hand. Because of these number limitations, no arbitrary UTXO spending by issuer nor self-paying transaction can make more output and more benefits to him than respecting the already issued MT. please investigate on figure 1.0. (Security checks) for more details. Now show me a case (with precise amounts of inputs and outputs) that fits in Sabu restrictions AND issuer can make an arbitrary transaction with more benefit than MT! > the *largest* safe payment will vary depending on onchain mempool state, and if the mempool is almost empty, the largest safe payment will be much smaller than at other times. All these transactions are formed relatively (the numbers in GT are calculated based on MT), so they are relative, so no matter how much mempool is full or empty. The only consideration for mempool is the propagation delay which is another story and has its own solution as well. > I think your UX will be fairly awful. All validations and communications are behind the scene, so the UX will be enough smooth and friendly except the latency of email-based communications, which needs to be considered in details. BTW this is not a big deal considering the sovereignty and the freedom are bringing to our financial activities. > Good morning Raymo, > > >> Good morning ZmnSCPxj >> Sorry for late reply. >> >> > Guarantee Transactions (GT) being higher-fee is not assured. >> >> The question is “assuring what?”. >> The whole point of my proposal is the fact that issuers and creditors >> act rationally and won't harm their selves. The numbers (input and >> output amounts), the relation between inputs and outputs amounts, the >> minimum and maximum of inputs and outputs amounts, and conditions of a >> valid trans-action in Sabu protocol are all designed precisely to >> leading the rational users toward the making profit from the system. And >> irrationals (either issuer or creditor) can harm the others and >> inevitably in con-sequence will hurt themselves too. So, there is a fair >> and just transaction (MT). >> The creditor can send the GT to Bitcoin network and lose 70% of his >> money and damage 15% of is-suer money! >> Vice versa the issuer can send GT to Bitcoin network and harm itself 15% >> in cost of hurt creditors 70% which is none sense. Or issuer can pay >> even more money directly to miner and hurt itself even more which is >> even more irrational! Or the miner will ignore the transaction fees of a >> GT and put the fraudulent transaction in next block, which I cannot >> imagine a miner that pass up his legal and legiti-mate income in favor >> of a greedy issuer! >> Please write me a scenario (preferably with clear amount of inputs and >> outputs) by which the cheater (either issuer or creditor) gains more >> profit than playing honestly. >> Only in this case we can accept your claim about weakness of protocol. >> >> > Every offchain protocol needs the receiver as a signatory to any unconfirmed transaction. the receiver must be a signatory --- the receiver cannot trust an unconfirmed transaction where the spent UTXO has an alternate branch that does not have the receiver as a signatory. >> >> I intentionally decided to not using 2 of 2 signature, because I didn't >> want to fall in same trap as Light-ening. I wanted to avoid this long >> drilling 2 of 2 signings and routing. Instead, I just proposed to >> cre-ate and sign a valid Bitcoin transaction between only 2 people in a >> pure-peer-to-peer communication. The only signer is the issuer (the UTXO >> owner). >> Again, same logic. Please write me a scenario by which the cheater >> (issuer or creditor) can cheat this only-issuer-signed transactions and >> gains more profit than playing honest. Due to numbers and trans-action >> restrictions and the insignificance of the amount of each transaction >> this scenario of fraud will fail too. > > As the issuer is the only one signing, it can trivially create a > self-paying transaction by itself that is neither a valid MT nor a > valid GT. > > Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change > output back to me. > After you hand over the equivalent of 1 BTC in other resources, I then > create an alternative transaction, signed only by myself, paying 0.5 > BTC to miners and 1.5 BTC to myself, and since the fee is so high, the > miners have every incentive to mine it. > > Yes, that is not a valid MT or GT, but nothing in the Bitcoin > blockchain layer requires that the *single* signer follow the > protocol. > The point here is that a single signer can sign anything, including a > transaction that is not an MT or a GT, but has arbitrary numbers that > are neither a valid GT nor a valid MT. > That is the reason why every trust-minimized offchain system requires > 2-of-2, somebody else has to countercheck the validity of a protocol > that is *not* directly on the blockchain. > The blockchain only cares about signature and timelock validity; it > does not care about (and check for validity) MTs and GTs. > > In essence, this is a trusted system where every creditor trusts every > issuer to *only* sign GTs and MTs, thus uninteresting --- you might as > well just use Coinbase as your offchain if you are going to inject > trust. > > Now you can counterargue that you intend this system to be used for > small payments and thus the fee for this non-MT non-GT clawback can > approach the security levels you so carefully computed for GT and MT, > but again --- the *largest* safe payment will vary depending on > onchain mempool state, and if the mempool is almost empty, the largest > safe payment will be much smaller than at other times. > This uncertainty is not handled well by most users, thus I think your > UX will be fairly awful. > > Regards, > ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-27 11:05 ` raymo @ 2021-06-28 5:20 ` ZmnSCPxj 2021-06-28 6:29 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: ZmnSCPxj @ 2021-06-28 5:20 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion Good morning Raymo, > > It looks you already missed the entire design of Sabu and its > restrictions. First of all, the Gazin wallet always controls the Sabu > restrictions for every transaction in order to consider it as a valid > transaction in a valid deal. That is, the creditor wallet controls the > MT and GT in first place. Stop right there. From the above, what I get is, "trust the Gazin wallet". Thus, the suggestion to just use Coinbase. At least it has existed longer and has more current users that trust it, rather than this Gazin thing. Is Gazin open-source? * If Gazin is open-source, I could download the source code, make a local copy that gives me a separate copy of the keys, and use the keys to sign any transaction I want. * If Gazin is not open-source, then why should I trust the Gazin wallet until my incoming funds to an open-source wallet I control have been confirmed deeply? Lightning is still superior because: * It can be open-sourced completely and even though I have keys to my onchain funds, I *still* cannot steal the funds of my counterparty. * Even if I connect my open-source node to a node with a closed-source implementation, I know I can rely on receives from that node without waiting for the transaction to be confirmed deeply. All the benefits your scheme claims, are derived from the trust assumption, which is uninteresting, we already have those, they are called custodial wallets. Lightning allows for non-custodiality while achieving high global TPS and low fees. And a central idea of Lightning is the requirement to use an n-of-n to form smaller sub-moneys from the global money. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 5:20 ` ZmnSCPxj @ 2021-06-28 6:29 ` raymo 2021-06-28 8:23 ` James Hilliard 2021-06-28 15:28 ` ZmnSCPxj 0 siblings, 2 replies; 41+ messages in thread From: raymo @ 2021-06-28 6:29 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion Hi ZmnSCPxj, Why you get the signal “trust the Gazin wallet”? Sabu is a protocol and the Gazin wallet will be an implementation of that protocol. We will implement it in react-native language to support both Android and iPhone. Of course it will be open source and GPL3. Here is the repository and yet is empty :) https://github.com/raymaot/Gazin I wonder why you do not look carefully into the proposal! IMHO the Sabu will be far better than Lightning. Can’t you see the fact that in Sabu you do not need open and close channels ever? Can you imagine only this feature how dramatically decrease the transactions cost and how increase the distribution of nodes and improve privacy level? it makes every mobile wallet act like a lightning network. Did you note the fact that in Sabu protocol there is no routing? And the only people knew about a transaction are issuer and creditor? No one else won’t be aware of transactions and million transactions per second can be sent and received and repeal dynamically without any footprint on any DLT? The English is not my mother language and probably my paper is not a smooth and easy to read paper, but these are not good excuse to not even reading a technical paper carefully and before understanding it or at least trying to understanding it start to complaining. > All the benefits your scheme claims, are derived from the trust assumption No, All the benefits my scheme claims, are derived from economically rational decision of both issuer and creditors. Regards Raymo On 2021-06-28 05:20, ZmnSCPxj wrote: > Good morning Raymo, > >> >> It looks you already missed the entire design of Sabu and its >> restrictions. First of all, the Gazin wallet always controls the Sabu >> restrictions for every transaction in order to consider it as a valid >> transaction in a valid deal. That is, the creditor wallet controls the >> MT and GT in first place. > > Stop right there. > > From the above, what I get is, "trust the Gazin wallet". > Thus, the suggestion to just use Coinbase. > At least it has existed longer and has more current users that trust > it, rather than this Gazin thing. > > > Is Gazin open-source? > > * If Gazin is open-source, I could download the source code, make a > local copy that gives me a separate copy of the keys, and use the keys > to sign any transaction I want. > * If Gazin is not open-source, then why should I trust the Gazin > wallet until my incoming funds to an open-source wallet I control have > been confirmed deeply? > > Lightning is still superior because: > > * It can be open-sourced completely and even though I have keys to my > onchain funds, I *still* cannot steal the funds of my counterparty. > * Even if I connect my open-source node to a node with a closed-source > implementation, I know I can rely on receives from that node without > waiting for the transaction to be confirmed deeply. > > > All the benefits your scheme claims, are derived from the trust > assumption, which is uninteresting, we already have those, they are > called custodial wallets. > Lightning allows for non-custodiality while achieving high global TPS > and low fees. > And a central idea of Lightning is the requirement to use an n-of-n to > form smaller sub-moneys from the global money. > > Regards, > ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 6:29 ` raymo @ 2021-06-28 8:23 ` James Hilliard 2021-06-28 9:52 ` raymo 2021-06-28 15:28 ` ZmnSCPxj 1 sibling, 1 reply; 41+ messages in thread From: James Hilliard @ 2021-06-28 8:23 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Hi ZmnSCPxj, > > Why you get the signal “trust the Gazin wallet”? > Sabu is a protocol and the Gazin wallet will be an implementation of > that protocol. We will implement it in react-native language to support > both Android and iPhone. Of course it will be open source and GPL3. > Here is the repository and yet is empty :) > https://github.com/raymaot/Gazin > > I wonder why you do not look carefully into the proposal! IMHO the Sabu > will be far better than Lightning. > Can’t you see the fact that in Sabu you do not need open and close > channels ever? Can you imagine only this feature how dramatically > decrease the transactions cost and how increase the distribution of > nodes and improve privacy level? it makes every mobile wallet act like a > lightning network. > Did you note the fact that in Sabu protocol there is no routing? And the > only people knew about a transaction are issuer and creditor? No one > else won’t be aware of transactions and million transactions per second > can be sent and received and repeal dynamically without any footprint on > any DLT? > > The English is not my mother language and probably my paper is not a > smooth and easy to read paper, but these are not good excuse to not even > reading a technical paper carefully and before understanding it or at > least trying to understanding it start to complaining. Considering that you have not effectively addressed any of the inaccurate assumptions made regarding how mining works that I pointed out earlier I assume your proposal is not viable in practice. See: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html > > > All the benefits your scheme claims, are derived from the trust assumption > No, All the benefits my scheme claims, are derived from economically > rational decision of both issuer and creditors. > > Regards > Raymo > > > > On 2021-06-28 05:20, ZmnSCPxj wrote: > > Good morning Raymo, > > > >> > >> It looks you already missed the entire design of Sabu and its > >> restrictions. First of all, the Gazin wallet always controls the Sabu > >> restrictions for every transaction in order to consider it as a valid > >> transaction in a valid deal. That is, the creditor wallet controls the > >> MT and GT in first place. > > > > Stop right there. > > > > From the above, what I get is, "trust the Gazin wallet". > > Thus, the suggestion to just use Coinbase. > > At least it has existed longer and has more current users that trust > > it, rather than this Gazin thing. > > > > > > Is Gazin open-source? > > > > * If Gazin is open-source, I could download the source code, make a > > local copy that gives me a separate copy of the keys, and use the keys > > to sign any transaction I want. > > * If Gazin is not open-source, then why should I trust the Gazin > > wallet until my incoming funds to an open-source wallet I control have > > been confirmed deeply? > > > > Lightning is still superior because: > > > > * It can be open-sourced completely and even though I have keys to my > > onchain funds, I *still* cannot steal the funds of my counterparty. > > * Even if I connect my open-source node to a node with a closed-source > > implementation, I know I can rely on receives from that node without > > waiting for the transaction to be confirmed deeply. > > > > > > All the benefits your scheme claims, are derived from the trust > > assumption, which is uninteresting, we already have those, they are > > called custodial wallets. > > Lightning allows for non-custodiality while achieving high global TPS > > and low fees. > > And a central idea of Lightning is the requirement to use an n-of-n to > > form smaller sub-moneys from the global money. > > > > Regards, > > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 8:23 ` James Hilliard @ 2021-06-28 9:52 ` raymo 2021-06-28 11:28 ` James Hilliard 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-06-28 9:52 UTC (permalink / raw) To: James Hilliard; +Cc: Bitcoin Protocol Discussion Hi James, Sorry for not responding in detail. So, lets jump in the critiques. > 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 No, it is a wish. I hope in future miners consider this rule as well. But for now, I absolutely do not count on this restriction. So, miner can/will accept a valid block which contains some valid transactions which they didn’t aware of those transactions in advance. In order to explain how economically this won’t happened, I have to refer you to the fact that a conspiracy between a miner(mining pool) and a group of issuers to mine a block full of cheating transaction will makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC now). The 1.2 is coming from average(max) 6,000 transaction per block * max 20K Satoshi cheating benefit for each promised used UTXO in a debt-doc(transaction). In order to achieve this conspiracy, the mining pool has to mine the block in stealth, lonely and without broadcasting any of transactions to Bitcoin network. They have only 10 minutes to solve puzzle, otherwise they have to change the block header and restart again. After all, if they succeed, they have to divide this extra dirty 1.2 BTC in between. I I am not expert in mining pool calculations; you may help me to answer these questions? Consider these given facts: More hashrate = more success chance. More hashrate = more electric cost = less profit per each participator There is a minimum hashrate to have a minimum chance to solve the puzzle in next 10 minutes, otherwise it doesn't make sense to participate in an activity that doesn't fit the minimum hope. How much is this minimum hashrate? How much costs this hashrate? Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it be economically cost effective (risk to reward) to dedicate your hashrate to mine this block? I am not sure. But if you show me the opposite by facts and numbers, I will highly appreciate you. > What would this BIP look like? > We suppose the miners always control transactions with doc-watchers As I told before, these assumptions are my wishes and I never relayed on these wishes. These are for future. For now, I just count on the calculation that asked you to help. > 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 It is great. Although this latency could be lesser (in case of empty mempools), but Sabu likes this latency. Because the creditors will have more time to be aware of a fraudulent activity from issuer and existence of a cheating transaction in mempool, so they have more time to send and broad cast the GT to network. More latency, more chance in batch update. So more chance for miners to face two or three transactions which are using same UTXO but sending to different addresses and paying different fees. More latency increases the chance of putting the higher-fee-payer transaction in next block. Regards Raymo On 2021-06-28 08:23, James Hilliard wrote: > On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> Hi ZmnSCPxj, >> >> Why you get the signal “trust the Gazin wallet”? >> Sabu is a protocol and the Gazin wallet will be an implementation of >> that protocol. We will implement it in react-native language to support >> both Android and iPhone. Of course it will be open source and GPL3. >> Here is the repository and yet is empty :) >> https://github.com/raymaot/Gazin >> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu >> will be far better than Lightning. >> Can’t you see the fact that in Sabu you do not need open and close >> channels ever? Can you imagine only this feature how dramatically >> decrease the transactions cost and how increase the distribution of >> nodes and improve privacy level? it makes every mobile wallet act like a >> lightning network. >> Did you note the fact that in Sabu protocol there is no routing? And the >> only people knew about a transaction are issuer and creditor? No one >> else won’t be aware of transactions and million transactions per second >> can be sent and received and repeal dynamically without any footprint on >> any DLT? >> >> The English is not my mother language and probably my paper is not a >> smooth and easy to read paper, but these are not good excuse to not even >> reading a technical paper carefully and before understanding it or at >> least trying to understanding it start to complaining. > > Considering that you have not effectively addressed any of the inaccurate > assumptions made regarding how mining works that I pointed out earlier > I assume your proposal is not viable in practice. > > See: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html > >> >> > All the benefits your scheme claims, are derived from the trust assumption >> No, All the benefits my scheme claims, are derived from economically >> rational decision of both issuer and creditors. >> >> Regards >> Raymo >> >> >> >> On 2021-06-28 05:20, ZmnSCPxj wrote: >> > Good morning Raymo, >> > >> >> >> >> It looks you already missed the entire design of Sabu and its >> >> restrictions. First of all, the Gazin wallet always controls the Sabu >> >> restrictions for every transaction in order to consider it as a valid >> >> transaction in a valid deal. That is, the creditor wallet controls the >> >> MT and GT in first place. >> > >> > Stop right there. >> > >> > From the above, what I get is, "trust the Gazin wallet". >> > Thus, the suggestion to just use Coinbase. >> > At least it has existed longer and has more current users that trust >> > it, rather than this Gazin thing. >> > >> > >> > Is Gazin open-source? >> > >> > * If Gazin is open-source, I could download the source code, make a >> > local copy that gives me a separate copy of the keys, and use the keys >> > to sign any transaction I want. >> > * If Gazin is not open-source, then why should I trust the Gazin >> > wallet until my incoming funds to an open-source wallet I control have >> > been confirmed deeply? >> > >> > Lightning is still superior because: >> > >> > * It can be open-sourced completely and even though I have keys to my >> > onchain funds, I *still* cannot steal the funds of my counterparty. >> > * Even if I connect my open-source node to a node with a closed-source >> > implementation, I know I can rely on receives from that node without >> > waiting for the transaction to be confirmed deeply. >> > >> > >> > All the benefits your scheme claims, are derived from the trust >> > assumption, which is uninteresting, we already have those, they are >> > called custodial wallets. >> > Lightning allows for non-custodiality while achieving high global TPS >> > and low fees. >> > And a central idea of Lightning is the requirement to use an n-of-n to >> > form smaller sub-moneys from the global money. >> > >> > Regards, >> > ZmnSCPxj >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 9:52 ` raymo @ 2021-06-28 11:28 ` James Hilliard 2021-06-28 16:33 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: James Hilliard @ 2021-06-28 11:28 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion On Mon, Jun 28, 2021 at 3:52 AM <raymo@riseup•net> wrote: > > > Hi James, > Sorry for not responding in detail. > So, lets jump in the critiques. > > > 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 > No, it is a wish. I hope in future miners consider this rule as well. There's only one practical approach I'm aware of for miners to actually do this, and that would be to effectively make mining centralized. So I would highly discourage this sort of policy when it comes to mining. > But for now, I absolutely do not count on this restriction. So, miner > can/will accept a valid block which contains some valid transactions > which they didn’t aware of those transactions in advance. Mempools among miners are generally not fully in sync with each other, rejecting valid blocks due to disagreements over which transactions were broadcast would destabilize the network as you'd get a bunch of network forks. > In order to explain how economically this won’t happened, I have to > refer you to the fact that a conspiracy between a miner(mining pool) and > a group of issuers to mine a block full of cheating transaction will > makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC > now). The 1.2 is coming from average(max) 6,000 transaction per block * > max 20K Satoshi cheating benefit for each promised used UTXO in a > debt-doc(transaction). But there's no risk really for a miner to choose the most profitable transactions to mine as long as they are valid per the network rules, that is unless you make mining fully centralized. > In order to achieve this conspiracy, the mining pool has to mine the > block in stealth, lonely and without broadcasting any of transactions to > Bitcoin network. They have only 10 minutes to solve puzzle, otherwise > they have to change the block header and restart again. After all, if > they succeed, they have to divide this extra dirty 1.2 BTC in between. I Miners regularly change block headers, and if they don't broadcast the transactions there wouldn't really be a time limit, so even a relatively small miner would be able to stealthily mine the transactions given enough time. > > > I am not expert in mining pool calculations; you may help me to answer > these questions? > > Consider these given facts: > > More hashrate = more success chance. > More hashrate = more electric cost = less profit per each participator > There is a minimum hashrate to have a minimum chance to solve the puzzle > in next 10 minutes, otherwise it doesn't make sense to participate in an > activity that doesn't fit the minimum hope. Why would they need to solve the block within 10 minutes? > How much is this minimum hashrate? I don't think there is a minimum. > How much costs this hashrate? Miners just use pools to reduce variance, there isn't a set minimum size to solo mine, only how much variance the miner can tolerate. > Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it > be economically cost effective (risk to reward) to dedicate your > hashrate to mine this block? I am not sure. But if you show me the > opposite by facts and numbers, I will highly appreciate you. All that matters is if that extra is more than they would otherwise get. > > > What would this BIP look like? > > We suppose the miners always control transactions with doc-watchers > As I told before, these assumptions are my wishes and I never relayed on > these wishes. These are for future. For now, I just count on the > calculation that asked you to help. The reason I ask is because I don't think this is possible to do without massively centralizing mining. > > > 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 > > It is great. Although this latency could be lesser (in case of empty > mempools), but Sabu likes this latency. Because the creditors will have > more time to be aware of a fraudulent activity from issuer and existence > of a cheating transaction in mempool, so they have more time to send and > broad cast the GT to network. More latency, more chance in batch update. > So more chance for miners to face two or three transactions which are > using same UTXO but sending to different addresses and paying different > fees. > More latency increases the chance of putting the higher-fee-payer > transaction in next block. Actually it's the opposite, if pools updated their templates every second the GT transaction could almost immediately replace the fraudulent transaction, however due to the batch updating if the fraudulent transaction ended up in a template it could take a significant amount of time for it to be purged from all the mining pool templates, no matter the fee difference. Ultimately this means that one should always expect miners to mine the first seen transaction for a significant period of time, with no guarantees that it would be replaced. > > Regards > Raymo > > > On 2021-06-28 08:23, James Hilliard wrote: > > On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> > >> Hi ZmnSCPxj, > >> > >> Why you get the signal “trust the Gazin wallet”? > >> Sabu is a protocol and the Gazin wallet will be an implementation of > >> that protocol. We will implement it in react-native language to support > >> both Android and iPhone. Of course it will be open source and GPL3. > >> Here is the repository and yet is empty :) > >> https://github.com/raymaot/Gazin > >> > >> I wonder why you do not look carefully into the proposal! IMHO the Sabu > >> will be far better than Lightning. > >> Can’t you see the fact that in Sabu you do not need open and close > >> channels ever? Can you imagine only this feature how dramatically > >> decrease the transactions cost and how increase the distribution of > >> nodes and improve privacy level? it makes every mobile wallet act like a > >> lightning network. > >> Did you note the fact that in Sabu protocol there is no routing? And the > >> only people knew about a transaction are issuer and creditor? No one > >> else won’t be aware of transactions and million transactions per second > >> can be sent and received and repeal dynamically without any footprint on > >> any DLT? > >> > >> The English is not my mother language and probably my paper is not a > >> smooth and easy to read paper, but these are not good excuse to not even > >> reading a technical paper carefully and before understanding it or at > >> least trying to understanding it start to complaining. > > > > Considering that you have not effectively addressed any of the inaccurate > > assumptions made regarding how mining works that I pointed out earlier > > I assume your proposal is not viable in practice. > > > > See: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html > > > >> > >> > All the benefits your scheme claims, are derived from the trust assumption > >> No, All the benefits my scheme claims, are derived from economically > >> rational decision of both issuer and creditors. > >> > >> Regards > >> Raymo > >> > >> > >> > >> On 2021-06-28 05:20, ZmnSCPxj wrote: > >> > Good morning Raymo, > >> > > >> >> > >> >> It looks you already missed the entire design of Sabu and its > >> >> restrictions. First of all, the Gazin wallet always controls the Sabu > >> >> restrictions for every transaction in order to consider it as a valid > >> >> transaction in a valid deal. That is, the creditor wallet controls the > >> >> MT and GT in first place. > >> > > >> > Stop right there. > >> > > >> > From the above, what I get is, "trust the Gazin wallet". > >> > Thus, the suggestion to just use Coinbase. > >> > At least it has existed longer and has more current users that trust > >> > it, rather than this Gazin thing. > >> > > >> > > >> > Is Gazin open-source? > >> > > >> > * If Gazin is open-source, I could download the source code, make a > >> > local copy that gives me a separate copy of the keys, and use the keys > >> > to sign any transaction I want. > >> > * If Gazin is not open-source, then why should I trust the Gazin > >> > wallet until my incoming funds to an open-source wallet I control have > >> > been confirmed deeply? > >> > > >> > Lightning is still superior because: > >> > > >> > * It can be open-sourced completely and even though I have keys to my > >> > onchain funds, I *still* cannot steal the funds of my counterparty. > >> > * Even if I connect my open-source node to a node with a closed-source > >> > implementation, I know I can rely on receives from that node without > >> > waiting for the transaction to be confirmed deeply. > >> > > >> > > >> > All the benefits your scheme claims, are derived from the trust > >> > assumption, which is uninteresting, we already have those, they are > >> > called custodial wallets. > >> > Lightning allows for non-custodiality while achieving high global TPS > >> > and low fees. > >> > And a central idea of Lightning is the requirement to use an n-of-n to > >> > form smaller sub-moneys from the global money. > >> > > >> > Regards, > >> > ZmnSCPxj > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists•linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 11:28 ` James Hilliard @ 2021-06-28 16:33 ` raymo 0 siblings, 0 replies; 41+ messages in thread From: raymo @ 2021-06-28 16:33 UTC (permalink / raw) To: James Hilliard; +Cc: Bitcoin Protocol Discussion Hi James, > There's only one practical approach I'm aware of for miners to actually > do this, and that would be to effectively make mining centralized. > So I would highly discourage this sort of policy when it comes to mining. I do not know about the approach you talking about it, but my solution is not centralized at all. In Sabu proposal/architecture you can find the doc-watchers network. It will be a torrent-like network where nodes just gossip the very light information about used UTXOs in Sabu protocol. All nodes will receive information and flood it to other nodes. So, all nodes just mirror same information. Two types of information are transferring through this peer-to-peer doc-watcher network. One is a very minimal record history of the UTXOs and a Merkle root of proper Sabu transactions. This information will be used by mobile wallet to be ensure issuer didn’t promise same UTXO to different creditors. The second data type are moving through doc-watchers nodes are signed UTXOs in order to signal to miners the fact that this UTXO is promised to some creditors. So, miners won’t allow this UTXO to be used in other ways to promise. In order to release (un-pledge) this UTXO the issuer has to sign it again alongside a release request. It is roughly what I suppose to be implemented and be respected by miners in future. It wouldn’t be centralized unless you believe torrent is centralized. Miners can/will control UTXOs status (in sense of is promised to someone or not) before putting them in batch template. > Miners regularly change block headers, and if they don't broadcast the > transactions there wouldn't really be a time limit, so even a relatively small > miner would be able to stealthily mine the transactions given enough time. It means a miner at least every 10 minutes has to change the header and re-try to solve the puzzle. Yes, a miner or a mining pool can stealthily mine transactions given enough time. And we already knew time of solving a puzzle is almost random. So “maybe” the small miner is enough lucky to find a block full of fraudulent transaction. But the question is; this effort to fraud, how much more economically beneficial than participation in the healthy chain will be? The answer will tell us the feasibility of Sabu protocol. There is another protection that won't let the worker and creditor to mine stealthily a particular UTXO set for unlimited time. please read the appendix "V: Recycling UTXOs" for more details. > Why would they need to solve the block within 10 minutes? You are right, they are not forced to solve it in 10 minutes but definitely they have to change the header every 10 minutes. Otherwise, they would end up in mining an orphan block which has no sense. Although it is not linear, but I used to believe changing block header every 10 minutes will reduce efficiency and chance of solving puzzle dramatically. > All that matters is if that extra is more than they would otherwise get. Yes, while it is true, but it is not enough. We need numbers and calculation to find if this kind of attack is possible? And how much is the possibility? And… An attack with 0.01% of success is obviously a failed plan and no one consider it as a threat. Although even this small threat will be resolve by the mentioned BIP absolutely. About the timing details. You are right. The less batch update time means more chance to fraudulent transaction replaced by the GT transaction. BTW even this scenario would be improved by suggested BIP implementation, since the fraudulent transaction won’t be in batch template at all. Best On 2021-06-28 11:28, James Hilliard wrote: > On Mon, Jun 28, 2021 at 3:52 AM <raymo@riseup•net> wrote: >> >> >> Hi James, >> Sorry for not responding in detail. >> So, lets jump in the critiques. >> >> > 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 >> No, it is a wish. I hope in future miners consider this rule as well. > > There's only one practical approach I'm aware of for miners to actually > do this, and that would be to effectively make mining centralized. > So I would highly discourage this sort of policy when it comes to mining. > >> But for now, I absolutely do not count on this restriction. So, miner >> can/will accept a valid block which contains some valid transactions >> which they didn’t aware of those transactions in advance. > > Mempools among miners are generally not fully in sync with each other, > rejecting valid blocks due to disagreements over which transactions were > broadcast would destabilize the network as you'd get a bunch of network > forks. > >> In order to explain how economically this won’t happened, I have to >> refer you to the fact that a conspiracy between a miner(mining pool) and >> a group of issuers to mine a block full of cheating transaction will >> makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC >> now). The 1.2 is coming from average(max) 6,000 transaction per block * >> max 20K Satoshi cheating benefit for each promised used UTXO in a >> debt-doc(transaction). > > But there's no risk really for a miner to choose the most profitable > transactions to mine as long as they are valid per the network rules, > that is unless you make mining fully centralized. > >> In order to achieve this conspiracy, the mining pool has to mine the >> block in stealth, lonely and without broadcasting any of transactions to >> Bitcoin network. They have only 10 minutes to solve puzzle, otherwise >> they have to change the block header and restart again. After all, if >> they succeed, they have to divide this extra dirty 1.2 BTC in between. I > > Miners regularly change block headers, and if they don't broadcast the > transactions there wouldn't really be a time limit, so even a relatively small > miner would be able to stealthily mine the transactions given enough time. > >> >> >> I am not expert in mining pool calculations; you may help me to answer >> these questions? >> >> Consider these given facts: >> >> More hashrate = more success chance. >> More hashrate = more electric cost = less profit per each participator >> There is a minimum hashrate to have a minimum chance to solve the puzzle >> in next 10 minutes, otherwise it doesn't make sense to participate in an >> activity that doesn't fit the minimum hope. > > Why would they need to solve the block within 10 minutes? > >> How much is this minimum hashrate? > > I don't think there is a minimum. > >> How much costs this hashrate? > > Miners just use pools to reduce variance, there isn't a set minimum size to > solo mine, only how much variance the miner can tolerate. > >> Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it >> be economically cost effective (risk to reward) to dedicate your >> hashrate to mine this block? I am not sure. But if you show me the >> opposite by facts and numbers, I will highly appreciate you. > > All that matters is if that extra is more than they would otherwise get. > >> >> > What would this BIP look like? >> > We suppose the miners always control transactions with doc-watchers >> As I told before, these assumptions are my wishes and I never relayed on >> these wishes. These are for future. For now, I just count on the >> calculation that asked you to help. > > The reason I ask is because I don't think this is possible to do > without massively > centralizing mining. > >> >> > 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 >> >> It is great. Although this latency could be lesser (in case of empty >> mempools), but Sabu likes this latency. Because the creditors will have >> more time to be aware of a fraudulent activity from issuer and existence >> of a cheating transaction in mempool, so they have more time to send and >> broad cast the GT to network. More latency, more chance in batch update. >> So more chance for miners to face two or three transactions which are >> using same UTXO but sending to different addresses and paying different >> fees. >> More latency increases the chance of putting the higher-fee-payer >> transaction in next block. > > Actually it's the opposite, if pools updated their templates every second > the GT transaction could almost immediately replace the fraudulent transaction, > however due to the batch updating if the fraudulent transaction ended up > in a template it could take a significant amount of time for it to be purged > from all the mining pool templates, no matter the fee difference. > > Ultimately this means that one should always expect miners to mine the > first seen transaction for a significant period of time, with no guarantees > that it would be replaced. > >> >> Regards >> Raymo >> >> >> On 2021-06-28 08:23, James Hilliard wrote: >> > On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev >> > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> >> >> Hi ZmnSCPxj, >> >> >> >> Why you get the signal “trust the Gazin wallet”? >> >> Sabu is a protocol and the Gazin wallet will be an implementation of >> >> that protocol. We will implement it in react-native language to support >> >> both Android and iPhone. Of course it will be open source and GPL3. >> >> Here is the repository and yet is empty :) >> >> https://github.com/raymaot/Gazin >> >> >> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu >> >> will be far better than Lightning. >> >> Can’t you see the fact that in Sabu you do not need open and close >> >> channels ever? Can you imagine only this feature how dramatically >> >> decrease the transactions cost and how increase the distribution of >> >> nodes and improve privacy level? it makes every mobile wallet act like a >> >> lightning network. >> >> Did you note the fact that in Sabu protocol there is no routing? And the >> >> only people knew about a transaction are issuer and creditor? No one >> >> else won’t be aware of transactions and million transactions per second >> >> can be sent and received and repeal dynamically without any footprint on >> >> any DLT? >> >> >> >> The English is not my mother language and probably my paper is not a >> >> smooth and easy to read paper, but these are not good excuse to not even >> >> reading a technical paper carefully and before understanding it or at >> >> least trying to understanding it start to complaining. >> > >> > Considering that you have not effectively addressed any of the inaccurate >> > assumptions made regarding how mining works that I pointed out earlier >> > I assume your proposal is not viable in practice. >> > >> > See: >> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html >> > >> >> >> >> > All the benefits your scheme claims, are derived from the trust assumption >> >> No, All the benefits my scheme claims, are derived from economically >> >> rational decision of both issuer and creditors. >> >> >> >> Regards >> >> Raymo >> >> >> >> >> >> >> >> On 2021-06-28 05:20, ZmnSCPxj wrote: >> >> > Good morning Raymo, >> >> > >> >> >> >> >> >> It looks you already missed the entire design of Sabu and its >> >> >> restrictions. First of all, the Gazin wallet always controls the Sabu >> >> >> restrictions for every transaction in order to consider it as a valid >> >> >> transaction in a valid deal. That is, the creditor wallet controls the >> >> >> MT and GT in first place. >> >> > >> >> > Stop right there. >> >> > >> >> > From the above, what I get is, "trust the Gazin wallet". >> >> > Thus, the suggestion to just use Coinbase. >> >> > At least it has existed longer and has more current users that trust >> >> > it, rather than this Gazin thing. >> >> > >> >> > >> >> > Is Gazin open-source? >> >> > >> >> > * If Gazin is open-source, I could download the source code, make a >> >> > local copy that gives me a separate copy of the keys, and use the keys >> >> > to sign any transaction I want. >> >> > * If Gazin is not open-source, then why should I trust the Gazin >> >> > wallet until my incoming funds to an open-source wallet I control have >> >> > been confirmed deeply? >> >> > >> >> > Lightning is still superior because: >> >> > >> >> > * It can be open-sourced completely and even though I have keys to my >> >> > onchain funds, I *still* cannot steal the funds of my counterparty. >> >> > * Even if I connect my open-source node to a node with a closed-source >> >> > implementation, I know I can rely on receives from that node without >> >> > waiting for the transaction to be confirmed deeply. >> >> > >> >> > >> >> > All the benefits your scheme claims, are derived from the trust >> >> > assumption, which is uninteresting, we already have those, they are >> >> > called custodial wallets. >> >> > Lightning allows for non-custodiality while achieving high global TPS >> >> > and low fees. >> >> > And a central idea of Lightning is the requirement to use an n-of-n to >> >> > form smaller sub-moneys from the global money. >> >> > >> >> > Regards, >> >> > ZmnSCPxj >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev@lists•linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 6:29 ` raymo 2021-06-28 8:23 ` James Hilliard @ 2021-06-28 15:28 ` ZmnSCPxj 2021-06-28 16:58 ` raymo 2021-06-28 17:29 ` Tao Effect 1 sibling, 2 replies; 41+ messages in thread From: ZmnSCPxj @ 2021-06-28 15:28 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion Good morning Raymo, > Hi ZmnSCPxj, > > Why you get the signal “trust the Gazin wallet”? > Sabu is a protocol and the Gazin wallet will be an implementation of > that protocol. We will implement it in react-native language to support > both Android and iPhone. Of course it will be open source and GPL3. > Here is the repository and yet is empty :) > https://github.com/raymaot/Gazin > > I wonder why you do not look carefully into the proposal! IMHO the Sabu > will be far better than Lightning. > Can’t you see the fact that in Sabu you do not need open and close > channels ever? Can you imagine only this feature how dramatically > decrease the transactions cost and how increase the distribution of > nodes and improve privacy level? it makes every mobile wallet act like a > lightning network. > Did you note the fact that in Sabu protocol there is no routing? And the > only people knew about a transaction are issuer and creditor? No one > else won’t be aware of transactions and million transactions per second > can be sent and received and repeal dynamically without any footprint on > any DLT? > > The English is not my mother language and probably my paper is not a > smooth and easy to read paper, but these are not good excuse to not even > reading a technical paper carefully and before understanding it or at > least trying to understanding it start to complaining. What prevents the creditor from signing a transaction that is neither a valid MT nor a GT? Nothing. In Lightning, sure one side can sign a transaction that is not a valid commitment transaction, but good luck getting the other side to *also* sign the transaction; it will not. Thus, you need n-of-n. 1-of-1 is simply not secure, full stop, you need to redesign the whole thing to use *at least* 2-of-2. At which point you will have reinvented Lightning. Otherwise, you are simply trusting that the wallet is implemented correctly, and in particular, that any creditor will not simply insert code in your open-source software to sign invalid transactions. With a 1-of-1, any invalid-in-Sabu transaction can still be valid in the Bitcoin blockchain layer, thus the scheme is simply insecure. Features are meaningless without this kind of basic trust-minimization security. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 15:28 ` ZmnSCPxj @ 2021-06-28 16:58 ` raymo 2021-06-28 17:58 ` Alex Schoof 2021-06-28 17:29 ` Tao Effect 1 sibling, 1 reply; 41+ messages in thread From: raymo @ 2021-06-28 16:58 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion > What prevents the creditor from signing a transaction that is neither a valid MT nor a GT? Please stop comparing Sabu and Lightning. Otherwise, it won't let you true understanding of Sabu. In Sabu protocol, only the issuer (the UTXO owner) can sign the transaction and decide how much money goes to whom. The engaged UTXO(s) belonged to issuer and the creditor never put UTXO in transaction, thus never can sign the transaction because he has no ownership on the used UTXOs. As I already wrote in paper, the issuer creates and signs a transaction and delivers it to creditor(s). If a creditor intends to send all or part of his money to another person (AKA spending his money), he will ask for a new signed transaction from issuer, in which a part of his credit will transfer to another creditor. The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of doc-watchers which maybe it was the cause you always compare it to Lightning. I am not presenting lightning neither condemning it. I am presenting Sabu protocol. Please let concentrate on how Sabu works or not works. On 2021-06-28 15:28, ZmnSCPxj wrote: > Good morning Raymo, > >> Hi ZmnSCPxj, >> >> Why you get the signal “trust the Gazin wallet”? >> Sabu is a protocol and the Gazin wallet will be an implementation of >> that protocol. We will implement it in react-native language to support >> both Android and iPhone. Of course it will be open source and GPL3. >> Here is the repository and yet is empty :) >> https://github.com/raymaot/Gazin >> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu >> will be far better than Lightning. >> Can’t you see the fact that in Sabu you do not need open and close >> channels ever? Can you imagine only this feature how dramatically >> decrease the transactions cost and how increase the distribution of >> nodes and improve privacy level? it makes every mobile wallet act like a >> lightning network. >> Did you note the fact that in Sabu protocol there is no routing? And the >> only people knew about a transaction are issuer and creditor? No one >> else won’t be aware of transactions and million transactions per second >> can be sent and received and repeal dynamically without any footprint on >> any DLT? >> >> The English is not my mother language and probably my paper is not a >> smooth and easy to read paper, but these are not good excuse to not even >> reading a technical paper carefully and before understanding it or at >> least trying to understanding it start to complaining. > > > What prevents the creditor from signing a transaction that is neither > a valid MT nor a GT? > > Nothing. > > In Lightning, sure one side can sign a transaction that is not a valid > commitment transaction, but good luck getting the other side to *also* > sign the transaction; it will not. > Thus, you need n-of-n. > > 1-of-1 is simply not secure, full stop, you need to redesign the whole > thing to use *at least* 2-of-2. > At which point you will have reinvented Lightning. > > Otherwise, you are simply trusting that the wallet is implemented > correctly, and in particular, that any creditor will not simply insert > code in your open-source software to sign invalid transactions. > > With a 1-of-1, any invalid-in-Sabu transaction can still be valid in > the Bitcoin blockchain layer, thus the scheme is simply insecure. > > Features are meaningless without this kind of basic trust-minimization security. > > Regards, > ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 16:58 ` raymo @ 2021-06-28 17:58 ` Alex Schoof 2021-06-28 19:07 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: Alex Schoof @ 2021-06-28 17:58 UTC (permalink / raw) To: Bitcoin Protocol Discussion, raymo [-- Attachment #1: Type: text/plain, Size: 5344 bytes --] Hey Raymo, Here’s a scenario: Alice has one UTXO. Suppose Alice sends Bob an MT and a GT over Sabu, and Bob gives whatever goods and services to Alice. Alice then goes and spends that UTXO to Charlie with a higher fee than the GT she sent to Bob. Charlie has no idea that Bob exists, because he gets a valid UTXO. Bob can try to publish the GT, but if Alice crafts the fees right, the TX to Charlie will be confirmed first. Alice now has goods from both Bob and Charlie, and has only paid one of them. She has is able to double spend because: (1) the gossip network you describe for sabu only protects people if everyone is on sabu and playing by the rules, it does not prevent spending outside of sabu; and (2) there is nothing encumbering the onchain UTXO and preventing it from being spent outside of a sabu payment. The reason people keep brining up Lightning is because Lightning solves this problem by having a channel-open involve locking funds in a 2-of-2 multisig, preventing them from being spent outside of lightning until the channel is torn down. If there is nothing stopping someone from spending onchain funds outside of the context of your system, then your system does not prevent double spends. Hope that explanation helps. Alex On Mon, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > What prevents the creditor from signing a transaction that is neither a > valid MT nor a GT? > Please stop comparing Sabu and Lightning. Otherwise, it won't let you > true understanding of Sabu. > In Sabu protocol, only the issuer (the UTXO owner) can sign the > transaction and decide how much money goes to whom. The engaged UTXO(s) > belonged to issuer and the creditor never put UTXO in transaction, thus > never can sign the transaction because he has no ownership on the used > UTXOs. > As I already wrote in paper, the issuer creates and signs a transaction > and delivers it to creditor(s). If a creditor intends to send all or > part of his money to another person (AKA spending his money), he will > ask for a new signed transaction from issuer, in which a part of his > credit will transfer to another creditor. > > The Sabu has nothing with Lightning. Sabu has a peer-to-peer network of > doc-watchers which maybe it was the cause you always compare it to > Lightning. > I am not presenting lightning neither condemning it. > I am presenting Sabu protocol. > Please let concentrate on how Sabu works or not works. > > > > On 2021-06-28 15:28, ZmnSCPxj wrote: > > Good morning Raymo, > > > >> Hi ZmnSCPxj, > >> > >> Why you get the signal “trust the Gazin wallet”? > >> Sabu is a protocol and the Gazin wallet will be an implementation of > >> that protocol. We will implement it in react-native language to support > >> both Android and iPhone. Of course it will be open source and GPL3. > >> Here is the repository and yet is empty :) > >> https://github.com/raymaot/Gazin > >> > >> I wonder why you do not look carefully into the proposal! IMHO the Sabu > >> will be far better than Lightning. > >> Can’t you see the fact that in Sabu you do not need open and close > >> channels ever? Can you imagine only this feature how dramatically > >> decrease the transactions cost and how increase the distribution of > >> nodes and improve privacy level? it makes every mobile wallet act like a > >> lightning network. > >> Did you note the fact that in Sabu protocol there is no routing? And the > >> only people knew about a transaction are issuer and creditor? No one > >> else won’t be aware of transactions and million transactions per second > >> can be sent and received and repeal dynamically without any footprint on > >> any DLT? > >> > >> The English is not my mother language and probably my paper is not a > >> smooth and easy to read paper, but these are not good excuse to not even > >> reading a technical paper carefully and before understanding it or at > >> least trying to understanding it start to complaining. > > > > > > What prevents the creditor from signing a transaction that is neither > > a valid MT nor a GT? > > > > Nothing. > > > > In Lightning, sure one side can sign a transaction that is not a valid > > commitment transaction, but good luck getting the other side to *also* > > sign the transaction; it will not. > > Thus, you need n-of-n. > > > > 1-of-1 is simply not secure, full stop, you need to redesign the whole > > thing to use *at least* 2-of-2. > > At which point you will have reinvented Lightning. > > > > Otherwise, you are simply trusting that the wallet is implemented > > correctly, and in particular, that any creditor will not simply insert > > code in your open-source software to sign invalid transactions. > > > > With a 1-of-1, any invalid-in-Sabu transaction can still be valid in > > the Bitcoin blockchain layer, thus the scheme is simply insecure. > > > > Features are meaningless without this kind of basic trust-minimization > security. > > > > Regards, > > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Alex Schoof [-- Attachment #2: Type: text/html, Size: 6757 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 17:58 ` Alex Schoof @ 2021-06-28 19:07 ` raymo 2021-06-29 21:42 ` ZmnSCPxj 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-06-28 19:07 UTC (permalink / raw) To: Alex Schoof; +Cc: Bitcoin Protocol Discussion Hey Alex, Your scenario works perfectly unless we put some restrictions on accepting transaction by creditor (in our case Bob). These are restrictions: Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as transaction input. Alice has to reserve 10,000 Sat as transaction fee (for MT transaction) regardless of transaction length or input/output amounts. Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the 6,000 remined fee must be paid by she and Bob in proportion to their outputs amounts) Alice can issue a transaction the has maximum 20,000 outputs for creditors (Bob and others). The rest (if exist) is change back to Alice address. The GT is formed based on MT. Bob considers a transaction couple (MT, GT) valid only if they respect these rules. Let’s put it in practice using some numbers (although you can find more detailed explanation in paper). The MT would be like that: Input: 40,000 Satoshi Outputs: Bob: 20,000 BTC-fee: 10,000 Change back to Alice: 10,000 Based on this MT the GT will be Input: 40,000 Satoshi Outputs: Bob: 20,000 – 20,000*70% = 6,000 BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change back) = 25,500 Change back to Alice: 10,000 – 10,000*15% = 8,500 Now if Alice wants to spend UTXO to Charlie with higher fee, she has to pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners to put his fraudulent transaction instead the GT in next block. Alice already got 20,000 Sat profit from Bob. Now she can earn another 14,999 Sat profit from Charlie because of same UTXO worth 40,000 Satoshi. Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods or services. Is she a winner? I am not sure! What do you think? By the way, we can tune the kI and kC coefficients to reduce this 34,999 to 30,000 or even less. In this case Alice rationally prefers to not cheat on Bob. The complementary protection would be the mentioned BIP for miners. That BIP not only solve all these .01% risks but also would be a huge improvement of adapting smart contracts (and consequently DeFi) on top of current Bitcoin with lowest cost, but it is another story for another day. Raymo On 2021-06-28 17:58, Alex Schoof wrote: > Hey Raymo, > > Here’s a scenario: > > Alice has one UTXO. > > Suppose Alice sends Bob an MT and a GT over Sabu, and Bob gives > whatever goods and services to Alice. > > Alice then goes and spends that UTXO to Charlie with a higher fee than > the GT she sent to Bob. Charlie has no idea that Bob exists, because > he gets a valid UTXO. Bob can try to publish the GT, but if Alice > crafts the fees right, the TX to Charlie will be confirmed first. > Alice now has goods from both Bob and Charlie, and has only paid one > of them. She has is able to double spend because: (1) the gossip > network you describe for sabu only protects people if everyone is on > sabu and playing by the rules, it does not prevent spending outside of > sabu; and (2) there is nothing encumbering the onchain UTXO and > preventing it from being spent outside of a sabu payment. > > The reason people keep brining up Lightning is because Lightning > solves this problem by having a channel-open involve locking funds in > a 2-of-2 multisig, preventing them from being spent outside of > lightning until the channel is torn down. > > If there is nothing stopping someone from spending onchain funds > outside of the context of your system, then your system does not > prevent double spends. > > Hope that explanation helps. > > Alex > > On Mon, Jun 28, 2021 at 1:36 PM raymo via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >>> What prevents the creditor from signing a transaction that is >> neither a valid MT nor a GT? >> Please stop comparing Sabu and Lightning. Otherwise, it won't let >> you >> true understanding of Sabu. >> In Sabu protocol, only the issuer (the UTXO owner) can sign the >> transaction and decide how much money goes to whom. The engaged >> UTXO(s) >> belonged to issuer and the creditor never put UTXO in transaction, >> thus >> never can sign the transaction because he has no ownership on the >> used >> UTXOs. >> As I already wrote in paper, the issuer creates and signs a >> transaction >> and delivers it to creditor(s). If a creditor intends to send all or >> part of his money to another person (AKA spending his money), he >> will >> ask for a new signed transaction from issuer, in which a part of his >> credit will transfer to another creditor. >> >> The Sabu has nothing with Lightning. Sabu has a peer-to-peer network >> of >> doc-watchers which maybe it was the cause you always compare it to >> Lightning. >> I am not presenting lightning neither condemning it. >> I am presenting Sabu protocol. >> Please let concentrate on how Sabu works or not works. >> >> On 2021-06-28 15:28, ZmnSCPxj wrote: >>> Good morning Raymo, >>> >>>> Hi ZmnSCPxj, >>>> >>>> Why you get the signal “trust the Gazin wallet”? >>>> Sabu is a protocol and the Gazin wallet will be an implementation >> of >>>> that protocol. We will implement it in react-native language to >> support >>>> both Android and iPhone. Of course it will be open source and >> GPL3. >>>> Here is the repository and yet is empty :) >>>> https://github.com/raymaot/Gazin >>>> >>>> I wonder why you do not look carefully into the proposal! IMHO >> the Sabu >>>> will be far better than Lightning. >>>> Can’t you see the fact that in Sabu you do not need open and >> close >>>> channels ever? Can you imagine only this feature how dramatically >>>> decrease the transactions cost and how increase the distribution >> of >>>> nodes and improve privacy level? it makes every mobile wallet act >> like a >>>> lightning network. >>>> Did you note the fact that in Sabu protocol there is no routing? >> And the >>>> only people knew about a transaction are issuer and creditor? No >> one >>>> else won’t be aware of transactions and million transactions >> per second >>>> can be sent and received and repeal dynamically without any >> footprint on >>>> any DLT? >>>> >>>> The English is not my mother language and probably my paper is >> not a >>>> smooth and easy to read paper, but these are not good excuse to >> not even >>>> reading a technical paper carefully and before understanding it >> or at >>>> least trying to understanding it start to complaining. >>> >>> >>> What prevents the creditor from signing a transaction that is >> neither >>> a valid MT nor a GT? >>> >>> Nothing. >>> >>> In Lightning, sure one side can sign a transaction that is not a >> valid >>> commitment transaction, but good luck getting the other side to >> *also* >>> sign the transaction; it will not. >>> Thus, you need n-of-n. >>> >>> 1-of-1 is simply not secure, full stop, you need to redesign the >> whole >>> thing to use *at least* 2-of-2. >>> At which point you will have reinvented Lightning. >>> >>> Otherwise, you are simply trusting that the wallet is implemented >>> correctly, and in particular, that any creditor will not simply >> insert >>> code in your open-source software to sign invalid transactions. >>> >>> With a 1-of-1, any invalid-in-Sabu transaction can still be valid >> in >>> the Bitcoin blockchain layer, thus the scheme is simply insecure. >>> >>> Features are meaningless without this kind of basic >> trust-minimization security. >>> >>> Regards, >>> ZmnSCPxj >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- > > Alex Schoof ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 19:07 ` raymo @ 2021-06-29 21:42 ` ZmnSCPxj 2021-06-30 12:21 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: ZmnSCPxj @ 2021-06-29 21:42 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion Good morning Raymo, > Hey Alex, > > Your scenario works perfectly unless we put some restrictions on > accepting transaction by creditor (in our case Bob). > These are restrictions: > Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as > transaction input. > Alice has to reserve 10,000 Sat as transaction fee (for MT transaction) > regardless of transaction length or input/output amounts. > Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the > 6,000 remined fee must be paid by she and Bob in proportion to their > outputs amounts) > Alice can issue a transaction the has maximum 20,000 outputs for > creditors (Bob and others). > The rest (if exist) is change back to Alice address. > The GT is formed based on MT. > Bob considers a transaction couple (MT, GT) valid only if they respect > these rules. > > Let’s put it in practice using some numbers (although you can find more > detailed explanation in paper). > > The MT would be like that: > Input: 40,000 Satoshi > Outputs: > Bob: 20,000 > BTC-fee: 10,000 > Change back to Alice: 10,000 > > Based on this MT the GT will be > Input: 40,000 Satoshi > Outputs: > Bob: 20,000 – 20,00070% = 6,000 > BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change > back) = 25,500 > Change back to Alice: 10,000 – 10,00015% = 8,500 > > Now if Alice wants to spend UTXO to Charlie with higher fee, she has to > pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners > to put his fraudulent transaction instead the GT in next block. > Alice already got 20,000 Sat profit from Bob. Now she can earn another > 14,999 Sat profit from Charlie because of same UTXO worth 40,000 > Satoshi. > Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods > or services. > Is she a winner? > I am not sure! > What do you think? You assume here that Alice the issuer only has a single UTXO and that it creates a single transaction spending that UTXO. It is helpful to remember that miners consider fee*rate*, but your security analysis is dependent on *fee* and not fee*rate*. Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs to 1000 different Bobs? Now, a GT has one input and two outputs. 1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on), 1000 inputs, and 2000 outputs. Now Alice the issuer, being the sole signer, can create a fraudulent transaction that spends all 1000 UTXOs and spends it to a single Carol output. This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output. Do you think Alice can get a better fee*rate* on that transaction while paying a lower aggregate *fee* than all the GTs combined? Remember, you based your security analysis on Alice being forced to pay a larger *fee*, but neglect that miners judge transactions based on fee*rate*, which is subtly different and not what you are relying on. I am sure that there exists some large enough number of UTXOs where a single aggregating fraudulent transaction will be far cheaper than the tons of little GTs your security analysis depends on. This is why we do not use 1-of-1 signers in safe offchain protocols. Not your keys, not your coins. -- In addition, your analysis is based on assuming that miners are perfect rational beings of perfect rationality, ***and*** are omniscient. In reality, miners possess bounded knowledge, i.e. they do not know everything. Even if Alice is in possession of only a single UTXO, Alice can still feed miners a transaction with lower feerate than the MT, then feed the rest of the network with a valid MT. Because transactions propagate through the network but this propagation is ***not*** instantaneous, it is possible for the MT to reach the miners later than the fraudulent transaction. In this window of time, a block may be mined that includes the fraudulent transaction, simply because the lucky miner never managed to hear of the correct MT. This attack is essentially costless to Alice, especially for big enough transactions where mining fees are a negligible part of the payment. This is why we do not use 1-of-1 signers in safe offchain protocols. Not your keys, not your coins. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-29 21:42 ` ZmnSCPxj @ 2021-06-30 12:21 ` raymo 0 siblings, 0 replies; 41+ messages in thread From: raymo @ 2021-06-30 12:21 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion Dear ZmnSCPxj Thanks for dedicating time to read carefully the Sabu proposal and many thanks for your accurate point. So, lets fix it. I didn’t suppose Alice has only one UTXO, instead I expect every issuer use hundreds or even millions UTXOs (for optimal benefit each worth exactly 40,000 Satoshi) in Sabu protocol in order to earn notable Sabu-transactions-fees daily. Your scenario is correct and Alice can send a batch transaction which has higher feeRate, but less fee amount comparing total fees of N number of GT transaction. It is true, the batch transaction will win the race and will go to next block instead of N small GT transactions. But Alice herself is not the winner, since she paid a huge transaction fee to miner, while in honest acting didn’t have to pay at all. Let’s show it by numbers. Imagine Alice convinced some people to pay her money and accept the MT and GT transactions in exchange. Alice issued N transactions and delivered to these guys. Till now Alice got money equal to N * Maximum debt per transaction, which is 20,000 N. A single GT length = length of Critical part of GT (named C) + length of Redundant part of GT (named R) Coefficient of Honesty benefits (called H) = C/R The bigger H means less Redundant part, means less benefit in batch transaction. The worst H would be 1 or less than 1. I can guess H in Bitcoin transaction is 4 or higher, but for now we take it 4. Probably you can help us and tell what H is exactly. The N GTs length = N * (C + R) One batch transaction length = (N * C) + R The GT feeRate = GTfee / (C + R) The batch transaction feeRate = batchFee / ((N * C) + R) We need to batch transaction feeRate be higher than each single GT feeRate (more or less the feeRate for all GTs are same). Thus batchFee / ((N * C) + R) must be bigger or at least equal to GTfee / (C + R) so, batchFee / ((N * C) + R) >= GTfee / (C + R) we already knew H = C/R then C = HR after simplifying batchFee >= (GTfee * ((N * H) + 1)) / (H + 1) So, this is the minimum fee that Alice has to pay for her batch transaction in order to compete with GTs feeRate. Let’s put the numbers From my previous example for @Alex Schoof, we already knew that the GTfee is 25,500 Satoshi H is 4 (please let me know what is more realistic number) I think N in max exploitation is 10,000. If Alice takes entire block space, she won’t be able to put more than 10,000 inputs in a single transaction in one block. So, batchFee must be higher than (25,500 * ((10,000 * 4) + 1)) / (4 + 1) batchFee must be higher than 2.04 Bitcoins. While if Alice was acting honestly, she had to pay zero BTC-transaction-fee, since the Sabu transactions are aimed to be circulated in Sabu network forever. But how much benefit Alice got? We already knew that Alice had fooled Some people by 10,000 transactions and got 10,000 transaction * 20,000 Max debt per transaction. She got 2 Bitcoins. After all, she lost 0.04 BTC. She definitely is a loser, unless she has conspiracy with miners which is another scenario and I already explained it. Note these facts: H is higher than 4. It is impossible to fit a batch transaction with 10,000 inputs and one output in one block. And after all we can simply hedge batch transaction benefits by fine tuning the “maximum allowed debt per transaction”. Finally, the complementary protection to cover 0.01% remind risk of issuer irrationality, would be the BIPxxx “for flagging/unflagging promised UTXOs” which is my suggestion. It will be good for Sabu. It will be good for adapting wide range of innovative smart contracts on top of current Bitcoin with no risk and cost. @James Hilliard If it implemented wisely, never won't affect on network stability. > your analysis is based on assuming that miners are perfect rational beings of perfect rationality, > ***and*** are omniscient. That’s not true! The proposal just assume miners are looking for more profit. The suggested BIPxxx “for flagging/unflagging promised UTXOs” (if community accept it) would prepare a knowledge about promised UTXOs for miner. > Even if Alice is in possession of only a single UTXO, Alice can still feed miners a transaction > with lower feerate than the MT, then feed the rest of the network with a valid MT. It is not important in what order Alice propagate which (MT, or whatever transaction) to Bitcoin network. The point is, before putting this transaction in next block, the creditor wallet will be aware of this renege and will send the GT to network. The rest is miner’s decision to put transaction with higher fee rate to next block. > This attack is essentially costless to Alice, > especially for big enough transactions where mining fees are a negligible part of the payment. No, in Sabu we have not big payments. Each big payment must be managed through N small transactions with each transaction max output less than 20,000 Satoshi. Regards Raymo On 2021-06-29 21:42, ZmnSCPxj wrote: > Good morning Raymo, > >> Hey Alex, >> >> Your scenario works perfectly unless we put some restrictions on >> accepting transaction by creditor (in our case Bob). >> These are restrictions: >> Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as >> transaction input. >> Alice has to reserve 10,000 Sat as transaction fee (for MT transaction) >> regardless of transaction length or input/output amounts. >> Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the >> 6,000 remined fee must be paid by she and Bob in proportion to their >> outputs amounts) >> Alice can issue a transaction the has maximum 20,000 outputs for >> creditors (Bob and others). >> The rest (if exist) is change back to Alice address. >> The GT is formed based on MT. >> Bob considers a transaction couple (MT, GT) valid only if they respect >> these rules. >> >> Let’s put it in practice using some numbers (although you can find more >> detailed explanation in paper). >> >> The MT would be like that: >> Input: 40,000 Satoshi >> Outputs: >> Bob: 20,000 >> BTC-fee: 10,000 >> Change back to Alice: 10,000 >> >> Based on this MT the GT will be >> Input: 40,000 Satoshi >> Outputs: >> Bob: 20,000 – 20,00070% = 6,000 >> BTC-fee: 10,000 + (14,000 of Bob’s output) + (1,500 of Alice’s change >> back) = 25,500 >> Change back to Alice: 10,000 – 10,00015% = 8,500 >> >> Now if Alice wants to spend UTXO to Charlie with higher fee, she has to >> pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners >> to put his fraudulent transaction instead the GT in next block. >> Alice already got 20,000 Sat profit from Bob. Now she can earn another >> 14,999 Sat profit from Charlie because of same UTXO worth 40,000 >> Satoshi. >> Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods >> or services. >> Is she a winner? >> I am not sure! >> What do you think? > > You assume here that Alice the issuer only has a single UTXO and that > it creates a single transaction spending that UTXO. > > It is helpful to remember that miners consider fee*rate*, but your > security analysis is dependent on *fee* and not fee*rate*. > > Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs > to 1000 different Bobs? > > Now, a GT has one input and two outputs. > > 1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on), > 1000 inputs, and 2000 outputs. > > Now Alice the issuer, being the sole signer, can create a fraudulent > transaction that spends all 1000 UTXOs and spends it to a single Carol > output. > > This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output. > > Do you think Alice can get a better fee*rate* on that transaction > while paying a lower aggregate *fee* than all the GTs combined? > Remember, you based your security analysis on Alice being forced to > pay a larger *fee*, but neglect that miners judge transactions based > on fee*rate*, which is subtly different and not what you are relying > on. > I am sure that there exists some large enough number of UTXOs where a > single aggregating fraudulent transaction will be far cheaper than the > tons of little GTs your security analysis depends on. > > This is why we do not use 1-of-1 signers in safe offchain protocols. > Not your keys, not your coins. > > -- > > In addition, your analysis is based on assuming that miners are > perfect rational beings of perfect rationality, ***and*** are > omniscient. > > In reality, miners possess bounded knowledge, i.e. they do not know everything. > > Even if Alice is in possession of only a single UTXO, Alice can still > feed miners a transaction with lower feerate than the MT, then feed > the rest of the network with a valid MT. > Because transactions propagate through the network but this > propagation is ***not*** instantaneous, it is possible for the MT to > reach the miners later than the fraudulent transaction. > In this window of time, a block may be mined that includes the > fraudulent transaction, simply because the lucky miner never managed > to hear of the correct MT. > > This attack is essentially costless to Alice, especially for big > enough transactions where mining fees are a negligible part of the > payment. > > This is why we do not use 1-of-1 signers in safe offchain protocols. > Not your keys, not your coins. > > Regards, > ZmnSCPxj ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 15:28 ` ZmnSCPxj 2021-06-28 16:58 ` raymo @ 2021-06-28 17:29 ` Tao Effect 2021-06-28 17:38 ` raymo 1 sibling, 1 reply; 41+ messages in thread From: Tao Effect @ 2021-06-28 17:29 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 535 bytes --] Hi ZmnSCPxj & Raymo, > On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Good morning Raymo, > >> Hi ZmnSCPxj, >> […] > What prevents the creditor from signing a transaction that is neither a valid MT nor a GT? > > Nothing. How would the creditor create such a transaction? They need the issuer’s private key, so they can’t create it? Am I misunderstanding the scenario you’re describing? If so could you give a more detailed description? Cheers, Greg [-- Attachment #2: Type: text/html, Size: 1274 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 17:29 ` Tao Effect @ 2021-06-28 17:38 ` raymo 2021-06-28 18:05 ` Ricardo Filipe 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-06-28 17:38 UTC (permalink / raw) To: Tao Effect; +Cc: Bitcoin Protocol Discussion Hi Greg, You are right, the whole scenario is: there is an issuer which own a UTXO issuers get fiat money or goods or services from creditor in exchange of a transaction. the transactions are intended to circulate in Sabu protocol instead of sending to Bitcoin network. creditor can not sign the transaction at all. instead he can ask issuer to change the balances (transaction outputs) and transfer some of his money to other creditor... here is complete paper to read it carefully: https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180 Cheers Raymo On 2021-06-28 17:29, Tao Effect wrote: > Hi ZmnSCPxj & Raymo, > >> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev >> <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> Good morning Raymo, >> >>> Hi ZmnSCPxj, >> >>> […] >> What prevents the creditor from signing a transaction that is >> neither a valid MT nor a GT? >> >> Nothing. > > How would the creditor create such a transaction? They need the > issuer’s private key, so they can’t create it? Am I > misunderstanding the scenario you’re describing? If so could you > give a more detailed description? > > Cheers, > Greg ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-28 17:38 ` raymo @ 2021-06-28 18:05 ` Ricardo Filipe 0 siblings, 0 replies; 41+ messages in thread From: Ricardo Filipe @ 2021-06-28 18:05 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion I believe Zman meant issuer. raymo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> escreveu no dia segunda, 28/06/2021 à(s) 18:45: > > Hi Greg, > You are right, the whole scenario is: > there is an issuer which own a UTXO > issuers get fiat money or goods or services from creditor in exchange of > a transaction. > the transactions are intended to circulate in Sabu protocol instead of > sending to Bitcoin network. > creditor can not sign the transaction at all. instead he can ask issuer > to change the balances (transaction outputs) and transfer some of his > money to other creditor... > here is complete paper to read it carefully: > https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180 > > Cheers > Raymo > > > On 2021-06-28 17:29, Tao Effect wrote: > > Hi ZmnSCPxj & Raymo, > > > >> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev > >> <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> > >> Good morning Raymo, > >> > >>> Hi ZmnSCPxj, > >> > >>> […] > >> What prevents the creditor from signing a transaction that is > >> neither a valid MT nor a GT? > >> > >> Nothing. > > > > How would the creditor create such a transaction? They need the > > issuer’s private key, so they can’t create it? Am I > > misunderstanding the scenario you’re describing? If so could you > > give a more detailed description? > > > > Cheers, > > Greg > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo ` (2 preceding siblings ...) 2021-06-20 0:53 ` ZmnSCPxj @ 2021-06-20 1:59 ` James Hilliard 2021-06-22 18:20 ` Billy Tetrud 3 siblings, 1 reply; 41+ messages in thread From: James Hilliard @ 2021-06-20 1:59 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-20 1:59 ` James Hilliard @ 2021-06-22 18:20 ` Billy Tetrud 2021-07-01 20:11 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: Billy Tetrud @ 2021-06-22 18:20 UTC (permalink / raw) To: James Hilliard, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5183 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 6494 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-06-22 18:20 ` Billy Tetrud @ 2021-07-01 20:11 ` raymo 2021-07-01 20:49 ` Erik Aronesty 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-07-01 20:11 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-01 20:11 ` raymo @ 2021-07-01 20:49 ` Erik Aronesty 2021-07-01 22:15 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: Erik Aronesty @ 2021-07-01 20:49 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion; +Cc: Billy Tetrud 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-01 20:49 ` Erik Aronesty @ 2021-07-01 22:15 ` raymo 2021-07-02 17:57 ` Billy Tetrud 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-07-01 22:15 UTC (permalink / raw) To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion, Billy Tetrud 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@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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-01 22:15 ` raymo @ 2021-07-02 17:57 ` Billy Tetrud 2021-07-03 8:02 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: Billy Tetrud @ 2021-07-02 17:57 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 22010 bytes --] Thanks for the details Raymo. A thought occurred to me. Given the fact that miners can abuse this system without penalty, it would be useful to be able to fix this. What if it was possible for the creditor to claw back the funds even if the cheating transaction was mined instead of the guarantee transaction? Let's say there was a way to sign a transaction that gives the receiver of that transaction the ability to override any other transaction that uses the UTXO? If this were possible, the issuer could give the creditor this kind of transaction as the guarantee transaction, and in the case a cheat was done, the creditor could still use the GT to reallocate that UTXO to themselves. Now there are issues with this. First of all, it could give anyone the ability to double spend. So it would be prudent to limit this in some way. The revocation probably should only be valid for up to 6 blocks, such that if the transaction has 6 confirmations, it can no longer be reallocated (thus preserving the 6 block finality rule). It could also be required that the UTXO be marked as opting into this behavior (so receivers would know about the possibility it could get revoked). This second requirement would require Sabu issuers to make an on-chain transaction to set themselves up as an issuer. Another issue is that this would make it possible for transactions to expire. Any claw-back transaction would expire 6 blocks after the initial transaction happened. This has been generally avoided in bitcoin, but I think the relevant issues are solvable. You can find additional discussion of that in this thread <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html> . I would imagine this kind of ability would be pretty controversial, but since it can close out the possibility for miners to escape punishment, it could make this protocol viable. On Thu, Jul 1, 2021 at 3:15 PM <raymo@riseup•net> wrote: > > Hi Erik > > Please correct me if I misunderstood. > > > email is fully compromised. > > What I got is: > Email is not good because the sender and receiver are compromised. > Email is not good because the message content is revealed. > I can claim same argue about any other client/server model. Since the > server (website) service provider will ask some sort of KYC. And even if > the server uses end-to-end encryption, the provider company still can > read the packets content. > In my model the passive listener only can discover who is communicate to > whom and make a graph of connections. Although it is a threat for > privacy but the server/client model has this flaw inherently, since > provider already knew everything about everyone. In my model at least > users can make some fake connections and send some fake emails in order > to inject noise to communications. > Please note the fact that entire communication between mobile wallets > (via emails) are asymmetric PGP encrypted. The PGP keys are controlled > by end users unlike ALL pretending secure messengers (e.g whatsApp, > signal, zoom,…). > 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@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 > [-- Attachment #2: Type: text/html, Size: 26634 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-02 17:57 ` Billy Tetrud @ 2021-07-03 8:02 ` raymo 2021-07-07 3:20 ` Billy Tetrud 0 siblings, 1 reply; 41+ messages in thread From: raymo @ 2021-07-03 8:02 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion 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@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@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 > > > Links: > ------ > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-03 8:02 ` raymo @ 2021-07-07 3:20 ` Billy Tetrud 2021-07-17 15:50 ` raymo 0 siblings, 1 reply; 41+ messages in thread From: Billy Tetrud @ 2021-07-07 3:20 UTC (permalink / raw) To: raymo; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 39831 bytes --] > 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 miner or 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@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@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@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 > > > > > > Links: > > ------ > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html > [-- Attachment #2: Type: text/html, Size: 49635 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-07 3:20 ` Billy Tetrud @ 2021-07-17 15:50 ` raymo 2021-07-17 18:54 ` Tao Effect 2021-08-08 9:11 ` raymo 0 siblings, 2 replies; 41+ messages in thread From: raymo @ 2021-07-17 15:50 UTC (permalink / raw) To: Billy Tetrud; +Cc: Bitcoin Protocol Discussion 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@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@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@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 >>> >>> >>> Links: >>> ------ >>> [1] >> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019050.html ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-17 15:50 ` raymo @ 2021-07-17 18:54 ` Tao Effect 2021-08-08 9:11 ` raymo 1 sibling, 0 replies; 41+ messages in thread From: Tao Effect @ 2021-07-17 18:54 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion; +Cc: Billy Tetrud Hi Raymo, I personally am excited about what you’re working on, and wish you the best of luck with it! Cheers, Greg > On Jul 17, 2021, at 8:50 AM, raymo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > 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. > [..] ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-07-17 15:50 ` raymo 2021-07-17 18:54 ` Tao Effect @ 2021-08-08 9:11 ` raymo 2021-08-09 0:03 ` s7r 1 sibling, 1 reply; 41+ messages in thread From: raymo @ 2021-08-08 9:11 UTC (permalink / raw) To: Bitcoin Protocol Discussion Fine tuning Sabu in order to minimize the protocol risks After representing Sabu protocol here (https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180) and answer some comments and critics here (https://raymo-49157.medium.com/scaling-bitcoin-by-sabu-protocol-risks-and-benefits-62157f8a664e), I dedicated some days to tuning the Sabu transaction criteria in order to reduce the risks either for issuers or creditors. After that fine tuning, most of risks were decreased dramatically. In this post I’ll represent these details. For whom may forget about how Sabu protocol work, the core points are repeated for concept recall. Why should we use Sabu protocol? The main goal of Sabu is “boosting Bitcoin C2C circulation” by distributing it between far more people. The protocol incentivizes the small Bitcoin owners (people who has a tenth of Bitcoin or less) to sell few Satoshi (4 or 5 dollar or so) in person with no KYC due to Bitcoin ethos and earn small transaction fees for each transaction. This movement will end up to 10x or more bigger Bitcoin users, which definitely improves Bitcoin’s community and its proper ecosystem. How Bitcoin transaction work? Owning Bitcoin, means having some UTXO (recorded in Bitcoin blockchain) under your control. That is, you can sign that UTXO to prove you are the legitimate owner of that money. Thus, if you want to spend your Bitcoins, you create a transaction by which sign your under-controlled UTXO(s) and represent your desire to transfer this ownership to the other person. This transaction is a document that issued by you and provides a legitimate order for this money transfer. In order to execute this money transfer, you need to broadcast your signed document to Bitcoin network aimed to record it in Bitcoin blockchain, otherwise, no money transfer has taken place. After recording this transaction in Bitcoin blockchain, the transfer is settled and "everyone" will be aware of the new owner(s) of that particular spent coins. How Sabu protocol work? You -as a UTXO owner- are an "issuer", and always can issue a document (AKA transaction) by which you represent your will to transfer some of your UTXOs to others. Thus, Sabu is a non-custodial protocol. As long as this debt document is not registered in the Bitcoin blockchain, it is nothing more than a liability, i.e., you owe some Bitcoins to someone else. That guy naming her/him "creditor" payed money to you or provided goods or services for you, in exchange of this debt-document. Thus s/he has a copy of this transaction in her/his wallet. The issuer or creditor always can send this transaction to Bitcoin blockchain network aimed to record this money transformation in Bitcoin blockchain, or keep this transaction in wallet. But due to the high transaction fee on the Bitcoin blockchain and the insignificance of the amount transferred (a few Dollars), they will not send the document to the Bitcoin network, instead prefers to use this document as a payment method and exchange these documents in Sabu protocol and in an off-chain manner. When the creditor wants to spend his money, his wallet will send a request to the issuer’s wallet and ask it to transfer the issuer’s liability to another creditor. The issuer prepares a new transaction in which issuer owes the new creditor(s), and delivers this new transaction to both old and new creditors. The issuers earn small Sabu-transaction-fee per each money transfer (one or two Sat per transaction). Millions of issuers and creditors are exchanging these documents (transactions) in a peer-to-peer network continually, with no central authority. There is no blockchain nor public ledger. After each dealing, the issuer cancels the old transaction and creates a new document, and updates the creditor balances. These documents will be in circulation between issuers and creditors in the Sabu network forever meanwhile less than one percent of these transactions will be recorded on the Bitcoin blockchain. Either issuers or creditors in order to use Sabu protocol need to install Sabu mobile wallet (called Gazin) and start to deal. That is all they need. No technical skill or extra cost needed. How Sabu prevents frauds? The main mechanism of the system against fraud is the un-profitability of fraud in terms of economic benefits. In other words, all of malicious activities will end up in losing money of attacker. In short, the Sabu anti-fraud system works like that. The issuer always creates and signs a transaction pair. The Main Transaction which represents the real amount of outputs. And the Guarantee Transaction which pays relatively higher Bitcoin-transaction-fee. This fee increment is obtained by cutting from the issuer and creditor outputs in Main Transaction. Check out this simple transaction to learn more about how the system works. Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So, she can spend it by create a transaction and sign it and broadcast it to Bitcoin network. Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000 Satoshi from Alice in exchange. Alice gets this 5$ and prepare a Main transaction that represents this liability of Alice to Bob. Main Transaction (20,000 Sat input): * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob has to pay 3,000 as BTC fee) * Alice (issuer): 6,000 Sat * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) This is a valid transaction and both Bob and/or Alice can send it to Bitcoin network, but none of them are interested in doing so. Because they will lose 5,000 Satoshi of their own money as Bitcoin transaction fee. Alongside this transaction Alice (the issuer) has to create the Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will not consider the deal completed. The Guarantee Transaction is another valid Bitcoin transaction. It is created based on Main Transaction and will cut a part of Bob and Alice money in favor of transaction fee. Guarantee Transaction (20,000 Sat input): * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from Bob) + 3,480 (from Al-ice) = 15,739 Sat The Guarantee Transaction applies when the issuer does not live up to its promise and intends to spend the promised UTXO(s) in a way other than that agreed upon. We already knew the fact that Sabu is not a custodial solution, neither a M of N signature schema. As a result, the UTXO owner always can spend the already promised UTXO(s) in Sabu protocol or out of Sabu on Bitcoin blockchain, Contrary to what was promised. When the Alice (issuer) breaks such a promise and sends the fraudulent transaction to the Bitcoin network, Bob's wallet realizes that she (issuer) is spending the promised UTXO(s) and it sends the Guarantee Transaction(s) to the network as a last resort. The miners will face two (or more) transactions which are spending same UTXO(s), but one of them is paying notably higher Bitcoin transaction fee, thus they chose the highest fee payer transaction, which is the Guarantee Transaction. The miner will put the Guarantee Transaction in next block and reject the rest double-spend transactions. Certainly, poor Bob cannot recoup all his Satoshis. But he can retrieve a portion of his money and forces Alice to lose some of her money as well. tit for tat! Because of this mechanism, the issuer will try to not cheat on creditor. By the way there are some attacks that have very small chance to succeed but the risk to reward ratio for these scenarios are too high to be considered as a real possible attack threat. I will review them a little later in this post. What are the advantages of Sabu over Lightning? There are four benefits to using Sabu. Cost: In Sabu unlike Lightning, the transaction parties do not need to open a channel and consequently they do not need to close it. Therefore, they do not need to pay Bitcoin transaction fees two times. The transaction parties will pay small Sabu-transaction-fee per each transaction to the issuer because of creating and signing new transaction. Every Sabu user can be an issuer (something like Lightning node) and earn Bitcoin because of issuing credit liability document (pretty much like banks). Ease of use: All a user needs to use protocol is install wallet -called Gazin- on mobile or desktop by one click. The user can be an issuer and issue transactions or be a creditor and buys Bitcoin or both simultaneously. Users can then transfer their money to each other in Sabu network. Every Sabu user can be a creditor and buy some Satoshi from issuer and spend it in small shopping. It seems that Bitcoiners can finally buy coffee with Bitcoin without worrying about transaction fee or system scalability or even recording transaction forever on Bitcoin blockchain. Privacy: Since the communication between nodes is PGP encrypted, and no transaction will go to record on Bitcoin blockchain, the Sabu protocol provides a strong privacy for transaction parties. Except sender and receiver, no one will know how much Bitcoin between who was transferred. Billions of micro transfers will be scattered between thousands of nodes without no central control point and no transaction history recording and absolutely no KYC. Scalability: Since the Sabu has no routing overhead and peers use the direct communication it will be more scalable than Lightning. New criteria: - Each transaction input must be 20,000 Satoshi or more. - Maximum liability in a single transaction would be 15,000 Satoshi. 14k for creditor whose credit is more than 1k, so he is eligible to have both MT & GT in his wallet, and 1k for the creditor without the right of having MT & GT due to his small amount of credit. - The maximum transaction fee (for Bitcoin blockchain) for Main Transaction is 5,000 Satoshi. For transaction with liability less than 4,000 Satoshi this fee would be less than 5,000 Satoshi relatively. - In Guarantee Transaction the issuer loses 1% to 68% of his output in favor of Bitcoin transaction fee depends to the liability amount. More liability more loss. - In Guarantee Transaction the creditor loses 100% to 78% of his output in favor of Bitcoin transaction fee in reverse of the credit amount. More credit less loss. - The transaction fee (for Bitcoin blockchain) for Guarantee Transaction would be transaction fee of Main Transaction plus 100% to 78% of creditor’s output plus 1% to 68% of issuer’s output. - The issuer has to issue both Main Transaction and Guarantee transaction and deliver them to creditor. Both issuer and creditor (sender and receiver) control these criteria before confirm the deal. Fraudulent activities risk: The griefers, - people who willing to spend time and money hurting someone else, even if they don't make a profit from it (other than schadenfreude). - still can hurt himself and the other party simultaneously, but the damage amount is reduced dramatically. The lowest amount that a griefer as a creditor can lose is 1,000 Satoshi to hurt the issuer 685 Satoshi (loss ratio 1.45), and the highest amount is losing 11,506 Satoshi to hurt issuer 4,720 Satoshi (loss ratio 2.43). In any case, a griefer still has trouble finding big number of victims, since the protocol is not centralized and the user’s information is scattered among thousands of different nodes. How can prevent the issuer from spending UTXO in a cheating way? There are two possible scenarios for fraudulent issuer. First is paying high Bitcoin transaction fee, even higher than Guarantee Transaction fee, with the intention of placing the transaction desired by the issuer in the next block. Even Guarantee Transaction will cause the issuer to waive part of his output in favor of Bitcoin transaction fee. Its loss is between 685 to 5,190 Satoshi. Therefore, carrying out this attack will not be economically viable. The second scenario is double spending the promised UTXO, hopping in a race condition, the cheating transaction win the Guarantee Transaction. The likelihood of success for this scenario is approximately 2 seconds / 10 minutes (0.3% chance). In other word, the issuer has 0.3% chance to win 10,000 Satoshi (15,000 Max liability in a transaction – 5,000 minimum transaction fee), and relatively he has 99.7% chance to lose 4,720 Satoshi. The risk to reward ratio is too high to consider this scenario as a practical attack at all. What if issuer is miner as well? What a wicked issuer can earn from a block full of fraudulent transactions or a real big batch transaction would be in maximum spending 10,000 promised UTXO as inputs. The issuer already got paid equal to 10,000 * 15,000 Satoshi from deceived creditors in fiat money or goods or services. He is a miner as well so the transaction fee is not the case, thus we can say all the 1.5 Bitcoin is the issuer/miner benefit. But a normal honest block usually makes same or more profit for its miner! So, what is the benefit of cheating creditors? The issuer/miner has to mine solely and take the risk of wasting energy for almost nothing advanced a normal honest participating in network! In other word, due to the small amount of inputs and outputs, spending these Satoshis on any type of Bitcoin transaction is not cost effective in most cases. What if creditor is miner as well? The wicked creditor in every case will lose part of his money, since he can only put Main transaction or Guarantee Transaction in next block. In first case he paid unnecessary Bitcoin transaction fee. In second case he paid even more unnecessary Bitcoin transaction fee. Conclusion: Till here, after tuning the transaction parameters and the criteria of a successful deal, seems most of the risks of Sabu protocol have been addressed. I intentionally didn’t talk about BIPxxx “mark/unmark promised UTXOs”, because the Sabu protocol will work enough good without touching current Bitcoin core protocol. In future, after implementing BIPxxx, the Sabu protocol can remove some limitations and improve its features and functionalities. What is the next step? The next step would be putting protocol in practice and developing a Minimum Viable Product (MVP). I am a developer and I think -for now- the best technology and stack to develop the protocol and the proper mobile wallet would be “react native”. The protocol and the software will be open source and under GPL v3.0. Let me know if you have alternate idea. At the moment I cannot work full-time on this project and I need some help, But I am gradually working on this project and looking forward to hear from Bitcoin real supporters. Regards Raymo <raymo@riseup•net> d89a49057b817be0 this post on medium.com https://raymo-49157.medium.com/fine-tuning-sabu-in-order-to-minimize-the-protocol-risks-95361dc5282b ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-08-08 9:11 ` raymo @ 2021-08-09 0:03 ` s7r 2021-08-09 16:22 ` raymo 2022-11-02 17:30 ` Erik Aronesty 0 siblings, 2 replies; 41+ messages in thread From: s7r @ 2021-08-09 0:03 UTC (permalink / raw) To: raymo, Bitcoin Protocol Discussion raymo via bitcoin-dev wrote: TL,DR: you were explained by ZmnSCPxj why this protocol will not work. The possibility for just one party to sign will not work. I will explain again why but in much more simpler description. > Check out this simple transaction to learn more about how the system > works. > Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So, > she can spend it by create a transaction and sign it and broadcast it to > Bitcoin network. > Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000 > Satoshi from Alice in exchange. > Alice gets this 5$ and prepare a Main transaction that represents this > liability of Alice to Bob. > > Main Transaction (20,000 Sat input): > * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob > has to pay 3,000 as BTC fee) > * Alice (issuer): 6,000 Sat > * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) > This is a valid transaction and both Bob and/or Alice can send it to > Bitcoin network, but none of them are interested in doing so. Because > they will lose 5,000 Satoshi of their own money as Bitcoin transaction > fee. > > Alongside this transaction Alice (the issuer) has to create the > Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will > not consider the deal completed. The Guarantee Transaction is another > valid Bitcoin transaction. It is created based on Main Transaction and > will cut a part of Bob and Alice money in favor of transaction fee. > > Guarantee Transaction (20,000 Sat input): > * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat > * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat > * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from > Bob) + 3,480 (from Al-ice) = 15,739 Sat > > The Guarantee Transaction applies when the issuer does not live up to > its promise and intends to spend the promised UTXO(s) in a way other > than that agreed upon. We already knew the fact that Sabu is not a > custodial solution, neither a M of N signature schema. As a result, the > UTXO owner always can spend the already promised UTXO(s) in Sabu > protocol or out of Sabu on Bitcoin blockchain, Contrary to what was > promised. > When the Alice (issuer) breaks such a promise and sends the fraudulent > transaction to the Bitcoin network, Bob's wallet realizes that she > (issuer) is spending the promised UTXO(s) and it sends the Guarantee > Transaction(s) to the network as a last resort. The miners will face two > (or more) transactions which are spending same UTXO(s), but one of them > is paying notably higher Bitcoin transaction fee, thus they chose the > highest fee payer transaction, which is the Guarantee Transaction. The > miner will put the Guarantee Transaction in next block and reject the > rest double-spend transactions. Certainly, poor Bob cannot recoup all > his Satoshis. But he can retrieve a portion of his money and forces > Alice to lose some of her money as well. tit for tat! > Because of this mechanism, the issuer will try to not cheat on creditor. > > By the way there are some attacks that have very small chance to succeed > but the risk to reward ratio for these scenarios are too high to be > considered as a real possible attack threat. I will review them a little > later in this post. > > You said that the guarantee transaction is created based on Main Transaction, how do you mean? If it is a child transaction of the Main Transaction it already doesn't work because Alice needs to broadcast the *Main Transaction* to the blockchain in order for the Guarantee transaction to be accepted, and of she does this, Bob doesn't care because the transaction pays to him already the correct agreed amount. If you did not mean this, still it won't work, because Simple: 1. Alice will create transaction #3, or call it Sabu-killing-transaction (20,000 Sat input): * Alice (issuer): 15,000 Sat * BTC Fee: 5,000 Sat PERIOD. When Bob tries to broadcast the "guarantee transaction" he will get an error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The much larger fee in the guarantee transaction will not matter. You have to assume a miner will violate the Bitcoin protocol and somehow drop Sabu-killing-transaction from mempool and consider the Guarantee transaction only. This is very unlikely to happen and you might also need connection direct with the miners because most full nodes will not even accept the Guarantee transaction to their mempools in order to further broadcast it until it reaches the miners. With the simple attack described above Alice's chance to fraud Bob are, from my point of view, 99%. (the only way to replace a transaction is Replace-By-Fee but this implies the transaction that IS TO BE REPLACED has a certain flag set, and it is optional). Given the Sabu-Killing-transaction comes first, Alice will of course create it without this flag set so even if you add to Sabu the requirement of RBF enabled to the Guarantee transaction it will not work, because it's the other way around. The second question is just for an observation that it has no real benefits over Lightning even if #1 wasn't true: 2. The creditor (Bob) has to leave his wallet running 24x7 and ensure he is connected to the internet, otherwise if he loses connection to the internet or energy supply, Alice attack will succeed entirely with 100% chances. So this means Bob needs to always be online like forever and ever. The 3rd one is hypothetical and you don't even have to answer it: 3. How does Bob (first creditor) spend the coins received / how does Bob become an issuer himself in relation to Dave (another creditor)? What happens if Alice tries to fraud Bob after Bob spent its Sabu credit to Dave? Dave has to hold all parent "guarantee transactions" and watch the network for any potential fraudulent transactions that cancels his credit? ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-08-09 0:03 ` s7r @ 2021-08-09 16:22 ` raymo [not found] ` <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com> 2022-11-02 17:30 ` Erik Aronesty 1 sibling, 1 reply; 41+ messages in thread From: raymo @ 2021-08-09 16:22 UTC (permalink / raw) To: s7r; +Cc: Bitcoin Protocol Discussion Hi s7r, I already answered to ZmnSCPxj's comments. Let’s go to yours. > If it is a child transaction of the Main Transaction Sorry for my shortcoming in English, because it caused the misunderstanding of proposal. There is not any relation between Main Transaction and Guarantee transaction. when I said “the Guarantee Transaction is created based on Main Transaction” I was intended only the numbers. I mean the output amounts of Guarantee Transaction are calculated relatively based on Main Transaction output amounts, in order to make a Guarantee Transaction with relatively higher transaction fee. So, either of MT or GT can be broadcasted or toke place in next block independently. > When Bob tries to broadcast the "guarantee transaction" he will get an error: > REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT Here is the part which I am not sure you are right about it. I do not know in detail and I'm not sure how miners will react to the two double-spend transactions and which one they will prefer. Will they use the first seen transaction for block pre-image, or will use the transaction with higher transaction fee? We need the help of Bitcoin core developers to clarify this transaction selection mechanism. If miners prefer the highest fee my scenario still is valid. But if miners always keep the first transaction received and drop subsequent transactions, I have three different solution to solve that I will explain in later posts. > 2. The creditor (Bob) has to leave his wallet running 24x7 and ensure he is connected > to the internet, otherwise if he loses connection to the internet or energy supply, > Alice attack will succeed entirely with 100% chances. > So this means Bob needs to always be online like forever and ever. Somehow you are right. Definitely Bob can delegate this task to a doc-watcher, pretty much like watch-tower in Lightning, but due to the small amount of creditor's credits and the fact that this amount is scattered among many different issuers, I removed this part from the original design of Sabu architecture. BTW major creditors, such as stores that receives debt-documents worth thousands of dollars a day, should (and better say must) always be online to protect their money. This job also creates a safe margin for other creditors. IMHO at the moment the protocol is good enough to start, but we can always talk about improving the protocol. > The 3rd one is hypothetical and you don't even have to answer it: > 3. How does Bob (first creditor) spend the coins received / > how does Bob become an issuer himself in relation to Dave (another creditor)? > What happens if Alice tries to fraud Bob after Bob spent its Sabu credit to Dave? > Dave has to hold all parent "guarantee transactions" and watch the network for > any potential fraudulent transactions that cancels his credit? I already explained it in response of Billy here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019271.html just look for “how normal transactions happen in their entirety.” Looking forward to hear from core developers about “how miners will react to the two double-spend transactions and which one they will prefer”. Regards Raymo On 2021-08-09 00:03, s7r wrote: > raymo via bitcoin-dev wrote: > > TL,DR: you were explained by ZmnSCPxj why this protocol will not work. > The possibility for just one party to sign will not work. I will > explain again why but in much more simpler description. > > >> Check out this simple transaction to learn more about how the system >> works. >> Consider Alice as an issuer. She owns a UTXO worth 20,000 Satoshi. So, >> she can spend it by create a transaction and sign it and broadcast it to >> Bitcoin network. >> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys 12,000 >> Satoshi from Alice in exchange. >> Alice gets this 5$ and prepare a Main transaction that represents this >> liability of Alice to Bob. >> >> Main Transaction (20,000 Sat input): >> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, but Bob >> has to pay 3,000 as BTC fee) >> * Alice (issuer): 6,000 Sat >> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) >> This is a valid transaction and both Bob and/or Alice can send it to >> Bitcoin network, but none of them are interested in doing so. Because >> they will lose 5,000 Satoshi of their own money as Bitcoin transaction >> fee. >> >> Alongside this transaction Alice (the issuer) has to create the >> Guarantee Transaction as well and deliver it to Bob. Otherwise, Bob will >> not consider the deal completed. The Guarantee Transaction is another >> valid Bitcoin transaction. It is created based on Main Transaction and >> will cut a part of Bob and Alice money in favor of transaction fee. >> >> Guarantee Transaction (20,000 Sat input): >> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = 1,740 Sat >> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 Sat >> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 (from >> Bob) + 3,480 (from Al-ice) = 15,739 Sat >> >> The Guarantee Transaction applies when the issuer does not live up to >> its promise and intends to spend the promised UTXO(s) in a way other >> than that agreed upon. We already knew the fact that Sabu is not a >> custodial solution, neither a M of N signature schema. As a result, the >> UTXO owner always can spend the already promised UTXO(s) in Sabu >> protocol or out of Sabu on Bitcoin blockchain, Contrary to what was >> promised. >> When the Alice (issuer) breaks such a promise and sends the fraudulent >> transaction to the Bitcoin network, Bob's wallet realizes that she >> (issuer) is spending the promised UTXO(s) and it sends the Guarantee >> Transaction(s) to the network as a last resort. The miners will face two >> (or more) transactions which are spending same UTXO(s), but one of them >> is paying notably higher Bitcoin transaction fee, thus they chose the >> highest fee payer transaction, which is the Guarantee Transaction. The >> miner will put the Guarantee Transaction in next block and reject the >> rest double-spend transactions. Certainly, poor Bob cannot recoup all >> his Satoshis. But he can retrieve a portion of his money and forces >> Alice to lose some of her money as well. tit for tat! >> Because of this mechanism, the issuer will try to not cheat on creditor. >> >> By the way there are some attacks that have very small chance to succeed >> but the risk to reward ratio for these scenarios are too high to be >> considered as a real possible attack threat. I will review them a little >> later in this post. >> >> > > You said that the guarantee transaction is created based on Main > Transaction, how do you mean? If it is a child transaction of the Main > Transaction it already doesn't work because Alice needs to broadcast > the *Main Transaction* to the blockchain in order for the Guarantee > transaction to be accepted, and of she does this, Bob doesn't care > because the transaction pays to him already the correct agreed amount. > If you did not mean this, still it won't work, because > > Simple: > 1. Alice will create transaction #3, or call it > Sabu-killing-transaction (20,000 Sat input): > * Alice (issuer): 15,000 Sat > * BTC Fee: 5,000 Sat > > PERIOD. > > When Bob tries to broadcast the "guarantee transaction" he will get an > error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The much > larger fee in the guarantee transaction will not matter. You have to > assume a miner will violate the Bitcoin protocol and somehow drop > Sabu-killing-transaction from mempool and consider the Guarantee > transaction only. This is very unlikely to happen and you might also > need connection direct with the miners because most full nodes will > not even accept the Guarantee transaction to their mempools in order > to further broadcast it until it reaches the miners. > > With the simple attack described above Alice's chance to fraud Bob > are, from my point of view, 99%. > > (the only way to replace a transaction is Replace-By-Fee but this > implies the transaction that IS TO BE REPLACED has a certain flag set, > and it is optional). > > Given the Sabu-Killing-transaction comes first, Alice will of course > create it without this flag set so even if you add to Sabu the > requirement of RBF enabled to the Guarantee transaction it will not > work, because it's the other way around. > > > The second question is just for an observation that it has no real > benefits over Lightning even if #1 wasn't true: > > 2. The creditor (Bob) has to leave his wallet running 24x7 and ensure > he is connected to the internet, otherwise if he loses connection to > the internet or energy supply, Alice attack will succeed entirely with > 100% chances. So this means Bob needs to always be online like forever > and ever. > > The 3rd one is hypothetical and you don't even have to answer it: > 3. How does Bob (first creditor) spend the coins received / how does > Bob become an issuer himself in relation to Dave (another creditor)? > What happens if Alice tries to fraud Bob after Bob spent its Sabu > credit to Dave? Dave has to hold all parent "guarantee transactions" > and watch the network for any potential fraudulent transactions that > cancels his credit? ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>]
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy [not found] ` <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com> @ 2021-08-09 20:22 ` raymo 0 siblings, 0 replies; 41+ messages in thread From: raymo @ 2021-08-09 20:22 UTC (permalink / raw) To: Chris Riley; +Cc: bitcoin-dev Hi Chris, Thanks for your detailed answer. So, as you answered there is an uncertainty about this case. For me, even this uncertainty would be a good point to start. Because if the miners realize the potentiality for increasing revenue under Sabu protocol, very soon they will want to update their transaction selecting mechanism priorities, even before occurring the first real attack on the protocol in “production software”. This upgrade in Bitcoin protocol will eliminate uncertainty totally. How hard do you think it will be this upgrade on protocol? IMO the most important thing will be the consensus on the implementation of these changes, while the code upgrading won't be a difficult technical issue. If it were difficult to agree on a Bitcoin core protocol change, we might be able to achieve our goals by changing the Stratum protocol. Unlike miners who would welcome that offer, full-nodes without hash power would probably not be interested in upgrading the software. Maybe because they do not want to disrupt the broadcasting of transactions by relying double-spend transactions. I'm not sure if the normal full nodes (without hash power) use the same software that miners use. If not, we have to fight on two fronts to upgrade the software. Again, thanks for your fast and flourish reply :-) Raymo On 2021-08-09 18:03, Chris Riley wrote: >> I'm not sure how miners will react to the two double-spend > transactions and which one they will prefer. >> Will they use the first seen transaction for block pre-image, or will > use the transaction with higher transaction fee? >> We need the help of Bitcoin core developers to clarify this > transaction selection mechanism. If miners >> prefer the highest fee my scenario still is valid. But if miners > always keep the first transaction received >> and drop subsequent transactions, > Hi, > > Miners have the incentive to accept the highest fee transaction > whenever they see it. That does not imply that miners _will_ accept > the highest fee transaction they see for a variety of reasons. If a > transaction does not signal RBF (BIP 125) then in general a "first > seen" rule is applied, if a transaction does signal RBF, then in > general the highest fee is prefered. Since this is an untrusted > network, a miner could use RBF even for transactions that don't signal > it, since she could claim she saw it first, assuming the miner was > aware of it which might imply it was submitted directly since the > network might not relay a higher fee transaction for a non-RBF > transaction. Or a miner could see the first transaction and include > it in a block just after the RBF transaction is broadcast but before > the block is propagated. etc > > So there is only a question of probabilities: in general miners > prefer the highest fee for RBF transactions and in general, miners > will not replace a non-RBF transaction with a later one. However, > nothing is guaranteed given it is an untrusted network and people > could use non-standard rules for selection of what transactions are > included in a block. > > :-) > > On Mon, Aug 9, 2021 at 12:57 PM raymo via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Hi s7r, >> I already answered to ZmnSCPxj's comments. >> >> Let’s go to yours. >> >>> If it is a child transaction of the Main Transaction >> Sorry for my shortcoming in English, because it caused the >> misunderstanding of proposal. >> There is not any relation between Main Transaction and Guarantee >> transaction. when I said “the Guarantee Transaction is created >> based on >> Main Transaction” I was intended only the numbers. I mean the >> output >> amounts of Guarantee Transaction are calculated relatively based on >> Main >> Transaction output amounts, in order to make a Guarantee Transaction >> with relatively higher transaction fee. So, either of MT or GT can >> be >> broadcasted or toke place in next block independently. >> >>> When Bob tries to broadcast the "guarantee transaction" he will >> get an error: >>> REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT >> Here is the part which I am not sure you are right about it. I do >> not >> know in detail and I'm not sure how miners will react to the two >> double-spend transactions and which one they will prefer. >> Will they use the first seen transaction for block pre-image, or >> will >> use the transaction with higher transaction fee? >> We need the help of Bitcoin core developers to clarify this >> transaction >> selection mechanism. >> If miners prefer the highest fee my scenario still is valid. But if >> miners always keep the first transaction received and drop >> subsequent >> transactions, I have three different solution to solve that I will >> explain in later posts. >> >>> 2. The creditor (Bob) has to leave his wallet running 24x7 and >> ensure he is connected >>> to the internet, otherwise if he loses connection to the internet >> or energy supply, >>> Alice attack will succeed entirely with 100% chances. >>> So this means Bob needs to always be online like forever and ever. >> Somehow you are right. Definitely Bob can delegate this task to a >> doc-watcher, pretty much like watch-tower in Lightning, but due to >> the >> small amount of creditor's credits and the fact that this amount is >> scattered among many different issuers, I removed this part from the >> original design of Sabu architecture. >> BTW major creditors, such as stores that receives debt-documents >> worth >> thousands of dollars a day, should (and better say must) always be >> online to protect their money. This job also creates a safe margin >> for >> other creditors. >> IMHO at the moment the protocol is good enough to start, but we can >> always talk about improving the protocol. >> >>> The 3rd one is hypothetical and you don't even have to answer it: >>> 3. How does Bob (first creditor) spend the coins received / >>> how does Bob become an issuer himself in relation to Dave (another >> creditor)? >>> What happens if Alice tries to fraud Bob after Bob spent its Sabu >> credit to Dave? >>> Dave has to hold all parent "guarantee transactions" and watch the >> network for >>> any potential fraudulent transactions that cancels his credit? >> I already explained it in response of Billy here >> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019271.html >> >> just look for “how normal transactions happen in their >> entirety.” >> >> Looking forward to hear from core developers about “how miners >> will >> react to the two double-spend transactions and which one they will >> prefer”. >> >> Regards >> Raymo >> >> On 2021-08-09 00:03, s7r wrote: >>> raymo via bitcoin-dev wrote: >>> >>> TL,DR: you were explained by ZmnSCPxj why this protocol will not >> work. >>> The possibility for just one party to sign will not work. I will >>> explain again why but in much more simpler description. >>> >>> >>>> Check out this simple transaction to learn more about how the >> system >>>> works. >>>> Consider Alice as an issuer. She owns a UTXO worth 20,000 >> Satoshi. So, >>>> she can spend it by create a transaction and sign it and >> broadcast it to >>>> Bitcoin network. >>>> Suppose Bob (as a creditor) pays Alice 5 dollars cash, and buys >> 12,000 >>>> Satoshi from Alice in exchange. >>>> Alice gets this 5$ and prepare a Main transaction that represents >> this >>>> liability of Alice to Bob. >>>> >>>> Main Transaction (20,000 Sat input): >>>> * Bob (creditor): 9,000 Sat (the real credit of Bob is 12,000, >> but Bob >>>> has to pay 3,000 as BTC fee) >>>> * Alice (issuer): 6,000 Sat >>>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) >>>> This is a valid transaction and both Bob and/or Alice can send it >> to >>>> Bitcoin network, but none of them are interested in doing so. >> Because >>>> they will lose 5,000 Satoshi of their own money as Bitcoin >> transaction >>>> fee. >>>> >>>> Alongside this transaction Alice (the issuer) has to create the >>>> Guarantee Transaction as well and deliver it to Bob. Otherwise, >> Bob will >>>> not consider the deal completed. The Guarantee Transaction is >> another >>>> valid Bitcoin transaction. It is created based on Main >> Transaction and >>>> will cut a part of Bob and Alice money in favor of transaction >> fee. >>>> >>>> Guarantee Transaction (20,000 Sat input): >>>> * Bob (creditor): 9,000 – 80.77%*9,000 = 9,000 – 7,260 = >> 1,740 Sat >>>> * Alice (issuer): 6,000 – 58%*6,000 = 6,000 – 3,480 = 2,520 >> Sat >>>> * BTC Fee: 5,000 Sat (2,000 from Alice + 3,000 from Bob) + 7,260 >> (from >>>> Bob) + 3,480 (from Al-ice) = 15,739 Sat >>>> >>>> The Guarantee Transaction applies when the issuer does not live >> up to >>>> its promise and intends to spend the promised UTXO(s) in a way >> other >>>> than that agreed upon. We already knew the fact that Sabu is not >> a >>>> custodial solution, neither a M of N signature schema. As a >> result, the >>>> UTXO owner always can spend the already promised UTXO(s) in Sabu >>>> protocol or out of Sabu on Bitcoin blockchain, Contrary to what >> was >>>> promised. >>>> When the Alice (issuer) breaks such a promise and sends the >> fraudulent >>>> transaction to the Bitcoin network, Bob's wallet realizes that >> she >>>> (issuer) is spending the promised UTXO(s) and it sends the >> Guarantee >>>> Transaction(s) to the network as a last resort. The miners will >> face two >>>> (or more) transactions which are spending same UTXO(s), but one >> of them >>>> is paying notably higher Bitcoin transaction fee, thus they chose >> the >>>> highest fee payer transaction, which is the Guarantee >> Transaction. The >>>> miner will put the Guarantee Transaction in next block and reject >> the >>>> rest double-spend transactions. Certainly, poor Bob cannot recoup >> all >>>> his Satoshis. But he can retrieve a portion of his money and >> forces >>>> Alice to lose some of her money as well. tit for tat! >>>> Because of this mechanism, the issuer will try to not cheat on >> creditor. >>>> >>>> By the way there are some attacks that have very small chance to >> succeed >>>> but the risk to reward ratio for these scenarios are too high to >> be >>>> considered as a real possible attack threat. I will review them a >> little >>>> later in this post. >>>> >>>> >>> >>> You said that the guarantee transaction is created based on Main >>> Transaction, how do you mean? If it is a child transaction of the >> Main >>> Transaction it already doesn't work because Alice needs to >> broadcast >>> the *Main Transaction* to the blockchain in order for the >> Guarantee >>> transaction to be accepted, and of she does this, Bob doesn't care >>> because the transaction pays to him already the correct agreed >> amount. >>> If you did not mean this, still it won't work, because >>> >>> Simple: >>> 1. Alice will create transaction #3, or call it >>> Sabu-killing-transaction (20,000 Sat input): >>> * Alice (issuer): 15,000 Sat >>> * BTC Fee: 5,000 Sat >>> >>> PERIOD. >>> >>> When Bob tries to broadcast the "guarantee transaction" he will >> get an >>> error: REJECTED FROM MEMPOOL, INPUTS (UTXO) ALREADY SPENT. The >> much >>> larger fee in the guarantee transaction will not matter. You have >> to >>> assume a miner will violate the Bitcoin protocol and somehow drop >>> Sabu-killing-transaction from mempool and consider the Guarantee >>> transaction only. This is very unlikely to happen and you might >> also >>> need connection direct with the miners because most full nodes >> will >>> not even accept the Guarantee transaction to their mempools in >> order >>> to further broadcast it until it reaches the miners. >>> >>> With the simple attack described above Alice's chance to fraud Bob >>> are, from my point of view, 99%. >>> >>> (the only way to replace a transaction is Replace-By-Fee but this >>> implies the transaction that IS TO BE REPLACED has a certain flag >> set, >>> and it is optional). >>> >>> Given the Sabu-Killing-transaction comes first, Alice will of >> course >>> create it without this flag set so even if you add to Sabu the >>> requirement of RBF enabled to the Guarantee transaction it will >> not >>> work, because it's the other way around. >>> >>> >>> The second question is just for an observation that it has no real >>> benefits over Lightning even if #1 wasn't true: >>> >>> 2. The creditor (Bob) has to leave his wallet running 24x7 and >> ensure >>> he is connected to the internet, otherwise if he loses connection >> to >>> the internet or energy supply, Alice attack will succeed entirely >> with >>> 100% chances. So this means Bob needs to always be online like >> forever >>> and ever. >>> >>> The 3rd one is hypothetical and you don't even have to answer it: >>> 3. How does Bob (first creditor) spend the coins received / how >> does >>> Bob become an issuer himself in relation to Dave (another >> creditor)? >>> What happens if Alice tries to fraud Bob after Bob spent its Sabu >>> credit to Dave? Dave has to hold all parent "guarantee >> transactions" >>> and watch the network for any potential fraudulent transactions >> that >>> cancels his credit? >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy 2021-08-09 0:03 ` s7r 2021-08-09 16:22 ` raymo @ 2022-11-02 17:30 ` Erik Aronesty 1 sibling, 0 replies; 41+ messages in thread From: Erik Aronesty @ 2022-11-02 17:30 UTC (permalink / raw) To: s7r, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 566 bytes --] > > (the only way to replace a transaction is Replace-By-Fee but this > implies the transaction that IS TO BE REPLACED has a certain flag set, > and it is optional). > 1. full rbf is becoming standard. tx without full rbf can just be rejected as a part of the sabu protocol 2. that's fine. watchtowers can be used to fix this that only have the ability to stop attacks in progress. guarantee transactions can include a small watchtower fee for your favorite always-on watchtower service 3. all parties need to maintain sabu state (it's just another mempool) [-- Attachment #2: Type: text/html, Size: 849 bytes --] ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2022-11-02 17:30 UTC | newest]
Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-16 13:44 [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy raymo
2021-06-18 1:42 ` Erik Aronesty
2021-06-18 13:44 ` Alex Schoof
2021-06-18 20:00 ` raymo
2021-06-19 21:14 ` Erik Aronesty
2021-06-18 13:37 ` Erik Aronesty
2021-06-18 20:22 ` raymo
2021-06-20 0:53 ` ZmnSCPxj
2021-06-26 21:54 ` raymo
2021-06-27 4:53 ` ZmnSCPxj
2021-06-27 11:05 ` raymo
2021-06-28 5:20 ` ZmnSCPxj
2021-06-28 6:29 ` raymo
2021-06-28 8:23 ` James Hilliard
2021-06-28 9:52 ` raymo
2021-06-28 11:28 ` James Hilliard
2021-06-28 16:33 ` raymo
2021-06-28 15:28 ` ZmnSCPxj
2021-06-28 16:58 ` raymo
2021-06-28 17:58 ` Alex Schoof
2021-06-28 19:07 ` raymo
2021-06-29 21:42 ` ZmnSCPxj
2021-06-30 12:21 ` raymo
2021-06-28 17:29 ` Tao Effect
2021-06-28 17:38 ` raymo
2021-06-28 18:05 ` Ricardo Filipe
2021-06-20 1:59 ` James Hilliard
2021-06-22 18:20 ` Billy Tetrud
2021-07-01 20:11 ` raymo
2021-07-01 20:49 ` Erik Aronesty
2021-07-01 22:15 ` raymo
2021-07-02 17:57 ` Billy Tetrud
2021-07-03 8:02 ` raymo
2021-07-07 3:20 ` Billy Tetrud
2021-07-17 15:50 ` raymo
2021-07-17 18:54 ` Tao Effect
2021-08-08 9:11 ` raymo
2021-08-09 0:03 ` s7r
2021-08-09 16:22 ` raymo
[not found] ` <CAL5BAw2f=xJBO743sTb-Cms80ZLsNNbGPAsWsR_Z3JDF51ssoQ@mail.gmail.com>
2021-08-09 20:22 ` raymo
2022-11-02 17:30 ` Erik Aronesty
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox