On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote:
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, i
On Fri, Dec 18, 2015 at 10:47:14AM +0800, Jonathan Toomim via bitcoin-dev wrote:
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
> wrote:
> > 1) The risk of an old full node wallet accepting a transaction that is
> > invalid to the new rules.
> > The receiver wallet chooses what add
To me it's getting clearer and clearer that th frintier between
softforks and hardforks it's softer than we thought.
Aoftforks should start having a minimum median time deplayment day (be
it height or median time, I don't care, just not header.nTime).
TYDGFHdfthfg64565$%^$
On Fri, Dec 18, 2015 at
On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev
wrote:
> If Bitcoin remains decentralized, miners have veto power over any
> blocksize increases. You can always soft-fork in a blocksize reduction
> in a decentralized blockchain that actually works.
You can always schism hardfork miner
On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille
wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > t
Jonathan Toomim via bitcoin-dev 於 2015-12-17 21:47 寫到:
Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
runs the old rules. Bob creates a p2pkh address for Mallory to use.
Mallory takes 1 BTC, and creates an invalid SegWit transaction that
Bob cannot properly validate and that
First of all, that's an expensive beer!
Second of all, any consensus rule change risks non-full-validating or
non-upgraded nodes seeing invalid confirmations...but assuming a large
supermajority (i.e. > 95%) of hashing power is behind the new rule, it
is extremely unlikely that very many inval
On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev
wrote:
> 1) The risk of an old full node wallet accepting a transaction that is
> invalid to the new rules.
>
> The receiver wallet chooses what address/script to accept coins on.
> They'll upgrade to the new softfork rules before cre
Hello all,
For a long time, I was personally of the opinion that soft forks
constituted a mild security reduction for old full nodes, albeit one
that was preferable to hard forks due to being far less risky, easier,
and less forceful to deploy.
After thinking more about this, I'm not convinced th
While it is interesting to contemplate moving to a world with
hard-fork only upgrades (deprecate soft-forks), now is possibly not
the time to consider that. Someone can take that topic and make a
what-if sketch for how it could work and put it on the wishlist wiki
if its not already there.
We wan
Doesn't a good soft fork signaling mechanism along with an activation warning
system for non-upgraded nodes (i.e. BIP9, or even block version ISM for that
matter) essentially fix this? I don't quite get why this should be an issue.
On December 17, 2015 10:52:39 AM PST, Jeff Garzik via bitcoin-de
On Thu, Dec 17, 2015 at 04:58:02PM +, Tier Nolan via bitcoin-dev wrote:
> This is really the most important question.
>
> Bitcoin is kind of like a republic where there is separation of powers
> between various groups.
>
> The power blocs in the process include
>
> - Core Devs
> - Miners
> -
This is not correct.
As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
are less secure than others? I don't think so. Since one invalid CLTV tx
will make the whole block invalid. Having more nodes to fully validate
non-CLTV txs won't make them any safer. The same logic a
On Thu, Dec 17, 2015 at 1:46 PM, jl2012 wrote:
> This is not correct.
>
> As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
> are less secure than others? I don't think so. Since one invalid CLTV tx
> will make the whole block invalid. Having more nodes to fully validate
>
On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik wrote:
> SW presents a blended price and blended basket of two goods. You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
> A different set o
On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev wrote:
> On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote:
> > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> > equivalent to the 2-4-8 "compromise" proposal [...]
> isn't SegWit gain ~75%? hence 2mb x
On Wed, Dec 16, 2015 at 9:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> We are not avoiding a choice. We don't have the authority to make a choice.
>
This is really the most important question.
Bitcoin is kind of like a republic where there is separation
On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
> equivalent to the 2-4-8 "compromise" proposal (which by the way I never
> liked, because I don't think anybody should be in a po
Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
tha
A planned hardfork, similar to certain softforks, leaves users with some
reduction in security. It does not leave them defenseless. Consider the
following:
1: Hard to be robbed on the basis of hashpower.
In reality the old chain will see mining all but stop, and blocks would be
hours to days ap
On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> A large part of your argument is that SW will take longer to deploy than a
> hard fork, but I completely disagree. Though I do not agree with some
> people claiming we can deploy SW sig
On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik wrote:
> >> You present this as if the Bitcoin Core development team is in charge
> >> of deciding the network consensus rules, and is res
I know my reply is a long one but please read before you hit send. I
have 2 proposals: fast BIP102 + slow SWSF and fast SWSF only. I guess no
one here is arguing for not doing segwit; and it is on the top of my
wish list. My main argument (maybe also Jeff's) is that segwit is too
complicated an
Maybe we should first gather concrete estimates about and roughly agree on
- how long SW (SF) development will probably take
- how long the ecosystem needs to prepare for a hardfork (SW (HF) or a
simple can kicking block size increase)
Opinions differ wildly from what it looks like, but maybe we
On Thu, Dec 17, 2015 at 12:32:11AM -0500, jl2012 via bitcoin-dev wrote:
> There are at least 2 proposals on the table:
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
>equals to 2MB actual limit
> 2. BIP102: 2MB actual limit
I think there's a few variants of (2) -- the
There are many reasons to support segwit beyond it being a soft-fork. For
example:
* the limitation of non-witness data to no more than 1MB makes the
quadratic scaling costs in large transaction validation no worse than they
currently are;
* redeem scripts in witness use a more accurate cost accou
26 matches
Mail list logo
