Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón via bitcoin-dev]

On Thu, Aug 20, 2015 at 3:00 AM, GC  wrote:
> Can this anecdote and similar be removed from the mailing list.
>
> Possibly one of the reddits is a better place for this kind of thing.

I should have posted that just on libbitcoin but not in bitcoin-dev.
My apologies.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[GC via bitcoin-dev]

Can this anecdote and similar be removed from the mailing list.

Possibly one of the reddits is a better place for this kind of thing.

On 20/8/15 7:56 am, "Jorge Timón via bitcoin-dev"
 wrote:

>By the way, now that I remember why I subscribed to the libbitcoin
>list I want to share it with you.
>I met Amir Taaki in person in a spanish hackmeeting and had the chance
>to talk a lot with him, very interesting person whose input in this
>blocksize matter I would greatly appreciate. He explained some of his
>concerns with Bitcoin Core (Bitcoin-qt at the time) and he
>specifically named 2 persons: Mike Hearn and Gavin Andresen. If I
>remember correctly, Hearn had recently proposed a blacklisting scheme
>for Bitcoin.
>
>I remember I said something along the lines:
>"Mike Hearn has certainly proposed some nasty things but I don't think
>other devs will ever accept that kind of changes in Bitcoin-qt.
>Regarding Gavin, I believe he is someone that can be trusted even if
>he visited the CIA. If anything, I think he is overly conservative
>about some changes, but that's very understandable given how fragile
>Bitcoin is (specially at this early stage)".
>
>Looking back, I now realize that his concerns were not exaggerated at
>all and I was clearly wrong thinking Gavin was overly conservative.
>He was also worried about the payment protocol and we agreed to
>disagree there (maybe I should read all the payment protocol stuff
>more deeply).
>
>I don't want this to be taken as an argument of authority "Mike and
>Gavin cannot be trusted because Amir didn't trust them", just as a
>curious anecdote.
>Amir, I wouldn't like to put words in your mouth: that's why I cc'ed
>you so you can correct me in case my memory is failing.
>___
>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] Libconsensus separated repository (was Bitcoin Core and hard forks)

[Jorge Timón via bitcoin-dev]

Moving it here from the other thread.

On Thu, Aug 20, 2015 at 2:08 AM, Eric Voskuil  wrote:
> On 08/19/2015 04:27 PM, Jorge Timón wrote:
>> No, as previously explained, once libconsensus is complete it can be
>> moved to a separate repository like libsecp256k1.
>
> I don't see this happening any time soon, and I'm not sure why we should
> wait for it.

Yes, unfortunately I don't see this happening any time soon either, at
least not with the amount of review I'm getting.
My initial hope was to complete libconsensus by 0.12 (one year should
be enough time, right?) but I was being too optimistic.
By "wait for it" I assume you mean waiting for libconsensus to be
complete before we separate it to a different repository.
The reason is just simplicity.

>>> In our discussion leading up to libbitcoin building libbitcoin-consensus
>>> we disagreed on whether intentional hard forks would (or even could)
>>> happen. I think that issue is now settled. So my question remains how do
>>> stakeholders (users/miners) maintain consensus when it's their
>>> individual intent (the first objective of libconsensus), and diverge
>>> when intended (which a direct dependency on libconsensus makes harder)?
>>> IMO it's unreasonable to operate as if this won't happen, given that it has.
>>
>> I believe the simplest option...
>
> You might consider this as feedback from your customer base.

Mhmm, not sure I understand this point.

>> would be to fork the libconsensus
>> project and do the schism/controversial/contentious hardfork there.
>> But of course modifying libconsensus will be much easier than
>> modifying Bitcoin Core (if anything, because the amount of code is
>> much smaller).
>
> That's a false dichotomy. We never would have considered forking Bitcoin
> Core, and still wouldn't. Why would we set ourselves up for this
> disruption, which would inevitably lead to us factoring the consensus
> portions of libconsensus out of /bitcoin at the 11th hour?
>
> We have to operate as if it can happen at any time. Otherwise we have
> relinquished control of this vote and failed our users. Given that
> operating assumption, it is much safer for us to have already done this
> work (which we did). [It also provides a forcing function for us to
> review in detail any consensus changes that get pushed out.]

Yes, you need to operate as if it can happen at any time. I now
understandbetter  your position of having your own repository until a
complete libconsensus is separated.
In the meantime you will have to keep using your re-implementation of
the rest of the consensus rules (besides the script checks), but
fortunately the most risky and harder reimplementation is the part of
the script validation.

> My question is why you would not embrace an independent consensus
> repository? Your work to evolve it doesn't change.

Yes, I want a separated repository. I just wanted to start with a
separated folder first. Right now there's consensus code all over the
place, specially in main.cpp.
I think changing the order (separated repository first, moving code
from Bitcoin Core to libconsensus later) would increase the total
amount of work.

Here's another option that has recently crossed my mind:

1) Finish the libconsensus separation in an independent branch on top
of a given version, for example 0.11.
2) Separate a repository from that. Alternative implementations can
start using a full libconsensus
3) Rebase that branch on top of bitcoin/master and start to PR small
groups of commits. Once the whole branch has been merged, Bitcoin Core
can replace the consensus folder with the libconsensus subtree, so
that Bitcoin Core itself can start using a full libconsensus.

Ironically with this plan Bitcoin Core may not be the full node first
implementation to use a full libconsensus.
There will be some consensus fork bug risks during 3 (which at the
current speed I estimate it could easily take 3 or 4 years) and there
would be some redundant work (replicating every consensus change in
both Bitcoin Core and libconsensus).
On the bright side, we may be able to have a full libconsensus this
year (which was my goal after we exposed VerifyScript in the first
libconsensus).

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

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Bryan Bishop via bitcoin-dev]

On Wed, Aug 19, 2015 at 3:59 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
> But technical people run away from noise while non-technical people
> chase them wherever their voices sounds more loud.
>

FWIW, and I mentioned this opinion in #bitcoin-dev on IRC, but I am
perfectly fine with receiving everything through a single mailing list. I
used to read the Wikipedia firehose of recent edits because I thought
that's how you were supposed to use the site. Edits per second eventually
reached beyond any reasonable estimate of human capacity and then I
realized what was going on. Any sort of "glorious future" for bitcoin with
hundreds of millions of users will also see this problem for future
developers, even if only 0.1% of that population are money-interested
programmers then that's 100,000 programmers to work with. I would never
want to turn off this raw feed. Having said that, I am somewhat surprise
that nobody has taken to weekly summaries of research and development
activity. Summarizing recent work is a valuable task that others can engage
in just by reading the mailing list and aggregating multiple thoughts
together, similar to release notes. I was also expecting to see something
like "individual developer's summaries of things they have found
interesting over the past 30-90 days or past year" digging up arcane
details from the mailing list archives, or more infrequent summaries of the
other smaller batched review emails. Digest mode mailing list consumption
is often recommended to those who are uninterested in dealing with low
signal-to-noise, but I suspect that summarizing activity would be more
valuable for this community, especially for the different cognitive niches
that have developed.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Jorge Timón via bitcoin-dev]

On Thu, Aug 20, 2015 at 1:44 AM, NxtChg via bitcoin-dev
 wrote:
> Number of posts, August:
>
> 72, Jorge Timón

Certainly I have talked to much this month, my apologies.
I believe most of my posts (if not all) were on-topic but I could
still had repeated myself much less.
I've been trying to concentrate my usual points in documents or
threads that I can link to so that my comments can be shorter.
But, yes, most of my posts have been related to general consensus
topics and not specific to Bitcoin Core development (that's part of
why I think the bitcoin-consensus and bitcoin-dev lists would be a
good separation).
In any case, my apologies for this unplanned record.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Voskuil via bitcoin-dev]

On 08/19/2015 04:27 PM, Jorge Timón wrote:
> On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil  wrote:
>> [cross-posted to libbitcoin]
>>
>> On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
>> 19, 2015 at 10:04 PM, Eric Lombrozo  wrote:
 But the consensus code should NOT be subject to the same commit
>> policies…and we should make an effort to separate the two clearly. And
>> we should find a way to communicate the difference succinctly and
>> clearly to laypeople (which is something I think the XT opponents have
>> been horrible at doing so far).
>>>
>>> I think that effort is in progress (again, much slower that I would
>>> like it to be) and it's called libconsensus.
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation (even if it is the reference one) and it's not "the
>>> specification of the consensus rules" which is a "privileged" position
>>> that brings all sorts of misunderstandings and problems (the block
>>> size debate is just one example).
>>
>> Jorge,
>>
>> I applaud your efforts and objectives WRT libconsensus independence. But
>> as you know I differ with you on this point:
>>
>>> Once we have libconsensus Bitcoin Core it's just another
>>> implementation
>>
>> I do not consider Bitcoin Core just another implementation as long as
>> libconsensus is built directly out of the bitcoind repository. It's a
>> finer point, but an important one. Eric makes this point emphatically as
>> well:
>>
 But the consensus code should NOT be subject to the same commit
>> policies...and we should make an effort to separate the two clearly.
>>
>> As you have implied, it's not likely to happen in the Bitcoin Core repo.
>> Taking a dependency on Bitcoin Core is a metaphorical deal with the
>> devil from our perspective. So my question is, how do you expect other
>> implementations to transition off of that repository (and commit
>> policies)? Or do you expect the dependency to be perpetual?
> 
> No, as previously explained, once libconsensus is complete it can be
> moved to a separate repository like libsecp256k1.

I don't see this happening any time soon, and I'm not sure why we should
wait for it.

> At first it will need to be a subtree/subrepository of Bitcoin Core
> (like libsecp256k1 currently is), but I still don't undesrtand how
> that can possibly be a problem for alternative implementations (they
> can use a subtree as well if they want to). Depending on a separated
> libconsensus doesn't "make Bitcoin Core a dependency" more than
> depending on libsecp256k1 currently does.
>
>> In our discussion leading up to libbitcoin building libbitcoin-consensus
>> we disagreed on whether intentional hard forks would (or even could)
>> happen. I think that issue is now settled. So my question remains how do
>> stakeholders (users/miners) maintain consensus when it's their
>> individual intent (the first objective of libconsensus), and diverge
>> when intended (which a direct dependency on libconsensus makes harder)?
>> IMO it's unreasonable to operate as if this won't happen, given that it has.
> 
> I believe the simplest option...

You might consider this as feedback from your customer base.

> would be to fork the libconsensus
> project and do the schism/controversial/contentious hardfork there.
> But of course modifying libconsensus will be much easier than
> modifying Bitcoin Core (if anything, because the amount of code is
> much smaller).

That's a false dichotomy. We never would have considered forking Bitcoin
Core, and still wouldn't. Why would we set ourselves up for this
disruption, which would inevitably lead to us factoring the consensus
portions of libconsensus out of /bitcoin at the 11th hour?

We have to operate as if it can happen at any time. Otherwise we have
relinquished control of this vote and failed our users. Given that
operating assumption, it is much safer for us to have already done this
work (which we did). [It also provides a forcing function for us to
review in detail any consensus changes that get pushed out.]

My question is why you would not embrace an independent consensus
repository? Your work to evolve it doesn't change.

>> There are a very small number of implementations that rely on consensus
>> (fewer that aren't also forks of Bitcoin Core). I think it's time we
>> discuss how to work together to achieve our mutual goal. I assume you
>> have been in contact with all of us. If you would like to facilitate
>> this I'd be happy to join in an offline discussion.
> 
> Unfortunately I only directly contacted libbitcoin because I was
> subscribed to the list at the time (maybe I'm still subscribed, not
> really sure).
> The other attempts to get feedback from other alternative
> implementations have been just mostly-ignored threads in bitcoin-dev.
> So, no, I cannot facilitate such a discussion, but I'm more than happy
> to collaborate to achieve our mutual goal.

OK

e
___
bitcoin-de

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón via bitcoin-dev]

By the way, now that I remember why I subscribed to the libbitcoin
list I want to share it with you.
I met Amir Taaki in person in a spanish hackmeeting and had the chance
to talk a lot with him, very interesting person whose input in this
blocksize matter I would greatly appreciate. He explained some of his
concerns with Bitcoin Core (Bitcoin-qt at the time) and he
specifically named 2 persons: Mike Hearn and Gavin Andresen. If I
remember correctly, Hearn had recently proposed a blacklisting scheme
for Bitcoin.

I remember I said something along the lines:
"Mike Hearn has certainly proposed some nasty things but I don't think
other devs will ever accept that kind of changes in Bitcoin-qt.
Regarding Gavin, I believe he is someone that can be trusted even if
he visited the CIA. If anything, I think he is overly conservative
about some changes, but that's very understandable given how fragile
Bitcoin is (specially at this early stage)".

Looking back, I now realize that his concerns were not exaggerated at
all and I was clearly wrong thinking Gavin was overly conservative.
He was also worried about the payment protocol and we agreed to
disagree there (maybe I should read all the payment protocol stuff
more deeply).

I don't want this to be taken as an argument of authority "Mike and
Gavin cannot be trusted because Amir didn't trust them", just as a
curious anecdote.
Amir, I wouldn't like to put words in your mouth: that's why I cc'ed
you so you can correct me in case my memory is failing.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[NxtChg via bitcoin-dev]

>I guess every mailing list should have its own internal SNR discussions.

Number of posts, August:

72, Jorge Timón
36, Hector Chu
32, Thomas Zander
27, Pieter Wuille
24, Eric Lombrozo
23, Mark Friedenbach
18, Adam Back
18, Btc Drak
18, Peter Todd
17, jl2012 
16, odinn
15, Gavin Andresen
12, Venzen Khaosan
12, Michael Naber
11, Anthony Towns
10, Tom Harding
10, Gregory Maxwell

Everybody else less than 10.

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

Re: [bitcoin-dev] Bitcoin XT Fork

[Simon Liu via bitcoin-dev]

Yes, you're right, the Bitcoin Foundation is facing many challenges, but
that's an entirely different discussion.

The question in hand is this: was the request to remove Gavin made by an
individual of their own volition, reflecting their own personal opinion,
or was it made on behalf of the company?

If the latter, it would imply that compromise is unlikely to be reached
and thus the ecosystem should start planning immediately for the
potential hard fork, rather than waiting and hoping for things to be
resolved.


On 08/19/2015 11:13 AM, Peter Todd wrote:
> On Wed, Aug 19, 2015 at 10:22:32AM -0700, Simon Liu via bitcoin-dev wrote:
>> Olivier Janssens claims that one of your colleagues is asking for Gavin
>> to be removed from his position.  Is this true?
>>
>> https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence
>>
>> http://pastebin.com/q2TT58Z5
> 
> IMO that's a very reasonable request; lately I've spent a lot of time
> having to educate journalists on how Bitcoin doesn't have a "chief
> scientist" with any kind of authority. Having Gavin Andresen in that
> position at the otherwise inactive and bankrupt Bitcoin Foundation
> misleads the public about the true nature of how Bitcoin operates,
> giving a misleading impression that it has the same centralized decision
> making as conventional financial systems do. Among other things, this
> harms the reputation of Bitcoin as a whole as it can confuse the public
> into thinking there aren't major differences between Bitcoin and those
> conventional financial systems.
> 
> As the email said "Regardless of your personal view on XT this is bad
> for bitcoin." - a statement I agree with 100%
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón via bitcoin-dev]

On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil  wrote:
> [cross-posted to libbitcoin]
>
> On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
> 19, 2015 at 10:04 PM, Eric Lombrozo  wrote:
>>> But the consensus code should NOT be subject to the same commit
> policies…and we should make an effort to separate the two clearly. And
> we should find a way to communicate the difference succinctly and
> clearly to laypeople (which is something I think the XT opponents have
> been horrible at doing so far).
>>
>> I think that effort is in progress (again, much slower that I would
>> like it to be) and it's called libconsensus.
>> Once we have libconsensus Bitcoin Core it's just another
>> implementation (even if it is the reference one) and it's not "the
>> specification of the consensus rules" which is a "privileged" position
>> that brings all sorts of misunderstandings and problems (the block
>> size debate is just one example).
>
> Jorge,
>
> I applaud your efforts and objectives WRT libconsensus independence. But
> as you know I differ with you on this point:
>
>> Once we have libconsensus Bitcoin Core it's just another
>> implementation
>
> I do not consider Bitcoin Core just another implementation as long as
> libconsensus is built directly out of the bitcoind repository. It's a
> finer point, but an important one. Eric makes this point emphatically as
> well:
>
>>> But the consensus code should NOT be subject to the same commit
> policies...and we should make an effort to separate the two clearly.
>
> As you have implied, it's not likely to happen in the Bitcoin Core repo.
> Taking a dependency on Bitcoin Core is a metaphorical deal with the
> devil from our perspective. So my question is, how do you expect other
> implementations to transition off of that repository (and commit
> policies)? Or do you expect the dependency to be perpetual?

No, as previously explained, once libconsensus is complete it can be
moved to a separate repository like libsecp256k1.
At first it will need to be a subtree/subrepository of Bitcoin Core
(like libsecp256k1 currently is), but I still don't undesrtand how
that can possibly be a problem for alternative implementations (they
can use a subtree as well if they want to). Depending on a separated
libconsensus doesn't "make Bitcoin Core a dependency" more than
depending on libsecp256k1 currently does.

> In our discussion leading up to libbitcoin building libbitcoin-consensus
> we disagreed on whether intentional hard forks would (or even could)
> happen. I think that issue is now settled. So my question remains how do
> stakeholders (users/miners) maintain consensus when it's their
> individual intent (the first objective of libconsensus), and diverge
> when intended (which a direct dependency on libconsensus makes harder)?
> IMO it's unreasonable to operate as if this won't happen, given that it has.

I believe the simplest option would be to fork the libconsensus
project and do the schism/controversial/contentious hardfork there.
But of course modifying libconsensus will be much easier than
modifying Bitcoin Core (if anything, because the amount of code is
much smaller).

> There are a very small number of implementations that rely on consensus
> (fewer that aren't also forks of Bitcoin Core). I think it's time we
> discuss how to work together to achieve our mutual goal. I assume you
> have been in contact with all of us. If you would like to facilitate
> this I'd be happy to join in an offline discussion.

Unfortunately I only directly contacted libbitcoin because I was
subscribed to the list at the time (maybe I'm still subscribed, not
really sure).
The other attempts to get feedback from other alternative
implementations have been just mostly-ignored threads in bitcoin-dev.
So, no, I cannot facilitate such a discussion, but I'm more than happy
to collaborate to achieve our mutual goal.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Peter Todd via bitcoin-dev]

On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote:
> Wouldnt the experience for SPV nodes be chaotic?  If the full nodes
> are 50:50 XT and bitcoin core, then SPV clients would connect at
> random and because XT and core will diverge immediately after
> activation.

Actually not necessarily!

To my knowledge there aren't any SPV implementations that do address
caching; they all use the peer servers in a centralized fashion every
time they connect. If those peer servers are setup to only return nodes
on one side of the fork or the other, that's all they'll connect too and
they'll never see another chain.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


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

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Dave Scotese via bitcoin-dev]

I guess every mailing list should have its own internal SNR discussions.

My answer is to respond when something is off-topic and offer a different
place for the topic.  I haven't been doing that, partly because no one else
has, but mostly because I figured I don't have a strong handle on what is
off-topic and what isn't.  Let's all start doing that.  Of course, someone
can object to the claim, "No, I don't think this is off-topic... blah blah
blah," and people can respond.  The norms will develop.  It just requires
some relative humility, courage, and honesty.

On Wed, Aug 19, 2015 at 12:28 PM, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> FYI, a few developers including Wladimir, Greg, Peter Todd, Pieter, and
> Alex Morcos have been discussing what to do about improving the signal
> noise ratio on bitcoin-dev list.  One proposal similar to this discussion
> was to split it into multiple mailing lists.  It was pointed out that the
> less technical Bitcoin discussion list already existed in the past and
> nobody used it.  Generally the discussion went away from creating yet
> another mailing list and toward instituting an on-topic guidelines for
> bitcoin-dev.  Gavin, Wladimir, and a few of the others agreed to a simple
> few paragraphs written by Alex Morcos.  IIRC Wladimir agreed to post it.
> Has it been posted yet?
>
> On Wed, Aug 19, 2015 at 11:47 AM, Btc Drak via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik  wrote:
>> > bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
>> > discussion?
>>
>> Well -dev or both, I dont particularly see a difference at the moment,
>> and establishing two lists isnt really going to make a difference so
>> long as Bitcoin Core is the reference client, which it is by defacto.
>> The risk of having too many lists is interested stakeholders will miss
>> a discussions. Normal protocol and core discussions are usually pretty
>> low volume in any case.
>>
>> > As Jorge notes, a general discussion list has existed for a long time
>> with
>> > little use.
>>
>> I would suggest it's only because there havent been any rules for -dev
>> that would force general discussion over to the bitcoin list. On IRC
>> we regularly tell people in #bitcoin-dev they are OT and ask them to
>> move to #bitcoin and as a result, -dev remains quite clear of chit
>> chat, #bitcoin has a steady stream of general chatter.
>>
>> We could reduce the OT/noise of bitcoin-dev list considerably by
>> offloading the non-technical/academic debate to the bitcoin list. It
>> just needs a bit of shepherding. I am more than happy to help out.
>> Especially if the list already exists, we should consider making a
>> decision now.
>>
>> Who are the moderators for that list? Do we really want to use
>> sourceforge or are there alternatives, like another list on
>> linuxfoundation?
>>
>> ping @Warren.
>> ___
>> 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] bitcoin-dev list etiquette

[Jorge Timón via bitcoin-dev]

On Thu, Aug 20, 2015 at 12:25 AM, Gary Mulder via bitcoin-dev
 wrote:
> So guys, do we need a BIP to address the existence of XT and its possible
> impact to the block chain?

The potential impacts of Schism/controversial/contentious hardforks
are shortly covered in
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
It is still a BIP draft so improvements are welcomed.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Voskuil via bitcoin-dev]

[cross-posted to libbitcoin]

On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote:> On Wed, Aug
19, 2015 at 10:04 PM, Eric Lombrozo  wrote:
>> But the consensus code should NOT be subject to the same commit
policies…and we should make an effort to separate the two clearly. And
we should find a way to communicate the difference succinctly and
clearly to laypeople (which is something I think the XT opponents have
been horrible at doing so far).
>
> I think that effort is in progress (again, much slower that I would
> like it to be) and it's called libconsensus.
> Once we have libconsensus Bitcoin Core it's just another
> implementation (even if it is the reference one) and it's not "the
> specification of the consensus rules" which is a "privileged" position
> that brings all sorts of misunderstandings and problems (the block
> size debate is just one example).

Jorge,

I applaud your efforts and objectives WRT libconsensus independence. But
as you know I differ with you on this point:

> Once we have libconsensus Bitcoin Core it's just another
> implementation

I do not consider Bitcoin Core just another implementation as long as
libconsensus is built directly out of the bitcoind repository. It's a
finer point, but an important one. Eric makes this point emphatically as
well:

>> But the consensus code should NOT be subject to the same commit
policies...and we should make an effort to separate the two clearly.

As you have implied, it's not likely to happen in the Bitcoin Core repo.
Taking a dependency on Bitcoin Core is a metaphorical deal with the
devil from our perspective. So my question is, how do you expect other
implementations to transition off of that repository (and commit
policies)? Or do you expect the dependency to be perpetual?

In our discussion leading up to libbitcoin building libbitcoin-consensus
we disagreed on whether intentional hard forks would (or even could)
happen. I think that issue is now settled. So my question remains how do
stakeholders (users/miners) maintain consensus when it's their
individual intent (the first objective of libconsensus), and diverge
when intended (which a direct dependency on libconsensus makes harder)?
IMO it's unreasonable to operate as if this won't happen, given that it has.

There are a very small number of implementations that rely on consensus
(fewer that aren't also forks of Bitcoin Core). I think it's time we
discuss how to work together to achieve our mutual goal. I assume you
have been in contact with all of us. If you would like to facilitate
this I'd be happy to join in an offline discussion.

e



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

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 11:25 PM, Gary Mulder via bitcoin-dev
 wrote:
> So guys, do we need a BIP to address the existence of XT and its possible
> impact to the block chain?

I believe there is BIP99 that addresses hard forks.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Adam Back via bitcoin-dev]

Wouldnt the experience for SPV nodes be chaotic?  If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.

Adam


On 19 August 2015 at 15:28, Jorge Timón
 wrote:
> On Wed, Aug 19, 2015 at 5:41 PM, s7r  wrote:
>> Hello Jorge, Eric,
>>
>> With all this noise on the -dev mail list I had to implement application
>> level filters so I can treat with priority posts from certain people,
>> you are on that list. While I agree with your arguments, I think it is
>> _very_ important to highlight some things. I am neither for the
>> blocksize increase neither against it, because plain and simple I don't
>> have enough arguments to take some definitive decision on this topic.
>
> I think everyone is in that position (we just don't have enough data
> about the proposed sizes) or it's just too optimistic.
>
>> What I am angry about is spreading FUD that a fork could kill Bitcoin
>> and what we are experiencing now is somehow terrible.
>>
>> 1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
>> split it into 2 different coins. It is the result of an open source free
>> system which lacks centralization. It is just at early stage, it could
>> have thousands for forks (or fork attempts) during its life.
>
> Bitcoin XT is just a software fork and nobody seem to have a problem
> with that (as repeated in other threads), people are worried about the
> way bip101 is going to be attempted to be deployed using Bitcoin XT.
> We already have more than 5000 software forks and that's totally fine.
>
> A Schism fork may not kill Bitcoin but it will certainly create 2
> different coins.
> The claim that "there will be a winner and everybody will just move
> there" is incredibly naive and uninformative.
> Many people will sell their xtbtc and reject the hardfork
> independently of its support by miners.
> Nobody knows what the result will be, but both currencies' prices
> dropping near zero is certainly a possibility that Gavin and Mike are
> not aware about or are not informing their followers about.
> Here's something a little bit longer about this topic:
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
> Note the last part:
>
> "
> +This is very disruptive and hopefully will never be needed. But if
> +it's needed the best deployment path is just to activate the rule
> +changes after certain block height in the future. On the other hand,
> +it is healthy decentralization-wise that many independent software
> +projects are ready to deploy a schism hardfork.
> "
>
>> 2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
>> something bad to Bitcoin. So far everything they have done is (or should
>> be) allowed. They have forked an open source software and implemented a
>> voting system for a consensus rule change - doesn't sound like they are
>> committing a crime here (either legally or morally). If they are
>> qualified enough to maintain the software, or if the decision is
>> technically correct or not is another story, and it should only matter
>> to whoever uses / wants to use -XT.
>
> Again, no problem with the code fork, but the Schism hardfork is very
> risky regardless of their intentions.
>
>> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
>> just by 2 people forking the software and submitting a consensus rule to
>> a vote, it means Bitcoin is dead already and it should be worthless! We
>> can't go around and panic every time somebody forks Bitcoin and tries to
>> change something - this should be allowed by the nature of its license.
>> If tomorrow 5 more people fork 5 different software implementing the
>> bitcoin protocol and submit 5 different new consensus rules to a vote,
>> then what? We should all sell so the price will drop to 1 cent, because
>> it is somehow not good enough, not stable enough?
>
> If they don't extensively lobby Bitcoin companies, they don't start a
> massive PR campaign labbeling other developers as "obstructionists"
> and don't misinform a big part of the Bitcoin users (often using
> logical fallacies, intentionally or not), probably those 5 new
> currencies will be ignored and nothing bad will happen.
> Unfortunately in this case a great division between users is being created.
>
>> I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
>> block in the future spends all the longest dusted coins to me, out of
>> which I give away 50% to the miners (so the hashing power will have
>> incentive to use my fork).
>>
>> Can they do it? YES
>> Will they do it? NO
>> Should the world care about this? NO
>>
>> It's as simple as that. We cannot continue to panic that "Bitcoin as a
>> project" is at threat because somebody forked it.
>
> Can you please stop conflating "Bitcoin Core as a project" and
> "Bitcoin consensus rules".
> They are different things and nobody is or can be "in charge" 

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 5:41 PM, s7r  wrote:
> Hello Jorge, Eric,
>
> With all this noise on the -dev mail list I had to implement application
> level filters so I can treat with priority posts from certain people,
> you are on that list. While I agree with your arguments, I think it is
> _very_ important to highlight some things. I am neither for the
> blocksize increase neither against it, because plain and simple I don't
> have enough arguments to take some definitive decision on this topic.

I think everyone is in that position (we just don't have enough data
about the proposed sizes) or it's just too optimistic.

> What I am angry about is spreading FUD that a fork could kill Bitcoin
> and what we are experiencing now is somehow terrible.
>
> 1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
> split it into 2 different coins. It is the result of an open source free
> system which lacks centralization. It is just at early stage, it could
> have thousands for forks (or fork attempts) during its life.

Bitcoin XT is just a software fork and nobody seem to have a problem
with that (as repeated in other threads), people are worried about the
way bip101 is going to be attempted to be deployed using Bitcoin XT.
We already have more than 5000 software forks and that's totally fine.

A Schism fork may not kill Bitcoin but it will certainly create 2
different coins.
The claim that "there will be a winner and everybody will just move
there" is incredibly naive and uninformative.
Many people will sell their xtbtc and reject the hardfork
independently of its support by miners.
Nobody knows what the result will be, but both currencies' prices
dropping near zero is certainly a possibility that Gavin and Mike are
not aware about or are not informing their followers about.
Here's something a little bit longer about this topic:
https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
Note the last part:

"
+This is very disruptive and hopefully will never be needed. But if
+it's needed the best deployment path is just to activate the rule
+changes after certain block height in the future. On the other hand,
+it is healthy decentralization-wise that many independent software
+projects are ready to deploy a schism hardfork.
"

> 2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
> something bad to Bitcoin. So far everything they have done is (or should
> be) allowed. They have forked an open source software and implemented a
> voting system for a consensus rule change - doesn't sound like they are
> committing a crime here (either legally or morally). If they are
> qualified enough to maintain the software, or if the decision is
> technically correct or not is another story, and it should only matter
> to whoever uses / wants to use -XT.

Again, no problem with the code fork, but the Schism hardfork is very
risky regardless of their intentions.

> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
> just by 2 people forking the software and submitting a consensus rule to
> a vote, it means Bitcoin is dead already and it should be worthless! We
> can't go around and panic every time somebody forks Bitcoin and tries to
> change something - this should be allowed by the nature of its license.
> If tomorrow 5 more people fork 5 different software implementing the
> bitcoin protocol and submit 5 different new consensus rules to a vote,
> then what? We should all sell so the price will drop to 1 cent, because
> it is somehow not good enough, not stable enough?

If they don't extensively lobby Bitcoin companies, they don't start a
massive PR campaign labbeling other developers as "obstructionists"
and don't misinform a big part of the Bitcoin users (often using
logical fallacies, intentionally or not), probably those 5 new
currencies will be ignored and nothing bad will happen.
Unfortunately in this case a great division between users is being created.

> I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
> block in the future spends all the longest dusted coins to me, out of
> which I give away 50% to the miners (so the hashing power will have
> incentive to use my fork).
>
> Can they do it? YES
> Will they do it? NO
> Should the world care about this? NO
>
> It's as simple as that. We cannot continue to panic that "Bitcoin as a
> project" is at threat because somebody forked it.

Can you please stop conflating "Bitcoin Core as a project" and
"Bitcoin consensus rules".
They are different things and nobody is or can be "in charge" of the
later, face it.

Can you please also stop conflating software fork and
"Schism/controversial/contentious hardfork"? Nobody has anything
against the former and as you point out it is allowed by its free
software license.

> 4. By having a software fork and consensus rule submitted to vote we
> actually prove how open Bitcoin is, and how there is lack of control
> over it from all pa

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Gary Mulder via bitcoin-dev]

So guys, do we need a BIP to address the existence of XT and its possible
impact to the block chain?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Theo Chino via bitcoin-dev]

Nelson,

Talking politics, Devs do day and night, however politics is also about
knocking on door and not sitting behind a keyboard writing a perl script to
spam the politicians with the same content. Politics is about maneuvering
to be in a position to get the elected official to do what you want because
if he don't, you will make sure it will not get elected next time.

I personally never could finish drilling into the code (which is very
elegantly written) because some New York idiot decided that Bitcoin was too
dangerous for society to handle. I had to stop playing with the code and
turn my attention elsewhere. *You can read the opinion of one of the idiot
here :
http://www.nytimes.com/2015/08/12/opinion/apple-google-when-phone-encryption-blocks-justice.html
*

Theo

On Wed, Aug 19, 2015 at 5:54 PM, Nelson Castillo 
wrote:

> On Wed, Aug 19, 2015 at 4:51 PM, Theo Chino via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> And this is why I love Bitcoin, politics + technical = all in one.
>>
>
> If you think developers do not talk politics go read LKML... Politics are
> inevitable.
> I think the "I don't know enough to code (Bitcoin) but I think that"
> belongs somewhere else (This is the -dev list).
>
>
>>
>> Regards,
>> Theo Chino
>> https://www.facebook.com/groups/557495624389384 (politics in NYS about
>> bitcoin.)
>> http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york
>>
>> On Wed, Aug 19, 2015 at 5:19 PM, Hector Chu via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Haha. Reminds me of when I asked Gavin earlier this year about whether
>>> he cared about politics and he replied that he only cared about and
>>> was responsible for the technicals. Little did he know he would
>>> unwittingly become the technical enabler for Mike's political
>>> shenanigans.
>>>
>>> On 19 August 2015 at 21:19, Eric Lombrozo via bitcoin-dev
>>>  wrote:
>>> > Those who are too smart to engage in politics are punished by being
>>> governed
>>> > by those who are dumber.
>>> > - Plato
>>> >
>>> > On Aug 19, 2015, at 1:11 PM, Eric Lombrozo 
>>> wrote:
>>> >
>>> > Alex,
>>> >
>>> > With all due respect, right now the biggest challenge facing Bitcoin
>>> is not
>>> > technical but political. I would love to see this list go back to
>>> technical
>>> > discussions, but unfortunately, until this political stuff is
>>> resolved, even
>>> > technical discussion is purely philosophical as there’s little chance
>>> of
>>> > actually making good progress on consensus…which in a space where
>>> everything
>>> > depends on consensus pretty much makes everything else moot.
>>> >
>>> > On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev
>>> >  wrote:
>>> >
>>> > This is a message that I wrote and had hoped that all the core devs
>>> would
>>> > sign on to, but I failed to finish organizing it.  So I'll just say it
>>> from
>>> > myself.
>>> >
>>> > There has been a valuable discussion over the last several months
>>> regarding
>>> > a hard fork with respect to block size.  However the sheer volume of
>>> email
>>> > and proportion of discussion that is more philosophical than technical
>>> has
>>> > rendered this list almost unusable for its primary purpose of technical
>>> > discussion related to Bitcoin development.  Many of us share the blame
>>> for
>>> > letting the discourse run off topic to such a degree, and we hope that
>>> an
>>> > appeal for individual self restraint will allow this list to return to
>>> a
>>> > higher signal-to-noise ratio.
>>> > -Please consider the degree to which any email you send is related to
>>> > technical development before sending it.
>>> > -Please consider how many emails you are sending to this list
>>> regarding the
>>> > same topic.
>>> > This list is not appropriate for an endless back and forth debate on
>>> the
>>> > philosophical underpinnings of Bitcoin.  Although such a debate may be
>>> > worthwhile it should be taken to another forum for discussion.  Every
>>> email
>>> > you send is received by hundreds of developers who value their time as
>>> much
>>> > as you value yours.  If your intended audience isn't really the
>>> majority of
>>> > them, perhaps private communication would be more appropriate.
>>> >
>>> > Thanks,
>>> > Alex
>>> >
>>> > ___
>>> > 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
>>> >
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/li

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 10:04 PM, Eric Lombrozo  wrote:
> But the consensus code should NOT be subject to the same commit policies…and 
> we should make an effort to separate the two clearly. And we should find a 
> way to communicate the difference succinctly and clearly to laypeople (which 
> is something I think the XT opponents have been horrible at doing so far).

I think that effort is in progress (again, much slower that I would
like it to be) and it's called libconsensus.
Once we have libconsensus Bitcoin Core it's just another
implementation (even if it is the reference one) and it's not "the
specification of the consensus rules" which is a "privileged" position
that brings all sorts of misunderstandings and problems (the block
size debate is just one example).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Nelson Castillo via bitcoin-dev]

On Wed, Aug 19, 2015 at 4:51 PM, Theo Chino via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> And this is why I love Bitcoin, politics + technical = all in one.
>

If you think developers do not talk politics go read LKML... Politics are
inevitable.
I think the "I don't know enough to code (Bitcoin) but I think that"
belongs somewhere else (This is the -dev list).


>
> Regards,
> Theo Chino
> https://www.facebook.com/groups/557495624389384 (politics in NYS about
> bitcoin.)
> http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york
>
> On Wed, Aug 19, 2015 at 5:19 PM, Hector Chu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Haha. Reminds me of when I asked Gavin earlier this year about whether
>> he cared about politics and he replied that he only cared about and
>> was responsible for the technicals. Little did he know he would
>> unwittingly become the technical enabler for Mike's political
>> shenanigans.
>>
>> On 19 August 2015 at 21:19, Eric Lombrozo via bitcoin-dev
>>  wrote:
>> > Those who are too smart to engage in politics are punished by being
>> governed
>> > by those who are dumber.
>> > - Plato
>> >
>> > On Aug 19, 2015, at 1:11 PM, Eric Lombrozo  wrote:
>> >
>> > Alex,
>> >
>> > With all due respect, right now the biggest challenge facing Bitcoin is
>> not
>> > technical but political. I would love to see this list go back to
>> technical
>> > discussions, but unfortunately, until this political stuff is resolved,
>> even
>> > technical discussion is purely philosophical as there’s little chance of
>> > actually making good progress on consensus…which in a space where
>> everything
>> > depends on consensus pretty much makes everything else moot.
>> >
>> > On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev
>> >  wrote:
>> >
>> > This is a message that I wrote and had hoped that all the core devs
>> would
>> > sign on to, but I failed to finish organizing it.  So I'll just say it
>> from
>> > myself.
>> >
>> > There has been a valuable discussion over the last several months
>> regarding
>> > a hard fork with respect to block size.  However the sheer volume of
>> email
>> > and proportion of discussion that is more philosophical than technical
>> has
>> > rendered this list almost unusable for its primary purpose of technical
>> > discussion related to Bitcoin development.  Many of us share the blame
>> for
>> > letting the discourse run off topic to such a degree, and we hope that
>> an
>> > appeal for individual self restraint will allow this list to return to a
>> > higher signal-to-noise ratio.
>> > -Please consider the degree to which any email you send is related to
>> > technical development before sending it.
>> > -Please consider how many emails you are sending to this list regarding
>> the
>> > same topic.
>> > This list is not appropriate for an endless back and forth debate on the
>> > philosophical underpinnings of Bitcoin.  Although such a debate may be
>> > worthwhile it should be taken to another forum for discussion.  Every
>> email
>> > you send is received by hundreds of developers who value their time as
>> much
>> > as you value yours.  If your intended audience isn't really the
>> majority of
>> > them, perhaps private communication would be more appropriate.
>> >
>> > Thanks,
>> > Alex
>> >
>> > ___
>> > 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
>> >
>> ___
>> 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
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Theo Chino via bitcoin-dev]

And this is why I love Bitcoin, politics + technical = all in one.

Regards,
Theo Chino
https://www.facebook.com/groups/557495624389384 (politics in NYS about
bitcoin.)
http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york

On Wed, Aug 19, 2015 at 5:19 PM, Hector Chu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Haha. Reminds me of when I asked Gavin earlier this year about whether
> he cared about politics and he replied that he only cared about and
> was responsible for the technicals. Little did he know he would
> unwittingly become the technical enabler for Mike's political
> shenanigans.
>
> On 19 August 2015 at 21:19, Eric Lombrozo via bitcoin-dev
>  wrote:
> > Those who are too smart to engage in politics are punished by being
> governed
> > by those who are dumber.
> > - Plato
> >
> > On Aug 19, 2015, at 1:11 PM, Eric Lombrozo  wrote:
> >
> > Alex,
> >
> > With all due respect, right now the biggest challenge facing Bitcoin is
> not
> > technical but political. I would love to see this list go back to
> technical
> > discussions, but unfortunately, until this political stuff is resolved,
> even
> > technical discussion is purely philosophical as there’s little chance of
> > actually making good progress on consensus…which in a space where
> everything
> > depends on consensus pretty much makes everything else moot.
> >
> > On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev
> >  wrote:
> >
> > This is a message that I wrote and had hoped that all the core devs would
> > sign on to, but I failed to finish organizing it.  So I'll just say it
> from
> > myself.
> >
> > There has been a valuable discussion over the last several months
> regarding
> > a hard fork with respect to block size.  However the sheer volume of
> email
> > and proportion of discussion that is more philosophical than technical
> has
> > rendered this list almost unusable for its primary purpose of technical
> > discussion related to Bitcoin development.  Many of us share the blame
> for
> > letting the discourse run off topic to such a degree, and we hope that an
> > appeal for individual self restraint will allow this list to return to a
> > higher signal-to-noise ratio.
> > -Please consider the degree to which any email you send is related to
> > technical development before sending it.
> > -Please consider how many emails you are sending to this list regarding
> the
> > same topic.
> > This list is not appropriate for an endless back and forth debate on the
> > philosophical underpinnings of Bitcoin.  Although such a debate may be
> > worthwhile it should be taken to another forum for discussion.  Every
> email
> > you send is received by hundreds of developers who value their time as
> much
> > as you value yours.  If your intended audience isn't really the majority
> of
> > them, perhaps private communication would be more appropriate.
> >
> > Thanks,
> > Alex
> >
> > ___
> > 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
> >
> ___
> 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] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 11:27 PM, Joseph Poon  wrote:
> On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev 
> wrote:
>> If anyone feels strongly about this, please speak up.
>>
>> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> > I repeated my nit on https://github.com/bitcoin/bips/pull/179
>
> I am also indifferent, but also dislike technical debt.
>
> It should maybe be noted for those who wish to do/write-code-for mempool
> transaction selection (irrespective of one's opinion on it) that lower
> is better, since transactions with shorter relative locks are
> transactions with "higher priority".

That policy code should be simple to change, but thank you for pointing it out.
Also thank you for declaring your position (indifference) on the subject.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Joseph Poon via bitcoin-dev]

On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev 
wrote:
> If anyone feels strongly about this, please speak up.
> 
> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > I repeated my nit on https://github.com/bitcoin/bips/pull/179

I am also indifferent, but also dislike technical debt.

It should maybe be noted for those who wish to do/write-code-for mempool
transaction selection (irrespective of one's opinion on it) that lower
is better, since transactions with shorter relative locks are
transactions with "higher priority".

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

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Hector Chu via bitcoin-dev]

Haha. Reminds me of when I asked Gavin earlier this year about whether
he cared about politics and he replied that he only cared about and
was responsible for the technicals. Little did he know he would
unwittingly become the technical enabler for Mike's political
shenanigans.

On 19 August 2015 at 21:19, Eric Lombrozo via bitcoin-dev
 wrote:
> Those who are too smart to engage in politics are punished by being governed
> by those who are dumber.
> - Plato
>
> On Aug 19, 2015, at 1:11 PM, Eric Lombrozo  wrote:
>
> Alex,
>
> With all due respect, right now the biggest challenge facing Bitcoin is not
> technical but political. I would love to see this list go back to technical
> discussions, but unfortunately, until this political stuff is resolved, even
> technical discussion is purely philosophical as there’s little chance of
> actually making good progress on consensus…which in a space where everything
> depends on consensus pretty much makes everything else moot.
>
> On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev
>  wrote:
>
> This is a message that I wrote and had hoped that all the core devs would
> sign on to, but I failed to finish organizing it.  So I'll just say it from
> myself.
>
> There has been a valuable discussion over the last several months regarding
> a hard fork with respect to block size.  However the sheer volume of email
> and proportion of discussion that is more philosophical than technical has
> rendered this list almost unusable for its primary purpose of technical
> discussion related to Bitcoin development.  Many of us share the blame for
> letting the discourse run off topic to such a degree, and we hope that an
> appeal for individual self restraint will allow this list to return to a
> higher signal-to-noise ratio.
> -Please consider the degree to which any email you send is related to
> technical development before sending it.
> -Please consider how many emails you are sending to this list regarding the
> same topic.
> This list is not appropriate for an endless back and forth debate on the
> philosophical underpinnings of Bitcoin.  Although such a debate may be
> worthwhile it should be taken to another forum for discussion.  Every email
> you send is received by hundreds of developers who value their time as much
> as you value yours.  If your intended audience isn't really the majority of
> them, perhaps private communication would be more appropriate.
>
> Thanks,
> Alex
>
> ___
> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Peter Todd via bitcoin-dev]

On Wed, Aug 19, 2015 at 09:32:49AM -0700, Mark Friedenbach via bitcoin-dev 
wrote:
> I think you misunderstand my suggestion Tier. I am suggesting the same as
> BtcDrak, I think:
> 
> Modify IsSuperMajority to take an (optional) mask field. Bits set in that
> mask are zero'd for the purpose of the IsSuperMajority calculation. For
> this vote we mask bits 0x2007.
> 
> Thus to signal support for CLTV/CSV/etc. (on Core, XT, or not-XT), you set
> bit 4. On Core this would mean a minimum version of 0x8, on XT/not-XT a
> minimum version of 0x2008.
> 
> However the vote is still over whether to enforce BIP 65, 68, etc. for
> blocks with nVersion>=4. So when this all clears up we haven't needlessly
> wasted an additional bit.

Ah, I see your point now re: wasting bits; my post was a bit incorrect
on that point.

So a subtle thing with the IsSuperMajority() mechanism, and the nVersion
bits proposal alternative, is one of the main objectives of the latter
proposal proposal is to allow forks to *fail* to be adopted cleanly.

To illustrate the problem, consider a hypothetical CLTV soft-fork,
implemented with IsSuperMajority() nVersion >= 4. We release Bitcoin
Core with that code, call it Bitcoin Core v0.12.0, however some
substantial fraction of the mining community refuses to upgrade,
believing CLTV to be a bad idea. This forms the community into Bitcoin
Core and Bitcoin Not-CLTV camps. The Not-CLTV camp then wants to do a
new soft-fork upgrade, say for CHECKSIG2

What now? If CHECKSIG2 is implemented via IsSuperMajority, nVersion >=
5, that'll falsely trigger Core nodes to think the upgrade has gone
though. You could safely define >= 5 semantics to be "OP_CLTV is now
disabled", but that's pretty ugly and unnecessarily uses up a NOP.

You can avoid this problem by assigning one bit out of nVersion for
every soft-fork, but then you can only do ~29 more soft-forks - ugly!


Come to think of it, if you're Really Sure™ the soft-fork will be
adopted, you can recycle those bits by using the following rule:

if (IsFlagBitMaskSuperMajority(1 << 4, pindex->pprev) || block.nMedianTime 
> CLTV_SOFTFORK_DEADLINE) {
flags |= SCRIPT_VERIFY_CLTV;
}

IsFlagBitMaskSuperMajority() is a masked version of the existing
IsSuperMajority() logic. CLTV_SOFTFORK_DEADLINE would be set some
reasonable amount of time in the future, perhaps 3 years.

This would probably be ok for non-controversial forks - implementing
DERSIG this way would have been fine - and an unlimited number of
soft-forks can be done this way safely. (even in parallel)

However, this idea still causes problems if forks ever fail to get
adoption, something the nVersion bits proposal handles cleanly, albeit
at the cost of a significantly more complex implementation. With a
sufficiently far off fork deadline in practice that may not be a big
issue - nearly everyone would have upgraded their software anyway -  but
it's still technically creating hard-fork scenarios with respect to
older software whenever forks fail to get adoption.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


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

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Eric Lombrozo via bitcoin-dev]

Those who are too smart to engage in politics are punished by being governed by 
those who are dumber.
- Plato

> On Aug 19, 2015, at 1:11 PM, Eric Lombrozo  > wrote:
> 
> Alex,
> 
> With all due respect, right now the biggest challenge facing Bitcoin is not 
> technical but political. I would love to see this list go back to technical 
> discussions, but unfortunately, until this political stuff is resolved, even 
> technical discussion is purely philosophical as there’s little chance of 
> actually making good progress on consensus…which in a space where everything 
> depends on consensus pretty much makes everything else moot.
> 
>> On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev 
>> > > wrote:
>> 
>> This is a message that I wrote and had hoped that all the core devs would 
>> sign on to, but I failed to finish organizing it.  So I'll just say it from 
>> myself.
>> 
>> There has been a valuable discussion over the last several months regarding 
>> a hard fork with respect to block size.  However the sheer volume of email 
>> and proportion of discussion that is more philosophical than technical has 
>> rendered this list almost unusable for its primary purpose of technical 
>> discussion related to Bitcoin development.  Many of us share the blame for 
>> letting the discourse run off topic to such a degree, and we hope that an 
>> appeal for individual self restraint will allow this list to return to a 
>> higher signal-to-noise ratio.
>> -Please consider the degree to which any email you send is related to 
>> technical development before sending it.
>> -Please consider how many emails you are sending to this list regarding the 
>> same topic.
>> This list is not appropriate for an endless back and forth debate on the 
>> philosophical underpinnings of Bitcoin.  Although such a debate may be 
>> worthwhile it should be taken to another forum for discussion.  Every email 
>> you send is received by hundreds of developers who value their time as much 
>> as you value yours.  If your intended audience isn't really the majority of 
>> them, perhaps private communication would be more appropriate.
>> 
>> Thanks,
>> Alex
>> 
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org 
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev list etiquette

[Eric Lombrozo via bitcoin-dev]

Alex,

With all due respect, right now the biggest challenge facing Bitcoin is not 
technical but political. I would love to see this list go back to technical 
discussions, but unfortunately, until this political stuff is resolved, even 
technical discussion is purely philosophical as there’s little chance of 
actually making good progress on consensus…which in a space where everything 
depends on consensus pretty much makes everything else moot.

> On Aug 19, 2015, at 1:08 PM, Alex Morcos via bitcoin-dev 
>  wrote:
> 
> This is a message that I wrote and had hoped that all the core devs would 
> sign on to, but I failed to finish organizing it.  So I'll just say it from 
> myself.
> 
> There has been a valuable discussion over the last several months regarding a 
> hard fork with respect to block size.  However the sheer volume of email and 
> proportion of discussion that is more philosophical than technical has 
> rendered this list almost unusable for its primary purpose of technical 
> discussion related to Bitcoin development.  Many of us share the blame for 
> letting the discourse run off topic to such a degree, and we hope that an 
> appeal for individual self restraint will allow this list to return to a 
> higher signal-to-noise ratio.
> -Please consider the degree to which any email you send is related to 
> technical development before sending it.
> -Please consider how many emails you are sending to this list regarding the 
> same topic.
> This list is not appropriate for an endless back and forth debate on the 
> philosophical underpinnings of Bitcoin.  Although such a debate may be 
> worthwhile it should be taken to another forum for discussion.  Every email 
> you send is received by hundreds of developers who value their time as much 
> as you value yours.  If your intended audience isn't really the majority of 
> them, perhaps private communication would be more appropriate.
> 
> Thanks,
> Alex
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] bitcoin-dev list etiquette

[Alex Morcos via bitcoin-dev]

This is a message that I wrote and had hoped that all the core devs would
sign on to, but I failed to finish organizing it.  So I'll just say it from
myself.

There has been a valuable discussion over the last several months regarding
a hard fork with respect to block size.  However the sheer volume of email
and proportion of discussion that is more philosophical than technical has
rendered this list almost unusable for its primary purpose of technical
discussion related to Bitcoin development.  Many of us share the blame for
letting the discourse run off topic to such a degree, and we hope that an
appeal for individual self restraint will allow this list to return to a
higher signal-to-noise ratio.
-Please consider the degree to which any email you send is related to
technical development before sending it.
-Please consider how many emails you are sending to this list regarding the
same topic.
This list is not appropriate for an endless back and forth debate on the
philosophical underpinnings of Bitcoin.  Although such a debate may be
worthwhile it should be taken to another forum for discussion.  Every email
you send is received by hundreds of developers who value their time as much
as you value yours.  If your intended audience isn't really the majority of
them, perhaps private communication would be more appropriate.

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

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Lombrozo via bitcoin-dev]

FWIW,

I would fully like to see the consensus stuff split off into a separate 
organization from everything else. Let XT continue to support additional p2p 
messages or relay policies or whatever. Let Mike and Gavin argue for their 
improved wallet or whatever - I have absolutely no problem with that.

But the consensus code should NOT be subject to the same commit policies…and we 
should make an effort to separate the two clearly. And we should find a way to 
communicate the difference succinctly and clearly to laypeople (which is 
something I think the XT opponents have been horrible at doing so far).


> On Aug 19, 2015, at 12:58 PM, Jorge Timón  wrote:
> 
> On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
>  wrote:
>> [...]
>> core devs” and relying on the fact that many people out there can’t seem to
>> tell the difference between a source code fork and a blockchain fork.
> 
> And this is precisely why we should make perfectly clear that we're
> not against a code fork where Hearn or anyone else acts as a
> "benevolent dictator", just against the controversial hardfork it is
> attempting to deploy.
> Otherwise the PR battle is probably lost (which may mean users sell
> all their BTC for XTBTC [or just forget about their BTC and only care
> about their XTBTC]).



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
 wrote:
> [...]
> core devs” and relying on the fact that many people out there can’t seem to
> tell the difference between a source code fork and a blockchain fork.

And this is precisely why we should make perfectly clear that we're
not against a code fork where Hearn or anyone else acts as a
"benevolent dictator", just against the controversial hardfork it is
attempting to deploy.
Otherwise the PR battle is probably lost (which may mean users sell
all their BTC for XTBTC [or just forget about their BTC and only care
about their XTBTC]).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Eric Lombrozo via bitcoin-dev]

Unfortunately, I think that from a PR angle, removing Gavin from commit 
privileges right now will probably play into his hand. Sadly.

Say what you will regarding Gavin and Mike’s technical merits, they’ve been 
quite clever on the PR front. Framing this issue as “obstructionism from the 
core devs” and relying on the fact that many people out there can’t seem to 
tell the difference between a source code fork and a blockchain fork.



> On Aug 19, 2015, at 12:32 PM, odinn via bitcoin-dev 
>  wrote:
> 
> Signed PGP part
> re. Gavin and commit access
> 
> On 08/19/2015 12:15 PM, Btc Drak via bitcoin-dev wrote:
> > On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd 
> > wrote:
> >> Normal GitHub users submitting pull-reqs to Bitcoin Core can't
> >> delete other users' comments on their own pull-reqs...
> >>
> >> IMO that's an abuse of the pull-req process, and in turn, Gavin
> >> Andresens's commit access rights for the Bitcoin Core repo.
> >
> > For the avoidance of doubt here's the archive link of my comment
> > https://archive.is/omvSY#40% (call me paranoid) and here's where he
> > tells me he's censored my posts https://archive.is/vym6N#40%
> >
> >> I think this should weigh in favor of Gavin Andresen not having
> >> commit privileges for the Bitcoin Core repository.
> >
> > It's time.
> 
> I agree, fwiw.  If he's going to censor others then that's
> inconsistent with the responsibility of having commit access.
> 
> > ___ bitcoin-dev mailing
> > list bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> 
> --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

re. Gavin and commit access

On 08/19/2015 12:15 PM, Btc Drak via bitcoin-dev wrote:
> On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd 
> wrote:
>> Normal GitHub users submitting pull-reqs to Bitcoin Core can't
>> delete other users' comments on their own pull-reqs...
>> 
>> IMO that's an abuse of the pull-req process, and in turn, Gavin 
>> Andresens's commit access rights for the Bitcoin Core repo.
> 
> For the avoidance of doubt here's the archive link of my comment 
> https://archive.is/omvSY#40% (call me paranoid) and here's where he
> tells me he's censored my posts https://archive.is/vym6N#40%
> 
>> I think this should weigh in favor of Gavin Andresen not having
>> commit privileges for the Bitcoin Core repository.
> 
> It's time.

I agree, fwiw.  If he's going to censor others then that's
inconsistent with the responsibility of having commit access.

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

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1NnDAAoJEGxwq/inSG8C0H0H/0ygc10hDP59Z2ktB8+wxqek
qLdMS4WbzPQzXkAAeVCu4RWzqeJjJZZ66VZ2aPBdsHHPIqOikAYAy3EaYQ2M7VIy
D6FW+AZK3ZHXX/ENVvtEPegu58ykk7QoWQkKQbH1Jqfxa0wcv3PQ5HtH92GReCNP
cNUMjnJkdI1XIVVQ8XRZ3OfOwUrJlSV7o9kKb6KRlEyXiGPRMI/myHIBBkKg5RkW
4Zc6GqRUiT7MIpQcRGV1/h5LuVyszbo70SrhX1D/w2W4B87bGScpH98hwqqKu+td
HnbI6VqLD1xMKBnj18GdpCJzKePkXoR0FHjkipcABXTjRa4Oy52AZyxU4w7luqI=
=PD5w
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Warren Togami Jr. via bitcoin-dev]

FYI, a few developers including Wladimir, Greg, Peter Todd, Pieter, and
Alex Morcos have been discussing what to do about improving the signal
noise ratio on bitcoin-dev list.  One proposal similar to this discussion
was to split it into multiple mailing lists.  It was pointed out that the
less technical Bitcoin discussion list already existed in the past and
nobody used it.  Generally the discussion went away from creating yet
another mailing list and toward instituting an on-topic guidelines for
bitcoin-dev.  Gavin, Wladimir, and a few of the others agreed to a simple
few paragraphs written by Alex Morcos.  IIRC Wladimir agreed to post it.
Has it been posted yet?

On Wed, Aug 19, 2015 at 11:47 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik  wrote:
> > bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
> > discussion?
>
> Well -dev or both, I dont particularly see a difference at the moment,
> and establishing two lists isnt really going to make a difference so
> long as Bitcoin Core is the reference client, which it is by defacto.
> The risk of having too many lists is interested stakeholders will miss
> a discussions. Normal protocol and core discussions are usually pretty
> low volume in any case.
>
> > As Jorge notes, a general discussion list has existed for a long time
> with
> > little use.
>
> I would suggest it's only because there havent been any rules for -dev
> that would force general discussion over to the bitcoin list. On IRC
> we regularly tell people in #bitcoin-dev they are OT and ask them to
> move to #bitcoin and as a result, -dev remains quite clear of chit
> chat, #bitcoin has a steady stream of general chatter.
>
> We could reduce the OT/noise of bitcoin-dev list considerably by
> offloading the non-technical/academic debate to the bitcoin list. It
> just needs a bit of shepherding. I am more than happy to help out.
> Especially if the list already exists, we should consider making a
> decision now.
>
> Who are the moderators for that list? Do we really want to use
> sourceforge or are there alternatives, like another list on
> linuxfoundation?
>
> ping @Warren.
> ___
> 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] Bitcoin XT Fork

[Eric Lombrozo via bitcoin-dev]

> On Aug 19, 2015, at 12:12 PM, Santino Napolitano via bitcoin-dev 
>  wrote:
> 
> Gavin has been very clear about the fact that he's on vacation. I'm not sure 
> what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks 
> are out for him so there isn't really anything he can possibly say which will 
> be constructively received on this highly adversarial and increasingly 
> ridiculous charade of a mailing list. I feel as though they've made their 
> case abundantly clear to anyone paying attention.

It’s good to know that Gavin still manages to keep his priorities straight. Of 
course, vacationing at the moment that the most controversial change in the 
history of Bitcoin which threatens to split the community is officially 
“announced” is probably exactly what he should be doing.

I’m glad to know that we’ll continue to have this amazing leadership under the 
XT fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Santino Napolitano via bitcoin-dev]

Gavin has been very clear about the fact that he's on vacation. I'm not sure 
what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks 
are out for him so there isn't really anything he can possibly say which will 
be constructively received on this highly adversarial and increasingly 
ridiculous charade of a mailing list. I feel as though they've made their case 
abundantly clear to anyone paying attention.

The community will weigh the independent merit of the two points of view and 
that community is not as naive and uninformed as everyone on this list likes to 
portray them to be. Your concern for companies' welfare is appreciated but I'm 
confident they can manage their own independent assessments of this matter as 
well as seek out enough varied expert opinions such that they can make an 
informed decision.

19.08.2015, 19:53, "Adam Back via bitcoin-dev" 
:
> It seems to be a recurring meme that BIP 101 is somehow "a solution
> put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
> etc are not.
>
> That is not at ALL the case, and is insulting (present company excluded).
>
> It is just that no one else is reckless enough to bypass the review
> process and risk a controversial hard fork deployment war. Myself and
> many other people warned Gavin a network fork "war" would start (ie
> someone would think of some way to sabotage or attack the deployment
> of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc. He
> ignored the warnings. Many also warned that 75% was an optimally BAD
> trigger ratio (and that in a hard fork it is not a miner vote really
> as in soft-forks). Gavin & Mike ignored that warning to. I know they
> heard those warnings because I told them 1:1 in person or via email
> and had on going conversations. Others did too.
>
> People can not blame bitcoin core or me, that this then predictably
> happened exactly as we said it would - it was completely obvious and
> predictable.
>
> In fact noBitcoinXT is even more dangerous and therefore amplified in
> effect in creating mutual assured destruction kind of risk profile
> than the loose spectrum of technical counters imagined. I did not
> personally put much effort into thinking about counters because I
> though it counter productive and hoped that Gavin & Mike would have
> the maturity to not start down such a path.
>
> Again any of the other proposals can easily be implemented. They
> *could* also spin up a web page and put up binaries, however no one
> else was crazy enough to try to start a deployment in that way.
>
> It is also puzzling timing - with all these BIPs and ongoing
> discussion and workshops coming imminently to then release ahead of
> that process where as far as I know Gavin said he was equally happy
> with BIP 100 or other proposal which ever is best, and on basically
> the eve of workshops planned to progress this collaboratively.
> Bitcoin-XT is also under tested, people are finding privacy bugs and
> other issues. (Not even mentioning the above 75% optimally bad
> parameter, and the damage to community reputation and collaborative
> environment that this all causes.)
>
> Very disappointing Gavin and Mike.
>
> I find it quite notable that Gavin and Mike have been radio silent on
> the bitcoin-dev list and yet we see a stream of media articles, blog
> posts, pod casts, and from what I can tell ongoing backroom lobbying
> of companies to run bitcoin-XT without trying AT ALL to offer a
> neutral or balanced or multi proposal information package so that
> companies technical people can make a balanced informed decision.
> That is what the workshops are trying to provide.
>
> Gavin, Mike - anything to say here?
>
> Adam
>
> On 18 August 2015 at 19:59, Angel Leon via bitcoin-dev
>  wrote:
>>  "How then to end this XT madness?"
>>
>>  Instead of bashing on someone that has actually put a solution forward, make
>>  your own fork and see if your ideas on how to solve the issue are any
>>  better.
>>
>>  As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
>>  block increase every day that passes, even with a "useless project" like you
>>  call it.
>>
>>  Go out there and see how bitcoin is actually used.
>>
>>  http://twitter.com/gubatron
>>
>>  On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
>>   wrote:
>>>  The "XT Fork" (better said, a POS alt*) and those behind it make not
>>>  even a pretense to work through process involved with bitcoin developmen
>>>  t.
>>>
>>>  (*This is not intended as a slight toward any other alts, as here in
>>>  this post I am focusing solely on XT.)
>>>
>>>  Instead of abandoning their useless project, or at least conceding
>>>  that their alt is operating essentially outside of the development
>>>  funnel (by this I mean BIP process), the developers of XT, via their
>>>  latest presentation of XT give nothing more than an attack on bitcoin
>>>  (albeit one that, more than anything, is designed to sidetrack real
>>>  di

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd  wrote:
> Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
> other users' comments on their own pull-reqs...
>
> IMO that's an abuse of the pull-req process, and in turn, Gavin
> Andresens's commit access rights for the Bitcoin Core repo.

For the avoidance of doubt here's the archive link of my comment
https://archive.is/omvSY#40% (call me paranoid)
and here's where he tells me he's censored my posts https://archive.is/vym6N#40%

> I think this should weigh in favor of Gavin Andresen not having commit
> privileges for the Bitcoin Core repository.

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

Re: [bitcoin-dev] Bitcoin XTs Tor IP blacklist downloading system has significant privacy leaks.

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 4:45 PM, Mike Hearn via bitcoin-dev
 wrote:
> The code was peer reviewed, in the XT project. I didn't bother submitting
> other revisions to Core, obviously, as it was already rejected.
>
> The quantity of incorrect statements in this thread is quite ridiculous.

Would you kindly link to said peer review as I was unable to find it
other than a couple of comments between you and Gavin which hardly
amounts to peer review.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik  wrote:
> bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
> discussion?

Well -dev or both, I dont particularly see a difference at the moment,
and establishing two lists isnt really going to make a difference so
long as Bitcoin Core is the reference client, which it is by defacto.
The risk of having too many lists is interested stakeholders will miss
a discussions. Normal protocol and core discussions are usually pretty
low volume in any case.

> As Jorge notes, a general discussion list has existed for a long time with
> little use.

I would suggest it's only because there havent been any rules for -dev
that would force general discussion over to the bitcoin list. On IRC
we regularly tell people in #bitcoin-dev they are OT and ask them to
move to #bitcoin and as a result, -dev remains quite clear of chit
chat, #bitcoin has a steady stream of general chatter.

We could reduce the OT/noise of bitcoin-dev list considerably by
offloading the non-technical/academic debate to the bitcoin list. It
just needs a bit of shepherding. I am more than happy to help out.
Especially if the list already exists, we should consider making a
decision now.

Who are the moderators for that list? Do we really want to use
sourceforge or are there alternatives, like another list on
linuxfoundation?

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

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:30 PM, Danny Thorpe  wrote:
> How do "big-block" testnet nodes running this 6382 rev recognize each other
> on the peer network? If I set up a 2MB block limit testnet node and -addnode
> another 2MB block testnet node (say, JornC's node) to it, and my node mines
> a block stuffed with 1.3MB of test txs, the other "big-block" node should
> accept my mined block, but it will be rejected / immediately orphaned by the
> rest of the testnet network because it exceeds their notion of block size
> limit, correct?

I have (hopefully) answered your questions in the other thread.
Review/testing of #6235 would be also appreciated (to hopefully
eventually merge the full #6382 branch into bitcoin/master).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Introduce N testnet chains to test different block sizes

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:30 PM, Danny Thorpe  wrote:
>>>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
> <<
>
> Ok, glad to hear that.
>
>>>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> <<
>
> I saw your post about that awhile ago, thanks for doing the work!  My
> fiddling with that end of the food chain is gated by my needing to block out
> a weekend to set up a bitcoind build environment.
>
> How do "big-block" testnet nodes running this 6382 rev recognize each other
> on the peer network? If I set up a 2MB block limit testnet node and -addnode
> another 2MB block testnet node (say, JornC's node) to it, and my node mines
> a block stuffed with 1.3MB of test txs, the other "big-block" node should
> accept my mined block, but it will be rejected / immediately orphaned by the
> rest of the testnet network because it exceeds their notion of block size
> limit, correct?

I don't have the time to use the code to write tests and simulations
myself right now but I would be really happy about someone else doing
it.
Even though they share the same port and magic numbers, each of the N
testchains in #6382 has a different genesis block, so they will reject
blocks from any other testchain from the start.
But you will likely connect the nodes directly and manually to get the
network topology you want to test anyway.
I hope this answers your questions but I'm happy to answer any other
questions you may have.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:32 PM, Btc Drak via bitcoin-dev
 wrote:
> On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
>  wrote:
>> ignored the warnings.  Many also warned that 75% was an optimally BAD
>> trigger ratio (and that in a hard fork it is not a miner vote really
>> as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
>> heard those warnings because I told them 1:1 in person or via email
>> and had on going conversations.  Others did too.
>
> I would like to add for the record, I also warned Gavin of this in his
> PR to Bitcoin Core, and also suggested a timeout which if
> activation/enforcement did not occur within, hard fork deployment
> would be cancelled. His response was to delete these from the PR
> claiming thresholds were not relevant conversation in his PR and
> belonged elsewhere (even though they had already been discussed
> elsewhere).

I don't know the timeline for this, but maybe he was referring to
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
(where he is one of the few people that have participated).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Peter Todd via bitcoin-dev]

On Wed, Aug 19, 2015 at 06:32:14PM +0100, Btc Drak via bitcoin-dev wrote:
> On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
>  wrote:
> > ignored the warnings.  Many also warned that 75% was an optimally BAD
> > trigger ratio (and that in a hard fork it is not a miner vote really
> > as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
> > heard those warnings because I told them 1:1 in person or via email
> > and had on going conversations.  Others did too.
> 
> I would like to add for the record, I also warned Gavin of this in his
> PR to Bitcoin Core, and also suggested a timeout which if
> activation/enforcement did not occur within, hard fork deployment
> would be cancelled. His response was to delete these from the PR
> claiming thresholds were not relevant conversation in his PR and
> belonged elsewhere (even though they had already been discussed
> elsewhere).

Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
other users' comments on their own pull-reqs...

IMO that's an abuse of the pull-req process, and in turn, Gavin
Andresens's commit access rights for the Bitcoin Core repo.

That kind of comment is perfectly on topic in the pull-req review
process; deleting it harms that process by removing useful information
about the trade-offs of the pull-req, both for people now, as well as
future efforts investigating the history of Bitcoin's protocol
development.

I think this should weigh in favor of Gavin Andresen not having commit
privileges for the Bitcoin Core repository.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


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

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Tier Nolan via bitcoin-dev]

On Wed, Aug 19, 2015 at 6:25 PM, Btc Drak  wrote:

> In our case for Bitcoin Core, option 2 we use nVersion=8, apply a
> bitmask of 0xdff8 thus:
>
> if ((block.nVersion & ~0x2007) >= 4 &&
> CBlockIndex::IsSuperMajority(...)) { //...}
>
> With nVersion=8, but using comparison >=4 allows us to recover the
> bit later, assuming we want it (otherwise we use version >=8).
>

That is the 75% "activation" rule portion?  The 95% rule has to apply to
all blocks.

The supermajority applies to unmasked blocks?

I think you want it so that a sequence of blocks with version 8 can be
followed by version 4 blocks?

If 950 of the last 1000 blocks have bit 0x08 set, then reject any block
with a version less than 4.

This means transitioning to the version bits BIP just requires dropping the
version back to 4 and adding a rule enforcing the BIPs for version 4 and
higher blocks.

This would be part of the version bits BIP enforcement.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Peter Todd via bitcoin-dev]

On Wed, Aug 19, 2015 at 10:22:32AM -0700, Simon Liu via bitcoin-dev wrote:
> Olivier Janssens claims that one of your colleagues is asking for Gavin
> to be removed from his position.  Is this true?
> 
> https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence
> 
> http://pastebin.com/q2TT58Z5

IMO that's a very reasonable request; lately I've spent a lot of time
having to educate journalists on how Bitcoin doesn't have a "chief
scientist" with any kind of authority. Having Gavin Andresen in that
position at the otherwise inactive and bankrupt Bitcoin Foundation
misleads the public about the true nature of how Bitcoin operates,
giving a misleading impression that it has the same centralized decision
making as conventional financial systems do. Among other things, this
harms the reputation of Bitcoin as a whole as it can confuse the public
into thinking there aren't major differences between Bitcoin and those
conventional financial systems.

As the email said "Regardless of your personal view on XT this is bad
for bitcoin." - a statement I agree with 100%

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


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

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
 wrote:
> ignored the warnings.  Many also warned that 75% was an optimally BAD
> trigger ratio (and that in a hard fork it is not a miner vote really
> as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
> heard those warnings because I told them 1:1 in person or via email
> and had on going conversations.  Others did too.

I would like to add for the record, I also warned Gavin of this in his
PR to Bitcoin Core, and also suggested a timeout which if
activation/enforcement did not occur within, hard fork deployment
would be cancelled. His response was to delete these from the PR
claiming thresholds were not relevant conversation in his PR and
belonged elsewhere (even though they had already been discussed
elsewhere).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Danny Thorpe via bitcoin-dev]

>>
I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.
<<

Ok, glad to hear that.

>>
In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
<<

I saw your post about that awhile ago, thanks for doing the work!  My
fiddling with that end of the food chain is gated by my needing to block
out a weekend to set up a bitcoind build environment.

How do "big-block" testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and
-addnode another 2MB block testnet node (say, JornC's node) to it, and my
node mines a block stuffed with 1.3MB of test txs, the other "big-block"
node should accept my mined block, but it will be rejected / immediately
orphaned by the rest of the testnet network because it exceeds their notion
of block size limit, correct?

Thanks,
-Danny

On Wed, Aug 19, 2015 at 2:29 AM, Jorge Timón  wrote:

> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
>  wrote:
> >
> > Ya, so?  All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
> >
> > And when I refer to testnet, I mean the public global testnet
> blockchain, not in-house isolated networks like testnet-in-a-box.
>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> Note that even if the new testchains are regtest-like (ie cheap proof
> of work) you don't need to test them "in-a-box": you can run them from
> many different places.
> Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
> perfectly made using #6382, it just didn't existed at the time.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 6:53 PM, Adam Back via bitcoin-dev
 wrote:
> (and that in a hard fork it is not a miner vote really
> as in soft-forks).

I think calling it "miner vote" was the first mistake: miner's
shouldn't have a "voting power" the rest of the users lack.
I prefer to call it "miner upgrade confirmation" and in BIP99 the
recommendation is to use 95% for both uncontroversial softforks and
uncontroversial hardforks (the uncontroversial harforks also have a
minimum height before starting the miner confirmation/voting to give
users additional time to upgrade).
To me it's no different that the mechanism is used for uncontroversial
softforks or hardforks, the main question is that it is NOT a "miners'
democracy/oligopoly".
If you expect everyone (including all miners) to upgrade, I don't
think any less than 95% makes sense. On the other hand, 100% makes it
relatively cheap for an attacker to block uncontroversial consensus
changes.

For a Schism hardfork, bip99 doesn't recommend to use miner's
confirmation/vote at all. Miners could be against the change, for
example in an ASIC-reset Schism hardfork or in a "hardfork" (it cannot
be a softfork if miners oppose to it) to reduce the block size), but
that shouldn't stop the hardforkers if they think dividing the
currency in 2 is the best solution to whatever is the problem at hand
(which I don't think it's the case now).

Of course, BIP99 is still a draft and can still be changed. But I
would really like that we focused on "how to do hardforks in general"
first and only then focus on how to make a blocksize hardfork
concretely.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 2:24 PM, Tier Nolan via bitcoin-dev
 wrote:
> On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev 
>  wrote:
>> What problem am I missing if we just mask of the offending bits. For my own 
>> project which uses auxpow (and thus has weird nVersion), I also used the 
>> bitmasking method to get rid of auxpow version bits before making the 
>> standard integer comparisons to deploy BIP66 using IsSuperMajority():
>>
>> if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...)) { 
>> //...}
>
> What if version number 257 is used in the future?  That would appear to be a 
> version 1 block and fail the test.

To clarify this is the code example for how the same problem occurs
with auxpow bits when running a an IsSuperMajority() softfork and how
it's solved in that instance.

In our case for Bitcoin Core, option 2 we use nVersion=8, apply a
bitmask of 0xdff8 thus:

if ((block.nVersion & ~0x2007) >= 4 &&
CBlockIndex::IsSuperMajority(...)) { //...}

With nVersion=8, but using comparison >=4 allows us to recover the
bit later, assuming we want it (otherwise we use version >=8).

This should, unless I am missing something, be forward compatible with
future softforks. My understanding was if "versionbits softfork" code
is not ready by the time we're ready for the deployment,
IsSuperMajority() would be acceptable; and this is how we could deploy
it in the wake of the XT developers' carelessness.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT Fork

[Simon Liu via bitcoin-dev]

Olivier Janssens claims that one of your colleagues is asking for Gavin
to be removed from his position.  Is this true?

https://www.reddit.com/r/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/?sort=confidence

http://pastebin.com/q2TT58Z5



> I find it quite notable that Gavin and Mike have been radio silent on
> the bitcoin-dev list and yet we see a stream of media articles, blog
> posts, pod casts, and from what I can tell ongoing backroom lobbying
> of companies to run bitcoin-XT without trying AT ALL to offer a
> neutral or balanced or multi proposal information package so that
> companies technical people can make a balanced informed decision.
> That is what the workshops are trying to provide.
> 
> Gavin, Mike - anything to say here?
> 
> Adam
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Upal Chakraborty via bitcoin-dev]

I think, keeping the reduction part is necessary to have it demand driven.
Otherwise, we could just increase it to a fixed size. If the max cap is
high, but there is not enough Tx in the mempool, then after one big block
many will go small. This will not be good when block reward become small
and mining revenue become dependent on Tx fee. But, if reduction is there,
max cap will come down soon and all miners will see revenue from Tx fee
again.

Proposal details: http://upalc.com/maxblocksize.php

On Wed, Aug 19, 2015 at 2:28 AM, Danny Thorpe 
wrote:

> I like the simplicity of this approach.  Demand driven response.
>
> Is there really a need to reduce the max block size at all?  It is just a
> maximum limit, not a required size for every block.  If a seasonal
> transaction surge bumps the max block size limit up a notch, what harm is
> there in leaving the max block size limit at the "high water mark"
> indefinitely, even though periods of decreased transaction volume?
>
> I'd argue to remove the reduction step, making the max block size
> calculation a monotonic increasing function. Cut the complexity in half.
>
> -Danny
>
> On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Regarding:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>>
>>
>> I am arguing with the following statement here...
>>
>> *I see problems to this approach. The biggest one I see is that a miner
>>> with 11% of hash power could sabotage block size increases by only ever
>>> mining empty blocks.*
>>
>>
>>
>> First, I would like to argue from economics' point of view. If someone
>> wants to hold back the block size increase with 11% hash power by mining
>> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
>> hash power will most likely be a pool and pool miners will find out soon
>> that they are losing Tx fees because of pool owner's intention. Hence,
>> they'll switch pool and pool owner will lose out. This is the same reason
>> why 51% attack will never happen, even if a pool gets more than 51% hash
>> power.
>>
>>
>> Next, I would like to propose a slightly modified technical solution to
>> this problem in algorithmic format...
>>
>> If more than 50% of block's size, found in the first 2000 of the last
>> difficulty period, is more than 90% MaxBlockSize
>>  Double MaxBlockSize
>> Else if more than 90% of block's size, found in the first 2000 of the
>> last difficulty period, is less than 50% MaxBlockSize
>>  Half MaxBlockSize
>> Else
>>  Keep the same MaxBlockSize
>>
>> This is how, those who want to stop increase, need to have more than 50%
>> hash power. Those who want to stop decrease, need to have more than 10%
>> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
>> this approach, not only miners, but also the end user have their say.
>> Because, end users will fill up the mempool, from where miners will take Tx
>> to fill up the blocks. Please note that, taking first 2000 of the last 2016
>> blocks is important to avoid data discrepancy among different nodes due to
>> orphan blocks. It is assumed that a chain can not be orphaned after having
>> 16 confirmation.
>>
>> Looking for comments.
>>
>>
>>
>>
>>
>> ___
>> 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] Bitcoin Core versus XT observations

[Felipe Micaroni Lalli via bitcoin-dev]

On 19/08/2015 09:24, Ken Friece via bitcoin-dev wrote:
> 5.) Not-BitcoinXT is a really terrible idea. Mike has proven time and time
> again that he will not blink or back down. The chances of Not-BitcoinXT
> gaining 25% of the hashrate are pretty much nil, so in effect, all
> Not-BitcoinXT will do is help XT reach the 75% threshold sooner and end up
> putting more people on the losing side of the fork.

If 25% or more of the hashpower are against XT, Not-BitcoinXT becomes an
important weapon for them. This was not a "bad idea", but can shake the
market.



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

Re: [bitcoin-dev] Bitcoin XT Fork

[Adam Back via bitcoin-dev]

It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.

That is not at ALL the case, and is insulting (present company excluded).

It is just that no one else is reckless enough to bypass the review
process and risk a controversial hard fork deployment war.  Myself and
many other people warned Gavin a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc.  He
ignored the warnings.  Many also warned that 75% was an optimally BAD
trigger ratio (and that in a hard fork it is not a miner vote really
as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
heard those warnings because I told them 1:1 in person or via email
and had on going conversations.  Others did too.

People can not blame bitcoin core or me, that this then predictably
happened exactly as we said it would - it was completely obvious and
predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined.  I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path.

Again any of the other proposals can easily be implemented.  They
*could* also spin up a web page and put up binaries, however no one
else was crazy enough to try to start a deployment in that way.

It is also puzzling timing - with all these BIPs and ongoing
discussion and workshops coming imminently to then release ahead of
that process where as far as I know Gavin said he was equally happy
with BIP 100 or other proposal which ever is best, and on basically
the eve of workshops planned to progress this collaboratively.
Bitcoin-XT is also under tested, people are finding privacy bugs and
other issues.  (Not even mentioning the above 75% optimally bad
parameter, and the damage to community reputation and collaborative
environment that this all causes.)

Very disappointing Gavin and Mike.

I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.

Gavin, Mike - anything to say here?

Adam

On 18 August 2015 at 19:59, Angel Leon via bitcoin-dev
 wrote:
> "How then to end this XT madness?"
>
> Instead of bashing on someone that has actually put a solution forward, make
> your own fork and see if your ideas on how to solve the issue are any
> better.
>
> As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
> block increase every day that passes, even with a "useless project" like you
> call it.
>
> Go out there and see how bitcoin is actually used.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
>  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> The "XT Fork" (better said, a POS alt*) and those behind it make not
>> even a pretense to work through process involved with bitcoin developmen
>> t.
>>
>> (*This is not intended as a slight toward any other alts, as here in
>> this post I am focusing solely on XT.)
>>
>> Instead of abandoning their useless project, or at least conceding
>> that their alt is operating essentially outside of the development
>> funnel (by this I mean BIP process), the developers of XT, via their
>> latest presentation of XT give nothing more than an attack on bitcoin
>> (albeit one that, more than anything, is designed to sidetrack real
>> discussion necessary to resolve the issues so as to achieve some level
>> of consensus in block size debates).  Curiously, XT is not even truly
>> the implementation of BIP 101; the actual proposed implementation of
>> BIP 101 as proposed at
>> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
>> ation
>> is found here: https://github.com/bitcoin/bitcoin/pull/6341
>> (It is currently a closed issue.)
>>
>> It's probably valid to call into question why Mike Hearn in particular
>> persists with this project at all, as he has been its biggest
>> cheerleader. Some reasons may be:
>> 1) His interest in attacking bitcoin in the past (seems to be a
>> recurring pattern)
>> https://bitcointalk.org/index.php?topic=333824.0
>>
>> 2) His employment (has come up before) - QinetiQ, Google, etc
>> https://plus.google.com/+MikeHearn/about - it's simply not
>> unreasonable to ask why he's pushing it so hard when nobody wants it.
>>
>> 3) Various reasons mentioned her

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Mark Friedenbach via bitcoin-dev]

I think you misunderstand my suggestion Tier. I am suggesting the same as
BtcDrak, I think:

Modify IsSuperMajority to take an (optional) mask field. Bits set in that
mask are zero'd for the purpose of the IsSuperMajority calculation. For
this vote we mask bits 0x2007.

Thus to signal support for CLTV/CSV/etc. (on Core, XT, or not-XT), you set
bit 4. On Core this would mean a minimum version of 0x8, on XT/not-XT a
minimum version of 0x2008.

However the vote is still over whether to enforce BIP 65, 68, etc. for
blocks with nVersion>=4. So when this all clears up we haven't needlessly
wasted an additional bit.

On Wed, Aug 19, 2015 at 6:22 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> We can use nVersion & 0x8 to signal support, while keeping the consensus
>> rule as nVersion >= 4, right? That way we don't waste a bit after this all
>> clears up.
>>
> What happens if XT gets 40% and this BIP gets 55%?  That gives 95% that
> accept the upgrade.  Version 3 and lower blocks need to be rejected after
> that.
>
> By advertising 0x7 for the last 3 bits, XT is effectively claiming to
> support the check locktime verify BIPs but they don't have the code.
>
> This sequence could be used, without a specific version-bits proposal.
>
> Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit
> set, then reject blocks with version numbers less than 8.
>
> At height N, if the above rule is active, then the BIP is permanent.
>
> It applies to any block with bit 0x8 set, once the 75% threshold is met.
>
> From height N + 5000 to N + 1, reject blocks which have bit 0x8 set.
>
> N could be set 1 year from now, or so.
>
>
> This gives a period of time after lock that bit 8 is kept and then a
> period where is is guaranteed to be zero.
>
> This gives software that is only watching the bit time to be upgraded and
> similarly time where the bit is set to zero before it can be reused.
>
> ___
> 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] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Mark Friedenbach via bitcoin-dev]

I am indifferent on this issue (the bit inversion), but so far only Jorge
has spoken up. I opted for this detail during implementation in order to
preserve existing semantics, even if those semantics are not commonly used.
This was the conservative choice, driven in part because I didn't want the
proposal to be held up by the other side saying "this is confusing because
it changes how sequence numbers work! it used to count up but now it counts
down!"

I can see both sides and as I said I'm indifferent, so I went with the
conservative choice of not messing with existing semantics. However if
there is strong preferences from _multiple_ people on this matter it is not
too late to change. If anyone feels strongly about this, please speak up.

On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I repeated my nit on https://github.com/bitcoin/bips/pull/179
>
>
> On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
>  wrote:
> > Please note there is now a PR for this BIP[1] and also a pull request for
> > the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
> >
> > [1] https://github.com/bitcoin/bips/pull/179
> > [2] https://github.com/bitcoin/bitcoin/pull/6564
> >
> >
> > ___
> > 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Tier Nolan via bitcoin-dev]

On Wed, Aug 19, 2015 at 4:22 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Will the adoption of BitcoinXT lead by miners? No, it won't. Actually,
> Chinese miners who control 60% of the network has already said that they
> would not adopt XT. So they must not be the leader in this revolution.
> Again, miners need to make sure they could sell their bitcoin in a good
> price, and that's not possible without support of exchanges and investors.
>

So, the exchanges get together to "encourage" the miners to start running
bitcoin-XT.  What would they do?

One scheme would be to create a taint system.  All non-XT coinbases outputs
are marked as tainted.  All outputs are tainted if any of the inputs into a
transaction are tainted.  Tainted coins can only be un-tainted by sending
0.5% of their value to the public address of one of the participating
exchanges (or to OP_RETURN).  They could slowly ratchet up the surcharge.

Exchanges in the cartel agree not to exchange tainted coins.  Even if some
still do, the tainted coins are still inherently less valuable, since fewer
exchanges accept them.

Schemes like that are the main way for non-miners to flex their muscles,
even if they seem unsavory.

Taint tracking would allow merchants to participate.  They could give less
credit for tainted bitcoins, even if the exchanges are trying to remain
neutral.  If that happens, the exchanges could run 2 prices, BTC and
BTC-tainted.

On the other hand, implementing taint machinery is a bad thing for
fungibility.

It can also be accomplished with checkpointing.  They need to create 1 big
block and then agree to checkpoint it.

A less strict rule rule could be that blocks after the first big block
count as double POW.  That means that the big block chain only needs 34% of
the hashing power to win.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XTs Tor IP blacklist downloading system has significant privacy leaks.

[Mike Hearn via bitcoin-dev]

The code was peer reviewed, in the XT project. I didn't bother submitting
other revisions to Core, obviously, as it was already rejected.

The quantity of incorrect statements in this thread is quite ridiculous.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[s7r via bitcoin-dev]

Hello Jorge, Eric,

With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
_very_ important to highlight some things. I am neither for the
blocksize increase neither against it, because plain and simple I don't
have enough arguments to take some definitive decision on this topic.
What I am angry about is spreading FUD that a fork could kill Bitcoin
and what we are experiencing now is somehow terrible.

1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
split it into 2 different coins. It is the result of an open source free
system which lacks centralization. It is just at early stage, it could
have thousands for forks (or fork attempts) during its life.

2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
something bad to Bitcoin. So far everything they have done is (or should
be) allowed. They have forked an open source software and implemented a
voting system for a consensus rule change - doesn't sound like they are
committing a crime here (either legally or morally). If they are
qualified enough to maintain the software, or if the decision is
technically correct or not is another story, and it should only matter
to whoever uses / wants to use -XT.

3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
just by 2 people forking the software and submitting a consensus rule to
a vote, it means Bitcoin is dead already and it should be worthless! We
can't go around and panic every time somebody forks Bitcoin and tries to
change something - this should be allowed by the nature of its license.
If tomorrow 5 more people fork 5 different software implementing the
bitcoin protocol and submit 5 different new consensus rules to a vote,
then what? We should all sell so the price will drop to 1 cent, because
it is somehow not good enough, not stable enough?

I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
block in the future spends all the longest dusted coins to me, out of
which I give away 50% to the miners (so the hashing power will have
incentive to use my fork).

Can they do it? YES
Will they do it? NO
Should the world care about this? NO

It's as simple as that. We cannot continue to panic that "Bitcoin as a
project" is at threat because somebody forked it.

4. By having a software fork and consensus rule submitted to vote we
actually prove how open Bitcoin is, and how there is lack of control
over it from all parties (developers, miners, engineers on the mail
list). This is reason to increase Bitcoin's value! It is a feature, not
a flaw!


It's very important for everyone in the ecosystem to understand:

- yes, Bitcoin is open source, even you can fork it tomorrow if you want
and you think enough users might follow you.

- no, it's not a requirement for 100% of the nodes in the network to be
running Core, or -XT or other implementation. The more we have, the better.

- yes, there is absolutely no authority in Bitcoin - this is what lead
to this dispute in the first place. This is the truly decentralized
nature of the software, not important if we have 10.000 full nodes or
1000 full nodes.

- no, Bitcoin won't split / die or whatever because of this fork.
Regardless what it happens, if XT will reach the threshold or not,
Bitcoin will go on just because it has some unique advantages and has no
competitor from some points of view.

- Bitcoin by its design has many many advantages, but also the
limitation that it relies on majority being honest / doing the right
thing! This is just the way it is, and the benefits it is offering
heavily win over this fundamental limitation.

On 8/19/2015 1:09 PM, Jorge Timón via bitcoin-dev wrote:
> On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
>  wrote:
>> I think that it is important to note that Bitcoin XT faces a natural
>> uphill battle.
>>
>> Since it is possible to setup atomic inter-fork coin trades. I do not
>> see how Bitcoin XT could possibly win if Satoshi decides to sell 1
>> XTBTC for BTC everyday for the first 100 days after the fork.
>>
>> In many ways Satoshi gets to decide the winning fork just by his huge
>> economic investment in Bitcoin.
>>
>>
>> Here is some simple game-theory for non-consensus forks:
>>
>> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
>> string.
>>
>> 2. Encourage all miners to false vote for the Bitcoin XT fork.
>>
>> - Now people have no-idea what % of the economy Bitcoin XT holds. -
>> Making it impossible for people to put economic faith behind Bitcoin XT.
>>
>> 3. Setup good Atomic Swap markets.
>> [...]
>> The price for XTBTC coins will plummet, Satoshi progressively dumping
>> his 1M stash over a year or it so will make sure that it doesn't recover
>> either.
> 
> Some XTBTC advocates may sell all their BTC for XTBTC and viceversa.
> But I'm afraid that

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 1:25 PM, odinn  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 08/19/2015 04:06 AM, Jorge Timón wrote:
>> On Wed, Aug 19, 2015 at 12:14 PM, odinn
>>  wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> Firstly, XT is controversial, not uncontroversial;
>>
>> XT it's just a software fork.
>
> Please read the whole pull request discussing this loathsome subject her
> e:
>
> https://github.com/bitcoin-dot-org/bitcoin.org/pull/899
>
> It was fairly detailed and conclusive. I'm not being a dumdum when I
> say that it is controversial.

And I'm not trying to be a dumdum (whatever that is) when saying that
Bitcoin XT the softfork and BIP101 implemented as a schism hardfork in
Bitcoin XT are different things. One existed before the other. And if
there wasn't a schism hardfork in the making there wouldn't be any
warning about Bitcoin XT in bitcoin.org because Bitcoin XT implemented
the same consensus rules (and I think was largely ignored).
When we say "Bitcoin XT is bad" some users read "Bitcoin Core devs
think any code fork to Bitcoin Core is back because they lose control
over it".
The second is not the case: nobody complained or cared about Bitcoin
XT when it implemented the same consensus rules.

>> BIP101 (as currently implemented in Bitcoin XT) is a Schism
>> hardfork (or an altcoin), but BIP101 could be modified to be
>> deployed like an uncontroversial hardfork (in current bip99's
>> draft, a given height plus 95% mining upgrade confirmation after
>> that).
>
> Everybody here is well aware of what this sad proposal is.  See
> detailed reply to the moaning and groaning of Hearn on this subject,
> where he claimed that "the difference between hard and soft forks is
> actually quite small, has got smaller with time and is thus hardly the
> policy-founding chasm you seem to think it is."  He was wrong, of
> course.  Thus, my reply to that, which I won't bother to quote in
> detail but which you can read here:
> https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
> 815987

I'm not sure I will learn anything by reading this link (I didn't
reading the previous link).
Have you read BIP99 already? Can you tell me where you disagree with
what's in BIP99 in one of its 2 threads?

https://github.com/bitcoin/bips/pull/181

> Given the state in which bitcoin is in now, one could say that things
> are fairly horrible, but by no means necessitating, as you put it, a
> schism hardfork.  It is clear and evidenced by my previous posts and
> others that Hearn's efforts are an attack on the bitcoin network.

Again, I'm against this Schism hardfork but maybe I'm in favor of an
Schism hardfork in the future, I don't know.
We're both against the Schism hardfork but somehow you think I'm in
favor and are trying to change my mind.
What are we even discussing about?

>>> There is no basis for further promoting XT by suggesting that it
>>> should even be tested.
>>
>> All I'm saying is that Bitcoin XT the software fork is totally
>> fine (like other alternative Bitcoin implementations).
>
> It's not totally fine at all.  It shouldn't even exist.  People are
> doing other unsuspecting users a disservice by even suggesting that it
> should be downloaded.

Right now it shouldn't be downloaded because it contains this quite
irrational Schism hardfork.
When it was only a not-up-to-date-bitcoin/master + the commits
(non-consensus changes) Hearn would like to see in Bitcoin Core nobody
was specially worried about it.

>  The big problem is
>> BIP101 being deployed as a Schism hardfork.
>
> This is certainly a problem.

So what are we discussing about?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[jl2012 via bitcoin-dev]

odinn via bitcoin-dev 於 2015-08-19 07:25 寫到:


 The big problem is

BIP101 being deployed as a Schism hardfork.


This is certainly a problem.




No, BitcoinXT won't become a Schism hardfork, or may be just for a few 
days, at most.


There is one, and only one scenario that BitcoinXT will win: it is 
supported by major exchanges, merchants, and investors, and they request 
miners to support it. When BIP101 is activated, these exchanges will 
refuse to accept or exchange tokens from the old chain. Miners in the 
old chain can't sell their newly generated coins and can't pay the 
electricity bill. They will soon realize that they are mining fool's 
gold and will be forced to switch to the new chain or sell their ASIC. 
The old chain will be abandoned and has no hope to revive without a 
hardfork to decrease the difficulty. The dust will settle in days if not 
hours.


Will the adoption of BitcoinXT lead by miners? No, it won't. Actually, 
Chinese miners who control 60% of the network has already said that they 
would not adopt XT. So they must not be the leader in this revolution. 
Again, miners need to make sure they could sell their bitcoin in a good 
price, and that's not possible without support of exchanges and 
investors.


What about that Not-Bitcoin-XT? The creator of the spoof client may stay 
anonymous, but the miners cannot. 95% of the blocks come from known 
entities and they have to be responsible to their actions. And again, 
they have real money in stake. If bitcoin is destroyed, their ASIC 
serves at best as very inefficient heaters.


So Bitcoin-XT is basically in a win-all-or-lose-all position. It all 
relies on one condition: the support of major exchanges, merchants, and 
investors. Their consensus is what really matters. With their consensus, 
that could not be a Schism hardfork. Without their consensus, nothing 
will happen.


---

Or let me analyse in a different angle. BitcoinXT is in no way similar 
to your examples of Schism hardforks. All of your examples, "ASIC-reset 
hardfork", "Anti-Block-creator hardfork", and "Anti-cabal hardfork", are 
hostile to the current biggest miners and will destroy their investment. 
These miners have no choice but stick to the original protocol so 2 
chains MUST coexist. However, BIP101 has no such effect at all and 
miners may freely switch between the forks. They will always choose the 
most valuable fork, so only one fork will survive.

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

Re: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining

[Jeff Garzik via bitcoin-dev]

As jl2012 indicated, this is an insufficient analysis.

You cannot assume that because X time passed since the last block, the
miner's internal block maker has updated the template, and from there, is
shipped out to the hashers in the field.  Further, even if you update the
block template at time Y, a hasher might return with a solution for the
block at time X, and the miner will of course publish solution X.

There are several steps of latency involved, even ignoring things such as
the miner relay network or getting US pool stratum links to a sub-pool in
China.






On Mon, Aug 17, 2015 at 4:42 AM, Luv Khemani via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
>   I previously mentioned in a post that i believe that technically nodes
> are capable of handling blocks an order of magnitude larger than the
> current blocksize limit, the only missing thing was an incentive to run
> them. I have been monitoring the blockchain for the past couple of weeks
> and am seeing that even miners who have all the incentives are for whatever
> reason struggling to download and validate much smaller blocks.
>
> The data actually paints a very grim picture of the current
> bandwidth/validating capacity of the global mining network.
>
> See the following empty blocks mined despite a non-trivial elapsed time
> from the previous block just from the past couple of days alone (Data from
> insight.bitpay.com):
>
> EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined
> by
> 
> 370165  29s  720784  Antpool
> 370160  31s  50129BTCChinaPool
> 370076  49s  469988  F2Pool
> 370059  34s  110994  Antpool
> 370057  73s  131603  Antpool
>
> We have preceding blocks as small as 50KB with 30s passing and the miner
> continues to mine empty blocks via SPV mining.
> The most glaring case is Block 370057 where despite 73s elapsing and the
> preceding block being a mere 131KB, the miner is unable to
> download/validate fast enough to include transactions in his block. Unless
> ofcourse the miner is mining empty blocks on purpose, which does not make
> sense as all of these pools do mine blocks with transactions when the
> elapsed time is greater.
>
> This is a cause for great concern, because if miners are SPV mining for a
> whole minute for <750KB blocks, at 8MB blocks, the network will just fall
> apart as a significant portion of the hashing power SPV mines throughout.
> All a single malicious miner has to do is mine an invalid block on purpose,
> let these pools SPV mine on top of them while it mines a valid block free
> of their competition. Yes, these pools deserve to lose money in that event,
> but the impact of reorgs and many block orphans for anyone not running a
> full node could be disastrous, especially more so in the XT world where
> Mike wants everyone to be running SPV nodes. I simply don't see the XT fork
> having any chance of surviving if SPV nodes are unreliable.
>
> And if these pools go out of business, it will lead to even more mining
> centralization which is already too centralized today.
>
> Can anyone representing these pools comment on why this is happening? Are
> these pools on Matt's relay network?
>
>
>
>
>
> ___
> 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] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Jeff Garzik via bitcoin-dev]

bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
discussion?

As Jorge notes, a general discussion list has existed for a long time with
little use.


On Wed, Aug 19, 2015 at 5:58 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón  wrote:
>
>> Apparently that existed already:
>> http://sourceforge.net/p/bitcoin/mailman/
>> But technical people run away from noise while non-technical people
>> chase them wherever their voices sounds more loud.
>>
>
> Regarding disruptors, if there are clear rules about what is acceptable on
> -dev, one can simply moderate out offenders. It's absolutely necessary we
> have a forum where we can share and discuss purely academic and technical
> matters. No-one can accuse censorship because all moderation would say
> would be to "take it to the other list". It's essential for all people who
> are developing and maintaining Bitcoin protocol software, or services that
> rely on it. The mailing list used to be very low volume.
>
> While we are at it, we should also think about a bitcoin-announce read
> only list which consumers of Bitcoin Core can subscribe for announcements
> about new versions of Bitcoin Core, and any critical warnings. Miners and
> service providers would particularly benefit from this. The list is
> moderated so only say Bitcoin Core commit engineers are allowed to post.
>
>
>> One thing that I would like though, is separating Bitcoin
>> Core-specific development from general bips and consensus discussions.
>>
>
> The potential downside is too much separation becomes confusing although I
> would not oppose such a change. My own suggestion would be try just a -dev
> and -discuss list and see how that goes first. It used to work well.
> Whatever the case I am very confident we need a general discussion mailing
> list.
>
>
>
> ___
> 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] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Jeff Garzik via bitcoin-dev]

A lot of this detail and worry is eliminated by simply asking BIP 102
maintainers to change to a different bit that works best for everyone.
Existing nVersion garbage will get buried in sufficient time window to
prevent anything from triggering.

Just settle on a specific standard, reserve bits for feature upgrade forks,
and move on.  There is already a rough standard proposed in sipa's gist.





On Wed, Aug 19, 2015 at 9:22 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> We can use nVersion & 0x8 to signal support, while keeping the consensus
>> rule as nVersion >= 4, right? That way we don't waste a bit after this all
>> clears up.
>>
> What happens if XT gets 40% and this BIP gets 55%?  That gives 95% that
> accept the upgrade.  Version 3 and lower blocks need to be rejected after
> that.
>
> By advertising 0x7 for the last 3 bits, XT is effectively claiming to
> support the check locktime verify BIPs but they don't have the code.
>
> This sequence could be used, without a specific version-bits proposal.
>
> Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit
> set, then reject blocks with version numbers less than 8.
>
> At height N, if the above rule is active, then the BIP is permanent.
>
> It applies to any block with bit 0x8 set, once the 75% threshold is met.
>
> From height N + 5000 to N + 1, reject blocks which have bit 0x8 set.
>
> N could be set 1 year from now, or so.
>
>
> This gives a period of time after lock that bit 8 is kept and then a
> period where is is guaranteed to be zero.
>
> This gives software that is only watching the bit time to be upgraded and
> similarly time where the bit is set to zero before it can be reused.
>
> ___
> 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] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Tier Nolan via bitcoin-dev]

On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> What problem am I missing if we just mask of the offending bits. For my
> own project which uses auxpow (and thus has weird nVersion), I also used
> the bitmasking method to get rid of auxpow version bits before making the
> standard integer comparisons to deploy BIP66 using IsSuperMajority():
>
> if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...))
> { //...}
>

What if version number 257 is used in the future?  That would appear to be
a version 1 block and fail the test.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Tier Nolan via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:10 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We can use nVersion & 0x8 to signal support, while keeping the consensus
> rule as nVersion >= 4, right? That way we don't waste a bit after this all
> clears up.
>
What happens if XT gets 40% and this BIP gets 55%?  That gives 95% that
accept the upgrade.  Version 3 and lower blocks need to be rejected after
that.

By advertising 0x7 for the last 3 bits, XT is effectively claiming to
support the check locktime verify BIPs but they don't have the code.

This sequence could be used, without a specific version-bits proposal.

Until height = N + 5000, if 950 of the last 1000 blocks have the 0x8 bit
set, then reject blocks with version numbers less than 8.

At height N, if the above rule is active, then the BIP is permanent.

It applies to any block with bit 0x8 set, once the 75% threshold is met.

>From height N + 5000 to N + 1, reject blocks which have bit 0x8 set.

N could be set 1 year from now, or so.


This gives a period of time after lock that bit 8 is kept and then a period
where is is guaranteed to be zero.

This gives software that is only watching the bit time to be upgraded and
similarly time where the bit is set to zero before it can be reused.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 11:31 AM, Jorge Timón  wrote:

> I don't think just using version=4 for cltv and friends would be a
> problem if it wasn't for the XT/nonXT issue.


What problem am I missing if we just mask of the offending bits. For my own
project which uses auxpow (and thus has weird nVersion), I also used the
bitmasking method to get rid of auxpow version bits before making the
standard integer comparisons to deploy BIP66 using IsSuperMajority():

if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...))
{ //...}
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core versus XT observations

[Milly Bitcoin via bitcoin-dev]

4.) Investors hate uncertainty, and the blocksize issue is adding a lot
of uncertainty right now, ...


That is true VC investors and people starting companies.  People who 
invest directly in Bitcoin love all this stuff.


A few weeks back a bunch of stories quoting nonsense spouted by Bitcoin 
cultists that Greece can use Bitcoin now as a replacement currency and 
store of value.  The price went about $300 so I sold a bunch of my 
coins.  Now we have these stories that Bitcoin is splitting in 2 and it 
went down to near $200 so I bought them back.


The point is that "developer attacks" have to be taken into 
consideration when discussing these things.


Russ




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

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu via bitcoin-dev]

On 19 August 2015 at 13:44, Jameson Lopp  wrote:
> It's possible to check that a transaction is cryptographically valid without
> having any blockchain data available; are you referring to a different type
> of validation?

It seems laborious to enumerate all the validations that are performed
on a transaction before it can be mined into a block, but for starters
we need to check it isn't a double-spend, and that its signatures
satisfy the outputs' pubkeys.

> If you're running an SPV node that is listening to full nodes on the
> network, you can request an unconfirmed transaction from connected peers
> after receiving the inventory message they send - that's how unconfirmed
> transactions propagate through the node network. This is not 100% proof that
> the transaction is valid for inclusion in the blockchain, but it's a very
> good indicator.

If you as an SPV node are waiting for unconfirmed transactions to be
relayed to you, you are going to have a slow start in mining those
transactions, decreasing the likelihood of receiving the mining
reward. Nodes should accept the first POW for a transaction and
discard any subsequent ones received.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp via bitcoin-dev]

On Wed, Aug 19, 2015 at 8:15 AM, Hector Chu  wrote:

> On 19 August 2015 at 13:08, Jameson Lopp  wrote:
> > If operating as an SPV node then it can check the transactions by
> querying
> > other nodes.
>
> SPV is for checking validity of transactions that have already entered
> the blockchain, as I understand it. My proposal requires nodes to
> validate transactions that are unconfirmed, and to commit to the
> validation by doing a POW on it.
>
> It's possible to check that a transaction is cryptographically valid
without having any blockchain data available; are you referring to a
different type of validation?

If you're running an SPV node that is listening to full nodes on the
network, you can request an unconfirmed transaction from connected peers
after receiving the inventory message they send - that's how unconfirmed
transactions propagate through the node network. This is not 100% proof
that the transaction is valid for inclusion in the blockchain, but it's a
very good indicator.

- Jameson


> > On an unrelated note, it sounds like your proposal will significantly
> > increase the data size of every transaction, which will create even more
> > contention for block space.
>
> If we stipulate that the coinbase fields only hold space for a single
> pubkey, then the entire block header including the two coinbases
> should only take an extra 100 bytes or so. Transactions are already
> routinely 250 bytes+. So an increase of roughly 33%.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Matt Corallo via bitcoin-dev]

Wait, why did Bitcoin-XT use that nVersion???

Definitely option 3 is much cleaner technically, and it would be nice to have 
that code implemented, but I'd be rather concerned about the size of the fork 
ballooning. It's already four separate features in one fork, which seems pretty 
big, even if the code isn't too huge. I'd probably prefer slightly to waste 
another two version bits than add a bunch of code to the fork now (maybe we can 
take just a part of the bit-based approach and allow lower version numbers 
again after the fork reaches 95%?). Either way, a proper version of the 
bit-based soft forking mechanism should be implemented sooner rather than later 
(maybe merged unused, even).

Still, it is entirely possible that there is relatively little uptake on XT and 
a competing proposal has a lot of support before we want to ship a LTV fork, so 
it may all be moot (or we could choose option 1 to fix the XT fork for them - 
easily forking off XT miners when either fork happens so XT isn't vulnerable to 
the 25% attack without needing to mine a massive transaction on Bitcoin first 
:p).

Matt

On August 19, 2015 11:34:54 AM GMT+02:00, "Jorge Timón via bitcoin-dev" 
 wrote:
>Seems like 3 is something we want to do no matter what and therefore
>is the "most future-proof" solution.
>I wonder if I can help with that (and I know there's more people that
>would be interested).
>Where's the current "non-full" nVersion bits implementation?
>Why implement a "non-full" version instead of going with the full
>implementation directly?
>
>
>On Wed, Aug 19, 2015 at 8:10 AM, Mark Friedenbach via bitcoin-dev
> wrote:
>> We can use nVersion & 0x8 to signal support, while keeping the
>consensus
>> rule as nVersion >= 4, right? That way we don't waste a bit after
>this all
>> clears up.
>>
>> On Aug 18, 2015 10:50 PM, "Peter Todd via bitcoin-dev"
>>  wrote:
>>>
>>> Deployment of the proposed CLTV, CSV, etc. soft-forks has been
>recently
>>> complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners.
>Both
>>> mine blocks with nVersion=0x2007, which would falsely trigger
>the
>>> previously suggested implementation using the IsSuperMajority()
>>> mechanism and nVersion=4 blocks. Additionally while the
>>> XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's
>>> nVersion soft-fork mechanism(3) a key component of it - fork
>>> deadlines(3) - is not implemented.
>>>
>>>
>>> XT/Not-Bitcoin-XT behavior
>>> --
>>>
>>> Both implementations produce blocks with nVersion=0x2007,
>>> or in binary: 0b001...111
>>>
>>> Neither implementation supports a fork deadline; both Not-Bitcoin-XT
>and
>>> XT will produce blocks with those bits set indefinitely under any
>>> circumstance, with the proviso that while XT has a hashing power
>>> majority, blocks it produces might not be part of the Bitcoin
>blockchain
>>> after Jan 11th 2016. (though this can flap back and forth if reorgs
>>> happen)
>>>
>>> Curiously the BIP101 draft was changed(4) at the last minute from
>using
>>> the nVersion bits compliant 0x2004 block nVersion, to using two
>more
>>> bits unnecessarily. The rational for doing this is unknown; the git
>>> commit message associated with the change suggested "compatibility
>>> concerns", but what the concerns actually were isn't specified.
>Equally
>>> even though implementing the fork deadline would be very each in the
>XT
>>> implementation, this was not done. (the XT codebase has had almost
>no
>>> peer review)
>>>
>>>
>>> Options for CLTV/CSV/etc. deployment
>>> 
>>>
>>> 1) Plain IsSuperMajority() with nVersion=4
>>>
>>> This option can be ruled out immediately due to the high risk of
>>> premature triggering, without genuine 95% miner support.
>>>
>>>
>>> 2) nVersion mask, with IsSuperMajority()
>>>
>>> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners
>would
>>> be masked away, prior to applying standard IsSuperMajority() logic:
>>>
>>> block.nVersion & ~0x2007
>>>
>>> This means that CLTV/CSV/etc. miners running Bitcoin Core would
>create
>>> blocks with nVersion=8, 0b1000. From the perspective of the
>>> CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners
>would be
>>> advertising blocks that do not trigger the soft-fork.
>>>
>>> For the perpose of soft-fork warnings, the highest known version can
>>> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT
>blocks
>>> as well as a future nVersion bits implementation. Equally,
>>> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
>>> unknown bit set.
>>>
>>> When nVersion bits is implemented by the Bitcoin protocol, the plan
>of
>>> setting the high bits to 0b001 still works. The three lowest bits
>will
>>> be unusable for some time, but will be eventually recoverable as
>>> XT/Not-Bitcoin-XT mining ceases.
>>>
>>> Equally, further IsSuperMajority() softforks can be accomplished
>with
>>> the same masking technique.

[bitcoin-dev] Bitcoin Core versus XT observations

[Ken Friece via bitcoin-dev]

1.) Most people are running XT as a vote for bigger blocks and not because
they specifically support BIP101. If Core supported bigger blocks, most XT
users would switch back to Core and XT would die.

2.) In this high stakes game of poker, XT just went all in, but Core still
has the far better hand. There are many, many scaling solutions Core could
adopt that would appease XT users enough to kill XT. Don't let perfect be
the enemy of good. The real question is whether or not anyone can provide
enough Core leadership to reach "consensus". The longer it takes for Core
to reach "consensus", the stronger XT gets.

3.) Bitcoin market price has a far greater mining centralizing effect than
larger blocks ever will. Right now, miners with reasonably efficient
hardware and energy costs (.5W/GH mining hardware, 10 cents per kilowatt
hour power, $250 BTC price) spend about half of their mining income on
electricity. If the total Bitcoin market cap is under ~5 billion at the
next halving in July 2016, it's game over for all but the most efficient
(large) miners. The mining centralization that may occur with 8MB blocks in
2016 is nothing compared to the centralization that will occur if the total
Bitcoin market cap does not grow substantially between now and the next
halving.

4.) Investors hate uncertainty, and the blocksize issue is adding a lot of
uncertainty right now, which makes the mining nightmare scenario outlined
above more likely. The entire ecosystem needs time to adjust and grow once
a Core scaling solution is adopted. Hopefully this issue will be revolved
well before the next halving in July 2016 so the market has time to adjust
and grow again.

5.) Not-BitcoinXT is a really terrible idea. Mike has proven time and time
again that he will not blink or back down. The chances of Not-BitcoinXT
gaining 25% of the hashrate are pretty much nil, so in effect, all
Not-BitcoinXT will do is help XT reach the 75% threshold sooner and end up
putting more people on the losing side of the fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu via bitcoin-dev]

On 19 August 2015 at 13:08, Jameson Lopp  wrote:
> If operating as an SPV node then it can check the transactions by querying
> other nodes.

SPV is for checking validity of transactions that have already entered
the blockchain, as I understand it. My proposal requires nodes to
validate transactions that are unconfirmed, and to commit to the
validation by doing a POW on it.

> On an unrelated note, it sounds like your proposal will significantly
> increase the data size of every transaction, which will create even more
> contention for block space.

If we stipulate that the coinbase fields only hold space for a single
pubkey, then the entire block header including the two coinbases
should only take an extra 100 bytes or so. Transactions are already
routinely 250 bytes+. So an increase of roughly 33%.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp via bitcoin-dev]

If operating as an SPV node then it can check the transactions by querying
other nodes.

On an unrelated note, it sounds like your proposal will significantly
increase the data size of every transaction, which will create even more
contention for block space.

- Jameson

On Wed, Aug 19, 2015 at 7:48 AM, Hector Chu  wrote:

> On 19 August 2015 at 12:42, Jameson Lopp  wrote:
> > If you can actually come up with a technical solution that allows for a
> node
> > operator to prove to the rest of the network that they are running an
> honest
> > full node that hosts the entire blockchain, then you can move forward
> with a
> > direct monetary incentivization proposal. To my knowledge no one has been
> > successful in that endeavor. To be more clear, your proposal would need
> to
> > be able to differentiate between a full node and a pseudonode.
> > https://github.com/basil00/PseudoNode
>
> The proof is in the validation of transactions. How can a node
> reliably validate transactions unless it has the past history of
> transactions? Entire blockchain not required or necessary, but that's
> a plus.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu via bitcoin-dev]

On 19 August 2015 at 12:42, Jameson Lopp  wrote:
> If you can actually come up with a technical solution that allows for a node
> operator to prove to the rest of the network that they are running an honest
> full node that hosts the entire blockchain, then you can move forward with a
> direct monetary incentivization proposal. To my knowledge no one has been
> successful in that endeavor. To be more clear, your proposal would need to
> be able to differentiate between a full node and a pseudonode.
> https://github.com/basil00/PseudoNode

The proof is in the validation of transactions. How can a node
reliably validate transactions unless it has the past history of
transactions? Entire blockchain not required or necessary, but that's
a plus.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A solution to increase the incentive of running a node

[Jameson Lopp via bitcoin-dev]

On Wed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin is imploding due to a failure of consensus. There has been a
> failure of consensus on how to fix the design flaw evinced by the block
> size fiasco.
>
> I disagree, but this isn't a technical claim so let's move on.

> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I suspect we need a better incentive for users to run nodes instead of
> relying solely on altruism.
>
> If you can actually come up with a technical solution that allows for a
node operator to prove to the rest of the network that they are running an
honest full node that hosts the entire blockchain, then you can move
forward with a direct monetary incentivization proposal. To my knowledge no
one has been successful in that endeavor. To be more clear, your proposal
would need to be able to differentiate between a full node and a
pseudonode. https://github.com/basil00/PseudoNode

The incentives for running a node may not be obvious to the average user,
but they are there. Rather than direct monetary incentives, they are
indirect. For one, it allows you to have a local copy of the blockchain
that you validated yourself - trustlessness is the entire point of this
system. Having local self-validated blockchain data is also essential for
any enterprise that needs to quickly access large volumes of it. The other
incentive is it supports the network. Users may feel that this is necessary
out of altruism or they may feel incentivized to protect their investments
in Bitcoin.

- Jameson



> This is the root cause of the disagreement. Not on what value the block
> size should be set to, a symptom and red herring. The whole argument
> against a block size increase is the further reduction in the node count.
>
> Therefore it makes sense to focus all energies on solving the root cause
> if we are to save Bitcoin in the short and long run. It is tempting to toy
> with the idea that a superior cryptocurrency which fixes the flaws can
> supplant Bitcoin while it dies, but there is significant merit in the
> suspicion that if Bitcoin fails the whole idea of cryptocurrencies will die
> with it for another generation.
>
> Below I will outline my thoughts on how Bitcoin can be improved so that
> more people will be incentivised to run nodes.
>
> 1. The current incentive is run like a lottery.
>
> Mining becomes more and more of a lottery the more value that Bitcoin
> acquires. Prudent and rational people don't partake in lotteries as the
> expected payoff is negative. Due to rewards at the block level, this leads
> to a winner-takes-all situation, which leads to centralisation.
>
> 2. Decentralised proof-of-work is equivalent to value.
>
> On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Nearly everyone has to agree on a change, and they have to do it without
> being forced or pressured into it.
>
> Proof-of-work is the basis of Bitcoin's security, which contributes to
> Bitcoin's value. Further, the more decentralised that proof-of-work is, the
> greater the value proposition of Bitcoin as a currency resistant to change
> by coercion.
>
> 3. Importance of a public technical forum.
>
> In order for there to be consensus, there must be a triumph of ideas over
> people. Ideas are immortal, people are not. Also, pragmatism over idealism.
> There must be no rank within the community, and no censorship or ignorance
> of others no matter their past contributions. However, it stands to reason
> that those who are more educated and experienced should be taken more
> seriously than those who are not.
>
> 4. Stronger ties between transaction validation and proof-of-work.
>
> As pointed out, mining in the pooled sense can be done without doing any
> validation whatsoever. By tying mining with transaction validation, the two
> must become inseparable.
>
> The logical conclusion of this is that instead of mining blocks per se,
> transactions must be mined individually.
>
> 5. Fees to be paid to nodes.
>
> The incentive to run nodes shall be made monetary. All the reward is
> currently going to those who do not really support the network.
>
> 50% of a transaction's fee should go to the node that mined the
> transaction.
>
> 6. The timechain.
>
> Currently it is difficult to envisage anything other than grouping
> transactions into blocks and timestamping them. The POW timestamping
> service must have sufficient time gap between blocks.
>
> Therefore as transactions are mined each one will have the possibility to
> become a block in the timechain. The POW difficulty for a block will
> obviously be much greater than the POW required to mine a single
> transaction.
>
> This also requires every mined transaction to contain a block header, in
> case it becomes a new block in the block chain. It will contain a prev
> block hash, a mer

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 08/19/2015 04:06 AM, Jorge Timón wrote:
> On Wed, Aug 19, 2015 at 12:14 PM, odinn
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> Firstly, XT is controversial, not uncontroversial;
> 
> XT it's just a software fork.


You must be really tired.

Please read the whole pull request discussing this loathsome subject her
e:

https://github.com/bitcoin-dot-org/bitcoin.org/pull/899

It was fairly detailed and conclusive. I'm not being a dumdum when I
say that it is controversial.

> BIP101 (as currently implemented in Bitcoin XT) is a Schism
> hardfork (or an altcoin), but BIP101 could be modified to be
> deployed like an uncontroversial hardfork (in current bip99's
> draft, a given height plus 95% mining upgrade confirmation after
> that).

Everybody here is well aware of what this sad proposal is.  See
detailed reply to the moaning and groaning of Hearn on this subject,
where he claimed that "the difference between hard and soft forks is
actually quite small, has got smaller with time and is thus hardly the
policy-founding chasm you seem to think it is."  He was wrong, of
course.  Thus, my reply to that, which I won't bother to quote in
detail but which you can read here:
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987

> 
>> Third, it poses major risks as a non-peer reviewed alt with a
>> number of problematic features (with the privacy problems
>> recently mentioned on this list being just one of them)
>> 
>> Fourth, it has not followed any semblance of process in terms of
>> the development funnel or BIPS process, with XT developers
>> instead choosing instead a dangerous path of hard forking bitcoin
>> while being well aware of miner voting on viable solutions which
>> have followed process.
> 
> I'm not defending the Schism hardfork being proposed. I am very 
> worried about it and I have publicly said so several times. If
> Bitcoin XT didn't contained the Schism bip101 hardfork I wouldn't 
> be so worried: users are free to use software that is less reviewed
> at their own risk.
> 
>> The following proposals http://bipsxdevs.azurewebsites.net/ 
>> regardless of what you think of any one of them, are deserving
>> of attention (BIP 100 / BIP 101) and are being voted on as you
>> read this by miners. (BIP sipa is not yet numbered, and BIP 102
>> is a backup /fallback option.)  BIP 100 is probably the best of
>> these (note, in part, it schedules a hardfork on testnet in
>> September).
> 
> It's users and not miners who decide the consensus rules.
> 
>> Contentious hard forks are bad for Bitcoin. 
>> https://bitcoin.org/en/posts/hard-fork-policy You may want to
>> read this again if you haven't recently.
> 
> You may want to read BIP99 to understand that I know this, but
> still think that Schism hardforks may be necessary in some
> situations (I don't think this one is reasonable though).


Given the state in which bitcoin is in now, one could say that things
are fairly horrible, but by no means necessitating, as you put it, a
schism hardfork.  It is clear and evidenced by my previous posts and
others that Hearn's efforts are an attack on the bitcoin network.

> 
>> There is no basis for further promoting XT by suggesting that it 
>> should even be tested.
> 
> All I'm saying is that Bitcoin XT the software fork is totally
> fine (like other alternative Bitcoin implementations).

It's not totally fine at all.  It shouldn't even exist.  People are
doing other unsuspecting users a disservice by even suggesting that it
should be downloaded.

 The big problem is
> BIP101 being deployed as a Schism hardfork.

This is certainly a problem.

> 

#GAVEL

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1GevAAoJEGxwq/inSG8CJXwH/3XX7Osr48MmcJ9mrPyOJ4Zn
WxRmdJ99mbO5KhrjD8+eRtFjURQNsQYAJ6ftnQEGaksuprSYCPQQR6WsV9mqRKZ2
/zdSz/5RjdADsjB2FDN6gWpwpyg7tzUpB6D4rCjuL1fcRmieCxwNUxnnFTbedxpE
MdT2oj9uSB7tTvU4AYs2VzJq0QeRn/c0pTJkBDwU0c4PN1tv/IQnOzmS+LnQDQJJ
eaunhpbmphRzqC9Mh8N7pD40ZyVoM5ysxVv86OaqmsOQL4W01CahQKADB4T/pBla
AOPh3LLxp7aamC9aYnBfxIaWXj28BZCwVasDkJdQ/Qg/rV5/Kze7TjJs9G2sowc=
=OvDj
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] A solution to increase the incentive of running a node

[Hector Chu via bitcoin-dev]

Bitcoin is imploding due to a failure of consensus. There has been a
failure of consensus on how to fix the design flaw evinced by the block
size fiasco.

On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I suspect we need a better incentive for users to run nodes instead of
relying solely on altruism.

This is the root cause of the disagreement. Not on what value the block
size should be set to, a symptom and red herring. The whole argument
against a block size increase is the further reduction in the node count.

Therefore it makes sense to focus all energies on solving the root cause if
we are to save Bitcoin in the short and long run. It is tempting to toy
with the idea that a superior cryptocurrency which fixes the flaws can
supplant Bitcoin while it dies, but there is significant merit in the
suspicion that if Bitcoin fails the whole idea of cryptocurrencies will die
with it for another generation.

Below I will outline my thoughts on how Bitcoin can be improved so that
more people will be incentivised to run nodes.

1. The current incentive is run like a lottery.

Mining becomes more and more of a lottery the more value that Bitcoin
acquires. Prudent and rational people don't partake in lotteries as the
expected payoff is negative. Due to rewards at the block level, this leads
to a winner-takes-all situation, which leads to centralisation.

2. Decentralised proof-of-work is equivalent to value.

On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Nearly everyone has to agree on a change, and they have to do it without
being forced or pressured into it.

Proof-of-work is the basis of Bitcoin's security, which contributes to
Bitcoin's value. Further, the more decentralised that proof-of-work is, the
greater the value proposition of Bitcoin as a currency resistant to change
by coercion.

3. Importance of a public technical forum.

In order for there to be consensus, there must be a triumph of ideas over
people. Ideas are immortal, people are not. Also, pragmatism over idealism.
There must be no rank within the community, and no censorship or ignorance
of others no matter their past contributions. However, it stands to reason
that those who are more educated and experienced should be taken more
seriously than those who are not.

4. Stronger ties between transaction validation and proof-of-work.

As pointed out, mining in the pooled sense can be done without doing any
validation whatsoever. By tying mining with transaction validation, the two
must become inseparable.

The logical conclusion of this is that instead of mining blocks per se,
transactions must be mined individually.

5. Fees to be paid to nodes.

The incentive to run nodes shall be made monetary. All the reward is
currently going to those who do not really support the network.

50% of a transaction's fee should go to the node that mined the transaction.

6. The timechain.

Currently it is difficult to envisage anything other than grouping
transactions into blocks and timestamping them. The POW timestamping
service must have sufficient time gap between blocks.

Therefore as transactions are mined each one will have the possibility to
become a block in the timechain. The POW difficulty for a block will
obviously be much greater than the POW required to mine a single
transaction.

This also requires every mined transaction to contain a block header, in
case it becomes a new block in the block chain. It will contain a prev
block hash, a merkle tree of mined transactions in the mempool, a nonce and
two separate coinbase addresses. One coinbase output will be used to pay
the miner of the transaction, and the other will also pay the miner the
(50%) transaction fees of the other transactions in the block, if the POW
on the transaction also satisfies the POW difficulty of a block.

7. Transaction POW difficulty.

Block POW difficulty can remain as it currently does, to produce blocks at
approximately 10 minute intervals.

Transaction POW difficulty affects the rate at which mined transactions are
produced.

Now, since each transaction contains a prev block hash an important
decision to make is whether to mandate that all transactions within a block
contain the same prev block hash, and that the prev block so referenced is
the immediate previous ancestor block, or whether any transaction may be
admitted into a block so long as the prev block referenced by the
transaction is any previous ancestor in the main chain.

If the former, then any transactions which don't make it into a block must
be re-mined for inclusion in the next block. Hence this more closely
enforces the rate at which transactions are mined and included.

The rate at which transactions are mined and included in blocks is
obviously proportional to the block size. The transaction POW difficulty
can be adjusted periodically so that the transaction rate or block size
follo

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 12:14 PM, odinn  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Firstly, XT is controversial, not uncontroversial;

XT it's just a software fork.
BIP101 (as currently implemented in Bitcoin XT) is a Schism hardfork
(or an altcoin), but BIP101 could be modified to be deployed like an
uncontroversial hardfork (in current bip99's draft, a given height
plus 95% mining upgrade confirmation after that).

> Third, it poses major risks as a non-peer reviewed alt with a number
> of problematic features (with the privacy problems recently mentioned
> on this list being just one of them)
>
> Fourth, it has not followed any semblance of process in terms of the
> development funnel or BIPS process, with XT developers instead
> choosing instead a dangerous path of hard forking bitcoin while being
> well aware of miner voting on viable solutions which have followed
> process.

I'm not defending the Schism hardfork being proposed. I am very
worried about it and I have publicly said so several times.
If Bitcoin XT didn't contained the Schism bip101 hardfork I wouldn't
be so worried: users are free to use software that is less reviewed at
their own risk.

> The following proposals
> http://bipsxdevs.azurewebsites.net/
> regardless of what you think of any one of them, are deserving of
> attention (BIP 100 / BIP 101) and are being voted on as you read this
> by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup
> /fallback option.)  BIP 100 is probably the best of these (note, in
> part, it schedules a hardfork on testnet in September).

It's users and not miners who decide the consensus rules.

> Contentious hard forks are bad for Bitcoin.
> https://bitcoin.org/en/posts/hard-fork-policy
> You may want to read this again if you haven't recently.

You may want to read BIP99 to understand that I know this, but still
think that Schism hardforks may be necessary in some situations (I
don't think this one is reasonable though).

> There is no basis for further promoting XT by suggesting that it
> should even be tested.

All I'm saying is that Bitcoin XT the software fork is totally fine
(like other alternative Bitcoin implementations). The big problem is
BIP101 being deployed as a Schism hardfork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 12:34 PM,   wrote:
> You misunderstand my intention. The experiment is not about a random
> hardfork. It's about a block size increase hardfork.

One of your goals is "show the world that reaching consensus for a
Bitcoin hardfork is possible", right?
BIP99 can achieve that goal without touching the block size (thus
probably less controversial).

> The data will help us
> to design further hardfork on block size.

The data can be collected using testchains. See #6382

> To make it less controversial, the size must not be too big.

That makes the data less interesting, doesn't it?

> To allow a meaningful experiment, the size must not be too small.
> Technically we could make it 1.01MB but that defeats all objectives I listed
> and there is no point to do it.

It wouldn't defeat the "show the world that reaching consensus for a
Bitcoin hardfork is possible" objective though. But again, we don't
need to touch the block size to achieve that goal.

> That's why I suggest 1.5MB.

But that wouldn't be uncontroversial (unless it was accompanied with
data that somehow quantifies the risks, in which case maybe another
bigger size is acceptable).

>>> 1. Today, we all agree that some kind of block size hardfork will happen
>>> on
>>> t1=*1 June 2016*
>>
>>
>> I disagree with this. I think it should be schedule at least a year
>> after it is deployed in the newest versions.
>> Maybe there's something special about June 2016 that I'm missing.
>
>
> I hope the fork could be done before the halving, which (hopefully) we may
> have a new bitcoin rush
>
> There was only 2 months for the BIP50 hardfork. You may argue that's a "bug
> fix" but practically there is no difference: people not fixing the bug in 2
> months was forked off. Four months of grace period (Feb to June 2016) is
> already a double of that.

Yes, emergency hardforks are a different case as explained in BIP99's draft.
In any case, " we all agree that some kind of block size hardfork will
happen on June 2016" it's clearly false since I can find many
counter-examples besides myself.

> Also, if we could have zero grace period for softfork, why must we have a
> ultra-long period for hardfork? (Unless you also agree to have an 1-year
> grace period for softfork. I don't buy the "softfork is safer than hardfork"
> theory. The recent BIP66 fork has clearly shown why it is wrong:
> non-upgrading full nodes are not full nodes)

I don't think giving 1 year for "everybody in the world" to upgrade is
an "ultra-long" period.
I'm proposing 5 years for the hardfork proposed in bip99.
I do think softforks are safer than hardforks, that doesn't mean
softforks don't have serious risks as well.

> The problem is many people won't update until they must do so. So 4 months
> or 1 year make little difference

I disagree with this conclusion as well (it doesn't follow from the
first sentence, non sequitur).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Jorge Timón via bitcoin-dev]

I repeated my nit on https://github.com/bitcoin/bips/pull/179


On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
 wrote:
> Please note there is now a PR for this BIP[1] and also a pull request for
> the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
>
> [1] https://github.com/bitcoin/bips/pull/179
> [2] https://github.com/bitcoin/bitcoin/pull/6564
>
>
> ___
> 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] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[jl2012 via bitcoin-dev]

Jorge Timón 於 2015-08-19 05:24 寫到:

On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
 wrote:
As I understand, there is already a consensus among core dev that 
block size
should/could be raised. The remaining questions are how, when, how 
much, and

how fast. These are the questions for the coming Bitcoin Scalability
Workshops but immediate consensus in these issues are not guaranteed.

Could we just stop the debate for a moment, and agree to a scheduled
experimental hardfork?

Objectives (by order of importance):

1. The most important objective is to show the world that reaching 
consensus
for a Bitcoin hardfork is possible. If we could have a successful one, 
we

would have more in the future


Apart from classifying all potential consensus rule changes and
recommend a deployment path for each case, deploying an
uncontroversial hardfork is one of the main goals of bip99:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html


2. With a slight increase in block size, to collect data for future
hardforks


The uncontroversial hardfork doesn't need to change the maximum block
size: there's plenty of hardfork proposals out there, some of them
very well tested (like the proposed hardfork in bip99).


You misunderstand my intention. The experiment is not about a random 
hardfork. It's about a block size increase hardfork. The data will help 
us to design further hardfork on block size.


To make it less controversial, the size must not be too big.

To allow a meaningful experiment, the size must not be too small. 
Technically we could make it 1.01MB but that defeats all objectives I 
listed and there is no point to do it.


That's why I suggest 1.5MB.

1. Today, we all agree that some kind of block size hardfork will 
happen on

t1=*1 June 2016*


I disagree with this. I think it should be schedule at least a year
after it is deployed in the newest versions.
Maybe there's something special about June 2016 that I'm missing.


I hope the fork could be done before the halving, which (hopefully) we 
may have a new bitcoin rush


There was only 2 months for the BIP50 hardfork. You may argue that's a 
"bug fix" but practically there is no difference: people not fixing the 
bug in 2 months was forked off. Four months of grace period (Feb to June 
2016) is already a double of that.


Also, if we could have zero grace period for softfork, why must we have 
a ultra-long period for hardfork? (Unless you also agree to have an 
1-year grace period for softfork. I don't buy the "softfork is safer 
than hardfork" theory. The recent BIP66 fork has clearly shown why it is 
wrong: non-upgrading full nodes are not full nodes)


The problem is many people won't update until they must do so. So 4 
months or 1 year make little difference

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

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Jorge Timón via bitcoin-dev]

I don't think just using version=4 for cltv and friends would be a
problem if it wasn't for the XT/nonXT issue.

On Wed, Aug 19, 2015 at 12:20 PM, Btc Drak  wrote:
> On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón
>  wrote:
>>
>> Seems like 3 is something we want to do no matter what and therefore
>> is the "most future-proof" solution.
>> I wonder if I can help with that (and I know there's more people that
>> would be interested).
>> Where's the current "non-full" nVersion bits implementation?
>> Why implement a "non-full" version instead of going with the full
>> implementation directly?
>
>
> There is a simple answer to this, convenience: versionbits has not been
> implemented yet, and I believe the BIP is still in review stage. As it seems
> likely the remaining locktime pull requests will be ready by or before the
> next major release, we need a deployment method if versionbits is not ready
> (which is unlikely because no-one appears to be working on it at the
> moment). Pieter indicated he is OK with another IsSuperMajority() rollout in
> the interim. Personally, I dont think we should let perfection be the enemy
> of progress here because at the end of the day, the deployment method is
> less important than the actual featureset being proposed.
>
> That said, the features in the next soft fork proposal are all related and
> best deployed as one featureset softfork, but moving forward, versionbits
> seems essential to be able to roll out multiple features in parallel without
> waiting for activation and enforcement each time.
>
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 11:58 AM, Btc Drak  wrote:
> On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón  wrote:
>>
>> Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
>> But technical people run away from noise while non-technical people
>> chase them wherever their voices sounds more loud.
>
>
> Regarding disruptors, if there are clear rules about what is acceptable on
> -dev, one can simply moderate out offenders. It's absolutely necessary we
> have a forum where we can share and discuss purely academic and technical
> matters. No-one can accuse censorship because all moderation would say would
> be to "take it to the other list". It's essential for all people who are
> developing and maintaining Bitcoin protocol software, or services that rely
> on it. The mailing list used to be very low volume.

I don't disagree with anything you have said. But I think that having
a list specific to Bitcoin Core development will make defining the
"clear rules" easier.

> While we are at it, we should also think about a bitcoin-announce read only
> list which consumers of Bitcoin Core can subscribe for announcements about
> new versions of Bitcoin Core, and any critical warnings. Miners and service
> providers would particularly benefit from this. The list is moderated so
> only say Bitcoin Core commit engineers are allowed to post.

Not sure if necessary but not opposed to this either.

>> One thing that I would like though, is separating Bitcoin
>> Core-specific development from general bips and consensus discussions.
>
>
> The potential downside is too much separation becomes confusing although I
> would not oppose such a change. My own suggestion would be try just a -dev
> and -discuss list and see how that goes first. It used to work well.
> Whatever the case I am very confident we need a general discussion mailing
> list.

As said, that list already exists, it's just that nobody uses it:
http://sourceforge.net/p/bitcoin/mailman/bitcoin-list/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Seems like 3 is something we want to do no matter what and therefore
> is the "most future-proof" solution.
> I wonder if I can help with that (and I know there's more people that
> would be interested).
> Where's the current "non-full" nVersion bits implementation?
> Why implement a "non-full" version instead of going with the full
> implementation directly?


There is a simple answer to this, convenience: versionbits has not been
implemented yet, and I believe the BIP is still in review stage. As it
seems likely the remaining locktime pull requests will be ready by or
before the next major release, we need a deployment method if versionbits
is not ready (which is unlikely because no-one appears to be working on it
at the moment). Pieter indicated he is OK with another IsSuperMajority()
rollout in the interim. Personally, I dont think we should let perfection
be the enemy of progress here because at the end of the day, the deployment
method is less important than the actual featureset being proposed.

That said, the features in the next soft fork proposal are all related and
best deployed as one featureset softfork, but moving forward, versionbits
seems essential to be able to roll out multiple features in parallel
without waiting for activation and enforcement each time.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Firstly, XT is controversial, not uncontroversial;
Second, this issue has been beat to death quite a while ago
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987
Third, it poses major risks as a non-peer reviewed alt with a number
of problematic features (with the privacy problems recently mentioned
on this list being just one of them)
Fourth, it has not followed any semblance of process in terms of the
development funnel or BIPS process, with XT developers instead
choosing instead a dangerous path of hard forking bitcoin while being
well aware of miner voting on viable solutions which have followed
process.

The following proposals
http://bipsxdevs.azurewebsites.net/
regardless of what you think of any one of them, are deserving of
attention (BIP 100 / BIP 101) and are being voted on as you read this
by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup
/fallback option.)  BIP 100 is probably the best of these (note, in
part, it schedules a hardfork on testnet in September).

Contentious hard forks are bad for Bitcoin.
https://bitcoin.org/en/posts/hard-fork-policy
You may want to read this again if you haven't recently.

There is no basis for further promoting XT by suggesting that it
should even be tested.

#GAVEL

On 08/19/2015 02:29 AM, Jorge Timón via bitcoin-dev wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev 
>  wrote:
>> 
>> Ya, so?  All that means is that the experiment might reach the
>> hard fork tipping point faster than mainnet would. Verifying that
>> the network can handle such transitions, and how larger blocks
>> affect the network, is the point of testing.
>> 
>> And when I refer to testnet, I mean the public global testnet
>> blockchain, not in-house isolated networks like
>> testnet-in-a-box.
> 
> I would expect any uncontroversial hardfork to be deployed in
> testnet3 before it is deployed in bitcoin's main chain.
> 
> In any case, you can already do these tests using 
> https://github.com/bitcoin/bitcoin/pull/6382 Note that even if the
> new testchains are regtest-like (ie cheap proof of work) you don't
> need to test them "in-a-box": you can run them from many different
> places. Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have
> been perfectly made using #6382, it just didn't existed at the
> time. ___ bitcoin-dev
> mailing list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJV1FcVAAoJEGxwq/inSG8CAd8H/R9khvHJJaNKrq7tjzksyc6V
jNN8ApaYUOE/i+goKd7XaeW0LM0aUC5vdqOCud632zb9XGo6awlk0fML4FV+wsE0
e5EfVDKZJxQ7zbaNCXXKTUfC+XRpJlhJgfF9jDgTsKv2l8fALbz+U6tn65Ke8F4+
9A4jJCe8yjttjBkX+8wLsSeDkDsPxo7f29rPfI6YMtN4MYbdxGiLjrTuRWrVje8q
l+3IFxrqGwKQl3LygRQHmLosvcW8UZzGYIM7hCleE9NUpc9TdpyTXPB3+9O9h4ty
5vY9jZ6t2Ww9CeljzD8S+1Nycz7sHqeoBCie+WexY7aT/QV2WQxFp4qnpO7PMSs=
=UNYA
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin XT 0.11A

[Jorge Timón via bitcoin-dev]

On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
 wrote:
> I think that it is important to note that Bitcoin XT faces a natural
> uphill battle.
>
> Since it is possible to setup atomic inter-fork coin trades. I do not
> see how Bitcoin XT could possibly win if Satoshi decides to sell 1
> XTBTC for BTC everyday for the first 100 days after the fork.
>
> In many ways Satoshi gets to decide the winning fork just by his huge
> economic investment in Bitcoin.
>
>
> Here is some simple game-theory for non-consensus forks:
>
> 1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
> string.
>
> 2. Encourage all miners to false vote for the Bitcoin XT fork.
>
> - Now people have no-idea what % of the economy Bitcoin XT holds. -
> Making it impossible for people to put economic faith behind Bitcoin XT.
>
> 3. Setup good Atomic Swap markets.
> [...]
> The price for XTBTC coins will plummet, Satoshi progressively dumping
> his 1M stash over a year or it so will make sure that it doesn't recover
> either.

Some XTBTC advocates may sell all their BTC for XTBTC and viceversa.
But I'm afraid that what most currency speculators (thus most Bitcoin
holders) will do is just sell both all their BTC and XTBTC for fiat,
and wait for things to settle before deciding whether to re-enter or
not.
This could result in both currencies' prices going down to 1 usd cent,
nobody knows.

> I cannot see how Bitcoin XT is but-not in a extremely weak position from
> game theory.

Unfortunately it also puts Bitcoin core in an extremely weaker
position than it was before the Schism hardfork.
Even if XT fails in making blocks bigger, it may destroy Bitcoin.
That's probably not the goal of Bitcoin XT, but I don't think Andresen
and Hearn fully undesrtand the risks of a Schism hardfork (not to
mention their "followers" in the interwebs).

Since we want to discard the assumption that Hearn and Andresen want
to make Bitcoin centralized or destroy it, it's reasonable to conclude
that have serious misunderstandings on how the global consensus works.
This is consistent with some of their strong positions on Bitcoin Core
policy defaults (like maintaining the first seen spending-conflict
replacement policy [the dumbest possible one after "last seen"]
forever).

On Mon, Aug 17, 2015 at 2:33 PM, Eric Lombrozo via bitcoin-dev
 wrote:
> Or can’t you create a transaction that’s still within the op count and sig 
> ops limits but is larger than 1MB?

Yes, it seems the simplest way to permanently separate your BTC from
your XTBTC is to move them all in transactions bigger than 1MB. You
may need too many outputs to increase the size (thus also hurting the
utxo size in Bitcoin XT), but that's just a side effect.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Btc Drak via bitcoin-dev]

On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón  wrote:

> Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
> But technical people run away from noise while non-technical people
> chase them wherever their voices sounds more loud.
>

Regarding disruptors, if there are clear rules about what is acceptable on
-dev, one can simply moderate out offenders. It's absolutely necessary we
have a forum where we can share and discuss purely academic and technical
matters. No-one can accuse censorship because all moderation would say
would be to "take it to the other list". It's essential for all people who
are developing and maintaining Bitcoin protocol software, or services that
rely on it. The mailing list used to be very low volume.

While we are at it, we should also think about a bitcoin-announce read only
list which consumers of Bitcoin Core can subscribe for announcements about
new versions of Bitcoin Core, and any critical warnings. Miners and service
providers would particularly benefit from this. The list is moderated so
only say Bitcoin Core commit engineers are allowed to post.


> One thing that I would like though, is separating Bitcoin
> Core-specific development from general bips and consensus discussions.
>

The potential downside is too much separation becomes confusing although I
would not oppose such a change. My own suggestion would be try just a -dev
and -discuss list and see how that goes first. It used to work well.
Whatever the case I am very confident we need a general discussion mailing
list.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

[Jorge Timón via bitcoin-dev]

On Tue, Aug 18, 2015 at 11:46 AM, NxtChg via bitcoin-dev
 wrote:
> Eric,
>
>>FWIW...
>
> These are all good points and I agree with most of them. Yes, the block size 
> debate is a lucky historical accident, which makes it easier for XT to pull 
> off the split, but that's not the point.
>
> The point is, the split _must_ happen because the centralized governance of 
> Bitcoin became a bigger problem than the risks of a fork or larger blocks.
>
> You cannot govern a decentralized currency with a centralized entity.

Nobody has complained about Bitcoin-XT (nor libbitcoin, nor libcoin,
nor against any other of the multiple alternative implementations of
bitcoin).
Please, understand that people are worried about the schism hardfork,
not about the software fork (which happened long ago when some of
Hearn's changes were reverted due to security concerns). If Bitcoin-XT
didn't had a schism hardfork, nobody would be calling it "an altcoin".
For consensus rules we use "the implementation is the specification"
as a principle for multiple reasons. By separating libconsensus (a
work in progress [far less progress than I would like]) we remove
Bitcoin Core's privileged position: Bitcoin Core wouldn't be "the
specification of the consensus rules" anymore, just a reference
implementation that is not "consensus-safer" compared to alternative
implementations (since they can use libconsensus directly [or a
software fork of it in the case of a reasonable schism hardfork]).

> That's why we shouldn't fear hard forks - they are the new reality, and if we 
> cannot set up a reliable process for them to happen then there _is_ no 
> decentralized Bitcoin and we all might as well just give up and go home.

We have many reasons to fear schism hardforks (
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki#Schism1_hardforks
), even though they may be unavoidable at some point (ie for an
ASIC-reset hardfork).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

[Jorge Timón via bitcoin-dev]

Seems like 3 is something we want to do no matter what and therefore
is the "most future-proof" solution.
I wonder if I can help with that (and I know there's more people that
would be interested).
Where's the current "non-full" nVersion bits implementation?
Why implement a "non-full" version instead of going with the full
implementation directly?


On Wed, Aug 19, 2015 at 8:10 AM, Mark Friedenbach via bitcoin-dev
 wrote:
> We can use nVersion & 0x8 to signal support, while keeping the consensus
> rule as nVersion >= 4, right? That way we don't waste a bit after this all
> clears up.
>
> On Aug 18, 2015 10:50 PM, "Peter Todd via bitcoin-dev"
>  wrote:
>>
>> Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
>> complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
>> mine blocks with nVersion=0x2007, which would falsely trigger the
>> previously suggested implementation using the IsSuperMajority()
>> mechanism and nVersion=4 blocks. Additionally while the
>> XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's
>> nVersion soft-fork mechanism(3) a key component of it - fork
>> deadlines(3) - is not implemented.
>>
>>
>> XT/Not-Bitcoin-XT behavior
>> --
>>
>> Both implementations produce blocks with nVersion=0x2007,
>> or in binary: 0b001...111
>>
>> Neither implementation supports a fork deadline; both Not-Bitcoin-XT and
>> XT will produce blocks with those bits set indefinitely under any
>> circumstance, with the proviso that while XT has a hashing power
>> majority, blocks it produces might not be part of the Bitcoin blockchain
>> after Jan 11th 2016. (though this can flap back and forth if reorgs
>> happen)
>>
>> Curiously the BIP101 draft was changed(4) at the last minute from using
>> the nVersion bits compliant 0x2004 block nVersion, to using two more
>> bits unnecessarily. The rational for doing this is unknown; the git
>> commit message associated with the change suggested "compatibility
>> concerns", but what the concerns actually were isn't specified. Equally
>> even though implementing the fork deadline would be very each in the XT
>> implementation, this was not done. (the XT codebase has had almost no
>> peer review)
>>
>>
>> Options for CLTV/CSV/etc. deployment
>> 
>>
>> 1) Plain IsSuperMajority() with nVersion=4
>>
>> This option can be ruled out immediately due to the high risk of
>> premature triggering, without genuine 95% miner support.
>>
>>
>> 2) nVersion mask, with IsSuperMajority()
>>
>> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
>> be masked away, prior to applying standard IsSuperMajority() logic:
>>
>> block.nVersion & ~0x2007
>>
>> This means that CLTV/CSV/etc. miners running Bitcoin Core would create
>> blocks with nVersion=8, 0b1000. From the perspective of the
>> CLTV/CSV/etc.  IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be
>> advertising blocks that do not trigger the soft-fork.
>>
>> For the perpose of soft-fork warnings, the highest known version can
>> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
>> as well as a future nVersion bits implementation. Equally,
>> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
>> unknown bit set.
>>
>> When nVersion bits is implemented by the Bitcoin protocol, the plan of
>> setting the high bits to 0b001 still works. The three lowest bits will
>> be unusable for some time, but will be eventually recoverable as
>> XT/Not-Bitcoin-XT mining ceases.
>>
>> Equally, further IsSuperMajority() softforks can be accomplished with
>> the same masking technique.
>>
>> This option does complicate the XT-coin protocol implementation in the
>> future. But that's their problem, and anyway, the maintainers
>> (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks
>> and/or appear to be in favor of a more centralized mandatory update
>> schedule.(6)
>>
>>
>> 3) Full nVersion bits implementation
>>
>> The most complex option would be to deploy via full nVersion bits
>> implementation using flag bit #4 to trigger the fork. Compliant miners
>> would advertise 0x2008 initially, followed by 0x2000 once the
>> fork had triggered. The lowest three bits would be unusable for forks
>> for some time, although they could be eventually recovered as
>> XT/Not-Bitcoin-XT mining ceases.
>>
>> The main disadvantage of this option is high initial complexity - the
>> reason why IsSuperMajority() was suggested for CLTV/CSV in the first
>> place. That said, much of the code required has been implemented in XT
>> for the BIP101 hard-fork logic, although as mentioned above, the code
>> has had very little peer review.
>>
>>
>> References
>> --
>>
>> 1) https://github.com/bitcoinxt/bitcoinxt
>>
>> 2) https://github.com/xtbit/notbitcoinxt
>>
>> 3) "Version bits proposal",
>> Pieter Wuille, May 26th 2015, Bitcoin-development mailing

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón via bitcoin-dev]

On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
 wrote:
>
> Ya, so?  All that means is that the experiment might reach the hard fork 
> tipping point faster than mainnet would. Verifying that the network can 
> handle such transitions, and how larger blocks affect the network, is the 
> point of testing.
>
> And when I refer to testnet, I mean the public global testnet blockchain, not 
> in-house isolated networks like testnet-in-a-box.

I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.

In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
Note that even if the new testchains are regtest-like (ie cheap proof
of work) you don't need to test them "in-a-box": you can run them from
many different places.
Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
perfectly made using #6382, it just didn't existed at the time.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

[Jorge Timón via bitcoin-dev]

On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
 wrote:
> As I understand, there is already a consensus among core dev that block size
> should/could be raised. The remaining questions are how, when, how much, and
> how fast. These are the questions for the coming Bitcoin Scalability
> Workshops but immediate consensus in these issues are not guaranteed.
>
> Could we just stop the debate for a moment, and agree to a scheduled
> experimental hardfork?
>
> Objectives (by order of importance):
>
> 1. The most important objective is to show the world that reaching consensus
> for a Bitcoin hardfork is possible. If we could have a successful one, we
> would have more in the future

Apart from classifying all potential consensus rule changes and
recommend a deployment path for each case, deploying an
uncontroversial hardfork is one of the main goals of bip99:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html

> 2. With a slight increase in block size, to collect data for future
> hardforks

The uncontroversial hardfork doesn't need to change the maximum block
size: there's plenty of hardfork proposals out there, some of them
very well tested (like the proposed hardfork in bip99).

> 1. Today, we all agree that some kind of block size hardfork will happen on
> t1=*1 June 2016*

I disagree with this. I think it should be schedule at least a year
after it is deployed in the newest versions.
Maybe there's something special about June 2016 that I'm missing.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork)

[Jorge Timón via bitcoin-dev]

On Wed, Aug 19, 2015 at 10:25 AM, Btc Drak via bitcoin-dev
 wrote:
> I see no problem with Satoshi returning to participate in peer review.
> Bitcoin development has long since migrated from a single authority figure
> to a system of technical peer review consensus. What is more of a problem is
> this list has degenerated to a generalised discussion forum where any
> academic or technical debate is drowned out by noise.
>
> I joined this list so I keep be abreast of bitcoin's technical development
> and proposals. I am sure many ecosystem stakeholders and participants also
> once used this list to keep abreast of technical developments and academic
> research. It would be splendid indeed if we could return to some semblance
> of decorum that once existed.
>
> Do you think we could have a "bitcoin-discuss" list where specifically
> non-technical discussion can happen leaving this list for more academic and
> technical debate together with setting a clear mandate about what is on
> topic for this list?

Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
But technical people run away from noise while non-technical people
chase them wherever their voices sounds more loud.

One thing that I would like though, is separating Bitcoin
Core-specific development from general bips and consensus discussions.
I know, the bitcoin-consensus mailing list will probably still be
noisy, but at least we will have a non-noisy one and the ability to
say things like "Bitcoin Core's default policy is off-topic in
bitcoin-consensus" in the noisy one...
Also developers of alternative implementations may not be interested
in Bitcoin Core-specific things, so they may want to subscribe to
bitcoin-consensus and unsubscribe from bitcoin-dev.

I already told this to some people and everybody seemed to be positive
about this change, at most sometimes skeptics about the potential
benefits.

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

Re: [bitcoin-dev] Bitcoin XT Fork

[Btc Drak via bitcoin-dev]

I see no problem with Satoshi returning to participate in peer review.
Bitcoin development has long since migrated from a single authority figure
to a system of technical peer review consensus. What is more of a problem
is this list has degenerated to a generalised discussion forum where any
academic or technical debate is drowned out by noise.

I joined this list so I keep be abreast of bitcoin's technical development
and proposals. I am sure many ecosystem stakeholders and participants also
once used this list to keep abreast of technical developments and academic
research. It would be splendid indeed if we could return to some semblance
of decorum that once existed.

Do you think we could have a "bitcoin-discuss" list where specifically
non-technical discussion can happen leaving this list for more academic and
technical debate together with setting a clear mandate about what is on
topic for this list?


On Tue, Aug 18, 2015 at 12:52 PM, Micha Bailey via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> My interpretation is that he's saying Satoshi wouldn't be welcome to
> return as Satoshi, because whatever he did/said would inevitably end up
> being treated with authority, which shouldn't be the case.
>
>
> On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I honestly don't understand your position, but I get the sense that you
>> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
>> active in development again?
>>
>> Warren
>> On Aug 17, 2015 1:38 PM, "Oliver Egginger"  wrote:
>>
>>> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
>>> > This bitcoin-dev list restarted with an empty subscriber list on June
>>> > 21st, 2015.  So whoever posted from sato...@vistomail.com
>>> >  subscribed and verified the address
>>> > recently.  Do you propose that we manually approve new subscribers to
>>> > prevent these kind of "abuses" as you put it?
>>>
>>> I would simply block the creators old email addresses. Easy with
>>> Mailman. I thought that would be a good and easy approach, but maybe I'm
>>> wrong.
>>>
>>> Some believes it is possible that the email could be genuine. Some say
>>> that only the content is important. I have closely followed. An
>>> interesting discussion. Thank you all so far.
>>>
>>> But let's say the poster would be the real Satoshi. Would we discuss his
>>> posting if he would not claim to be Satoshi? There are a lot of smart
>>> people on this list, which publish occasionally quite useful ideas. But
>>> much of this is hardly the subject of greater discussion. Especially not
>>> when it comes to the blocksize. On this subject almost everything has
>>> been already said. But not yet by everyone. Especially not by Satoshi.
>>>
>>> Satoshi would have a decisive influence on the community. I'm sure. To
>>> say it does not matter who's talking is maybe genteelly but a little bit
>>> remote from everyday life. Or not? Satoshi is the creator. What he says
>>> is in the newspaper and is perceived by all. If he says it's okay to do
>>> nothing as long as we stand together, then people have the courage to do
>>> maybe something dangerous or something wrong. Then people only follow
>>> their hearts. Otherwise they follow their fear. It is a paradox of the
>>> human nature that some type of Dictatorship can make you free. I say
>>> some type, not any type. Enough said.
>>>
>>> - oliver
>>>
>>>
> ___
> 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