Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 > 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 dro
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 Ali
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 / a
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
ontrolled >> 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 wo
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
fy 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 > 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 trans
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
sensus >> 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 >> 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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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, >>
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 > 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 pre
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 >> 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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
> 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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 >> > 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 w
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 > 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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 > 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 >> 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 > 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] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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
