Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 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
Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy
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 ___ 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
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 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
Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages
On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote: > 2) Solving the Pre-Signed Feerate problem : Package-Relay or > SIGHASH_ANYPREVOUT > > For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to > solve the pre-signed feerate issue [3] > > [...] > > [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT > solves pinnings beyond those LN meetings logs: > https://gnusha.org/lightning-dev/2020-06-08.log For anyone else looking, the most relevant line seems to be: 13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here - assuming a lot of complicated logic in core to do so, you could imagine blind-cpfp-bumping *any* commitment tx without knowing its there or which one it is all with one tx...in theory) That might work for current LN-penalty, but I'm not sure it works for eltoo. If Bitcoin Core can rewrite the blind CPFP fee bump transaction to refer to any prevout, that implies anyone else can do the same. Miners who were aware of two or more states from an eltoo channel would be incentivized to rewrite to the oldest state, giving them fee revenue now and ensuring fee revenue in the future when a later state update is broadcast. If the attacker using pinning is able to reuse their attack at no cost, they can re-pin the channel again and force the honest user to pay another anyprevout bounty to miners. Repeat this a bunch of times and the honest user has now spent more on fees than their balance from the closed channel. Even if my analysis above is wrong, I would encourage you or Matt or someone to write up this anyprevout idea in more detail and distribute it before you promote it much more. > package-relay sounds a reasonable, temporary "patch". Even if every protocol based on presigned transactions can magically allow dynamically adding inputs and modifying outputs for fees, and we also have a magic perfect transaction replacement protocol, package relay is still fundamentally useful for CPFP fee bumping very low feerate transactions received from an external party. E.g. Alice pays Bob, mempool min feerates increase and Alice's transaction is dropped, Bob still wants the money, so he submits a package with Alice's transaction plus his own high feerate spend of it. Package relay is a clear improvement now, and one I expect to be permanent for as long as we're using anything like the current protocol. > # Deployment timeline > > So what I believe as a rough deployment timeline. I don't think it's appropriate to be creating timelines like this that depend on the work of a large number of contributors who I don't believe you've consulted. For details on this point of view, please see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html Stuff will get done when it gets done. -Dave signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
