Re: [bitcoin-dev] On a new community process to specify covenants
On Fri, Sep 16, 2022 at 9:18 PM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Buck, > [...] > > I would vote against Slack. IRC is probably the best but maybe too high a > barrier to entry? Publishing logs at least would counter concerns of it > being exclusive. Maybe discord as an alternative. > > I would say I really like IRC too. The strong text-based format, the lack > of avatar emoji, the low-bar to participate pseudonymously, the leveling > field for non-native speakers contrary to audio and the easiness to grab > the mics, all features valuable for such a process I think. > > If IRC is still considered a technical high-bar for a standard > communication organ by many community stakeholders, discord is an > alternative. > I would rule out Discord, since it requires phone numbers. It doesn't require them for every user, but it's based on some risk measurement. The phone flow is probably more likely to be triggered by VPN / Tor. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
On Tue, Sep 13, 2022 at 6:03 PM Ryan Grant via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev > First just wanted to thank you > for taking the initiative to > > put this together. I think that as the community and > > ecosystem continue to grow, it's going to be an important > > part of the process to have groups like this develop. Hopefully > > they allow us to resist the "Tyranny of Structurelessness" without > > resorting to formalized governance processes and systems. > > Huh, lots of reading material behind that phrase. I'd heard it > before, but hadn't looked it up. > > > > Defining a communication channel is still an open question: IRC, Slack, > > Discord, Discourse, ... > > > > I would vote against Slack. IRC is probably the best but maybe too > > high a barrier to entry? Publishing logs at least would counter > > concerns of it being exclusive. Maybe discord as an alternative. > > I found Discord immediately wanted a phone number from me. I think > IRC remains the lowest bar for participants to contribute. > > Agreed, anything that requires a phone number makes it difficult to be pseudonymous. I recommend Matrix, since it doesn't require any privacy invasive information and has e2ee by default for 1-1 conversations. The Matrix room could optionally bridge to IRC if there is a significant demand for that. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Advancing the security of Neutrino using minimally trusted oracles
This would be very useful for the Validating Lightning Signer project, since we need to prove to a non-network connected signer that a UTXO has not been spent. It allows the signer to make sure the channel is still active. ( the related design doc is at https://gitlab.com/lightning-signer/docs/-/blob/master/oracle.md ) I think it would be useful if the oracles were non-interactive, so that they can communicate with the world over a one-way connection. This would reduce their attack surface. Instead of signing over a client-provided timestamp, we could pre-quantize the timestamp and emit attestations for each quantum time step. On Thu, Feb 10, 2022 at 11:10 AM enclade via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The design document which inspired Neutrino outlined the use of oracles to > provide a moderate level of confidence to lightweight clients in the > filters they have received from an untrusted source. Current > implementations of lightweight wallets using Neutrino either trust in a > single source, or a sampling of untrusted peers for this information. The > determinism of the filter headers allows for them to be simply and > compactly attested by a potentially large number of authoritative sources > with minimal loss in privacy. These sources could be exchanges, hardware > wallet manufacturers, block explorers, or other well known parties. > > The most obvious transport for these oracles is DNS, several[0][1] > implementations of tools exist which provide either headers or raw filter > data to clients by encoding it in record responses. With careful > construction oracles can operate using DNS with extremely low resource > requirements and attack surface, while providing a privacy maximizing > service to their clients. For situations where DNS is not appropriate, > other tools can aggregate the signatures into other formats as required. > > Clients could consider their view of the current network state to be > strong when several of their oracle sources present agreeing signatures, or > display an error to their user if no suitable number of attestations could > be found. Fault or fraud proofs can be generated by any party by simply > collecting differing signatures, for example if an oracle was presenting > disjoint filter headers from its peers the error would be readily apparent > and provable. > > - > > Host names and their associated keys would be baked into the binaries of > client software supporting the system, but their location and credentials > could be attested in a text file of their primary domain. For example, a > popular fictional exchange could advertise their ability to provide this > service using RFC5785. > > # curl https://pizzabase.com/.well-known/neutrino.txt > > 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c...@neutrino.pizzabase.com > > The client would request its known sources for attestations, using the > current unix timestamp as a nonce. Use of a lower precision (for example > rounded to 60 seconds) allows the oracle to cache the result with a long > TTL, while allowing a client to poll with relatively high frequency if > required. > > # dig 6204dd70.neutrino.pizzabase.com > # dig 6204dd70.neutrino.blockspaghettini.com > # dig 6204dd70.neutrino.mtgnocchi.com > > Oracles would return the current block hash, hash of the tip of the > neutrino header chain, and a ECDSA signature over the data including the > requesting quantized timestamp. In totality giving the client sufficient > and portable evidence that their view of the state of the network has not > been tampered with, while maintaining as much privacy as possible. > > - > > RFC. > > [0]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013417.html > [1]: https://github.com/mempoolco/chaindnsd > [2]: https://bitcoinheaders.net/ > ___ > 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] Proposal: Low Energy Bitcoin PoW
On Mon, May 17, 2021 at 11:47 PM ZmnSCPxj: > > When considering any new proof-of-foo, it is best to consider all effects > until you reach the base physics of the arrow of time, at which point you > will realize it is ultimately just another proof-of-work anyway. > Let's not simplify away economic considerations, such as externalities. The whole debate about the current PoW is about negative externalities related to energy production. Depending on the details, CAPEX (R, real-estate, construction, production) may have less externalities, and if that's the case, we should be interested in adopting a PoW that is intensive in these types of CAPEX. On Mon, May 17, 2021 at 2:20 PM Keagan McClelland wrote: First it just pushes the energy consumption upstream to the chip > manufacturing process, rather than eliminating it. And it may trade some > marginal amount of the energy consumption for the set of resources it takes > to educate and create chip manufacturers. The only way to avoid that cost > being funneled back into more energy consumption [...] > I challenge you to substantiate these assertions. Real-estate and human cognitive work are not energy intensive and are a major factor in the expected costs of some alternative PoWs. The expected mining effort is such that the cost will reach the expected reward, no more, so there is every reason to believe that energy consumption will be small compared to the current PoW. Therefore, the total associated negative externalities for the alternative PoWs may well be much lower than the externalities of energy production. This needs detailed analysis, not a knee-jerk reaction. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.
Hi Erik, Here's a scheme I posted here a few years ago, which smoothly transitions using geometric mean chain weight / difficulty: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Not sure of the best place to workshop ideas, so please take this with > a grain of salt. > > Starting with 3 assumptions: > > - assume that there exists a proof-of-burn that, for Bitcoin's > purposes, accurately-enough models the investment in and development > of ASICs to maintain miner incentive. > - assume the resulting timing problem "how much burn is enough to keep > blocks 10 minutes apart and what does that even mean" is also... > perfectly solvable > - assume "everyone unanimously loves this idea" > > The transition *could* look like this: > > - validating nodes begin to require proof-of-burn, in addition to > proof-of-work (soft fork) > - the extra expense makes it more expensive for miners, so POW slowly > drops > - on a predefined schedule, POB required is increased to 100% of the > "required work" to mine > > Given all of that, am I correct in thinking that a hard fork would not > be necessary? > > IE: We could transition to another "required proof" - such as a > quantum POW or a POB (above) or something else in a back-compat > way (existing nodes not aware of the rules would continue to > validate). > ___ > 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] Hardware wallets and "advanced" Bitcoin features
Dear ZmnSCPxj, On Thu, Jan 14, 2021 at 4:28 PM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The primary issue here is that we have a base assumption that the hardware > wallet cannot be sophisticated enough to have Internet access; "do not > enter seed words on an online device", as the typical advice goes. > Most clawback transactions are time-based, and *must* be broadcast at a > particular blockheight. > Yet if the hardware wallet cannot be an online device, then it cannot know > the current blockheight is now at a time when the clawback transaction > *must* be broadcast. > > Thus, the hardware must always tr\*st the software to actually perform the > clawback in that case. > I believe it is possible to achieve much of the desired "liveness" requirements without compromising too much on the air-gap. The solution requires the following: - a set of UTXO oracles which attest to the UTXO set - optionally, a set of clock oracles which attest to the current time (e.g. using the roughtime protocol) - an air-gap connection between the node software and the signer, e.g. using a narrow optical or serial protocol - a set of operators that can react to lack of liveness The Signer performs the following steps periodically: - if the funding UTXO has not been spent (per oracle attestation), proceed normally with any channel commitment signing - if the funding UTXO has been spent, ensure that the node provided the spending tx, and check if there is any reaction needed (e.g. a justice tx is needed) - if a reaction is needed, ensure that there is a further spend within a certain deadline (shorter than the CSV/CLTV deadline) - if there is no deadline violation, sign a heartbeat message with the current time (either from a local clock or from oracle clock) The node software then relays the signed heartbeat message to the operators, e.g. through Tor. If a heartbeat is not seen by the operators, they manually intervene (e.g. by standing up a clean node). Of course, we will never have Lightning paper wallets, by definition, since you can't participate in the network without being online. But the above setup seems to be at least as secure as USB hardware wallets attached to online machines. You could even have intermittently connected signers for slow-moving channels, or signers behind Tor, etc. . -- devrandom ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Card Shuffle To Bitcoin Seed
I would suggest 50+ 6-sided dice rolls, giving about 128 bits of entropy. Compared to a shuffle, it's easier to be sure that you got the right amount of entropy, even if the dice are somewhat biased. On Mon, Feb 4, 2019 at 2:33 PM James MacWhyte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > James > > > On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Conveniently a shuffled deck of cards also can serve as a physical backup >> which is easy to hide in plain sight with great plausible deniability. >> > > To make sure someone doesn't play with your cards and mix up the order, > use a permanent marker to draw a diagonal line on the side of the deck from > corner to corner. If the cards ever get mixed up, you can put them back in > order by making sure the diagonal line matches up. > ___ > 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] Multi party Schnorr Rust implementation
Hi Omer, Are there any candidates for non-interactive threshold signatures? Interactive signatures are not very suitable for air-gapped use cases. On Tue, Nov 27, 2018 at 11:18 AM Omer Shlomovits via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello all, > > I am working for the past few months with collaborators (in cc) on > providing Rust reference implementations to existing multi party schemes > for Schnorr signatures [1]. This includes aggregated signatures, > accountable signatures (which for n out of n are multi-signatures) and > threshold signatures (wip). > The project can be found here: > https://github.com/KZen-networks/multi-party-schnorr . > We aim that if the protocol is run in a configuration of a single party it > will be bip-schnorr [2] compliant. > > Hope you'll find it useful :) > Questions, suggestions and pull requests are welcome! > > > [1] > https://github.com/KZen-networks/multi-party-schnorr/tree/master/papers > [2] https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki > ___ > 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] Introducing a POW through a soft-fork
A hard-fork is a situation where non-upgraded nodes reject a block mined and relayed by upgraded nodes. This creates a fork that cannot heal regardless of what follows. This proposal is not a hard-fork, because the non-upgraded node *will heal* if the attack has less than 1/2 of the original-POW power in the long term. The cost of such an attack is the cost of a normal "51%" attack, multiplied by the fractional weight of the original POW (e.g. 0.75 or 0.5). So rather than saying this is a hard-fork, I would say that this is a soft-fork with reduced security for non-upgraded nodes. I would also say that the reduction in security is proportional to the reduction in weight of the original POW at the time of attack. As mentioned before, the original-POW weight starts at 1.0 and is reduced over a long period of time. I would set up the transition curve so that all nodes upgrade by the time the weight is, say, 0.75. In reality, nodes protecting high economic value would upgrade early. On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If a block that would be discarded under previous rules becomes accepted > after a rule addition, there is no reason to not simply call the new rule a > hard fork. IOW it's perfectly rational to consider a weaker block as > "invalid" relative to the strong chain. As such I don't see any reason to > qualify the term, it's a hard fork. But Peter's observation (the specific > behavior) is ultimately what matters. > > e > > On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > +1 to all of Peter Todd's comments > > On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote: >> >> Some quick thoughts... >> >> > Hi all, >> > >> > Feedback is welcome on the draft below. In particular, I want to see if >> > there is interest in further development of the idea and also >> interested in >> > any attack vectors or undesirable dynamics. >> > >> > (Formatted version available here: >> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md ) >> > >> > # Soft-fork Introduction of a New POW >> >> First of all, I don't think you can really call this a soft-fork; I'd >> call it a >> "pseudo-soft-fork" >> >> My reasoning being that after implementation, a chain with less total >> work than >> the main chain - but more total SHA256^2 work than the main chain - might >> be >> followed by non-supporting clients. It's got some properties of a >> soft-fork, >> but it's security model is definitely different. >> >> > ### Aux POW intermediate block >> > >> > Auxiliary POW blocks are introduced between normal blocks - i.e. the >> chain >> > alternates between the two POWs. >> > Each aux-POW block points to the previous normal block and contains >> > transactions just like a normal block. >> > Each normal block points to the previous aux-POW block and must contain >> all >> > transactions from the aux-POW block. >> >> Note how you're basically proposing for the block interval to be >> decreased, >> which has security implications due to increased orphan rates. >> >> > ### Heaviest chain rule change >> > >> > This is a semi-hard change, because non-upgraded nodes can get on the >> wrong >> > chain in case of attack. However, >> >> Exactly! Not really a soft-fork. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Introducing a POW through a soft-fork
> > Note how you're basically proposing for the block interval to be decreased, >> which has security implications due to increased orphan rates. >> > > Note that the total transaction rate and block size don't materially > change, so I don't > see why the orphan rate will change. Normal blocks are constrained to have > all of the txs of the aux blocks, so propagation time should stay the > same. Am I missing > something? > Ah, yes, I'm missing that the expected time to find each type of block is halved, so the orphan rate doubles. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Introducing a POW through a soft-fork
I am also concerned. However, this proposal allows two POWs to coexist and allows for gradual transitions. This is hopefully a less disruptive approach since it allows cooperative miners to migrate over time. And of course, as a soft-fork it keeps backwards compatibility with existing software. On Thu, Nov 2, 2017 at 4:55 PM Tao Effect <cont...@taoeffect.com> wrote: > Just going to throw in my support for a POW change, not any particular > implementation, but the idea. > > Bitcoin is technically owned by China now. That's not acceptable. > > - Greg > > -- > Please do not email me anything that you are not comfortable also sharing with > the NSA. > > On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi all, > > Feedback is welcome on the draft below. In particular, I want to see if > there is interest in further development of the idea and also interested in > any attack vectors or undesirable dynamics. > > (Formatted version available here: > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md ) > > # Soft-fork Introduction of a New POW > > ## Motivation: > > - Mitigate mining centralization pressures by introducing a POW that does > not have economies of scale > - Introduce an intermediary confirmation point, reducing the impact of > mining power fluctuations > > Note however that choice of a suitable POW will require deep analysis. > Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are > not, unexpected/covert optimization. > > In particular, unexpected/covert optimizations, such as ASCIBOOST, present > a potential centralizing and destabilizing force. > > ## Design > > ### Aux POW intermediate block > > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain > alternates between the two POWs. > Each aux-POW block points to the previous normal block and contains > transactions just like a normal block. > Each normal block points to the previous aux-POW block and must contain > all transactions from the aux-POW block. > Block space is not increased. > > The new intermediate block and the pointers are introduced via a soft-fork > restriction. > > ### Reward for aux POW miners > > The reward for the aux POW smoothly increases from zero to a target value > (e.g. 1/2 of the total reward) over time. > The reward is transferred via a soft-fork restriction requiring a coinbase > output to an address published in the > aux-POW block. > > ### Aux POW difficulty adjustment > > Difficulty adjustments remain independent for the two POWs. > > The difficulty of the aux POW is adjusted based on the average time > between normal block found > to aux block found. > > Further details are dependent on the specific POW. > > ### Heaviest chain rule change > > This is a semi-hard change, because non-upgraded nodes can get on the > wrong chain in case of attack. However, > it might be possible to construct an alert system that notifies > non-upgraded nodes of an upcoming rule change. > All blocks are still valid, so this is not a hardforking change. > > The heaviest chain definition changes from sum of `difficulty` to sum of: > > mainDifficulty ^ x * auxDifficulty ^ y > > where we start at: > > x = 1; y = 0 > > and end at values of x and y that are related to the target relative > rewards. For example, if the target rewards > are equally distributed, we will want ot end up at: > > x = 1/2; y = 1/2 > > so that both POWs have equal weight. If the aux POW is to become > dominant, x should end small relative to y. > > > ## Questions and Answers > > - What should be the parameters if we want the aux POW to have equal > weight? A: 1/2 of the reward should be transferred > to aux miners and x = 1/2, y = 1/2. > > - What should be the parameters if we want to deprecate the main POW? A: > most of the reward should be transferred to > aux miners and x = 0, y = 1. The main difficulty will tend to zero, and > aux miners will just trivially generate the > main block immediately after finding an aux block, with identical content. > > - Wasted bandwidth to transfer transactions twice? A: this can be > optimized by skipping transactions already > transferred. > > - Why would miners agree to soft-fork away some of their reward? A: they > would agree if they believe that > the coins will increase in value due to improved security properties. > > ## Open Questions > > - After a block of one type is found, we can naively assume that POW will > become idle while a block of the other type is being mined. In practice, > the spare
[bitcoin-dev] Introducing a POW through a soft-fork
Hi all,
Feedback is welcome on the draft below. In particular, I want to see if
there is interest in further development of the idea and also interested in
any attack vectors or undesirable dynamics.
(Formatted version available here:
https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
# Soft-fork Introduction of a New POW
## Motivation:
- Mitigate mining centralization pressures by introducing a POW that does
not have economies of scale
- Introduce an intermediary confirmation point, reducing the impact of
mining power fluctuations
Note however that choice of a suitable POW will require deep analysis.
Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are
not, unexpected/covert optimization.
In particular, unexpected/covert optimizations, such as ASCIBOOST, present
a potential centralizing and destabilizing force.
## Design
### Aux POW intermediate block
Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
alternates between the two POWs.
Each aux-POW block points to the previous normal block and contains
transactions just like a normal block.
Each normal block points to the previous aux-POW block and must contain all
transactions from the aux-POW block.
Block space is not increased.
The new intermediate block and the pointers are introduced via a soft-fork
restriction.
### Reward for aux POW miners
The reward for the aux POW smoothly increases from zero to a target value
(e.g. 1/2 of the total reward) over time.
The reward is transferred via a soft-fork restriction requiring a coinbase
output to an address published in the
aux-POW block.
### Aux POW difficulty adjustment
Difficulty adjustments remain independent for the two POWs.
The difficulty of the aux POW is adjusted based on the average time between
normal block found
to aux block found.
Further details are dependent on the specific POW.
### Heaviest chain rule change
This is a semi-hard change, because non-upgraded nodes can get on the wrong
chain in case of attack. However,
it might be possible to construct an alert system that notifies
non-upgraded nodes of an upcoming rule change.
All blocks are still valid, so this is not a hardforking change.
The heaviest chain definition changes from sum of `difficulty` to sum of:
mainDifficulty ^ x * auxDifficulty ^ y
where we start at:
x = 1; y = 0
and end at values of x and y that are related to the target relative
rewards. For example, if the target rewards
are equally distributed, we will want ot end up at:
x = 1/2; y = 1/2
so that both POWs have equal weight. If the aux POW is to become dominant,
x should end small relative to y.
## Questions and Answers
- What should be the parameters if we want the aux POW to have equal
weight? A: 1/2 of the reward should be transferred
to aux miners and x = 1/2, y = 1/2.
- What should be the parameters if we want to deprecate the main POW? A:
most of the reward should be transferred to
aux miners and x = 0, y = 1. The main difficulty will tend to zero, and
aux miners will just trivially generate the
main block immediately after finding an aux block, with identical content.
- Wasted bandwidth to transfer transactions twice? A: this can be
optimized by skipping transactions already
transferred.
- Why would miners agree to soft-fork away some of their reward? A: they
would agree if they believe that
the coins will increase in value due to improved security properties.
## Open Questions
- After a block of one type is found, we can naively assume that POW will
become idle while a block of the other type is being mined. In practice,
the spare capacity can be used to find alternative ("attacking") blocks or
mine other coins. Is that a problem?
- Is selfish mining amplified by this scheme for miners that have both
types of hardware?
## POW candidates
- SHA256 (i.e. use same POW, but introduce an intermediate block for faster
confirmation)
- Proof of Space and Time (Bram Cohen)
- Equihash
- Ethash
## Next Steps
- evaluate POW candidates
- evaluate difficulty adjustment rules
- simulate miner behavior to identify if there are incentives for
detrimental behavior patterns (e.g. block withholding / selfish mining)
- Protocol details
## Credits
Bram Cohen came up with a similar idea back in March:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
