...

[kano]

Lulz, not sure why some people seem to think that the limited amount of exit nodes and limited bandwidth of Tor would be a good source for DDoSing.
Most successful DDoSes use botnets which are open IP addresses.

Targeting Tor IPs as a scapegoat for DDoS is like targeting Bitcoin to blame for all illegal activity.

[1714123668]

1714123668

[1714123668]

1714123668

[1714123668]

1714123668

[1714123668]

1714123668

[tvbcof]

Lulz, not sure why some people seem to think that the limited amount of exit nodes and limited bandwidth of Tor would be a good source for DDoSing.
Most successful DDoSes use botnets which are open IP addresses.

Targeting Tor IPs as a scapegoat for DDoS is like targeting Bitcoin to blame for all illegal activity.

Who authorized you to apply logic and something approaching an mild understanding of today's network infrastructure?

I've always thought that what would make a dandy botnet would be a large fleet of SPV wallets, and in particular one's which were calling mothership regularly for 'checkpoint' updates.  The actual owners of the devices (who, parenthetically, are also the one's paying their service fees) would be largely to stupid to know that they were even being used like a bitch, and if they did they would be easily convinced that they are 'playing their part' in something worthwhile.

[canth]

Lulz, not sure why some people seem to think that the limited amount of exit nodes and limited bandwidth of Tor would be a good source for DDoSing.
Most successful DDoSes use botnets which are open IP addresses.

Targeting Tor IPs as a scapegoat for DDoS is like targeting Bitcoin to blame for all illegal activity.

Sure - I agree that it's an edge case where it would be activated and a smaller edge case where it would be helpful. That's also part of the reason that throwing a fuss about it is essentially just trolling - it can't be used to break bitcoin.

[poeEDgar]

Honestly, I wasn't around during the discussions so I'm not completely familiar with why they were voted down.

Regarding trust, a lot of bitcoiners seem to be very black and white about their risk modeling. I agree that we don't want to erode decentralization or rely upon centralized 3rd parties, but actually thinking about the tradeoffs is better than gut rejections.

Let's ask the question:
What happens if the Tor Project gets compromised and the IP list is flooded with known node IP addresses?

- If your node is behind a proxy, nothing - anti-ddos is auto disabled
- If your node is manually turned off, nothing - anti-ddos is disabled
- If your node is not under attack, nothing - anti-ddos doesn't activate until incoming connections are full

- If your node has all inbound connections full (presumably under attack), then you will start dropping connections based upon the "Tor Project's compromised lists". You'll still have your outbound connections which won't be affected but some known nodes won't be able to connect to your node.

Seems like a pretty mild issue to me.

Let's take a look at this from another angle.

Does a node need a trusted list to tell it when an IP address is maliciously attacking it? No. It can deprioritize access from that IP address.

So what's the point of the list? Before we get to trusted vs. trustless -- why does this feature even exist? It serves no purpose.

What does "maliciously attacking" mean in that concrete context?
And if it is so easy to determine that, why has nobody done it yet?

On the basis of consistent maxing out of inbound connections. Are you suggesting that one can observe a DDOS attack from a specific group of IPs (TOR exit nodes), but without specifically associating them with a proxy network, this is impossible? This implies that these IP addresses are being blacklisted because they are part of the TOR network -- not because they are a likely source of DDOS attack.

The feature isn't about dealing with a single IP address attack - rather it's what to do when you have full incoming connections and are 'attacked' by multiple sources. I'll turn it around - if you have full inbound connections, what should the policy be? Should your node not accept any new incoming connections? (that's the goal of the attack) Or if you need to drop connections, which should be dropped first? If you were an attacker, would you attack on clearnet or via Tor and proxy? There is a rationale that went into this feature - it wasn't just for shits and giggles.

The silly thing is that for most users, most of the time it'll never come into play. It's a non-issue.

It's unlikely indeed. That's partly why this is so silly. It's like attacking a plague of locusts with a knife. If you were an attacker, you would attack on clearnet. Indeed the source of DDOS are usually botnets, not TOR nodes.

A node could begin to isolate IP addresses that repeatedly connect to it when inbound connections are maxed out and begin assigning lower and lower priority to them. The point should be to mitigate a DDOS attack, not throw an umbrella of suspicion over proxy networks. At the least, there should be evidence offered here that TOR exit nodes -- in comparison to any other set of IP addresses -- can be reasonably expected to be a source of DDOS attack. A simple anecdotal observation that a DDOS attack came from the TOR network is not sufficient evidence of that. One would need to take a much more comprehensive overview of all IP addresses that may comprise DDOS attacks over time.

This is probably more tied to Mike Hearn's mindset, which is to say, TOR/proxy traffic is for illegitimate use and non-TOR/proxy traffic is for legitimate use ("exchanges don't use it"). Perhaps a baby step on a long slippery slope.

That's also part of the reason that throwing a fuss about it is essentially just trolling - it can't be used to break bitcoin.

I don't think this was ever about "breaking" bitcoin. But it may be the wrong precedent to set and serve no real purpose.

[erik777]

To be sure, Mike's patch had logic along the lines of:

1> Get list of Tor exit nodes from trusted third-party.
2> Running out of nodes.  Must be DDoS.  I bet Tor is behind it.  So, I'll just "lower the priority" of Tor, effectively refusing Tor connections until this DDoS stops.

Besides the obvious trust issue in #1, #2 has these issues:

- Effectively bans Tor connections even if Tor is not the source of the DDoS. 
- Even if Tor was the source, even Mike admitted it will prevent innocent Tor users from reaching the nodes.

Add to this the many reasons stated on bitcoin-dev why DDoS are far more likely to come from non-Tor sources, and this unduly punishes Tor users (and Bitcoin) with virtually no benefit to the nodes or Bitcoin. 

In fact, with this in place on a majority of Nodes, anyone could cripple Tor users by launching a DDoS attack on the Bitcoin nodes without even using Tor to launch the attack!

Either Mike is incredibly lacking in intelligence, or he wants to intentionally cripple Tor. Given his redlists proposal and his propensity for proposing introducing centralized trust to Bitcoin, the latter is very possible.   

[canth]

To be sure, Mike's patch had logic along the lines of:

1> Get list of Tor exit nodes from trusted third-party.
2> Running out of nodes.  Must be DDoS.  I bet Tor is behind it.  So, I'll just "lower the priority" of Tor, effectively refusing Tor connections until this DDoS stops.

Besides the obvious trust issue in #1, #2 has these issues:

- Effectively bans Tor connections even if Tor is not the source of the DDoS. 
- Even if Tor was the source, even Mike admitted it will prevent innocent Tor users from reaching the nodes.

Add to this the many reasons stated on bitcoin-dev why DDoS are far more likely to come from non-Tor sources, and this unduly punishes Tor users (and Bitcoin) with virtually no benefit to the nodes or Bitcoin. 

In fact, with this in place on a majority of Nodes, anyone could cripple Tor users by launching a DDoS attack on the Bitcoin nodes without even using Tor to launch the attack!

Either Mike is incredibly lacking in intelligence, or he wants to intentionally cripple Tor. Given his redlists proposal and his propensity for proposing introducing centralized trust to Bitcoin, the latter is very possible.   

Without any mitigation, an attack where nodes are full of inbound connections will effectively block all new connections, including Tor / proxy users. Full inbound connections is a problem - the question again is how do you prioritize which connections to drop?

Any attacker than can fill inbound connections on a lot of nodes is going to cause problems for everyone. Doing nothing is an option - it's what the reference client does. Or XT can prioritize. It's not exactly a stupid option, albeit not super effective.

[iCEBREAKER]

To be sure, Mike's patch had logic along the lines of:

1> Get list of Tor exit nodes from trusted third-party.
2> Running out of nodes.  Must be DDoS.  I bet Tor is behind it.  So, I'll just "lower the priority" of Tor, effectively refusing Tor connections until this DDoS stops.

Besides the obvious trust issue in #1, #2 has these issues:

- Effectively bans Tor connections even if Tor is not the source of the DDoS. 
- Even if Tor was the source, even Mike admitted it will prevent innocent Tor users from reaching the nodes.

Add to this the many reasons stated on bitcoin-dev why DDoS are far more likely to come from non-Tor sources, and this unduly punishes Tor users (and Bitcoin) with virtually no benefit to the nodes or Bitcoin. 

In fact, with this in place on a majority of Nodes, anyone could cripple Tor users by launching a DDoS attack on the Bitcoin nodes without even using Tor to launch the attack!

Either Mike is incredibly lacking in intelligence, or he wants to intentionally cripple Tor. Given his redlists proposal and his propensity for proposing introducing centralized trust to Bitcoin, the latter is very possible.   

Heam@sigint.google.mil isn't trying to break Bitcoin, he's trying to integrate levers into it which give his MiB buddies discretionary control.

Fuck him and the former core dev he rode in on, as well as their astroturf mob of redditurds.

[iCEBREAKER]

It was one of the devs (Peter Todd maybe) who wrote on reddit that Sidechains are not a solution for scaling.  For some time now, I haven't seen them claim that they are.  Sidechains are still said to be ways to test all sorts of alternative ideas without endangering Bitcoin itself.

Last I heard, Todd has nothing to do with Blockstream other than he throws rocks at them as is his nature.  Philosophically, I like his treechains idea better but I see it as at best impractical and maybe impossible.  As I see it, what I had in 2011 called 'subordinate chains' have a wide and diverse set of advantages.  You've quasi-listed a few.

As for myself, I have read the Oct/2014 whitepaper with some care,  It mentions many examples of things that COULD be Sidechains of bitcoin; but I still don't know what CANNOT be a sidechain.  

One fundamental property is that each sidechain is supposed to be designed, implemented, and managed by an independent team.  Therefore the bitcoin developers cannot give any assurances that the sidechain will do what it claims to do, or will follow any constraints.  

According to the paper, a sidechain can even have its own tokens, not pegged to the bitcoins that were exported to it.  I cannot see how the sidechains could help bitcoin scale to hundreds of millions of users -- except by being altcoins independent of bitcoin.

As I see it, the 'chain' part of 'sidechains' would be a bit of a misnomer.  I'd imagine all sidecoins to have a chain to use as an interface layer but not necessarily as a back-end.  I would hope that it is close to true to say that there is not much which 'cannot' be a sidecoin.  I've argued (sort of) to Adam that a token back-end makes more sense for a lot of use-cases than a '(now)classic' chain-based system.  Of course I'm limited in what I can 'teach' Dr. Back about...well...almost anything.

As for Blockstream's 'design, implementation, and management', I've seen nothing which indicates that it will differ from any other open-source project and nothing to be threatened by (unless you have a burning need to feel threatened of course.)  If that changes, so will my stance toward Blockstream.  And, I expect, so will many of those who are currently organized under that tent.

Blockstream either said straight-out or I inferred that that intend to produce an open-source reference implementation for sidechains.  In that case, anyone could pick up the ball and run with it.

As for LN, I have not followed it that closely.  My impression is that it is subtly different from how I envision sidechains, but very interesting technology which will be valuable to develop and experiment with if nothing else.

The LN is very different from sidechains.  It executed payments by means of "bitcoin IOUs" that are guaranteed by actual bitcoins that were locked by users for a predetermined time.  While sidechains are too unconstrained, the LN is too constrained.  

From all that I know, it has some formidable practical problems, like requiring that users lock in advance all the bitcoins that they intend to spend for the next 6 months into bank-like entities.

I have asked about these problems directly to Adam Back, Luke Jr, and a few other developers, including Joseph Poon, one of the LN inventors.  The dialogue always ends at that point.

The thing about LN that really impressed me was the 'slack'.  Once in a while I pull the keys out of my pocket and a quarter comes with them and falls in a gutter.  That does not stop me from using coins and having pocket change.  From an engineering perspective there is a huge amount to be gained by having a little room for error.  That the designers were cognizant of this impressed me...although it is rather obvious to anyone who has done systems work.

I'll not speak for the LN developers, but as a general design goal a fraud-proofing perspective, the most critical thing is to not allow an operator to profit from fraud.  This will almost completely evaporate many forms of fraud from even being attempted.  A distant second priority would be how long it takes me to get my value back in the event of a failure (which I would expect to be an uncommon event and one I may never see.)

Well, right now, if they control Blockstream, they control the future of Bitcoin...

Considering that most of the Bitcoin 'core developers' who are worth a shit are involved, that would be true with or without the Blockstream umbrella.

The fact that sidechains and Blockstream has you (Stolfi) running scared is one of the best indicators yet that the may live up to the hopes I have for them.

So you don't mind having the bitcoin network literally owned by one company, which intends to make it unusable for its original purpose and to reuse it as an internal component of their nonsensical project... It makes me very hopeful that bitcoin will collapse -- not under external attacks, as bitcoiners always feared, but from the greed and mistakes of its defenders.  It will be fun to watch...

Blatant and bogus propaganda on several levels:

 - Open source means that they not only welcome competition but foster it.  So down goes the 'one company' BS.  Blockstream only need to do it better, and that is highly likely given the makeup of the entity.

 - Nothing about sidechains in any way detracts from the ability for individuals to use native Bitcoin except perhaps that they won't be subsidized and will thus have to pay transaction fees proportional to the cost of operating a secure system.

 - Given the level of talent who were induced to work on this project, you should think a little bit about who looks like a clown when you label it as 'nonsensical'.

I do sense that you are deeply hopeful that Bitcoin will collapse.  Again, I suspect that this is why Blockstream and sidechains bothers you so much.

Blockchains are the new hotness in compsci and fintech.  That a compsci professor still views them with skepticism at this point (five years on) indicates Stolfi is either letting his political objections color his technical analysis, or he's just too proud to admit being wrong and upset he didn't buy in earlier.  Or he's an idiot of the 'those who can't do X, teach X' variety.

Stolfi's (now infamous) "I think XT will win" opinion indicates he is spectacularly unreliable as a source of valid predictions (despite his ostensible qualifications).

That's a shame, because the community can always use insightful critics to keep our groupthink in check.

Unfortunately, Stolfi has now demonstrated his positions originate from technical incompetence and/or bad faith.

[iCEBREAKER]

Cartoons and graphics sometimes say more than thousand words.
Today I found the truth table in the cyberspace.

How's that "truth" of community support for BIP101 working out for you?

Oh wait, not a single BIP101 block was ever mined.  After the tremendous noise/drama/chaos over XT, all Team Gavin got were some spoofed blocks (and cartoons).

Meanwhile most of the hashing power supports the unfinished BIP100 as a giant FUCK YOU to BIP101.   

[canth]

Cartoons and graphics sometimes say more than thousand words.
Today I found the truth table in the cyberspace.

<snip>

How's that "truth" of community support for BIP101 working out for you?

Oh wait, not a single BIP101 block was ever mined.  After the tremendous noise/drama/chaos over XT, all Team Gavin got were some spoofed blocks (and cartoons).

Meanwhile most of the hashing power supports the unfinished BIP100 as a giant FUCK YOU to BIP101.  

Knock it off with the FUD. ~9  exchanges/merchants signed on for BIP101 support and some miners who have been DDoSed supported BIP101 as well, namely Slush and P2P. You know very well that big blocks are far from being decided.

I think that the next interesting advancement is whether or not merchants want BIP101 vs BIP100 or if they just want consensus & big blocks and don't care how it happens.

[iCEBREAKER]

The voting implantation was so laughably simplistic that the attack practically suggested itself.  If that is the design quality of XT under Hearn's benevolent dictatorship, heaven state sponsored judicial system help you guys.

The BIP66 voting was inept too.  It was the ineptitude of the Core devs, not dishonest miners, that caused the two "forks of July" (6-block and 3-block long, respectively) and required broadcasting to all clients the embarrassing alert "everybody had better wait for 30 confirmations for a while".

The BIP100 voting scheme is a joke.

I think that blcokchain voting in general is a stupid idea, but the 75% of the BIP101 voting is not bad.  Any brat can set up NotXT nodes to falsify the node statistics; miners, however, will not want to play games with their revenue.  If they are against BIP101, their interest is to vote against it, to prevent the 75% trigger to happen. Why would they want to trigger a messy fork and then have it collapse?  That is the sort of puerile "cut the nose to spite the face" reprisal that only a Blockstream worker would find amusing...

If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.

If Adam had not been born, BitcoinCore would probably have lifted the block size limit years ago...

Absent Adam Backamoto there would be no HashCash, and thus no Bitcoin.  It's not like some 3rd rate CS prof at a 3rd rate school in a Turd World country would ever invent the former, much less the latter.  Sounds like a certain underpaid public employee is a little jealous of Dr. Back's myriad world-changing accomplishments and fat private-sector paycheck.   

Pools will "play games" to increase their hashpower/revenue.   EG Slush, in order to shore up its falling user base, used the XT/101 drama to offer defectors the chance to make their (tiny, insignificant) voices heard.

Slush wasn't actually running XT/101, he just spoofed the version string to stroke the high-maintenance egos of the Gavinista insurgents.   

[iCEBREAKER]

So the real issue is only whose boots are to be licked, Adam's Satoshi's or Mike's?

FixtItForU 

[Agaguk24]

Is Bitcoin XT on the way up, or is it disappearing? Which wallet should I install...

[canth]

Pools will "play games" to increase their hashpower/revenue.   EG Slush, in order to shore up its falling user base, used the XT/101 drama to offer defectors the chance to make their (tiny, insignificant) voices heard.

Slush wasn't actually running XT/101, he just spoofed the version string to stroke the high-maintenance egos of the Gavinista insurgents.   

And who's running BIP100 code? It's called a miner vote, at least in this case Slush knows that BIP101 has finalized code. Can't say the same about BIP100.

[canth]

Is Bitcoin XT on the way up, or is it disappearing? Which wallet should I install...

It makes no difference - they're both consensus compatible at this point. It's not a popularity contest.

[iCEBREAKER]

Only gamblers would run XT marked mining operations without accepting larger blocks. I for one don't believe that a significant amount of hashing power will choose to risk the outcome of a contentious hard fork that they would clearly be responsible for by their deceiptful indication of larger block support. Not a likely scenario IMO.

The only pool producing XT blocks is apparently doing exactly that - just marking them as "XT version" and no more.
See slush's comments about his pool.

But more importantly, no pool in their right mind would be running the XT code yet.
The XT code has been severely lacking in testing compared to normal Core code changes.

Fair enough. No pool in mid-January 2016 will be marking XT blocks but not actually running BIP 101 compatible blocksize code.

As a troll I admire how, upon being proven completely wrong at present, you unhesitatingly and unflinchingly move the goalposts from ~now to Jan '16.  

Given the utter failure of XT/101, do you still think anyone will GAS about them 3 months from now?

I said I'd be a good loser if XT won.  Are you going to likewise be a good sport now that XT/101 has been #R3KT and tossed into the rubbish tip of history?

Knock it off with the FUD. ~9  exchanges/merchants signed on for BIP101 support and some miners who have been DDoSed supported BIP101 as well, namely Slush and P2P. You know very well that big blocks are far from being decided.

I think that the next interesting advancement is whether or not merchants want BIP101 vs BIP100 or if they just want consensus & big blocks and don't care how it happens.

ZOMG STOP THE PRESSES - MBA FRAT BOY VCS LIKE MONEY AND WILL SAY WHATEVER THEY THINK WILL GET THEM MORE!!!11!1!

So much for my hope you would not be a sore loser.  

Nobody Cares^® that Hearn's Gang of Nine made supportive noises about 101.  It's not like they're going to accept XTcoins!  

Fuck Circle, Goldman, and all the rest of those wannabe gatekeepers.  They and the rest of you Gavinistas are going to have to deal with the fact the socioeconomic majority favors BIP100, which is functionally a vote for Don't-Do-Anything-Anytime-Soon^TM.

Your sense of false urgency had a shelf life of Two Weeks.  Too bad the Stress Tests backfired by conclusively demonstrating Bitcoin will function as it was designed to, that is with an ambient backlog due to cosmic background spam, regulated by fee markets.  

[iCEBREAKER]

As it appears that XT is inevitable it would be nice get a better understanding of the migration path to XT or effects of staying firm with the core... anyone care to make some rough projections?

XT is being run by a few hobbyists who dream of a State-sanctioned utopian PanoptiCoin, free transactions and ice-cream forever ... it will always be niche belief system but not accepted by the mainstream.

Throwing around insults to get people to listen to you - how's that been working so far?

MoA is stating facts, not "throwing around insults."  He has put his finger precisely on the crux of the matter.  And (TYVM for asking) so far that's been working great!   

In Hearn's (google.mil inspired) vision, Bitcoin PanoptiCoin is free to use because we consumers are the product.  Just like GMail, GMaps, GSearch, etc.

But Bitcoin was born as a rejection of the Fiat Empire's 'We Want Your Soul' paradigm.

That's why the cypherpunk preference is for cheap nodes + expensive tx, while the corporatists/statists prefer expensive nodes + cheap tx.

[newb4now]

Does anyone have a prediction about when this debate will be resolved?

My guess is March 2016

[canth]

As a troll I admire how, upon being proven completely wrong at present, you unhesitatingly and unflinchingly move the goalposts from ~now to Jan '16.   

Given the utter failure of XT/101, do you still thing anyone will GAS about them 3 months from now?

I said I'd be a good loser if XT won.  Are you going to likewise be a good sport now that XT/101 has been #R3KT and tossed into the rubbish tip of history?

I'm fine with whatever solution wins - whether it's 1MB 4evah, BIP100 or BIP101 or BIPxxx - I've said all along that I'll go with whatever the economic supermajority chooses. My only grudge that I don't see letting go anytime soon is Theymos' heavy handed approach to moderation, but I'll admit - I'm still here on bitcointalk, I still download software from bitcoin.org and I hit /r/bitcoin so that just shows that the network effect is not inconsiderable.

Knock it off with the FUD. ~9  exchanges/merchants signed on for BIP101 support and some miners who have been DDoSed supported BIP101 as well, namely Slush and P2P. You know very well that big blocks are far from being decided.

I think that the next interesting advancement is whether or not merchants want BIP101 vs BIP100 or if they just want consensus & big blocks and don't care how it happens.

ZOMG STOP THE PRESSES - MBA FRAT BOY VCS LIKE MONEY AND WILL SAY WHATEVER THEY THINK WILL GET THEM MORE!!!11!1!

So much for my hope you would not be a sore loser.   

Nobody Cares^® that Hearn's Gang of Nine made supportive noises about 101.  It's not like they're going to accept XTcoins!   

Fuck Circle, Goldman, and all the rest of those wannabe gatekeepers.  They and the rest of you Gavinistas are going to have to deal with the fact the socioeconomic majority favors BIP100, which is functionally a vote for Don't-Do-Anything-Anytime-Soon^TM.

Your sense of false urgency had a shelf life of Two Weeks.  Too bad the Stress Tests backfired by conclusively demonstrating Bitcoin will function as it was designed to, that is with an ambient backlog due to cosmic background spam, regulated by fee markets.   

I don't think this is over yet. BIP100 doesn't have consensus (or finalized code). BIP101 could be tweaked with more conservative numbers. We could still be arguing about bigger block BIPxxx a year or two for now. I also don't think XT is pointless. There will be more than one version of consensus software that runs bitcoin and that's a good thing.

[canth]

Does anyone have a prediction about when this debate will be resolved?

My guess is March 2016

Heh...that'd be a good bet, although I have no idea about when this ends up being over. Put it up on https://bitbet.us/