* [Bitcoin-development] Bitcoin difficulty sanity check suggestion
@ 2013-12-23 3:10 Ryan Carboni
2013-12-23 3:22 ` Mark Friedenbach
0 siblings, 1 reply; 9+ messages in thread
From: Ryan Carboni @ 2013-12-23 3:10 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]
I think Bitcoin should have a sanity check: after three days if only four
blocks have been mined, difficulty should be adjusted downwards.
This might become important in the near future. I project a Bitcoin mining
bubble.
[-- Attachment #2: Type: text/html, Size: 271 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
2013-12-23 3:10 [Bitcoin-development] Bitcoin difficulty sanity check suggestion Ryan Carboni
@ 2013-12-23 3:22 ` Mark Friedenbach
2013-12-23 20:22 ` Robin Ranjit Singh Chauhan
2013-12-24 1:51 ` Ryan Carboni
0 siblings, 2 replies; 9+ messages in thread
From: Mark Friedenbach @ 2013-12-23 3:22 UTC (permalink / raw)
To: Ryan Carboni, Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ryan, these sort of adjustments introduce security risks. If you were
isolated from the main chain by a low-hashpower attacker, how would
you know? They'd need just three days without you noticing that
network block generation has stalled - maybe they wait for a long
weekend - then after that the block rate is normal but completely
controlled by the attacker (and isolated from mainnet).
There are fast acting alternative difficulty adjustment algorithms
being explored by some alts, such as the 9-block interval, 144-block
window, Parks-McClellan FIR filter used by Freicoin to recover from
just such a mining bubble. If it were to happen to bitcoin, there
would be sophisticated alternative to turn to, and enough time to make
the change.
On 12/22/2013 07:10 PM, Ryan Carboni wrote:
> I think Bitcoin should have a sanity check: after three days if
> only four blocks have been mined, difficulty should be adjusted
> downwards.
>
> This might become important in the near future. I project a
> Bitcoin mining bubble.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS
qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb
snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc
oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3
hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS
to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0
02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE
C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ
+0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8
IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr
j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN
DOTF7jpt0ZmCm7uhG9z7
=5Q2H
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
2013-12-23 3:22 ` Mark Friedenbach
@ 2013-12-23 20:22 ` Robin Ranjit Singh Chauhan
2013-12-24 1:51 ` Ryan Carboni
1 sibling, 0 replies; 9+ messages in thread
From: Robin Ranjit Singh Chauhan @ 2013-12-23 20:22 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev, Ryan Carboni
[-- Attachment #1: Type: text/plain, Size: 4343 bytes --]
Mark, thank you for a very clear explanation of why this proposal would be
dangerous.
What I have noted in many discussions regarding blockchain security and
proof-or-work schemes, is there is a wide gulf between those few people who
can clearly reason about it, and those who have a lot trouble with it (I
mostly fall into the later camp).
I wonder if anyone can point to resources who can help "the rest of us"
reason clearly about these types of proposals, prior to bringing them to
this list or a senior dev.
Ideally it would illustrate various past proposals, explain why they would
and wouldnt work, and build up some fundamental concepts, like a "Newtons
laws of blockchain security" that would help us evaluate such ideas on our
own.
Blockchain stuff is often counterintuitive.
On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach <mark@monetize•io> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ryan, these sort of adjustments introduce security risks. If you were
> isolated from the main chain by a low-hashpower attacker, how would
> you know? They'd need just three days without you noticing that
> network block generation has stalled - maybe they wait for a long
> weekend - then after that the block rate is normal but completely
> controlled by the attacker (and isolated from mainnet).
>
> There are fast acting alternative difficulty adjustment algorithms
> being explored by some alts, such as the 9-block interval, 144-block
> window, Parks-McClellan FIR filter used by Freicoin to recover from
> just such a mining bubble. If it were to happen to bitcoin, there
> would be sophisticated alternative to turn to, and enough time to make
> the change.
>
> On 12/22/2013 07:10 PM, Ryan Carboni wrote:
> > I think Bitcoin should have a sanity check: after three days if
> > only four blocks have been mined, difficulty should be adjusted
> > downwards.
> >
> > This might become important in the near future. I project a
> > Bitcoin mining bubble.
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS
> qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb
> snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc
> oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3
> hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS
> to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0
> 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE
> C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ
> +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8
> IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr
> j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN
> DOTF7jpt0ZmCm7uhG9z7
> =5Q2H
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Robin R Chauhan
CEO, Pathway Intelligence Inc
robin@pathwayi•com
Office: 778-588-6217 Ext. 201
Cell: 604-865-0517
Fax: 778-588-1042
http://pathwayi.com/
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information or constitute non-public information. Any use of this
information by anyone other than the intended recipient is prohibited.
If you have received this transmission in error, please immediately
reply to the sender and delete this information from your system.
Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
[-- Attachment #2: Type: text/html, Size: 5836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
2013-12-23 3:22 ` Mark Friedenbach
2013-12-23 20:22 ` Robin Ranjit Singh Chauhan
@ 2013-12-24 1:51 ` Ryan Carboni
2013-12-24 4:05 ` Allen Piscitello
` (2 more replies)
1 sibling, 3 replies; 9+ messages in thread
From: Ryan Carboni @ 2013-12-24 1:51 UTC (permalink / raw)
To: Mark Friedenbach, bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]
I think you misunderstood my statement. If time > 3 days, and after 4
blocks have been mined, then difficulty would be reset.
In theory, one would have to isolate roughly one percent of the Bitcoin
network's hashing power to do so. Which would indicate an attack by a state
actor as opposed to anything else. Arguably, the safest way to run Bitcoin
is through a proprietary dial-up network.
On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach <mark@monetize•io> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ryan, these sort of adjustments introduce security risks. If you were
> isolated from the main chain by a low-hashpower attacker, how would
> you know? They'd need just three days without you noticing that
> network block generation has stalled - maybe they wait for a long
> weekend - then after that the block rate is normal but completely
> controlled by the attacker (and isolated from mainnet).
>
> There are fast acting alternative difficulty adjustment algorithms
> being explored by some alts, such as the 9-block interval, 144-block
> window, Parks-McClellan FIR filter used by Freicoin to recover from
> just such a mining bubble. If it were to happen to bitcoin, there
> would be sophisticated alternative to turn to, and enough time to make
> the change.
>
> On 12/22/2013 07:10 PM, Ryan Carboni wrote:
> > I think Bitcoin should have a sanity check: after three days if
> > only four blocks have been mined, difficulty should be adjusted
> > downwards.
> >
> > This might become important in the near future. I project a
> > Bitcoin mining bubble.
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS
> qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb
> snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc
> oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3
> hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS
> to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0
> 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE
> C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ
> +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8
> IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr
> j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN
> DOTF7jpt0ZmCm7uhG9z7
> =5Q2H
> -----END PGP SIGNATURE-----
>
[-- Attachment #2: Type: text/html, Size: 3196 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
2013-12-24 1:51 ` Ryan Carboni
@ 2013-12-24 4:05 ` Allen Piscitello
2013-12-24 7:41 ` Ryan Carboni
[not found] ` <52B8EB37.2080006@monetize.io>
2013-12-24 8:34 ` Matt Corallo
2 siblings, 1 reply; 9+ messages in thread
From: Allen Piscitello @ 2013-12-24 4:05 UTC (permalink / raw)
To: Ryan Carboni; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]
Ryan,
Why do you continue to try to correct people who clearly have put more
thought into this than you? Everyone understood you just fine, you just
seem to have trouble comprehending why your ideas are terrible.
On Mon, Dec 23, 2013 at 7:51 PM, Ryan Carboni <ryan.jc.pc@gmail•com> wrote:
> I think you misunderstood my statement. If time > 3 days, and after 4
> blocks have been mined, then difficulty would be reset.
>
> In theory, one would have to isolate roughly one percent of the Bitcoin
> network's hashing power to do so. Which would indicate an attack by a state
> actor as opposed to anything else. Arguably, the safest way to run Bitcoin
> is through a proprietary dial-up network.
>
>
> On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach <mark@monetize•io>wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ryan, these sort of adjustments introduce security risks. If you were
>> isolated from the main chain by a low-hashpower attacker, how would
>> you know? They'd need just three days without you noticing that
>> network block generation has stalled - maybe they wait for a long
>> weekend - then after that the block rate is normal but completely
>> controlled by the attacker (and isolated from mainnet).
>>
>> There are fast acting alternative difficulty adjustment algorithms
>> being explored by some alts, such as the 9-block interval, 144-block
>> window, Parks-McClellan FIR filter used by Freicoin to recover from
>> just such a mining bubble. If it were to happen to bitcoin, there
>> would be sophisticated alternative to turn to, and enough time to make
>> the change.
>>
>> On 12/22/2013 07:10 PM, Ryan Carboni wrote:
>> > I think Bitcoin should have a sanity check: after three days if
>> > only four blocks have been mined, difficulty should be adjusted
>> > downwards.
>> >
>> > This might become important in the near future. I project a
>> > Bitcoin mining bubble.
>> >
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.14 (GNU/Linux)
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS
>> qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb
>> snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc
>> oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3
>> hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS
>> to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0
>> 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE
>> C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ
>> +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8
>> IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr
>> j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN
>> DOTF7jpt0ZmCm7uhG9z7
>> =5Q2H
>> -----END PGP SIGNATURE-----
>>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 4845 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
[not found] ` <52B8EB37.2080006@monetize.io>
@ 2013-12-24 7:37 ` Ryan Carboni
0 siblings, 0 replies; 9+ messages in thread
From: Ryan Carboni @ 2013-12-24 7:37 UTC (permalink / raw)
To: Mark Friedenbach, bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
It does take a state-level actor to apparently disconnect *multiple *miners
from the rest of the network.
How many Bitcoin miners hash an entire percent or more of the Bitcoin
network? What you're proposing is an attack at the highest levels of the
internet infrastructure.
On Mon, Dec 23, 2013 at 6:02 PM, Mark Friedenbach <mark@monetize•io> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Which would leave you entirely in the hands of your dialup provider.
> Or the manufacturer of your switch. Or your ISP's backbone provider.
> It does not take a state-level actor to do network attacks.
>
> BTW, what does "difficulty would be reset" mean? There are multiple
> ways to interpret that statement. In the most straightforward way, my
> objections apply.
>
> On 12/23/2013 05:51 PM, Ryan Carboni wrote:
> > I think you misunderstood my statement. If time > 3 days, and after
> > 4 blocks have been mined, then difficulty would be reset.
> >
> > In theory, one would have to isolate roughly one percent of the
> > Bitcoin network's hashing power to do so. Which would indicate an
> > attack by a state actor as opposed to anything else. Arguably, the
> > safest way to run Bitcoin is through a proprietary dial-up
> > network.
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJSuOs3AAoJEAdzVfsmodw4BwAP/0Ynq/SxNIBFFdL7RaSiE5KM
> zNRtlZJCYvmCXgKKtMyO+Ron+YGqY8yg8r0ifb6oqlJCG5t0msExym/CA9CYMV6V
> UnVaGaNkFrLSF1q8Dt6X4I9OSeCiBstahQOjPaerUycLTY2W/cKPblhCC0rvXrfI
> 3Fz3p6SHbCcNHw89w6ry3QG420+UNroFCpNu+Oa2YfWoZY2p91JLbuiUwXL5KEac
> PDskHGsb9q1vyAkCJ6eOp3MJfFP/Dy7mASVwPql/nzf2ceSDtO4dpngo0uNsCwFo
> QSWIRdWv4OiJk1OM6fjEj/51mebczgO0ShczRKk9QkX4FEFEqP/ARdbl8bSC4IsT
> /3s2HHiYDahEOMiXV5ao3kmBpyUR8p4erRbtwRzdZzOgGL37yxj8VGmY93bkVQNB
> zi2n3WCCju0a+gqREyaEFAM8kPIhx9++YNIddwQxK38njUSe2CzqM8t+28ZfseYl
> YnQeNFUfcmvzhxTXxgyoCuGF5HbFRTn/AallkYSPxYtxGq4WuLN36BS3cTv8wCLz
> sYTyuxWxjZ7CS8fx8MWilw72tQf9torwmrWJtjgRLFE3OvQxRjN+ppDV8cfC8UAB
> p0CGzBgVaw5yZ5LzCawQVTGWJdzs+ZPlQu8SO53dHhEtRAmdbFa0mMD2FrS/5Ih/
> YcwdP6Xm69HTgzCenu5F
> =HtRS
> -----END PGP SIGNATURE-----
>
[-- Attachment #2: Type: text/html, Size: 2901 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
2013-12-24 4:05 ` Allen Piscitello
@ 2013-12-24 7:41 ` Ryan Carboni
2013-12-24 7:53 ` Gavin Costin
0 siblings, 1 reply; 9+ messages in thread
From: Ryan Carboni @ 2013-12-24 7:41 UTC (permalink / raw)
To: Allen Piscitello, bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4069 bytes --]
Maybe it's because the arguments being presented are nonsensical and
irrelevant to the current Bitcoin network topology, composed of a small
number of mining pools, not solo miners? Furthermore I think people would
realize that their mining pool has gone "off the reservation" so to speak.
On Mon, Dec 23, 2013 at 8:05 PM, Allen Piscitello <
allen.piscitello@gmail•com> wrote:
> Ryan,
>
> Why do you continue to try to correct people who clearly have put more
> thought into this than you? Everyone understood you just fine, you just
> seem to have trouble comprehending why your ideas are terrible.
>
>
> On Mon, Dec 23, 2013 at 7:51 PM, Ryan Carboni <ryan.jc.pc@gmail•com>wrote:
>
>> I think you misunderstood my statement. If time > 3 days, and after 4
>> blocks have been mined, then difficulty would be reset.
>>
>> In theory, one would have to isolate roughly one percent of the Bitcoin
>> network's hashing power to do so. Which would indicate an attack by a state
>> actor as opposed to anything else. Arguably, the safest way to run Bitcoin
>> is through a proprietary dial-up network.
>>
>>
>> On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach <mark@monetize•io>wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Ryan, these sort of adjustments introduce security risks. If you were
>>> isolated from the main chain by a low-hashpower attacker, how would
>>> you know? They'd need just three days without you noticing that
>>> network block generation has stalled - maybe they wait for a long
>>> weekend - then after that the block rate is normal but completely
>>> controlled by the attacker (and isolated from mainnet).
>>>
>>> There are fast acting alternative difficulty adjustment algorithms
>>> being explored by some alts, such as the 9-block interval, 144-block
>>> window, Parks-McClellan FIR filter used by Freicoin to recover from
>>> just such a mining bubble. If it were to happen to bitcoin, there
>>> would be sophisticated alternative to turn to, and enough time to make
>>> the change.
>>>
>>> On 12/22/2013 07:10 PM, Ryan Carboni wrote:
>>> > I think Bitcoin should have a sanity check: after three days if
>>> > only four blocks have been mined, difficulty should be adjusted
>>> > downwards.
>>> >
>>> > This might become important in the near future. I project a
>>> > Bitcoin mining bubble.
>>> >
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.14 (GNU/Linux)
>>> Comment: GPGTools - http://gpgtools.org
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS
>>> qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb
>>> snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc
>>> oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3
>>> hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS
>>> to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0
>>> 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE
>>> C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ
>>> +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8
>>> IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr
>>> j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN
>>> DOTF7jpt0ZmCm7uhG9z7
>>> =5Q2H
>>> -----END PGP SIGNATURE-----
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 5640 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
2013-12-24 7:41 ` Ryan Carboni
@ 2013-12-24 7:53 ` Gavin Costin
0 siblings, 0 replies; 9+ messages in thread
From: Gavin Costin @ 2013-12-24 7:53 UTC (permalink / raw)
To: Ryan Carboni; +Cc: bitcoin-development
[-- Attachment #1.1: Type: text/plain, Size: 5271 bytes --]
Ryan,
Maybe you could test out your ideas somewhere like bitcointalk.org and/or provide some more technical substance before engaging with this forum.
Developers tend to prefer dealing with numbers known to be either 1 or 0, not a variable set of possible values depending on non-technical factors ...
Gavin
> On 24/12/2013, at 15:42, "Ryan Carboni" <ryan.jc.pc@gmail•com> wrote:
>
> Maybe it's because the arguments being presented are nonsensical and irrelevant to the current Bitcoin network topology, composed of a small number of mining pools, not solo miners? Furthermore I think people would realize that their mining pool has gone "off the reservation" so to speak.
>
>
>> On Mon, Dec 23, 2013 at 8:05 PM, Allen Piscitello <allen.piscitello@gmail•com> wrote:
>> Ryan,
>>
>> Why do you continue to try to correct people who clearly have put more thought into this than you? Everyone understood you just fine, you just seem to have trouble comprehending why your ideas are terrible.
>>
>>
>>> On Mon, Dec 23, 2013 at 7:51 PM, Ryan Carboni <ryan.jc.pc@gmail•com> wrote:
>>> I think you misunderstood my statement. If time > 3 days, and after 4 blocks have been mined, then difficulty would be reset.
>>>
>>> In theory, one would have to isolate roughly one percent of the Bitcoin network's hashing power to do so. Which would indicate an attack by a state actor as opposed to anything else. Arguably, the safest way to run Bitcoin is through a proprietary dial-up network.
>>>
>>>
>>>> On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach <mark@monetize•io> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Ryan, these sort of adjustments introduce security risks. If you were
>>>> isolated from the main chain by a low-hashpower attacker, how would
>>>> you know? They'd need just three days without you noticing that
>>>> network block generation has stalled - maybe they wait for a long
>>>> weekend - then after that the block rate is normal but completely
>>>> controlled by the attacker (and isolated from mainnet).
>>>>
>>>> There are fast acting alternative difficulty adjustment algorithms
>>>> being explored by some alts, such as the 9-block interval, 144-block
>>>> window, Parks-McClellan FIR filter used by Freicoin to recover from
>>>> just such a mining bubble. If it were to happen to bitcoin, there
>>>> would be sophisticated alternative to turn to, and enough time to make
>>>> the change.
>>>>
>>>> On 12/22/2013 07:10 PM, Ryan Carboni wrote:
>>>> > I think Bitcoin should have a sanity check: after three days if
>>>> > only four blocks have been mined, difficulty should be adjusted
>>>> > downwards.
>>>> >
>>>> > This might become important in the near future. I project a
>>>> > Bitcoin mining bubble.
>>>> >
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.14 (GNU/Linux)
>>>> Comment: GPGTools - http://gpgtools.org
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>
>>>> iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS
>>>> qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb
>>>> snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc
>>>> oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3
>>>> hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS
>>>> to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0
>>>> 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE
>>>> C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ
>>>> +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8
>>>> IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr
>>>> j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN
>>>> DOTF7jpt0ZmCm7uhG9z7
>>>> =5Q2H
>>>> -----END PGP SIGNATURE-----
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>> organizations don't have a clear picture of how application performance
>>> affects their revenue. With AppDynamics, you get 100% visibility into your
>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #1.2: Type: text/html, Size: 7498 bytes --]
[-- Attachment #2: Type: text/plain, Size: 455 bytes --]
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
2013-12-24 1:51 ` Ryan Carboni
2013-12-24 4:05 ` Allen Piscitello
[not found] ` <52B8EB37.2080006@monetize.io>
@ 2013-12-24 8:34 ` Matt Corallo
2 siblings, 0 replies; 9+ messages in thread
From: Matt Corallo @ 2013-12-24 8:34 UTC (permalink / raw)
To: bitcoin-development
An attacker with some small hashpower isolates you (as an individual)
from the network by MITMing your network. You just switch the the
attackers chain as if nothing happened because of the network rule
that defines it as OK. Today, you will see that you're behind and warn
the user.
Was it really so hard to write a three-sentence paragraph to clarify
the attack instead of insulting people? Still, posting ideas here
without spending time to ensure you understand the Bitcoin network
well is frowned upon.
Matt
On 12/23/13 17:51, Ryan Carboni wrote:
> I think you misunderstood my statement. If time > 3 days, and after
> 4 blocks have been mined, then difficulty would be reset.
>
> In theory, one would have to isolate roughly one percent of the
> Bitcoin network's hashing power to do so. Which would indicate an
> attack by a state actor as opposed to anything else. Arguably, the
> safest way to run Bitcoin is through a proprietary dial-up
> network.
>
>
> On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach
> <mark@monetize•io <mailto:mark@monetize•io>> wrote:
>
> Ryan, these sort of adjustments introduce security risks. If you
> were isolated from the main chain by a low-hashpower attacker, how
> would you know? They'd need just three days without you noticing
> that network block generation has stalled - maybe they wait for a
> long weekend - then after that the block rate is normal but
> completely controlled by the attacker (and isolated from mainnet).
>
> There are fast acting alternative difficulty adjustment algorithms
> being explored by some alts, such as the 9-block interval,
> 144-block window, Parks-McClellan FIR filter used by Freicoin to
> recover from just such a mining bubble. If it were to happen to
> bitcoin, there would be sophisticated alternative to turn to, and
> enough time to make the change.
>
> On 12/22/2013 07:10 PM, Ryan Carboni wrote:
>> I think Bitcoin should have a sanity check: after three days if
>> only four blocks have been mined, difficulty should be adjusted
>> downwards.
>
>> This might become important in the near future. I project a
>> Bitcoin mining bubble.
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application
> performance affects their revenue. With AppDynamics, you get 100%
> visibility into your Java,.NET, & PHP application. Start your
> 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-12-24 8:35 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-23 3:10 [Bitcoin-development] Bitcoin difficulty sanity check suggestion Ryan Carboni
2013-12-23 3:22 ` Mark Friedenbach
2013-12-23 20:22 ` Robin Ranjit Singh Chauhan
2013-12-24 1:51 ` Ryan Carboni
2013-12-24 4:05 ` Allen Piscitello
2013-12-24 7:41 ` Ryan Carboni
2013-12-24 7:53 ` Gavin Costin
[not found] ` <52B8EB37.2080006@monetize.io>
2013-12-24 7:37 ` Ryan Carboni
2013-12-24 8:34 ` Matt Corallo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox