It will help to assume that there is at least one group of evil people who
are investing in Bitcon's demise. Not because there are, but because there
might be. So let's assume they are making a set of a billion transactions,
or a trillion, and maintaining currently-being-legitimately-used hashing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1 on every point, sipa
On 08/02/2015 05:32 PM, Pieter Wuille via bitcoin-dev wrote:
2. Starting date: 30 days after 75% miner support, but not
before 2016-01-12 00:00 UTC
Rationale: A 30-day grace period is given to make sure
>>>
>>> 2. Starting date: 30 days after 75% miner support, but not before
>>> 2016-01-12 00:00 UTC
>>>
>>> Rationale: A 30-day grace period is given to make sure everyone has
>>> enough time to follow. This is a compromise between 14 day in BIP101
>>> and 1 year in BIP103. I tend to agree with BIP101.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am in favor of a more gradual (longer) period and a softforking
solution... that is, more than 30 days of grace period (some period
between 60 days and a year), ...
... and given the number of valid softforking proposals out there it
seems to me tha
Pieter Wuille 於 2015-08-01 16:45 寫到:
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev
wrote:
2. Starting date: 30 days after 75% miner support, but not before
2016-01-12 00:00 UTC
Rationale: A 30-day grace period is given to make sure everyone has
enough time to follow. This is a com
On 8/1/2015 1:45 PM, Pieter Wuille via bitcoin-dev wrote:
>
> Regarding "reasonable", I have a theory. What if we would have had 8
> MB blocks from the start? My guess is that some more people would have
> decided to run their high-transaction-rate use cases on chain, that
> we'd regularly see 4-6
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is a summary of the proposals in my previous mail at
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
> 1. Initiation: BIP34 style voting, with support of
There's a large array of solutions that are bigger than the cheapest home
broadband, but smaller then renting hardware in a data center. Every
company with internet service to their location purchases one of these
options. If Bitcoin full node bandwidth requirements ever exceed a
hobbyist's reach
Here are some books that will help more people understand why Adam's
concern is important:
Kicking the Dragon (by Larken Rose)
The State (by Franz Oppenheimer)
Like he said, it isn't much about bitcoin. Our crypto is just one of the
defenses we've created, and understanding what it defends will h
That's all well and fine. But the pattern of your argument I would
say is "arguing security down" ie saying something is not secure
anyway, nothing is secure, everything could be hacked, so lets forget
that and give up, so that what is left is basically no
decentralisation security.
It is not par
1. Data centers are not some uniform group of businesses with identical
policies nor firms with identical laws applied. The ability to get a search
warrant at a Swedish hosting provider will be dramatically different than a
Singaporean business. Similar to the decentralized nature of bi
Yes, data-center operators are bound to follow laws, including NSLs
and gag orders. How about your ISP? Is it bound to follow laws,
including NSLs and gag orders?
https://edri.org/irish_isp_introduces_blocking/
Do you think everyone should run a full node behind TOR? No way, your
repressive
I think trust the data-center logic obviously fails, and I was talking
about this scenario in the post you are replying to. You are trusting the
data-center operator period. If one could trust data-centers to run
verified code, to not get hacked, filter traffic, respond to court orders
without no
There is a summary of the proposals in my previous mail at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
I think there could be a compromise between Gavin's BIP101 and
Pieter's proposal (called "BIP103" here). Below I'm trying to play
with the parameters, whi
14 matches
Mail list logo
