...

[dooglus]

You do know that is a python script, run at compile time to dynamically generate the list from tor? Unless you are recompiling bitcoin binaries ( on your live server!!) every time you start your node, then this is not an issue. If tor does indeed log ip addresses ( which makes the whole thing pointless anyway) then they are only logging the address of the machine that compiled the code. In most (intelligent) cases that will not be the one running the node. In most cases you will be downloading binaries.

Do I get my candy now?

No candy for you.

See this code which runs at run time not compile time, and which also sends your IP address to torproject.org.

[1714487225]

1714487225

[Lucko]

You do know that is a python script, run at compile time to dynamically generate the list from tor? Unless you are recompiling bitcoin binaries ( on your live server!!) every time you start your node, then this is not an issue. If tor does indeed log ip addresses ( which makes the whole thing pointless anyway) then they are only logging the address of the machine that compiled the code. In most (intelligent) cases that will not be the one running the node. In most cases you will be downloading binaries.

Do I get my candy now?

No candy for you.

See this code which runs at run time not compile time, and which also sends your IP address to torproject.org.

If by send you means connect to https and reads IPs... But only if you are not using TOR or proxy and this function is not disabled...

EDIT: FTFY:
See this code which runs at run time not compile time, and which also makes HTTPS connection to torproject.org if you are not running any anonymising tools and you haven't turn that of.

It is not hidden you can find it documented and you can turn it off even if you don't use TOR or proxy. If you are not hiding your IP this really isn't a issue... Your IP is not hidden. Anyone knows where you are...

[meono]

The thing is we all know the OP, turtlehurricane, does not even code or know anything about coding.

He just copied and pasted some shit that he was told from troll box somewhere.

He was asked to show those line of codes so many times and kept coming back to repeating the same shit " Its in here look...." while claiming this "blacklisting" is tens thousands of code.

While he cant give the lines of code that support his statement he mixed to comments that does not relate to each other to support his claim.

So who is the one behind OP? they must know they're spreading BS and used idiot like OP to buy what they told him.

Puppet master, you're doing a terrible job

Majorly false, I developed code for the University of Wisconsin Nonhydrostatic modeling system. I know how to simulate the entire fucking atmosphere from a hurricane to a leaf floating on a breeze. I can read code.

I work for myself, no one is behind this but me. My career is Bitcoin so I have an obligation to protect it.

You're telling me University of Wisconsin hired the most incompetent programmer i've ever seen? Does not how to report a few line of codes? Doesnt know CVS? And never use githup?

Somehow i doubt it, and you're just full of shit.

Prove me wrong then, tell us why you couldnt give us the code ? Why did you only give us 2 seperate comments which are not even related to each other?

Noone and i mean noone quote comments in source code as a proof of what the code does. If you belive the comments are true then why did you ignore Mike's comment explaining what the mechanism does?

Go ahead. Prove me wrong

[turvarya]

The thing is we all know the OP, turtlehurricane, does not even code or know anything about coding.

He just copied and pasted some shit that he was told from troll box somewhere.

He was asked to show those line of codes so many times and kept coming back to repeating the same shit " Its in here look...." while claiming this "blacklisting" is tens thousands of code.

While he cant give the lines of code that support his statement he mixed to comments that does not relate to each other to support his claim.

So who is the one behind OP? they must know they're spreading BS and used idiot like OP to buy what they told him.

Puppet master, you're doing a terrible job

Majorly false, I developed code for the University of Wisconsin Nonhydrostatic modeling system. I know how to simulate the entire fucking atmosphere from a hurricane to a leaf floating on a breeze. I can read code.

I work for myself, no one is behind this but me. My career is Bitcoin so I have an obligation to protect it.

So, what (Bitcoin) projects have you worked on?
Give us any reference.

[dooglus]

I work for myself, no one is behind this but me. My career is Bitcoin so I have an obligation to protect it.

You seem confused. There are thousands of lines of code in Bitcoin Core itself concerned with the whitelisting and blacklisting of peers based on their behaviour. I get that you're trying to "help", by railing against XT, but when you overstate your case it isn't helpful. You're unable to point to specifics in the XT changeset that implement blacklisting because they don't exist.

Specifically, the 'fShouldBan' member which you keep quoting is already part of Bitcoin Core, and has been for a long time now. It is nothing to do with XT.

See this code in the original Bitcoin repository.

Hearn's changes are relatively small if you ignore the IP list itself which makes up the majority of the diff.

It does the following:

* fetches a list of Tor exit nodes from torproject.org, leaking your IP address to that site in the process
* in the event that your node is full, it will disconnect a Tor exit node if a non-Tor peer attempts to connect

That's about all.

I don't know why anyone would think it's a good idea to lump a bunch of unpopular changes in with the silly change which increases the block size limit from 1 MB to 8000 MB. Each extra already-rejected-by-people-who-know-their-shit change you add in surely just makes the whole package even less attractive. Unless maybe the strategy is to make the shit sandwich less unappealing over time by removing one turd at a time until only the blocksize change remains. Then everyone will exclaim "boy, there's only one turd in this sandwich - that's so much better than five turds" and gobble it up.

I hope not.

[Lucko]

* fetches a list of Tor exit nodes from torproject.org, leaking your IP address to that site in the process

Only if you are not using TOR or proxy and you didn't disable it... So your IP is public anyway...

And I can tell you why. Run XT for some time and you will see that it is needed. There are some people out there that will do anything to stop XT... Even when BIT101 was not implemented I got a lot of DOS...

[meono]

I work for myself, no one is behind this but me. My career is Bitcoin so I have an obligation to protect it.

You seem confused. There are thousands of lines of code in Bitcoin Core itself concerned with the whitelisting and blacklisting of peers based on their behaviour. I get that you're trying to "help", by railing against XT, but when you overstate your case it isn't helpful. You're unable to point to specifics in the XT changeset that implement blacklisting because they don't exist.

Specifically, the 'fShouldBan' member which you keep quoting is already part of Bitcoin Core, and has been for a long time now. It is nothing to do with XT.

See this code in the original Bitcoin repository.

Hearn's changes are relatively small if you ignore the IP list itself which makes up the majority of the diff.

It does the following:

* fetches a list of Tor exit nodes from torproject.org, leaking your IP address to that site in the process
* in the event that your node is full, it will disconnect a Tor exit node if a non-Tor peer attempts to connect

That's about all.

I don't know why anyone would think it's a good idea to lump a bunch of unpopular changes in with the silly change which increases the block size limit from 1 MB to 8000 MB. Each extra already-rejected-by-people-who-know-their-shit change you add in surely just makes the whole package even less attractive. Unless maybe the strategy is to make the shit sandwich less unappealing over time by removing one turd at a time until only the blocksize change remains. Then everyone will exclaim "boy, there's only one turd in this sandwich - that's so much better than five turds" and gobble it up.

I hope not.

BitcoinXT has been out for a long time. Certainly there are users that would like those features. The BIP101 was added so the network can move forward to consensus which shouldnt be only between a handful of people.

They dont just strip all the features to roll out the BIP101. And its not like they hide or sneak any thing in. People hereare just clueless because bitcoinXT did not have a fair discussions.

Anyone can remove any features they want. The protocol rule is what matters. Even Electrum can use BIP101 and we all have the same chain.

[dzimbeck]

I know that this update is not good because of the lack of consensus used to obtain it, and the ip address issues. However, it also is not good that the Bitcoin "foundation" has almost forcefully kept Bitcoin in the stone ages and a few of them are so afraid to fork that they are causing the issues we see here today. They should be forking all the time improving the code so it will get bigger adoption.

However, I would like to point out that using Tor with Bitcoin is not safe. Because if a person controls enough exit nodes they can easily attack and it can also seriously jeopardize your anonymity.

Regardless, anti-ddos is one thing... tracking ip addresses and "prioritizing them" and having "blacklist" features is another and should never be allowed in the source.

The lightning network is a good idea, however that too should not need as drastic of a change as they say it would. Since you can daisy chain 2 of 2 multisig together there is a more decentralized way to do that(just routing ious). And also, it seems like a network like that would never get done before the end of the year securely.

If they really want, there should only be two features added. A block size update is perfectly fine but 8mb? Why so much? The problems we face immediately get solved if we double or quadruple it. Then they should add a feature which allows alerts for updates so future forks can be more frequent.

Also they should add checklocktimeverify so Bitcoin can actually start being more useful.

[Velkro]

This unknown code doesnt have to be bad.
However it MUST be documented in open source project well. You can't hide anything anyway, but it should be pointed out first.

[Stringer Bell]

yes, if bitcoin can repulse the Hearn-Andresen XT PanoptiCoin FUD panic and forking social attack we'll be in good shape for the next leg up  (and hopefully well shod of those two little ratbags)

strongly agree.

[johnyj]

This kind of discussion is useless due to the complexity is out of reach of majority of users

If you have been here enough long, you will understand that bitcoin protocol was 100% centralized in the hands of a few core developers. Although everyone can submit their code, but core devs have the right to decide what code goes in and what should not go in

In early days, they even have support of the large mining pools, thus they could easily direct majority of the hash power to kill an unwanted fork during 2013

But now the political landscape has changed. Hash power has mostly moved to industry miners, this dramatically increased their political power in deciding where bitcoin is going. And since industry miners mostly care about making profit through mining, any change that could hurt their profit will not be accepted by them. So we can imagine that even core devs are lobbying the industry mining guys to accept their vision, if any change that could potentially cause the bitcoin's value to drop, they will not consider it

Money's value comes from trust, and trust comes from integrity and stability

[hdbuck]

This kind of discussion is useless due to the complexity is out of reach of majority of users

If you have been here enough long, you will understand that bitcoin protocol was 100% centralized in the hands of a few core developers. Although everyone can submit their code, but core devs have the right to decide what code goes in and what should not go in

In early days, they even have support of the large mining pools, thus they could easily direct majority of the hash power to kill an unwanted fork during 2013

But now the political landscape has changed. Hash power has mostly moved to industry miners, this dramatically increased their political power in deciding where bitcoin is going. And since industry miners mostly care about making profit through mining, any change that could hurt their profit will not be accepted by them. So we can imagine that even core devs are lobbying the industry mining guys to accept their vision, if any change that could potentially cause the bitcoin's value to drop, they will not consider it

Money's value comes from trust, and trust comes from integrity and stability

miners would not want their mining fees reduced to nil because of large blocks and considering halving incoming too.

[tsoPANos]

This kind of discussion is useless due to the complexity is out of reach of majority of users

If you have been here enough long, you will understand that bitcoin protocol was 100% centralized in the hands of a few core developers. Although everyone can submit their code, but core devs have the right to decide what code goes in and what should not go in

In early days, they even have support of the large mining pools, thus they could easily direct majority of the hash power to kill an unwanted fork during 2013

But now the political landscape has changed. Hash power has mostly moved to industry miners, this dramatically increased their political power in deciding where bitcoin is going. And since industry miners mostly care about making profit through mining, any change that could hurt their profit will not be accepted by them. So we can imagine that even core devs are lobbying the industry mining guys to accept their vision, if any change that could potentially cause the bitcoin's value to drop, they will not consider it

Money's value comes from trust, and trust comes from integrity and stability

This post has a huge value/character ratio.
I couldn't agree more.


One example of how devs behave depending on their interests.

3. Support for querying the UTXO set given an outpoint. This is useful for apps that use partial transactions, such as the Lighthouse crowdfunding app. The feature allows a client to check that a partial SIGHASH_ANYONECANPAY transaction is correctly signed and by querying multiple nodes, build up some confidence that the output is not already spent.

The Lighthouse crowdfunding app in backed by Mike Hearn, and if you want to accept bigger blocks, you will also have to support his patch to make his app possible.


I am deeply dissapointed by every high-ranking dev involved in this, and even our administrator seems to censor XT.
I do believe that XT is more centralized than Core as it follows Hearn's agenda only, Core is in a similar situation though.
Censoring one or another causes bad on bitcoin, and any bitcoin enthusiast has no reason on doing so.

[turvarya]

@turtlehurricane
Why don't you answer my question?

So, what (Bitcoin) projects have you worked on?
Give us any reference.

Maybe because you are a liar?
You proved again and again, that you don't know shit about Bitcoin.

[DooMAD]

I work for myself, no one is behind this but me. My career is Bitcoin so I have an obligation to protect it.

You seem confused. There are thousands of lines of code in Bitcoin Core itself concerned with the whitelisting and blacklisting of peers based on their behaviour. I get that you're trying to "help", by railing against XT, but when you overstate your case it isn't helpful. You're unable to point to specifics in the XT changeset that implement blacklisting because they don't exist.

Specifically, the 'fShouldBan' member which you keep quoting is already part of Bitcoin Core, and has been for a long time now. It is nothing to do with XT.

See this code in the original Bitcoin repository.

Hearn's changes are relatively small if you ignore the IP list itself which makes up the majority of the diff.

It does the following:

* fetches a list of Tor exit nodes from torproject.org, leaking your IP address to that site in the process
* in the event that your node is full, it will disconnect a Tor exit node if a non-Tor peer attempts to connect

That's about all.

It's valiant of you to try, dooglus, but turtlehurricane is only going to deflect this because he's not interested in having an honest discussion.  If he were to admit the truth that half the code he's jumping at shadows for is already present in core, it would undermine the entire premise of the thread, which is to cause undue alarm.  He's worse than a politician for not being able to give a straight answer to a simple question.  And yet for some reason, every thread he starts exclaiming the sky is falling, half the forum buy into the fear campaign.  This is why we can't have nice things.   

https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=fShouldBan

"OMG THERE'S BLACKLISTING IN CORE TOO!  ABANDON SHIP!"   

[c4p0ne]

Solutions?

[iCEBREAKER]

it's political because Gavin went off on his own and tried to fork bitcoin when core devs didn't take to his ideas

Thats your perspective due to your lack of understanding the issue. Its not my way or highway, its due to one side refuse to compromise to come to an agreement.

Yes i do insult other members when its clearly their agenda is to spread BS and attack the opposite side. They werent here to see everything. To me ditching and trashing Gavin because of some conspiracy is a disgrace of this community.

We're ditching and trashing Gavin because he (like Mike) is a shitlord:

If you thought Litecoin and altcoins dilute the value of Bitcoin, wait til you see what BTCXT does to the price! Actually, the market is already giving us a hint as to why BitcoinXT is such a bad idea.

A more responsible option would have been to set the trigger threshold at a real super majority of 90% miner vote. If it was set at 90%, the chance of a bad fork would be far less likely. But Mike & Gavin knows that there's no way they can get 90% support, so they would rather risk hurting Bitcoin in order to get their way. Mike has even mention using checkpoints to force the issue if XT doesn't get the hashrate majority (https://bitcointalk.org/index.php?topic=1089283.0). That is scary.

Is coblee's perspective also due to lack of understanding the issue?   

[meono]

I work for myself, no one is behind this but me. My career is Bitcoin so I have an obligation to protect it.

You seem confused. There are thousands of lines of code in Bitcoin Core itself concerned with the whitelisting and blacklisting of peers based on their behaviour. I get that you're trying to "help", by railing against XT, but when you overstate your case it isn't helpful. You're unable to point to specifics in the XT changeset that implement blacklisting because they don't exist.

Specifically, the 'fShouldBan' member which you keep quoting is already part of Bitcoin Core, and has been for a long time now. It is nothing to do with XT.

See this code in the original Bitcoin repository.

Hearn's changes are relatively small if you ignore the IP list itself which makes up the majority of the diff.

It does the following:

* fetches a list of Tor exit nodes from torproject.org, leaking your IP address to that site in the process
* in the event that your node is full, it will disconnect a Tor exit node if a non-Tor peer attempts to connect

That's about all.

I don't know why anyone would think it's a good idea to lump a bunch of unpopular changes in with the silly change which increases the block size limit from 1 MB to 8000 MB. Each extra already-rejected-by-people-who-know-their-shit change you add in surely just makes the whole package even less attractive. Unless maybe the strategy is to make the shit sandwich less unappealing over time by removing one turd at a time until only the blocksize change remains. Then everyone will exclaim "boy, there's only one turd in this sandwich - that's so much better than five turds" and gobble it up.

I hope not.

Wouldn't you say it's worth a thorough review considering this statement? You'd be one of the people who suffers first from the blacklist so you better check twice.

I would like to start a discussion and brainstorming session on the topic of coin tracking/tainting or as I will call it here, "redlisting". Specifically, what I mean is something like this: Consider an output that is involved with some kind of crime, like a theft or extortion. A "redlist" is an automatically maintained list of outputs derived from that output, along with some description of why the coins are being tracked. When you receive funds that inherit the redlisting, your wallet client would highlight this in the user interface. Some basic information about why the coins are on the redlist would be presented... I think this is a topic on which the Foundation should eventually arrive at a coherent policy for.

-Mike Hearn, BitcoinXT developer, lead author of Anti-DoS "patch"

A dog would have value its integrity more than you value yours.

Seriously do you ever have any self respect?

You knew your FUD is exposed and you're still trying to stick to it and continue causing more harm the the community? Your agenda is nothing but want to lead ppl to make ill-informed decision.

[meono]

it's political because Gavin went off on his own and tried to fork bitcoin when core devs didn't take to his ideas

Thats your perspective due to your lack of understanding the issue. Its not my way or highway, its due to one side refuse to compromise to come to an agreement.

Yes i do insult other members when its clearly their agenda is to spread BS and attack the opposite side. They werent here to see everything. To me ditching and trashing Gavin because of some conspiracy is a disgrace of this community.

We're ditching and trashing Gavin because he (like Mike) is a shitlord:

If you thought Litecoin and altcoins dilute the value of Bitcoin, wait til you see what BTCXT does to the price! Actually, the market is already giving us a hint as to why BitcoinXT is such a bad idea.

A more responsible option would have been to set the trigger threshold at a real super majority of 90% miner vote. If it was set at 90%, the chance of a bad fork would be far less likely. But Mike & Gavin knows that there's no way they can get 90% support, so they would rather risk hurting Bitcoin in order to get their way. Mike has even mention using checkpoints to force the issue if XT doesn't get the hashrate majority (https://bitcointalk.org/index.php?topic=1089283.0). That is scary.

Is coblee's perspective also due to lack of understanding the issue?   

Well his shitcoin is useless and non innovative. Hes just mad like you. However from this thread you will always be a number 2 no matter what you try. Turtlehuricane top your charts in every way.

[ChetnotAtkins]

meono, you can be observed to repeatedly evade facts and to conduct continuous personal attacks against people like turtlehurricane who support this community by working through the code to reveal things that every Bitcoin user needs to know.

I can see your account was created just for the blocksize debate. So please inform us, why exactly are your here? Why do you have an interest in dividing Bitcoin and it's userbase?