<unnamed>

Public Key

npub1j0js72tmnxzmrtd6j0j5wcvfuhsqwgqxdwkpmw28rmmuy22y3wzsdw9k8n

Profile Code

nprofile1qqsf8eg099aenpd34kaf8e28vxy7tcq8yqrxhtqah9r3aa7z99zghpgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds4l3l9k

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-09 15:06:00 CEST

- 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-07 20:16:18 CEST

- 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 20:07:22 CEST

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