Re: [bitcoin-dev] Braidpool: Proposal for a decentralised mining pool
Good morning all,
A thing I just realized about Braidpool is that the payout server is still a
single central point-of-failure.
Although the paper claims to use Tor hidden service to protect against DDoS
attacks, its centrality still cannot protect against sheer accident.
What happens if some clumsy human (all humans are clumsy, right?) fumbles the
cables in the datacenter the hub is hosted in?
What happens if the country the datacenter is in is plunged into war or
anarchy, because you humans love war and chaos so much?
What happens if Zeus has a random affair (like all those other times), Hera
gets angry, and they get into a domestic, and then a random thrown lightning
bolt hits the datacenter the hub is in?
The paper relies on economic arguments ("such an action will end the pool and
the stream of future profits for the hub"), but economic arguments tend to be a
lot less powerful in a monopoly, and the hub effectively has a monopoly on all
Braidpool miners.
Hashers might be willing to tolerate minor peccadilloes of the hub, simply to
let the pool continue (their other choices would be even worse).
So it seems to me that it would still be nicer, if it were at all possible, to
use multiple hubs.
I am uncertain how easily this can be done.
Perhaps a Lightning model can be considered.
Multiple hubs may exist which offer liquidity to the Braidpool network, hashers
measure uptime and timeliness of payouts, and the winning hasher elects one of
the hubs.
The hub gets paid on the coinbase, and should send payouts, minus fees, on the
LN to the miners.
However, this probably complicates the design too much, and it may be more
beneficial to get *something* working now.
Let not the perfect be the enemy of the good.
Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
If you make the to be reorged flag 2 bits, 1 bit can mark final block and the other can mark to be reorged. That way the nodes opting into reorg can see the reorg and ignore the final blocks (until a certain time? Or until it's via a reorg?), and the nodes wanting not to see reorgs get continuous service without disruption On Tue, Sep 7, 2021, 9:12 AM 0xB10C via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > tl;dr: We want to make reorgs on SigNet a reality and are looking for > feedback on approach and parameters. > > One of the ideas for SigNet is the possibility for it to be reliably > unreliable, for example, planned chain reorganizations. These have not > been implemented yet. > > My summerofbitcoin.org mentee Nikhil Bartwal and I have been looking at > implementing support for reorgs on SigNet. We are looking for feedback > on which approach and parameters to use. Please consider answering the > questions below if you or your company is interested in chain > reorganizations on SigNet. > > With feedback from AJ and Kalle Alm (thanks again!), we came up with two > scenarios that could be implemented in the current SigNet miner script > [0]. Both would trigger automatically in a fixed block interval. > Scenario 1 simulates a race scenario where two chains compete for D > blocks. Scenario 2 simulates a chain rollback where the top D blocks get > replaced by a chain that outgrows the earlier branch. > > AJ proposed to allow SigNet users to opt-out of reorgs in case they > explicitly want to remain unaffected. This can be done by setting a > to-be-reorged version bit flag on the blocks that won't end up in the > most work chain. Node operators could choose not to accept to-be-reorged > SigNet blocks with this flag set via a configuration argument. > > The reorg-interval X very much depends on the user's needs. One could > argue that there should be, for example, three reorgs per day, each 48 > blocks apart. Such a short reorg interval allows developers in all time > zones to be awake during one or two reorgs per day. Developers don't > need to wait for, for example, a week until they can test their reorgs > next. However, too frequent reorgs could hinder other SigNet users. > > We propose that the reorg depth D is deterministically random between a > minimum and a maximum based on, e.g., the block hash or the nonce of the > last block before the reorg. Compared to a local randint() based > implementation, this allows reorg-handling tests and external tools to > calculate the expected reorg depth. > > # Scenario 1: Race between two chains > > For this scenario, at least two nodes and miner scripts need to be > running. An always-miner A continuously produces blocks and rejects > blocks with the to-be-reorged version bit flag set. And a race-miner R > that only mines D blocks at the start of each interval and then waits X > blocks. A and R both have the same hash rate. Assuming both are well > connected to the network, it's random which miner will first mine and > propagate a block. In the end, the A miner chain will always win the race. > > # Scenario 2: Chain rollback > > This scenario only requires one miner and Bitcoin Core node but also > works in a multiminer setup. The miners mine D blocks with the > to-be-reorged version bit flag set at the start of the interval. After > allowing the block at height X+D to propagate, they invalidate the block > at height X+1 and start mining on block X again. This time without > setting the to-be-reorged version bit flag. Non-miner nodes will reorg > to the new tip at height X+D+1, and the first-seen branch stalls. > > # Questions > > 1. How do you currently test your applications reorg handling? Do >the two discussed scenarios (race and chain rollback) cover your >needs? Are we missing something you'd find helpful? > > 2. How often should reorgs happen on the default SigNet? Should >there be multiple reorgs a day (e.g., every 48 or 72 blocks >assuming 144 blocks per day) as your engineers need to be awake? >Do you favor less frequent reorgs (once per week or month)? Why? > > 3. How deep should the reorgs be on average? Do you want to test >deeper reorgs (10+ blocks) too? > > > # Next Steps > > We will likely implement Scenario 1, the race between two chains, first. > We'll set up a public test-SigNet along with a faucet, block explorer, > and a block tree visualization. If there is interest in the second > approach, chain rollbacks can be implemented too. Future work will add > the possibility to include conflicting transactions in the two branches. > After enough testing, the default SigNet can start to do periodical > reorgs, too. > > Thanks, > 0xB10C > > [0]: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org >
[bitcoin-dev] Reorgs on SigNet - Looking for feedback on approach and parameters
Hello, tl;dr: We want to make reorgs on SigNet a reality and are looking for feedback on approach and parameters. One of the ideas for SigNet is the possibility for it to be reliably unreliable, for example, planned chain reorganizations. These have not been implemented yet. My summerofbitcoin.org mentee Nikhil Bartwal and I have been looking at implementing support for reorgs on SigNet. We are looking for feedback on which approach and parameters to use. Please consider answering the questions below if you or your company is interested in chain reorganizations on SigNet. With feedback from AJ and Kalle Alm (thanks again!), we came up with two scenarios that could be implemented in the current SigNet miner script [0]. Both would trigger automatically in a fixed block interval. Scenario 1 simulates a race scenario where two chains compete for D blocks. Scenario 2 simulates a chain rollback where the top D blocks get replaced by a chain that outgrows the earlier branch. AJ proposed to allow SigNet users to opt-out of reorgs in case they explicitly want to remain unaffected. This can be done by setting a to-be-reorged version bit flag on the blocks that won't end up in the most work chain. Node operators could choose not to accept to-be-reorged SigNet blocks with this flag set via a configuration argument. The reorg-interval X very much depends on the user's needs. One could argue that there should be, for example, three reorgs per day, each 48 blocks apart. Such a short reorg interval allows developers in all time zones to be awake during one or two reorgs per day. Developers don't need to wait for, for example, a week until they can test their reorgs next. However, too frequent reorgs could hinder other SigNet users. We propose that the reorg depth D is deterministically random between a minimum and a maximum based on, e.g., the block hash or the nonce of the last block before the reorg. Compared to a local randint() based implementation, this allows reorg-handling tests and external tools to calculate the expected reorg depth. # Scenario 1: Race between two chains For this scenario, at least two nodes and miner scripts need to be running. An always-miner A continuously produces blocks and rejects blocks with the to-be-reorged version bit flag set. And a race-miner R that only mines D blocks at the start of each interval and then waits X blocks. A and R both have the same hash rate. Assuming both are well connected to the network, it's random which miner will first mine and propagate a block. In the end, the A miner chain will always win the race. # Scenario 2: Chain rollback This scenario only requires one miner and Bitcoin Core node but also works in a multiminer setup. The miners mine D blocks with the to-be-reorged version bit flag set at the start of the interval. After allowing the block at height X+D to propagate, they invalidate the block at height X+1 and start mining on block X again. This time without setting the to-be-reorged version bit flag. Non-miner nodes will reorg to the new tip at height X+D+1, and the first-seen branch stalls. # Questions 1. How do you currently test your applications reorg handling? Do the two discussed scenarios (race and chain rollback) cover your needs? Are we missing something you'd find helpful? 2. How often should reorgs happen on the default SigNet? Should there be multiple reorgs a day (e.g., every 48 or 72 blocks assuming 144 blocks per day) as your engineers need to be awake? Do you favor less frequent reorgs (once per week or month)? Why? 3. How deep should the reorgs be on average? Do you want to test deeper reorgs (10+ blocks) too? # Next Steps We will likely implement Scenario 1, the race between two chains, first. We'll set up a public test-SigNet along with a faucet, block explorer, and a block tree visualization. If there is interest in the second approach, chain rollbacks can be implemented too. Future work will add the possibility to include conflicting transactions in the two branches. After enough testing, the default SigNet can start to do periodical reorgs, too. Thanks, 0xB10C [0]: https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC
With a new BIP editor (Kalle Alm) in place and Taproot activation locked in it is probably/possibly as good time as any to revisit the BIP process and see if we can bolster it, improve it or at least inform why certain things operate the way they do. Hence two IRC meetings are being organized, one on Tuesday September 14th (23:00 UTC) and one on Wednesday September 29th (23:00 UTC), both on the Libera IRC channel #bitcoin-dev. Possible discussion topics range from the relatively mundane (should BIP champions need to ACK basic spelling change PRs) to the possibly contentious (what role if any do the BIPs have in informing the community of soft fork activation parameters). At the very least it would be good to address some common misunderstandings and subtleties of the BIP process that many (including myself) are lacking context on. So if you are interested in the BIP process or certainly if you have experienced frustrations with the BIP process in the past as a BIP champion or BIP contributor please attend and we’ll see what progress we can make. There is a BIP process wishlist that some have already contributed ideas too: https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist And of course BIP 2 outlines the current BIP process: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki This is being organized in the spirit of seeking to improve a process and a resource that we as a community all rely on so please engage in the spirit that is intended. I will keep the mailing list informed of anything that comes out of the meetings and the #bitcoin-dev channel is open for discussion outside of the meetings. -- Michael Folkson Email: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Drivechain: BIP 300 and 301
Good morning Prayank, > Thanks for sharing all the details. One thing that I am not sure about: > > > * We already ***know*** that blockchains cannot scale > > * Your plan for scaling is to make ***more*** blockchains? > > Scaling Bitcoin can be different from scaling Bitcoin sidechains. You can > experiment with lot of things on sidechains to scale which isn't true for > Bitcoin. I would classify this as "prototyping new features" (i.e. it just happens to be a feature that theoretically improves blockchain scaling, with the sidechain as a demonstration and the goal eventually to get something like it into Bitcoin blockchain proper), not really scaling-by-sidechains/shards, so I think this is a fine example of "just make a federated sidechain" solution for the prototyping bit. Do note that the above idea is a kernel for the argument that Drivechains simply allow for miner-controlled block size increases, an argument I have seen elsewhere but have no good links for, so take it is hearsay. > Most important thing is requirements for running a node differ. Its easy to > run a node for LN, Liquid and Rootstock right now. Will it remain the same? I > am not sure. > > LND: https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md > > Liquid: > https://help.blockstream.com/hc/en-us/articles/92026026-How-do-I-set-up-a-Liquid-node- > > Rootstock: https://developers.rsk.co/rsk/node/install/ LN will likely remain easy to install and maintain, especially if you use C-Lightning and CLBOSS *cough*. > > More to the point: what are sidechains **for**? > > Smart contracts are possible on Bitcoin but with limited functionality so lot > of applications are not possible using Bitcoin (Layer1). Some of these don't > even make sense on Layer 1 and create other issues like MEV however deploying > them on sidechains should not affect base layer. Key being "should" --- as noted, part of the Drivechains security argument from Paul Sztorc is that a nuclear option can be deployed, which *possibly* means that issues in the sidechain may infect the mainchain. Also see stuff like "smart contracts unchained": https://zmnscpxj.github.io/bitcoin/unchained.html This allows creation of small federations which are *not* coordinated via inefficient blockchain structures. So, really, my main point is: before going for the big heavy blockchain hammer, maybe other constructions are possible for any specific application? > > > Increasing the Drivechain security parameter leads to slower > >sidechain->mainchin withdrawals, effectively a bottleneck on how much can be > >transferred sidechain->mainchain. > > I think 'withdrawals' is the part which can be improved in Drivechain. Not > sure about any solution at this point or trade-offs involved but making few > changes can help Drivechain and Bitcoin. It is precisely due to the fact that the mainchain cannot validate the sidechain rules, that side->main transfers must be bottlenecked, so that sidechain miners have an opportunity to gainsay any theft attempts that violate the sidechain rules. Consider a similar parameter in Lightning when exiting non-cooperatively from a channel, which allows the other side to gainsay any theft attempts, a parameter which will still exist even in Decker-Russell-Osuntokun. This parameter existed even in the old Blockstream sidechains proposal from sipa et al. For the old Blockstream proposal the parameter is measured in sidechain blocks, and the sidechain has its own miners instead of riding off mainchain, but ultimately there exists a parameter that restricts the rate at which side->main transfers can be performed. At least LN does not require any changes at the base layer (at least not anymore, after SegWit). Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
