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

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.

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.

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.

Quote from: Gavin Andresen

I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.

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.

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).

If you aren't the sole controller of your private keys, you don't have any bitcoins.

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.

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......

Quote from: Gavin Andresen

I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.

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

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010

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......

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......

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......

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

In short these were:

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

-- 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 neverdeclines)

-- 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 betransmitted at the moment a block is discovered is proportional to theblock'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-listdiscussion]

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

In one sense, this was a success: Our conversation concluded with youenumerating 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 correctiveactions in the nearly month that has passed. I certainly understand beingbacklogged, but you've also continued to make public comments about yourwork seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending yourwork and wasn't made aware of these points. A result was that the otherauthor'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 adetails-unspecified academic disagreement with me and "I look forwardto a white paper demonstrating otherwise!", in direct contradiction toyour remarks to me three weeks ago in private correspondence: In privateyou said that your model may only hold in an asymptotic sense and that"the phenomena in the paper (may) be negligible compared to the dynamicsfrom some other effect"; but in public you said /my/ position was"academic".

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

I apologize if in doing so I've breached your confidence, none of thematerial we discussed was a sort that I would have ordinarily consideredprivate, and you had already talked about making the product of ourcommunication published as part of your corrective actions.I do not think it would be reasonable to demand that I spent timerepeating the same discussion again with the other author, or deprivethem of your side of it and/or the corrective actions which you hadsaid you would take but have not yet taken.

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

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

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

I believe my time would be better spent actually _implementing_ improvedrelaying described (and describe what was implemented) than continuea purely academic debate with you over the (IMO) inconsequential differencebetween epsilon and zero.

"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_ improvedrelaying described (and describe what was implemented) than continuea purely academic debate with you over the (IMO) inconsequential differencebetween epsilon and zero."

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

In short these were:

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

-- 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 neverdeclines)

-- 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 betransmitted at the moment a block is discovered is proportional to theblock'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-listdiscussion]

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

In one sense, this was a success: Our conversation concluded with youenumerating 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 correctiveactions in the nearly month that has passed. I certainly understand beingbacklogged, but you've also continued to make public comments about yourwork seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending yourwork and wasn't made aware of these points. A result was that the otherauthor'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 adetails-unspecified academic disagreement with me and "I look forwardto a white paper demonstrating otherwise!", in direct contradiction toyour remarks to me three weeks ago in private correspondence: In privateyou said that your model may only hold in an asymptotic sense and that"the phenomena in the paper (may) be negligible compared to the dynamicsfrom some other effect"; but in public you said /my/ position was"academic".

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

I apologize if in doing so I've breached your confidence, none of thematerial we discussed was a sort that I would have ordinarily consideredprivate, and you had already talked about making the product of ourcommunication published as part of your corrective actions.I do not think it would be reasonable to demand that I spent timerepeating the same discussion again with the other author, or deprivethem of your side of it and/or the corrective actions which you hadsaid you would take but have not yet taken.

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

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

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

I believe my time would be better spent actually _implementing_ improvedrelaying described (and describe what was implemented) than continuea purely academic debate with you over the (IMO) inconsequential differencebetween epsilon and zero.

"I believe my time would be better spent actually _implementing_ improvedrelaying described (and describe what was implemented) than continuea purely academic debate with you over the (IMO) inconsequential differencebetween 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

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010

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

In short these were:

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

-- 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 neverdeclines)

-- 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 betransmitted at the moment a block is discovered is proportional to theblock'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-listdiscussion]

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

In one sense, this was a success: Our conversation concluded with youenumerating 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 correctiveactions in the nearly month that has passed. I certainly understand beingbacklogged, but you've also continued to make public comments about yourwork seemingly (to me) in contradiction with the above corrective actions.

Today I discovered that another author spent their time extending yourwork and wasn't made aware of these points. A result was that the otherauthor'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 adetails-unspecified academic disagreement with me and "I look forwardto a white paper demonstrating otherwise!", in direct contradiction toyour remarks to me three weeks ago in private correspondence: In privateyou said that your model may only hold in an asymptotic sense and that"the phenomena in the paper (may) be negligible compared to the dynamicsfrom some other effect"; but in public you said /my/ position was"academic".

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

I apologize if in doing so I've breached your confidence, none of thematerial we discussed was a sort that I would have ordinarily consideredprivate, and you had already talked about making the product of ourcommunication published as part of your corrective actions.I do not think it would be reasonable to demand that I spent timerepeating the same discussion again with the other author, or deprivethem of your side of it and/or the corrective actions which you hadsaid you would take but have not yet taken.

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

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

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

I believe my time would be better spent actually _implementing_ improvedrelaying described (and describe what was implemented) than continuea purely academic debate with you over the (IMO) inconsequential differencebetween epsilon and zero.

"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_ improvedrelaying described (and describe what was implemented) than continuea purely academic debate with you over the (IMO) inconsequential differencebetween 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.

"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_ improvedrelaying described (and describe what was implemented) than continuea purely academic debate with you over the (IMO) inconsequential differencebetween 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.

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)....

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010

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.”

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.