Devrandom [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-11-01 to 2022-09-17
💬 Posted a total of 18 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:06:00

- reply

📅 Original date posted:2022-05-09
📝 Original message:
( a formatted version of this message is here:
https://gitlab.com/lightning-signer/docs/-/wikis/Blind%20Signing%20Considered%20Harmful
)
# Introduction
This post discusses blind signers. Blind signers do not put the user in
control of their funds and are subject to a long list of exploits.
This post also (re-)introduces the open-source [Validating Lightning
Signer](https://gitlab.com/lightning-signer/docs/-/blob/master/README.md)
Project.
# Background
A **Signer** is a component that performs cryptographic operations,
separately from a wallet. A Bitcoin hardware wallet is an example of a
Signer, where private keys are controlled on a hardened device. There is
currently no complete solution for a hardware signer for the Lightning
network.
A **Blind Signer** is a signer that does not perform validation. There are
several Lightning wallets and node implementations that as of today support
only blind signing. I believe these configurations are insecure.
A **Validating Signer** performs a comprehensive set of policy checks to
ensure that the keys are not misused. For example, a validating Bitcoin
hardware wallet checks the destination, amount and change outputs in
collaboration with the user.
A layer-2 validating signer is significantly more complex, because of the
complexity of the Lightning protocol.
**While a Blind Signer is a technical step on the road to the higher
security of a Validating Signer, by itself it actually reduces security if
deployed in production. This is because it presents two points of attack -
at the node and at the signer.**
# The VLS Project
The [Validating Lightning Signer](
https://gitlab.com/lightning-signer/docs/-/blob/master/README.md) project
aims to close the gap for securing the Lightning ecosystem. It is an
open-source Rust library and reference implementation. The project is
approaching Beta, which is the point where the main goal will be met: funds
are safe even if the node is completely compromised.
The task is relatively complex because of the complexity of the Lightning
protocol. There are more than [50 policies](
https://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md)
that must be enforced, and many of them require stateful inspection of the
protocol.
Both servers and consumer devices are targeted, the latter via a Rust
`no_std` compilation mode.
# Signing Configurations
Here are some of the potential configurations of a Lightning node:
* Monolithic node
* Node with a separate Blind Signer
* Node with a separate Validating Signer - the signer ensures that the
Lightning state machine ran correctly and funds are not at risk
# The (In)security of Blind Signing
![blind-signing-diagram-1.svg](uploads/78db1bd2b59228492e09ea272c873cf3/blind-signing-diagram-1.svg)
* The monolithic case has one point of attack - at the node.
* The blind signing case has **two points of attack** - at the node and at
the Signer. A blind signer will perform any signing operation the node
requests, so **a compromised node will still result in loss of funds**. And
obviously, a compromised signer will also result in loss of funds. This is
worse than a monolithic node because funds can be lost if **either** is
compromised.
* The validated signing case has just one point of attack with a small
attack surface
# Wallets with Blind Signers Must Trust the Node Operator
Blind signing wallets where the node is run by an LSP (Lightning Service
Provider) are not self-custodial because the LSP can unilaterally control
the funds. The LSP merely has to provide the Signer with a transaction that
sends the funds to the LSP or another destination.
# Examples of Blind Signing Exploits
A compromised node can unilaterally submit transactions to be signed by the
blind Signer. The following can result in the funds being stolen:
* The node submits a mutual closing transaction which sends funds to the
attacker's address
* The node asks the blind signer to sign a revoked transaction which will
cause loss of all funds when published
* And many more ...
A compromised node can also lose funds when it doesn't follow the Lightning
protocol. Some potential exploits include:
* The node fails to validate the counter-party's revocation, and the
counter-party broadcasts an old commitment transaction that sends most of
the funds to the counter-party
* The node fails to claim input HTLCs when routing payments, leading to the
gradual loss of all funds
* And many more ...
# Validating Signers
In the Validating Signer case, a compromise of the Lightning node will not
result in the loss of funds. The security of such a setup is only dependent
on the security of the Signer. The Signer can be hardened as needed for the
specific use case.
Some of the validation rules that a validated Signer can implement include:
- Don't sign a revoked commitment transaction
- Don't revoke a signed commitment transaction
- Don't close a channel to an unapproved destination
- Routed payments must have at least as much input as output value
- Payments must claim at least as much from the input as was claimed from
us on the output
- And many more ...
# Conclusion
Blind signers reduce the security of Lightning nodes and are subject to
[many exploits](
https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits).
Validating signers improve security by reducing the attack surface. The VLS
project aims to provide a library and reference implementation for
enterprise servers and consumer devices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220509/95d3c85d/attachment.html>

2023-06-09 13:06:00

- reply

📅 Original date posted:2022-05-10
📝 Original message:
Good morning ZmnSCPxj,
On Mon, May 9, 2022 at 5:40 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning devrandom,
>
> It seems to me that a true validating Lightning signer would need to be a
> Bitcoin node with active mitigation against eclipse attacks, the ability to
> monitor the blockheight, and the ability to broadcast transactions.
>
The UTXO Oracle(s) have some additional properties that improve on a plain
Bitcoin node:
- they provide compact attestations that can be checked in an
isolated/hardened environment, so that the signer doesn't need to be
exposed to a network stack and can live on a consumer device or HSM
- a UTXO Oracle can send out attestations on a broadcast medium (e.g. live
behind Tor, satellite, etc.), so it's harder to block or eclipse
- the periodic attestation would cover the current block hash, and a
commitment for the UTXO set hash (e.g. hash of the compact filter history)
Broadcast is a separate concern. For broadcast, the intent is to have a
disaster recovery procedure:
- the signer sends out a heartbeat if it has a quorum of non-stale oracle
attestations and there are no upcoming safety deadlines (e.g. HTLC timeout
or need to breach-remedy)
- the heartbeats form a "deadman's switch" - if the node operator doesn't
get them, they spring into action
- the operator falls back to sneakernet for broadcasting a
closing/breach-remedy transaction if needed
>
> Otherwise, a compromised node can lie and tell the signer that the block
> height is much lower than it really is, letting the node peers clawback
> incoming HTLCs and claim outgoing HTLCs, leading to a net loss of funds in
> the forwarding case.
>
Right, routing nodes really need to be aware of the on-chain status of
incoming channels.
>
> Looking at the link, it seems to me that you have a "UTXO Set Oracle",
> does this inform your `lightning-signer` about block height and facilitate
> transaction broadcast?
> Is this intended to be a remote device from the `lightning-signer` device?
>
It could be a quorum of systems, remote from the signer device, some or all
of which may be under third-party operational control. The attestation for
a certain block is deterministic, so they should all agree.
> If so, what happens if the connection between the "UTXO Set Oracle" remote
> device and the `lightning-signer` is interrupted?
>
If there is no quorum, heartbeats would cease, which would alert the
operator to start disaster recovery.
>
> In particular:
> [...]
>
Agreed, that's the main attack scenario on a router that doesn't properly
chain the on-chain status of an input channel.
This seems to be listed in:
> https://gitlab.com/lightning-signer/docs/-/wikis/Potential-Exploits
>
> > an HTLC is failed and removed on the input before it is removed on the
> output. The output is then claimed by the counterparty, losing that amount
>
> Is there a mitigation, planned or implemented, against this exploit?
>
Yes, heartbeats would cease and the operator would manually intervene as
above.
That said, there is another potential mode: if you limit the value of
HTLCs in flight (e.g. 5% of channel value), are willing to lose that
amount, you don't do routing, and you have watchtowers, then you can live
without the UTXO Oracle component. This may be acceptable in a consumer
application.
Finally, we could essentially embed UTXO Oracles into the network if:
- we commit to compact-filters or utreexo roots in the consensus
- we are OK with SPV-style security, where we detect an eclipse by noticing
a reduction in block rate
But it's hard to say when the first item might be plausibly deployed.
--
devrandom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220510/b1cb218a/attachment-0001.html>

2023-06-09 13:01:52

- reply

📅 Original date posted:2021-01-10
📝 Original message:
Hi Omer,
Thank you for raising the topic of quorum key management for Lightning. I
believe this approach is an important direction for securing Lightning
nodes. Please see comments below.
On Tue, Dec 15, 2020 at 11:26 PM Omer Shlomovits <omer.shlomovits at gmail.com>
wrote:
> The attacker model is intuitive: an attacker attacks a machine which
> happens to run a lightning node. The attacker is *not* part of the
> network.
>
Well, that's an assumption. :) In general, an attacker may also control
one or more peers, either because they compromised them or because they
initiated a connection to the target node.
> Usually the attacked machine/device will have security measures in place:
> write/read permissions for different users. Our assumption is that the
> attacker does not necessarily
>
achieve full control over the node but only *some* elevated access: it may
> have only read or only write access for example which means it can steal
> some keys while not
>
Also a significant assumption, since in many cases an attacker can
completely compromise a system. It would be a much stronger security
posture if we defended against this too. What is the motivation for these
assumptions? Did you feel it's too difficult to defend against arbitrary
compromise?
I also want to mention that there are many ways funds can be lost in
Lightning once we assume that the node software can be fully compromised.
I believe we can defend against all these, but it requires implementation
of a relatively large set of controls in the key management layer. In the
Lightning Signer project we attempt to enumerate these controls - see:
https://gitlab.com/lightning-signer/docs/-/blob/master/policy-controls.md
For example - one of the more complex policy controls is "HTLC receive
channel validity - the funding UTXO of the receive channel must be active
on-chain with enough depth". i.e. we have to check that routed HTLCs are
coming from a valid channel or we could have all funds siphoned off over
time.
Looking forward to further work on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210110/4dad4d0e/attachment.html>

2023-06-09 12:59:06

- reply

📅 Original date posted:2020-02-28
📝 Original message:
On Thu, Feb 27, 2020 at 8:42 PM Gleb Naumenko <naumenko.gs at gmail.com> wrote:
>
> In this email, myself (gleb) and ariard want to discuss some aspects of the LN implementations when it comes to massive channel closing.
>
> [...]
> - how many nodes implement dynamic bumping
I think it's important to distinguish time-sensitive and
non-time-sensitive tx broadcasts
>From a game theoretic point of view, for non-time-sensitive txs (e.g.
normal closing) you just want to bump fees in a non-aggressive way, to
optimize tx inclusion vs time-value of money. So you mostly want to
track the global fee situation. The expected fee is less than 1% in
most situations.
For time-sensitive txs (mostly penalty broadcast), you stand to lose
your balance after the deadline, so you want to bump in an aggressive
way to keep the chance of losing your balance relatively low. Another
complication is that your estimate of the global state of fees might
be wrong because of fast changes in the global situation. So I would
expect that the game theoretic response would be to smoothly escalate
the fee to a significant % of the balance (maybe 50%+) as you get
close to the deadline.
Hopefully an attacker cannot trigger the time-sensitive case globally.
> Bounding dynamic-fees engine may be viewed as a game-theoretic aspect between LN parties (burn the maximum in fee rate to avoid an attacker to make any profit) and macro-considerations (prevent miner to exploit the whole LN network, conservative mempool/resources usage).
I'm not sure it makes sense to manage macro considerations with local
policies, if those policies end up contrary to self-interest of the
node operators. The rational response of the operator would be to
modify the software to conform to their local self-interest. The
magic of Bitcoin is that there are no selfish local modifications that
result in fatal global dynamics. If it ends up that LN has such
potential local modifications, we should be looking at protocol
changes to fix the local incentives.

2023-06-09 12:58:01

- reply

📅 Original date posted:2020-01-15
📝 Original message:
Thank you for the detailed evaluation. Please see inline comments.
To make reading easier, I've replaced some uncontroversial text with
[...].
On Tue, Jan 14, 2020 at 7:15 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> [...]
> In any case, the goal is to have some hardware unit, using only a simple communications channel with the software, to act as signer for all Lightning-related things (channel funding, channel updates, reclaiming funds after channel close).
> As is typical for such Bitcoin-related hardware units, it might possess its own user interface by which it can require confirmation of certain actions.
> Also, to reduce risk of hacking, the hardware unit does not have a connection to the netwrok, only a communications channel that is restricted to a local direct connection (such as USB).
>
> I will now demonstrate that such a design cannot achieve what an onchain Bitcoin hardware wallet does, namely that the hardware need not tr\*st the software and need not keep any state beyond the private key (which remains constant).
> For Lightning, it seems any hardware would require tr\*st in the software *and* some state.
Agreed, any external signer must maintain state because it must not
sign revoked transactions, etc. .
>
> Channel Updates
> ===============
>
> [...]
> Thus, the hardware has to remember at least what the current state is, and store this knowledge in persistent, secure, modifiable memory that the software cannot touch.
Agreed.
> It need not store the *whole* state: for example, it could store just a commitment to the current state (and have the software store the entire state).
> In fact, it is best for the hardware to store the *signature* for the commitment transaction:
I would say that's not enough, if we assume that the attacker can
destroy the underlying data, and destroy all backups. If the attacker
can do that, the node is at the mercy of channel partners, since they
will be able to publish old state without the possibility of
retaliation. Thus there needs to be a secure form of storage where at
least one backup must be recoverable at all times within the penalty
time window.
I do agree that a low-resource hardware wallet may just store the
signature, or other commitment to the state. In that case, we could
store the full data using an append-only log to a hardened machine
that specializes in preventing destruction of data by an attacker.
>
> [...]
>
> Tr\*sted Eventual Synchrony of Two Commitments
> ==============================================
> [...]
> This may prevent some HTLCs from being safely forwardable, but that only means stalls in payment forwarding.
This is a good point we haven't considered in our original writeup.
Intuitively, you are right that this can only result in stalls.
>
>
>
> Non-publication of Revoked Transactions
> =======================================
>
> [...]
> To prevent publication of our *own* commitment transaction at least, the hardware can simply not sign *own* commitment transactions as they are created.
Agreed.
>
> [...]
> Thus, the hardware has to have a concept of a "closed" channel, where it marks that the current txid for the *own* commitment transaction is the last one, and it
Agreed.
>
> [...]
> Thus the hardware provides three APIs:
>
> * Mark-as-close.
> * Get-final-signature (unilateral or mutual close option).
> * Delete-closed.
It seems that the first API call can be folded into the second. Also,
delete must be only performed once enough time has passed so that the
closing tx is unlikely to be reorged out of existence. This requires
the hardware wallet to have a trusted source of knowledge about the
state of the blockchain or current time. We wrote about UTXO set
oracle and the use of roughtime oracles in our original writeup.
>
> [...]
> Tr\*sted Revocation of Old Remote State
> =======================================
>
> Unfortunately, the hardware has to tr\*st the software to check that the other node is not cheating.
> As the hardware itself is not capable of accessing the blockchain or mempool, it cannot do this checking directly.
> Thus, revocation of old remote state is not ensurable by the hardware.
I am more optimistic about this. Publishing of penalty transactions
can be delegated to a quorum of watchtowers, some possibly run by
other entities. The node software can prove to the hardware that the
watchtowers have been informed of new state by providing a receipt
signed by the watchtowers. Thus it's possible to reduce trust in the
node software.
>
>
> As revocation can only be done by the software anyway, the revocation secrets for the *remote* commitment transactions can be stored by the software only.
> The hardware need never learn the revocation secrets as it can do nothing with them anyway.
I would at least back up the secrets in the secure storage attached to
the hardware store, so that the node can be recreated if the node
software has been catastrophically compromised.
>
> Opening a Channel
> =================
>
> [...]
> If there is a difference, that implies that this node is what pays the fee, and the hardware should probably double-confirm with the user using its UI whether the paid fees are acceptab;e.
If the fee is under a preset threshold, it can be auto-approved.
>
>
> Tr\*sted Forwarding
> ===================
>
> Forwarding should be automated and not require a confirmation from the user on the hardware unit UI.
> Unfortunately, the hardware has to trust the software to actually perform forwarding correctly.
Let's look at this carefully, I feel it should be possible to prove
correctness of forwarding to the hardware.
>
> However, the hardware has to keep track that an incoming HTLC only has at most one outgoing HTLC,.
> It cannot identify using the hash, incidentally: it is theoretically possible for a route to loop through a node twice, e.g. A -> B -> C -> D -> E -> C -> F, where C appears twice.
I think it's enough to require that each incoming HTLC can be
associated with a single outgoing HTLC. The hardware would have to
maintain state about which HTLCs have been "used up" in this way.
>
> Further, if a payment attempt fails, then the ultimate payer might still try to route through this node, giving a different postfix past this node, so this node may forward the same hash twice on two or more different payment attempts.
hmm... that doesn't sound safe, because then two different nodes would
be able to claim the funds from us, and we can only propagate back to
a single input, so we lose funds. If the Lightning protocol allows
this, then it sounds like a design issue. Seems like the failed HTLC
should be invalidated first. The invalidation can be proven to the
hardware (a new commitment tx is signed, removing the HTLC, or the
outgoing channel is closed).
>
> [...]
> Regardless, even if we somehow, the *enforcement* of HTLCs is still controlled by the software:
>
> * The hardware has no access to the blockchain, thus it cannot know if the incoming HTLC is in fact something in the deep past already.
> A corrupted software can induce the hardware to create an outgoing HTLC whose timelock is deeply in the past, then refuse to take the timelock branch of the outgoing HTLC while letting the timelock branch of the incoming HTLC be claimed by the other nodes.
See above about watchtowers, and trusted sources of time/blockchain state.
>
>
> Thus, forwarding is still trusted.
>
> [...]
> Reducing Storage Size
> =====================
>
> The hardware can, instead of storing multiple channel slots and payment slots in its own persistent memory, can instead just store a single *commitment* to the current state it knows to be valid.
Agreed, but see the need to have a reliable backup above.
>
>
>
> Regards,
> ZmnSCPxj

2023-06-07 23:13:25

- reply

📅 Original date posted:2022-09-17
📝 Original message:On Fri, Sep 16, 2022 at 9:18 PM Antoine Riard via bitcoin-dev <
bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220917/e432d554/attachment.html>

2023-06-07 23:13:23

- reply

📅 Original date posted:2022-09-15
📝 Original message:On Tue, Sep 13, 2022 at 6:03 PM Ryan Grant via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220915/2f70be72/attachment.html>

2023-06-07 23:04:05

- reply

📅 Original date posted:2022-02-10
📝 Original message: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 at 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
>
> 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/dcc0fea8/attachment-0001.html>

2023-06-07 22:53:41

- reply

📅 Original date posted:2021-05-18
📝 Original message: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&D, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210518/15c18301/attachment.html>

2023-06-07 22:51:52

- reply

📅 Original date posted:2021-04-17
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210417/1d1d8922/attachment.html>

2023-06-07 18:28:13

- reply

📅 Original date posted:2021-01-17
📝 Original message:Dear ZmnSCPxj,
On Thu, Jan 14, 2021 at 4:28 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210116/25ea76d6/attachment-0001.html>

2023-06-07 18:16:18

- reply

📅 Original date posted:2019-02-04
📝 Original message: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 at lists.linuxfoundation.org> wrote:
>
> James
>
>
> On Sun, Feb 3, 2019 at 10:27 AM Ryan Havar via bitcoin-dev <
> bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190204/11466a14/attachment-0001.html>

2023-06-07 18:15:22

- reply

📅 Original date posted:2018-11-28
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181127/9bf84f7f/attachment.html>

2023-06-07 18:07:26

- reply

📅 Original date posted:2017-11-06
📝 Original message:>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/ebea9284/attachment.html>

2023-06-07 18:07:25

- reply

📅 Original date posted:2017-11-06
📝 Original message:Hi Peter, thank you for the review. See below
On Mon, Nov 6, 2017 at 11:50 AM Peter Todd <pete at petertodd.org> wrote:
> On Wed, Nov 01, 2017 at 05:48:27AM +0000, 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.
>
The interesting thing is that the cost of attack varies smoothly as you
vary the POW weights.
To attack non-upgraded nodes, you still have to "51%" the original POW.
The reward going to that POW will vary smoothly between 1.0 * block_reward
and whatever
target value (e.g. 0.5 * block_reward) and the difficulty of attack will
tend to be proportional to that.
In a real hard-fork, your software just breaks at the fork point. In this
case, it's just the non-upgraded
node security level declining from 100% to 50% over a long period of time.
I envision the transition of POW weights will be over 1-3 years, which
leaves plenty of time to
upgrade after the fork activates.
>
> > ### 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.
>
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?
>
> > ### 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.
>
"smooth-fork" perhaps? :)
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/69e6bc4e/attachment.html>

2023-06-07 18:07:25

- reply

📅 Original date posted:2017-11-07
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171107/81f53507/attachment.html>

2023-06-07 18:07:23

- reply

📅 Original date posted:2017-11-02
📝 Original message: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 <contact at 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 at 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 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171103/d8fa3100/attachment.html>

2023-06-07 18:07:22

- reply

📅 Original date posted:2017-11-01
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171101/9dc7ba4e/attachment.html>