-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Cameron,
Presumably the "very serious security vulnerability" posed is one of
increased centralization of hash power. Would this danger exist
without the patent risk?
e
On 05/26/2017 01:02 AM, Cameron Garnham via bitcoin-dev wrote:
> Thank you
I rarely post here, out of respect to the mailing list. But since my name
was mentioned...
I much prefer Gregory Maxwell's proposal to defuse covert ASICBOOST (only)
with a segwit-like commitment to the coinbase which does not obligate
miners to signal Segwit or implement Segwit, thus disarming
I agree the date can be brought forward. FWIW, I originally set the date far
out enough that people wouldn't immediately fixate on the date and rather look
at the meat of the proposal instead.
Given that we saw around 70% of nodes upgrade to BIP141 in around 5/6 months, I
dont see any reason
On Friday, 26 May 2017 10:02:27 CEST Cameron Garnham via bitcoin-dev wrote:
> So, I started searching for the motivations of such a large amount of the
> mining hash-rate holding a position that isn’t at-all represented in the
> wider Bitcoin Community. My study of ASICBOOST lead to a ‘bingo’
Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is
something that will simply never happen for basic engineering reasons.
Spoonet, an oft-quoted hard fork that actually has some strong support, is
a much better candidate for the code base - but not of the supposed
supporters
On Friday, 26 May 2017 16:39:30 CEST Erik Aronesty wrote:
> Linking a bit4 MASF with a bit4 "lock in of a hard fork in 6 months" is
> something that will simply never happen for basic engineering reasons.
The modifications to Bitcoin Core would take at most a day to do, plus a week
to test.
I’m
Mandatory signalling is the only way to lock in segwit with less than
95% hashpower without a full redeployment(which for a number of
technical reasons isn't feasible until after the existing segwit
deployment expires). There's no reason not to signal BIP141 bit 1
while also signalling bit 4, but
While I'm not 100% convinced there are strict technical reasons for needing to
wait till after segwit is active before a hard fork can be started (you can,
after all, activate segwit as a part of the HF), there are useful design and
conservatism reasons (not causing massive discontinuity in fee
On Friday, 26 May 2017 23:30:37 CEST James Hilliard via bitcoin-dev wrote:
> It would not be feasible to schedule any HF until one can be
> completely sure BIP141 is active
why?
> Since it is likely a HF will take months of development and testing I
> see this or something similar as the fastest
Forgive me if this is a dumb question. Suppose that rather than directly
activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in just
triggered BIP141 signaling (plus later HF). Would that avoid
incompatibility with existing BIP141 nodes, and get segwit activated
sooner? Eg:
- Bit 4
A more important consideration than segwit's timeout is when code can be
released, which will no doubt be several months after SegWit's current
timeout.
Greg's proposed 6 months seems much more reasonable to me, assuming its
still many months after the formal release of code implementing it.
On Friday, 26 May 2017 19:47:11 CEST Jacob Eliosoff via bitcoin-dev wrote:
> Forgive me if this is a dumb question.
Sorry for picking your email.
I understand people want something different for the agreement, I know I do
too.
We have a specific agreement on the table, signed by a huge
Hello Eric,
Thank you for your question and your time off-list clarifying your position.
I’m posting to the list so that a wider audience may benefit.
Original Question: ‘Presumably the "very serious security vulnerability" posed
is one of increased centralization of hash power. Would this
Your proposal seems to be simply BIP 91 tied to the
as-yet-entirely-undefined hard fork Barry et al proposed.
Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as
you propose, would make the deployment on the incredibly short timeline
Barry et al proposed slightly more
Just to clarify one thing, what I described differs from BIP91 in that
there's no orphaning. Just when Segwit2MB support reaches 80%, those 80%
join everyone else in signaling for BIP141. BIP91 orphaning is an optional
addition but my guess is it wouldn't be needed.
On May 26, 2017 4:02 PM,
Thank you for your reply Andreas,
I can assure you that I have many motivations for activating SegWit.
Before studding ASICBOOST I wanted to activate SegWit as it is a wonderful
upgrade for Bitcoin. It seems to me that virtually the entire Bitcoin Ecosystem
agrees with me. Except for around
16 matches
Mail list logo
