is Greg Maxwell wrong about the block increase?

[johnyj]

If you can stop assuming everyone is an idiot but you then we can have a conversation.

Just maybe you're not as smart as everyone else? Ever think of that?

FYI, the ability to choose different implementation is the first step of having decentralized development. If you cant grasp this fact, go think about it some more. Having how many numbers of devs behind an implementation does not matter if you cant have another to choose.

Also are you ignoring my other question? That blocksize increase cause more centralization in the bitcoin network?
 

 You are basically proving that you have the same mindset as Gavin: The smartest should be the king and rule others. Unfortunately, people vote with their foot when they feel that you are smarter 

[1713941435]

1713941435

[1713941435]

1713941435

[1713941435]

1713941435

[1713941435]

1713941435

[meono]

If you can stop assuming everyone is an idiot but you then we can have a conversation.

Just maybe you're not as smart as everyone else? Ever think of that?

FYI, the ability to choose different implementation is the first step of having decentralized development. If you cant grasp this fact, go think about it some more. Having how many numbers of devs behind an implementation does not matter if you cant have another to choose.

Also are you ignoring my other question? That blocksize increase cause more centralization in the bitcoin network?
 

 You are basically proving that you have the same mindset as Gavin: The smartest should be the king and rule others. Unfortunately, people vote with their foot when they feel that you are smarter  

You sound like any many of those antiXT dummies. Ignoring question while making dumb statements as facts.

Btw what happens to your "omg these mining corps are not in satoshi's vision" ? now that BIP100 will even give them more control?  ....

I guess you're just jumping on whatever bandwagon that oppose bitcoinXT huh? What a joke you are.

[jonald_fyookball]

People seem confused. The protocol is decentralized, and ideally will stay that way. The development process has never been and does not need to be decentralized. That's completely irrelevant to the protocol. People are free to develop whatever they want, but the purpose of consensus is to make contentious hard forks unlikely. I have no problem with a non-Core development team, but I wouldn't expect that severely untested code which has not been achieved through any formal consensus would be backed by even a modicum of hashing power.

You are right that they are two different things, but why shouldn't we try to also decentralize the development process.  Don't you see a benefit in that?
There is certainly turmoil right now because large segments of the Bitcoin community don't agree with how the centralized process is going.

 You are basically proving that you have the same mindset as Gavin: The smartest should be the king and rule others. Unfortunately, people vote with their foot when they feel that you are smarter 

From what I've observed, Gavin doesn't have that attitude at all.  That's why he stepped down from being the lead developer.
Actions speak louder than words.  If he was still "ruling", he would have already implemented Bip 101.   

[poeEDgar]

People seem confused. The protocol is decentralized, and ideally will stay that way. The development process has never been and does not need to be decentralized. That's completely irrelevant to the protocol. People are free to develop whatever they want, but the purpose of consensus is to make contentious hard forks unlikely. I have no problem with a non-Core development team, but I wouldn't expect that severely untested code which has not been achieved through any formal consensus would be backed by even a modicum of hashing power.

You are right that they are two different things, but why shouldn't we try to also decentralize the development process.  Don't you see a benefit in that?
There is certainly turmoil right now because large segments of the Bitcoin community don't agree with how the centralized process is going.

Like I said, people can develop whatever they want. But I believe (and hope) that few will support code that is controversial and untested. "Centralization" of the development process isn't a problem in and of itself, and has no bearing on whether bitcoin is decentralized.

People disagree about how to approach the block size limit. That doesn't mean that forming sectarian camps is going to be fruitful.

[jonald_fyookball]

People disagree about how to approach the block size limit. That doesn't mean that forming sectarian camps is going to be fruitful.

You're right.  It doesn't necessarily mean that.  Consensus is difficult.  One thing though, is that if we did have different 'camps'
as you put it, I feel it would perhaps remove some of the biases and allow a better debate. 

[Holliday]

Why scaling bitcoin would make it be less censorship-free?

Well, does the solution allow full nodes to function over anonymizing networks like ToR, for example.

I think you are confusing BIP101 and XT here. This arguable DDOS protection implemented in XT has nothing to do with scaling issues...

No. I'm wondering how easy it would be to sync a client from scratch (something I find myself doing quite often) over ToR if huge blocks drastically increase the size of the chain. Also, what are the ramifications of mining over ToR, or even low bandwidth connections, if blocks are massive?

Now put on your tinfoil hat and consider the future of internet censorship (a problem which already exists in some locations around the world). Would it be easier to maintain a system that requires more or less information to be shared between peers?

For Bitcoin to truly be different than the status quo, it needs to function in places where getting information may be difficult (for varied reasons). Who cares how well it works in the best of circumstances, we need it to work in the worst circumstances imaginable.

My vision for the future: A worldwide wireless mesh network which is capable of maintaining the Bitcoin network (among other things).

[jonald_fyookball]

Why scaling bitcoin would make it be less censorship-free?

Well, does the solution allow full nodes to function over anonymizing networks like ToR, for example.

I think you are confusing BIP101 and XT here. This arguable DDOS protection implemented in XT has nothing to do with scaling issues...

No. I'm wondering how easy it would be to sync a client from scratch (something I find myself doing quite often) over ToR if huge blocks drastically increase the size of the chain. Also, what are the ramifications of mining over ToR, or even low bandwidth connections, if blocks are massive?

Now put on your tinfoil hat and consider the future of internet censorship (a problem which already exists in some locations around the world). Would it be easier to maintain a system that requires more or less information to be shared between peers?

For Bitcoin to truly be different than the status quo, it needs to function in places where getting information may be difficult (for varied reasons). Who cares how well it works in the best of circumstances, we need it to work in the worst circumstances imaginable.

My vision for the future: A worldwide wireless mesh network which is capable of maintaining the Bitcoin network (among other things).

Why cant I mine over TOR and use small blocks?  A blocksize limit is a cap -- you can go smaller if you want.

[poeEDgar]

Why scaling bitcoin would make it be less censorship-free?

Well, does the solution allow full nodes to function over anonymizing networks like ToR, for example.

I think you are confusing BIP101 and XT here. This arguable DDOS protection implemented in XT has nothing to do with scaling issues...

No. I'm wondering how easy it would be to sync a client from scratch (something I find myself doing quite often) over ToR if huge blocks drastically increase the size of the chain. Also, what are the ramifications of mining over ToR, or even low bandwidth connections, if blocks are massive?

Now put on your tinfoil hat and consider the future of internet censorship (a problem which already exists in some locations around the world). Would it be easier to maintain a system that requires more or less information to be shared between peers?

For Bitcoin to truly be different than the status quo, it needs to function in places where getting information may be difficult (for varied reasons). Who cares how well it works in the best of circumstances, we need it to work in the worst circumstances imaginable.

My vision for the future: A worldwide wireless mesh network which is capable of maintaining the Bitcoin network (among other things).

Why cant I mine over TOR and use small blocks?  A blocksize limit is a cap -- you can go smaller if you want.

Huh? How does that work if other miners are propagating blocks that are > 1MB......

[brg444]

Why scaling bitcoin would make it be less censorship-free?

Well, does the solution allow full nodes to function over anonymizing networks like ToR, for example.

I think you are confusing BIP101 and XT here. This arguable DDOS protection implemented in XT has nothing to do with scaling issues...

No. I'm wondering how easy it would be to sync a client from scratch (something I find myself doing quite often) over ToR if huge blocks drastically increase the size of the chain. Also, what are the ramifications of mining over ToR, or even low bandwidth connections, if blocks are massive?

Now put on your tinfoil hat and consider the future of internet censorship (a problem which already exists in some locations around the world). Would it be easier to maintain a system that requires more or less information to be shared between peers?

For Bitcoin to truly be different than the status quo, it needs to function in places where getting information may be difficult (for varied reasons). Who cares how well it works in the best of circumstances, we need it to work in the worst circumstances imaginable.

My vision for the future: A worldwide wireless mesh network which is capable of maintaining the Bitcoin network (among other things).

Why cant I mine over TOR and use small blocks?  A blocksize limit is a cap -- you can go smaller if you want.

Because you will be run off the network by larger miners pushing big blocks

[jonald_fyookball]

Why scaling bitcoin would make it be less censorship-free?

Well, does the solution allow full nodes to function over anonymizing networks like ToR, for example.

I think you are confusing BIP101 and XT here. This arguable DDOS protection implemented in XT has nothing to do with scaling issues...

No. I'm wondering how easy it would be to sync a client from scratch (something I find myself doing quite often) over ToR if huge blocks drastically increase the size of the chain. Also, what are the ramifications of mining over ToR, or even low bandwidth connections, if blocks are massive?

Now put on your tinfoil hat and consider the future of internet censorship (a problem which already exists in some locations around the world). Would it be easier to maintain a system that requires more or less information to be shared between peers?

For Bitcoin to truly be different than the status quo, it needs to function in places where getting information may be difficult (for varied reasons). Who cares how well it works in the best of circumstances, we need it to work in the worst circumstances imaginable.

My vision for the future: A worldwide wireless mesh network which is capable of maintaining the Bitcoin network (among other things).

Why cant I mine over TOR and use small blocks?  A blocksize limit is a cap -- you can go smaller if you want.

Huh? How does that work if other miners are propagating blocks that are > 1MB......

Thats true, but typically download speeds are faster than upload speeds.

This brings up the issue of SPV mining which Is going to have to be dealt with sooner rather than later.
I don't think that can be solved simply by keeping blocks small.

[brg444]

Why scaling bitcoin would make it be less censorship-free?

Well, does the solution allow full nodes to function over anonymizing networks like ToR, for example.

I think you are confusing BIP101 and XT here. This arguable DDOS protection implemented in XT has nothing to do with scaling issues...

No. I'm wondering how easy it would be to sync a client from scratch (something I find myself doing quite often) over ToR if huge blocks drastically increase the size of the chain. Also, what are the ramifications of mining over ToR, or even low bandwidth connections, if blocks are massive?

Now put on your tinfoil hat and consider the future of internet censorship (a problem which already exists in some locations around the world). Would it be easier to maintain a system that requires more or less information to be shared between peers?

For Bitcoin to truly be different than the status quo, it needs to function in places where getting information may be difficult (for varied reasons). Who cares how well it works in the best of circumstances, we need it to work in the worst circumstances imaginable.

My vision for the future: A worldwide wireless mesh network which is capable of maintaining the Bitcoin network (among other things).

Why cant I mine over TOR and use small blocks?  A blocksize limit is a cap -- you can go smaller if you want.

Huh? How does that work if other miners are propagating blocks that are > 1MB......

Thats true, but typically download speeds are faster than upload speeds.

This brings up the issue of SPV mining which Is going to have to be dealt with sooner rather than later.
I don't think that can be solved simply by keeping blocks small.

Large, well-connected miners will soon benefit from near constant propagation time. Smaller miners (over Tor for example) will get drowned out the network.

[RoadTrain]

Why scaling bitcoin would make it be less censorship-free?

Well, does the solution allow full nodes to function over anonymizing networks like ToR, for example.

I think you are confusing BIP101 and XT here. This arguable DDOS protection implemented in XT has nothing to do with scaling issues...

No. I'm wondering how easy it would be to sync a client from scratch (something I find myself doing quite often) over ToR if huge blocks drastically increase the size of the chain. Also, what are the ramifications of mining over ToR, or even low bandwidth connections, if blocks are massive?

Now put on your tinfoil hat and consider the future of internet censorship (a problem which already exists in some locations around the world). Would it be easier to maintain a system that requires more or less information to be shared between peers?

For Bitcoin to truly be different than the status quo, it needs to function in places where getting information may be difficult (for varied reasons). Who cares how well it works in the best of circumstances, we need it to work in the worst circumstances imaginable.

My vision for the future: A worldwide wireless mesh network which is capable of maintaining the Bitcoin network (among other things).

Why cant I mine over TOR and use small blocks?  A blocksize limit is a cap -- you can go smaller if you want.

Huh? How does that work if other miners are propagating blocks that are > 1MB......

Thats true, but typically download speeds are faster than upload speeds.

So what? When you download a block over Tor, the exit node uploads it to you. Try to apply you argument again.

[jonald_fyookball]

By that logic, you're going to be multiples slower than with TOR vs non-TOR, regardless of the blocksize.

[RoadTrain]

By that logic, you're going to be multiples slower than with TOR vs non-TOR, regardless of the blocksize.

No. With higher blocksizes, disadvantage of TOR mining increases.

[hdbuck]

Gmaxwell did the thankless task of debunking Peter R here:

Code:

On Sun, Aug 30, 2015 at 1:43 AM, Peter R <peter_r at gmx.com> wrote:
> Dear Greg,
>
> I am moving our conversation into public as I've recently learned that
> you've been forwarding our private email conversation verbatim without
> my permission [I received permission from dpinna to share the email
> below that proves this fact].

Unfortunately, your work extensive as it was made at least two
non-disclosed or poorly-disclosed simplifying assumptions and a significant
system understanding error which, I believe, undermined it completely.

In short these were:

* You assume miners do not have the ability to change their level
centralization.

 -- In fact they do, not just in theory but in pratice have responded
    to orphaning this way in the past; and it is one of the major
    concerns in this space.

* You assume the supply of bitcoin is infinite (that subsidy never
declines)

 -- It declines geometrically, and must if the 21m limit is to be upheld.
    (Though I think this is not equally important as the other concerns)

* You argue, incorrectly, that amount of information which must be
transmitted at the moment a block is discovered is proportional to the
block's size.

 -- Instead the same information can be transmitted _in advance_, as
 has been previously proposed, and various techniques can make doing
 so arbitrarily efficient.

[I would encourage anyone who is interested to read the posted off-list
discussion]

I contacted you in private as a courtesy in the hope that it would be
a more productive pathway to improving our collective understanding; as well
as a courtesy to the readers of the list in consideration of traffic levels.

In one sense, this was a success: Our conversation concluded with you
enumerating a series of corrective actions that you would take:

--------
> 1.  I will make it more clear that the results of the paper hinge on
> the assumption that block solutions are propagated across channels,
> and that the quantity of pure information communicated per solution
> is proportional to the amount of information contained within the block.
>
> 2.  I will add a note [unless you ask me not to] something to the effect
> of "Greg Maxwell challenges the claim that the coding gain cannot
> be infinite…" followed by a summary of the scenario you described.
> I will reference "personal communication."  I will also run the note
> by you before I make the next revision public.
>
> 3.  I will point out that if the coding gain can be made spectacularly
> high, that the propagation impedance in my model will become very small,
> and that although a fee market may strictly exist in the asymptotic
> sense, such a fee market may not be relevant (the phenomena in the paper
> would be negligible compared to the dynamics from some other effect).
>
> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
> next revision (the "you don't orphan your own block" point).
>
> Lastly, thank you for the note about what might happen when fees >
> rewards.  I've have indeed been thinking about this.  I believe it is
> outside the scope of the present paper, although I am doing some work
> on the topic.  (Perhaps I'll add a bit more discussion on this topic
> to the present paper to get the reader thinking in this direction).
--------

To the best of my knowledge, you've taken none of these corrective
actions in the nearly month that has passed.  I certainly understand being
backlogged, but you've also continued to make public comments about your
work seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending your
work and wasn't made aware of these points.  A result was that the other
author's work may require significant revisions.

I complained about this to you, again privately, and your (apparent)
response was to post to that thread stating that there was a
details-unspecified academic disagreement with me and "I look forward
to a white paper demonstrating otherwise!", in direct contradiction to
your remarks to me three weeks ago in private correspondence: In private
you said that your model may only hold in an asymptotic sense and that
"the phenomena in the paper (may) be negligible compared to the dynamics
from some other effect"; but in public you said /my/ position was
"academic".

At this point I thought continuing to withhold this information from
the other author was unreasonable and no longer justified by courtesy
to you, and I forwarded our complete discussion to the other author
with the comment "I'll forward you a set of private correspondence
that I've had with Peter R.  I would recommend you take the time to
read it and consider it.".

I apologize if in doing so I've breached your confidence, none of the
material we discussed was a sort that I would have ordinarily considered
private, and you had already talked about making the product of our
communication published as part of your corrective actions.
I do not think it would be reasonable to demand that I spent time
repeating the same discussion again with the other author, or deprive
them of your side of it and/or the corrective actions which you had
said you would take but have not yet taken.

(In fact, I would argue that you were already obligated to share at least the
substance of the discussion  with the other author, both as part of your
commitment to me as well it being necessiary for intellectual progress.)

As you say, 'we are all here trying to learn about this new amazing
thing called Bitcoin'; and I'm not embarrassed to error towards doing
that and aiding others in doing so, but at the same time I am sorry
to have done so in a way which caused you some injury.

In any case, your prior proposed corrective actions seemed sufficient to me.

It surprises me, greatly, that you are failing to see the extreme
practicality of what I described to you, and that it does not meaningfully
diminish miner control of transaction selection-- but even without it your
remark that the proportionality could be arbitrarily small (Rather than
0, as I argue) is an adequate correction to your work, in my view.

I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero.

Cheers,

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010744.html




TL;DR:

Peter R be like:

"I will carry on my verbal diarrhea until gavin and hearn give me a popsicle.."


Gmax:

"I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero."



lmao

[brg444]

Gmaxwell did the thankless task of debunking Peter R here:

Code:

On Sun, Aug 30, 2015 at 1:43 AM, Peter R <peter_r at gmx.com> wrote:
> Dear Greg,
>
> I am moving our conversation into public as I've recently learned that
> you've been forwarding our private email conversation verbatim without
> my permission [I received permission from dpinna to share the email
> below that proves this fact].

Unfortunately, your work extensive as it was made at least two
non-disclosed or poorly-disclosed simplifying assumptions and a significant
system understanding error which, I believe, undermined it completely.

In short these were:

* You assume miners do not have the ability to change their level
centralization.

 -- In fact they do, not just in theory but in pratice have responded
    to orphaning this way in the past; and it is one of the major
    concerns in this space.

* You assume the supply of bitcoin is infinite (that subsidy never
declines)

 -- It declines geometrically, and must if the 21m limit is to be upheld.
    (Though I think this is not equally important as the other concerns)

* You argue, incorrectly, that amount of information which must be
transmitted at the moment a block is discovered is proportional to the
block's size.

 -- Instead the same information can be transmitted _in advance_, as
 has been previously proposed, and various techniques can make doing
 so arbitrarily efficient.

[I would encourage anyone who is interested to read the posted off-list
discussion]

I contacted you in private as a courtesy in the hope that it would be
a more productive pathway to improving our collective understanding; as well
as a courtesy to the readers of the list in consideration of traffic levels.

In one sense, this was a success: Our conversation concluded with you
enumerating a series of corrective actions that you would take:

--------
> 1.  I will make it more clear that the results of the paper hinge on
> the assumption that block solutions are propagated across channels,
> and that the quantity of pure information communicated per solution
> is proportional to the amount of information contained within the block.
>
> 2.  I will add a note [unless you ask me not to] something to the effect
> of "Greg Maxwell challenges the claim that the coding gain cannot
> be infinite…" followed by a summary of the scenario you described.
> I will reference "personal communication."  I will also run the note
> by you before I make the next revision public.
>
> 3.  I will point out that if the coding gain can be made spectacularly
> high, that the propagation impedance in my model will become very small,
> and that although a fee market may strictly exist in the asymptotic
> sense, such a fee market may not be relevant (the phenomena in the paper
> would be negligible compared to the dynamics from some other effect).
>
> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
> next revision (the "you don't orphan your own block" point).
>
> Lastly, thank you for the note about what might happen when fees >
> rewards.  I've have indeed been thinking about this.  I believe it is
> outside the scope of the present paper, although I am doing some work
> on the topic.  (Perhaps I'll add a bit more discussion on this topic
> to the present paper to get the reader thinking in this direction).
--------

To the best of my knowledge, you've taken none of these corrective
actions in the nearly month that has passed.  I certainly understand being
backlogged, but you've also continued to make public comments about your
work seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending your
work and wasn't made aware of these points.  A result was that the other
author's work may require significant revisions.

I complained about this to you, again privately, and your (apparent)
response was to post to that thread stating that there was a
details-unspecified academic disagreement with me and "I look forward
to a white paper demonstrating otherwise!", in direct contradiction to
your remarks to me three weeks ago in private correspondence: In private
you said that your model may only hold in an asymptotic sense and that
"the phenomena in the paper (may) be negligible compared to the dynamics
from some other effect"; but in public you said /my/ position was
"academic".

At this point I thought continuing to withhold this information from
the other author was unreasonable and no longer justified by courtesy
to you, and I forwarded our complete discussion to the other author
with the comment "I'll forward you a set of private correspondence
that I've had with Peter R.  I would recommend you take the time to
read it and consider it.".

I apologize if in doing so I've breached your confidence, none of the
material we discussed was a sort that I would have ordinarily considered
private, and you had already talked about making the product of our
communication published as part of your corrective actions.
I do not think it would be reasonable to demand that I spent time
repeating the same discussion again with the other author, or deprive
them of your side of it and/or the corrective actions which you had
said you would take but have not yet taken.

(In fact, I would argue that you were already obligated to share at least the
substance of the discussion  with the other author, both as part of your
commitment to me as well it being necessiary for intellectual progress.)

As you say, 'we are all here trying to learn about this new amazing
thing called Bitcoin'; and I'm not embarrassed to error towards doing
that and aiding others in doing so, but at the same time I am sorry
to have done so in a way which caused you some injury.

In any case, your prior proposed corrective actions seemed sufficient to me.

It surprises me, greatly, that you are failing to see the extreme
practicality of what I described to you, and that it does not meaningfully
diminish miner control of transaction selection-- but even without it your
remark that the proportionality could be arbitrarily small (Rather than
0, as I argue) is an adequate correction to your work, in my view.

I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero.

Cheers,

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010744.html


"I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero."

lmao

Have you read the whole email exhange? I can't believe Peter would bring that up, this is one of the worst case of self-exposing I've seen on the internet 

[hdbuck]

Gmaxwell did the thankless task of debunking Peter R here:

Code:

On Sun, Aug 30, 2015 at 1:43 AM, Peter R <peter_r at gmx.com> wrote:
> Dear Greg,
>
> I am moving our conversation into public as I've recently learned that
> you've been forwarding our private email conversation verbatim without
> my permission [I received permission from dpinna to share the email
> below that proves this fact].

Unfortunately, your work extensive as it was made at least two
non-disclosed or poorly-disclosed simplifying assumptions and a significant
system understanding error which, I believe, undermined it completely.

In short these were:

* You assume miners do not have the ability to change their level
centralization.

 -- In fact they do, not just in theory but in pratice have responded
    to orphaning this way in the past; and it is one of the major
    concerns in this space.

* You assume the supply of bitcoin is infinite (that subsidy never
declines)

 -- It declines geometrically, and must if the 21m limit is to be upheld.
    (Though I think this is not equally important as the other concerns)

* You argue, incorrectly, that amount of information which must be
transmitted at the moment a block is discovered is proportional to the
block's size.

 -- Instead the same information can be transmitted _in advance_, as
 has been previously proposed, and various techniques can make doing
 so arbitrarily efficient.

[I would encourage anyone who is interested to read the posted off-list
discussion]

I contacted you in private as a courtesy in the hope that it would be
a more productive pathway to improving our collective understanding; as well
as a courtesy to the readers of the list in consideration of traffic levels.

In one sense, this was a success: Our conversation concluded with you
enumerating a series of corrective actions that you would take:

--------
> 1.  I will make it more clear that the results of the paper hinge on
> the assumption that block solutions are propagated across channels,
> and that the quantity of pure information communicated per solution
> is proportional to the amount of information contained within the block.
>
> 2.  I will add a note [unless you ask me not to] something to the effect
> of "Greg Maxwell challenges the claim that the coding gain cannot
> be infinite…" followed by a summary of the scenario you described.
> I will reference "personal communication."  I will also run the note
> by you before I make the next revision public.
>
> 3.  I will point out that if the coding gain can be made spectacularly
> high, that the propagation impedance in my model will become very small,
> and that although a fee market may strictly exist in the asymptotic
> sense, such a fee market may not be relevant (the phenomena in the paper
> would be negligible compared to the dynamics from some other effect).
>
> 4. [UNRELATED] I also plan to address Dave Hudson's objections in my
> next revision (the "you don't orphan your own block" point).
>
> Lastly, thank you for the note about what might happen when fees >
> rewards.  I've have indeed been thinking about this.  I believe it is
> outside the scope of the present paper, although I am doing some work
> on the topic.  (Perhaps I'll add a bit more discussion on this topic
> to the present paper to get the reader thinking in this direction).
--------

To the best of my knowledge, you've taken none of these corrective
actions in the nearly month that has passed.  I certainly understand being
backlogged, but you've also continued to make public comments about your
work seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending your
work and wasn't made aware of these points.  A result was that the other
author's work may require significant revisions.

I complained about this to you, again privately, and your (apparent)
response was to post to that thread stating that there was a
details-unspecified academic disagreement with me and "I look forward
to a white paper demonstrating otherwise!", in direct contradiction to
your remarks to me three weeks ago in private correspondence: In private
you said that your model may only hold in an asymptotic sense and that
"the phenomena in the paper (may) be negligible compared to the dynamics
from some other effect"; but in public you said /my/ position was
"academic".

At this point I thought continuing to withhold this information from
the other author was unreasonable and no longer justified by courtesy
to you, and I forwarded our complete discussion to the other author
with the comment "I'll forward you a set of private correspondence
that I've had with Peter R.  I would recommend you take the time to
read it and consider it.".

I apologize if in doing so I've breached your confidence, none of the
material we discussed was a sort that I would have ordinarily considered
private, and you had already talked about making the product of our
communication published as part of your corrective actions.
I do not think it would be reasonable to demand that I spent time
repeating the same discussion again with the other author, or deprive
them of your side of it and/or the corrective actions which you had
said you would take but have not yet taken.

(In fact, I would argue that you were already obligated to share at least the
substance of the discussion  with the other author, both as part of your
commitment to me as well it being necessiary for intellectual progress.)

As you say, 'we are all here trying to learn about this new amazing
thing called Bitcoin'; and I'm not embarrassed to error towards doing
that and aiding others in doing so, but at the same time I am sorry
to have done so in a way which caused you some injury.

In any case, your prior proposed corrective actions seemed sufficient to me.

It surprises me, greatly, that you are failing to see the extreme
practicality of what I described to you, and that it does not meaningfully
diminish miner control of transaction selection-- but even without it your
remark that the proportionality could be arbitrarily small (Rather than
0, as I argue) is an adequate correction to your work, in my view.

I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero.

Cheers,

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010744.html




TL;DR:

Peter R be like:

"I will carry on my verbal diarrhea until gavin and hearn give me a popsicle.."


Gmax:

"I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero."



lmao

Have you read the whole email exhange? I can't believe Peter would bring that up, this is one of the worst case of self-exposing I've seen on the internet  

no where is it? altho i cant be bothered reading more of his utter squeaking garbage.

but you can link it for the people here ^^

[brg444]

Gmaxwell did the thankless task of debunking Peter R here:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010744.html

TL;DR:

Peter R be like:

"I will carry on my verbal diarrhea until gavin and hearn give me a popsicle.."


Gmax:

"I believe my time would be better spent actually _implementing_ improved
relaying described (and describe what was implemented) than continue
a purely academic debate with you over the (IMO) inconsequential difference
between epsilon and zero."



lmao

Have you read the whole email exhange? I can't believe Peter would bring that up, this is one of the worst case of self-exposing I've seen on the internet  

no where is it? altho i cant be bothered reading more of his utter squeaking garbage.

but you can link it for the people here ^^

http://pastebin.com/jFgkk8M3

How could you have written at such length and complexity but ignoring the simple expident miners have of simply centeralizing their operation around larger pools to lower their costs-- an activity they previously performed, in practice, not just theory (which was walked back by handing them more efficient relay mechenisms) and which is simple, easy, and which reduces those marginal costs to 0 at the limit (e.g. all miners served off a particular host) --- after I specifically called you out on this previously?   Doubly so when your analysis gives provides a framework for analyizing the profitibility of moving from one point on that income tradeoff graph to another (e.g. the lost income from failing to centeralize)....

[johnyj]

 You are basically proving that you have the same mindset as Gavin: The smartest should be the king and rule others. Unfortunately, people vote with their foot when they feel that you are smarter 

From what I've observed, Gavin doesn't have that attitude at all.  That's why he stepped down from being the lead developer.
Actions speak louder than words.  If he was still "ruling", he would have already implemented Bip 101.   

If the following statement is true then it is not as bright as you described

"In the absence of institutions capable of implementing clear standards, it’s plain that Andresen and Hearn decided to take matters into their own hands. XT is above all a path toward establishing new leadership. I asked Andresen whether, if XT were to achieve full acceptance, he would then include all the earlier Bitcoin core devs in the new XT team. He replied that “[XT] will have a different set of developers. Part of the reason for forking is to have a clear decision-making process for the software development.”

http://www.newyorker.com/business/currency/inside-the-fight-over-bitcoins-future

[tl121]

By that logic, you're going to be multiples slower than with TOR vs non-TOR, regardless of the blocksize.

No. With higher blocksizes, disadvantage of TOR mining increases.

It is possible to run a mining rig over TOR to a node that can be a mining pool or solo mining pool.  The bandwidth required over TOR is minimal because of the design of the Stratum protocol.  The blocksize can be small or large, as determined by the full node and your mining rig(s).  The bandwidth required between your site and the mining pool is independent of block size and independent of your hash rate, or even number of mining rigs if you use a local stratum proxy.