Re: [bitcoin-dev] Block solving slowdown question/poll

[Dave Scotese via bitcoin-dev]

The software currently allows up to a two hour difference between the
system clock and the time implied by a fresh block's timestamp (if I
remember correctly).  This reliance on realtime system clocks can be used
in a much weaker form to justify a plan for a difficulty adjustment to be
built into the software for when the expected block production rate is far
enough behind its expected value.

We would have to agree on how far behind mining should be to justify
expediting the adjustment.  The sooner we decide on and implement this
second difficulty adjustment trigger, the better.  It cuts off a nightmare
scenario made possible by collusion between states through regulation and
fiat, as well as any other external factors.  I propose that miners
detecting that the expected 2016 blocks have not been mined after twice the
expected wait time (4032 * 10 minutes = 28 days) ought to signal their
recognition in any block they produce, to be rejected by any miner whose
clock disagrees (after taking into account the 2-hour leeway), and that any
block produced on top of one with such a signal should reflect an expedited
difficulty adjustment (and also include the signal), which is then in
effect for the rest of the 2016 blocks and the entire following difficulty
period.  Every block from there until the modulo 2016 block should have the
same signal, which not only indicates that a difficulty adjustment was
expedited, but also that the next modulo 2016 block should not make one,
but rather turn off the signal.

If anyone thinks it's a good enough idea for a BIP, I will consider writing
one unless someone else wants to.

Dave.

On Sun, Mar 22, 2020 at 9:54 AM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Mining is a lottery.
>
> e
>
> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 
> There seems to be the real possibility that miners are simply trying to
> optimise mining profit by limiting the average hash rate during the
> retargeting, saving some electricity but poorly considering the overall
> situation where they give opportunity to other miners probably raising the
> hashrate for the next period. It is far more profitable for the ecosystem
> considering the whole to hold a lottery for minig as has been discussed
> elsewhere some time ago.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
>
>
> --
> *From:* bitcoin-dev  on
> behalf of David A. Harding via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Sunday, 22 March 2020 6:54 PM
> *To:* Dave Scotese ; Bitcoin Protocol Discussion
> 
> *Subject:* Re: [bitcoin-dev] Block solving slowdown question/poll
>
> On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev
> wrote:
> > [Imagine] we also see mining power dropping off at a rate that
> > suggests the few days [until retarget] might become a few weeks, and
> > then, possibly, a few months or even the unthinkable, a few eons.  I'm
> > curious to know if anyone has ideas on how this might be handled
>
> There are only two practical solutions I'm aware of:
>
> 1. Do nothing
> 2. Hard fork a difficulty reduction
>
> If bitcoins retain even a small fraction of their value compared to the
> previous retarget period and if most mining equipment is still available
> for operation, then doing nothing is probably the best choice---as block
> space becomes scarcer, transaction feerates will increase and miners
> will be incentivized to increase their block production rate.
>
> If the bitcoin price has plummeted more than, say, 99% in two weeks
> with no hope of short-term recovery or if a large fraction of mining
> equipment has become unusable (again, say, 99% in two weeks with no
> hope of short-term recovery), then it's probably worth Bitcoin users
> discussing a hard fork to reduce difficulty to a currently sustainable
> level.
>
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy  and Meme Racing
 (in alpha).
I'm the webmaster for The Voluntaryist  which
now accepts Bitcoin.
I also code for The Dollar Vigilante .
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block solving slowdown question/poll

[Eric Voskuil via bitcoin-dev]

Mining is a lottery.

e

> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev 
>  wrote:
> 
> 
> There seems to be the real possibility that miners are simply trying to 
> optimise mining profit by limiting the average hash rate during the 
> retargeting, saving some electricity but poorly considering the overall 
> situation where they give opportunity to other miners probably raising the 
> hashrate for the next period. It is far more profitable for the ecosystem 
> considering the whole to hold a lottery for minig as has been discussed 
> elsewhere some time ago.
> 
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
> 
> 
> From: bitcoin-dev  on behalf 
> of David A. Harding via bitcoin-dev 
> Sent: Sunday, 22 March 2020 6:54 PM
> To: Dave Scotese ; Bitcoin Protocol Discussion 
> 
> Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
>  
> On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:
> > [Imagine] we also see mining power dropping off at a rate that
> > suggests the few days [until retarget] might become a few weeks, and
> > then, possibly, a few months or even the unthinkable, a few eons.  I'm
> > curious to know if anyone has ideas on how this might be handled
> 
> There are only two practical solutions I'm aware of:
> 
> 1. Do nothing
> 2. Hard fork a difficulty reduction
> 
> If bitcoins retain even a small fraction of their value compared to the
> previous retarget period and if most mining equipment is still available
> for operation, then doing nothing is probably the best choice---as block
> space becomes scarcer, transaction feerates will increase and miners
> will be incentivized to increase their block production rate.
> 
> If the bitcoin price has plummeted more than, say, 99% in two weeks
> with no hope of short-term recovery or if a large fraction of mining
> equipment has become unusable (again, say, 99% in two weeks with no
> hope of short-term recovery), then it's probably worth Bitcoin users
> discussing a hard fork to reduce difficulty to a currently sustainable
> level.
> 
> -Dave
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques

[Tim Ruffing via bitcoin-dev]

On Sun, 2020-03-22 at 11:30 -0400, Russell O'Connor wrote:
> Your claim is that if we don't fix the pubkey issue there is no point
> in fixing the signature issue.  I disagree.  While I think both
> issues need to be fully addressed, the issues around the original
> proposed non-deterministic signature scheme are far more severe. The
> proposal would move us from a deterministic scheme, where spot checks
> are possible, with all the caveats that entails, to a non-
> deterministic scheme where spot checks are impossible.  My hope is
> that we can standardise a scheme that has the advantages of non-
> determinism without the threat of covert channels.

I think we agree that both issues should be addressed, and this is all
what matters in the end. Now that we have a proposal for Schnorr
signatures, it's indeed a good time to work on these issues.

Tim

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques

[Russell O'Connor via bitcoin-dev]

On Sun, Mar 22, 2020 at 5:43 AM Tim Ruffing  wrote:

> On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> > Public keys are deterministic and can be spot checked.  In fact,
> > AFAIU if hardened HD key derivations are not used, then spot checking
> > is very easy.
> >
> > While spot checking isn't ideal, my original concern with the
> > synthetic none standard proposal was that it is inherently non-
> > deterministic and cannot ever be spot checked.  This is why anti-
> > covert signing protocols are so important if we are going to use
> > synthetic nonces.
>
> If spot checking means checking a few instances, then I think this is a
> pretty weak defense. What if the device starts to behave differently
> after a year?
>

I agree, which is why there perhaps is merit in using a non-hardered
derivation path so that the software side of a hardware wallet can check
the pubkey. Though I understand there are some disadvantages to the
non-hardened paths.

However, spot checking can even be done retroactively (and thoroughly).
Again, I agree that this is less than ideal, but does let you take some
action once you notice a deviation.

Your claim is that if we don't fix the pubkey issue there is no point in
fixing the signature issue.  I disagree.  While I think both issues need to
be fully addressed, the issues around the original proposed
non-deterministic signature scheme are far more severe. The proposal would
move us from a deterministic scheme, where spot checks are possible, with
all the caveats that entails, to a non-deterministic scheme where spot
checks are impossible.  My hope is that we can standardise a scheme that
has the advantages of non-determinism without the threat of covert channels.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block solving slowdown question/poll

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

There seems to be the real possibility that miners are simply trying to 
optimise mining profit by limiting the average hash rate during the 
retargeting, saving some electricity but poorly considering the overall 
situation where they give opportunity to other miners probably raising the 
hashrate for the next period. It is far more profitable for the ecosystem 
considering the whole to hold a lottery for minig as has been discussed 
elsewhere some time ago.

Regards,
LORD HIS EXCELLENCY JAMES HRMH



From: bitcoin-dev  on behalf of 
David A. Harding via bitcoin-dev 
Sent: Sunday, 22 March 2020 6:54 PM
To: Dave Scotese ; Bitcoin Protocol Discussion 

Subject: Re: [bitcoin-dev] Block solving slowdown question/poll

On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:
> [Imagine] we also see mining power dropping off at a rate that
> suggests the few days [until retarget] might become a few weeks, and
> then, possibly, a few months or even the unthinkable, a few eons.  I'm
> curious to know if anyone has ideas on how this might be handled

There are only two practical solutions I'm aware of:

1. Do nothing
2. Hard fork a difficulty reduction

If bitcoins retain even a small fraction of their value compared to the
previous retarget period and if most mining equipment is still available
for operation, then doing nothing is probably the best choice---as block
space becomes scarcer, transaction feerates will increase and miners
will be incentivized to increase their block production rate.

If the bitcoin price has plummeted more than, say, 99% in two weeks
with no hope of short-term recovery or if a large fraction of mining
equipment has become unusable (again, say, 99% in two weeks with no
hope of short-term recovery), then it's probably worth Bitcoin users
discussing a hard fork to reduce difficulty to a currently sustainable
level.

-Dave
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques

[Tim Ruffing via bitcoin-dev]

On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> Public keys are deterministic and can be spot checked.  In fact,
> AFAIU if hardened HD key derivations are not used, then spot checking
> is very easy.
> 
> While spot checking isn't ideal, my original concern with the
> synthetic none standard proposal was that it is inherently non-
> deterministic and cannot ever be spot checked.  This is why anti-
> covert signing protocols are so important if we are going to use
> synthetic nonces.

If spot checking means checking a few instances, then I think this is a
pretty weak defense. What if the device starts to behave differently
after a year?

On Sat, 2020-03-21 at 21:29 +0100, Marko Bencun wrote:
> Practically speaking, most hardware wallets allow you to import your
> own BIP39 seed, so you can work around key generation attacks today,
> with a one time inconvenience at the start. However, with the signing
> nonce attacks, a user today has no protection.
> 

How do you know that the device really uses your seed? This can only be
done by comparing the public keys output by the HW with a second
computation. Even if you use only non-hardened derivation, you need to
check the master (root) public key and that means you need compute the
master root public key once from the seed. You can't do this manually
on a sheet of paper after you rolled a few dice to generate your seed.
So you need to store the seed on a second device (if only for a short
time). And I think this defeats the purpose of a HW wallet.

And even if assume that spot checking and importing the seed works, the
problem is not solved. We still need a clearly specified full protocol
that we can analyze. 

Best,
Tim

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains

[Ethan Kosakovsky via bitcoin-dev]

I have completely revised the wording of this proposal I hope to be clearer in 
explaining the motivation and methodology.

https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d6

Ethan

‐‐‐ Original Message ‐‐‐
On Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev 
 wrote:

> I would like to present a proposal for discussion and peer review. It aims to 
> solve the problem of "too many seeds and too many backups" due to the many 
> reasons stipulated in the proposal text.
>
> https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki
>
> 
> BIP:
> Title: Deterministic Entropy From BIP32 Keychains
> Author: Ethan Kosakovsky ethankosakov...@protonmail.com
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-03-20
> License: BSD-2-Clause
> OPL
> 
>
> ==Abstract==
>
> This proposal provides a way to derive entropy from a HD keychain path in 
> order to deterministically derive the initial entropy used to create keychain 
> mnemonics and seeds.
>
> ==Motivation==
>
> BIP32 uses some initial entropy as a seed to deterministically derive a BIP32 
> root for hierarchical deterministic keychains. BIP39 introduced a method of 
> encoding initial entropy into a mnemonic phrase which is used as input to a 
> one way hash function in order to deterministically derive a BIP32 seed. The 
> motivation behind mnemonic phrases was to make it easier for humans to backup 
> and store offline. There are also other variations of this theme.
>
> The initial motivation of BIP32 was to make handling of large numbers of 
> private keys easier to manage and backup, since you only need one BIP32 seed 
> to cover all possible keys in the keychain. In practice however, due to 
> various wallet implementations and security models, the average user may be 
> faced with the need to handle an ever growing number of seeds/mnemonics. This 
> is due to incompatible wallet standards, hardware wallets (HWW), seed formats 
> and standards, as well as, the need to used a mix of hot and cold wallets 
> depending on the application and environment.
>
> Examples would span wallets on mobile phones, online servers running 
> protocols like Join Market or Lightning, and the difference between Electrum 
> and BIP39 mnemonic seed formats. The reference implementation of Bitcoin Core 
> uses BIP32, while other cryptocurrencies like Monero use different mnemonic 
> encoding schemes.
>
> We must also consider the different variety of physical backups including 
> paper, metal and other physical storage devices, as well as the potentially 
> splitting backups across different geographical locations. This complexity 
> may result in less care being taken with subsequently generated seeds for new 
> wallets need to be stored and it ultimately results in less security. In 
> reality, the idea of having "one seed for all" has proven to be more 
> difficult in practice than originally thought.
>
> Since all these derivation schemes are deterministic based on some initial 
> entropy, this proposal aims to solve the above problems by detailing a way to 
> deterministically derive the initial entropy used for new root keychains 
> using a single BIP32 style "master root key". This will allow one root key or 
> mnemonic to derive any variety of different root keychains in whatever format 
> is required (like BIP32 and BIP39 etc).
>
> ==Specification==
>
> Input starts with a BIP32 seed. Derivation scheme uses the format 
> `m/83696968'/type'/index'` where `type` is the final seed type, and `index` 
> in the key index of the hardened child private key.
>
> type
>
> bits
>
> output
>
> 0
>
> 128
>
> 12 word BIP39 mnemonic
>
> 1
>
> 256
>
> 24 word BIP39 mnemonic
>
> 2
>
> 128
>
> 12 word Electrum mnemonic
>
> 3
>
> 256
>
> 24 word Electrum mnemonic
>
> 4
>
> 256
>
> WIF for Bitcoin Core
>
> 5
>
> 256
>
> 25 word Monero mnemonic
>
> Entropy is calculated from the HMAC-SHA512(key=k, 
> msg='bip-entropy-from-bip32') of the derived 32 byte private key (k). Entropy 
> is taken from the result according to the number of bits required. This 
> entropy can then be used as input to derive a mnemonic, wallet etc according 
> to the`type` specified.
>
> ==Compatibility==
>
> In order to maintain the widest compatibility, the input to this function is 
> a BIP32 seed, which may or may not have been derived from a BIP39 like 
> mnemonic scheme. This maintains the original motivation that one backup can 
> store any and all child derivation schemes depending on the user's preference 
> or hardware signing devices. For example, devices that store the HD seed as a 
> BIP39 mnemonic, Electrum seed, or BIP32 root key would all be able to 
> implement this standard.
>
> ==Discussion==
>
> This proposal could be split into multiple discrete BIPs in the same way that 
> BIP32 described 

Re: [bitcoin-dev] Block solving slowdown question/poll

[David A. Harding via bitcoin-dev]

On Sat, Mar 21, 2020 at 11:40:24AM -0700, Dave Scotese via bitcoin-dev wrote:
> [Imagine] we also see mining power dropping off at a rate that
> suggests the few days [until retarget] might become a few weeks, and
> then, possibly, a few months or even the unthinkable, a few eons.  I'm
> curious to know if anyone has ideas on how this might be handled

There are only two practical solutions I'm aware of:

1. Do nothing
2. Hard fork a difficulty reduction

If bitcoins retain even a small fraction of their value compared to the
previous retarget period and if most mining equipment is still available
for operation, then doing nothing is probably the best choice---as block
space becomes scarcer, transaction feerates will increase and miners
will be incentivized to increase their block production rate.

If the bitcoin price has plummeted more than, say, 99% in two weeks
with no hope of short-term recovery or if a large fraction of mining
equipment has become unusable (again, say, 99% in two weeks with no
hope of short-term recovery), then it's probably worth Bitcoin users
discussing a hard fork to reduce difficulty to a currently sustainable
level.

-Dave


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev