<unnamed>

Public Key

npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8n

Profile Code

nprofile1qqsf8eg099aenpd34kaf8e28vxy7tcq8yqrxhtqah9r3aa7z99zghpgpzpmhxue69uhkummnw3ezuamfdejs52gdgy

Publishing to

nostr.wine

Last Notes

2023-06-09 13:06:00 UTC

- 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 UTC

- 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-07 18:28:13 UTC

- 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 UTC

- 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:07:25 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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>