Bitcoin Forum
September 21, 2017, 07:19:36 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 »
  Print  
Author Topic: ...  (Read 58842 times)
turvarya
Hero Member
*****
Offline Offline

Activity: 714


View Profile
September 04, 2015, 07:20:47 AM
 #701

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?

https://forum.bitcoin.com/
New censorship-free forum by Roger Ver. Try it out.
1505978376
Hero Member
*
Offline Offline

Posts: 1505978376

View Profile Personal Message (Offline)

Ignore
1505978376
Reply with quote  #2

1505978376
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1505978376
Hero Member
*
Offline Offline

Posts: 1505978376

View Profile Personal Message (Offline)

Ignore
1505978376
Reply with quote  #2

1505978376
Report to moderator
canth
Legendary
*
Offline Offline

Activity: 1428



View Profile
September 04, 2015, 12:53:41 PM
 #702

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.

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.

kano
Legendary
*
Offline Offline

Activity: 2212


Linux since 1997 RedHat 4


View Profile
September 04, 2015, 01:12:02 PM
 #703

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.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
tvbcof
Legendary
*
Offline Offline

Activity: 2268


View Profile
September 04, 2015, 02:33:22 PM
 #704

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
Legendary
*
Offline Offline

Activity: 1428



View Profile
September 04, 2015, 05:43:48 PM
 #705

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
Sr. Member
****
Offline Offline

Activity: 299



View Profile
September 04, 2015, 05:54:08 PM
 #706

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.

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.
erik777
Full Member
***
Offline Offline

Activity: 194


View Profile
September 04, 2015, 10:11:54 PM
 #707

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
Legendary
*
Offline Offline

Activity: 1428



View Profile
September 04, 2015, 10:56:33 PM
 #708

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
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
September 04, 2015, 11:54:36 PM
 #709

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.


The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
September 05, 2015, 12:16:00 AM
 #710


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.

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

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

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
September 05, 2015, 12:25:28 AM
 #711



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



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

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
canth
Legendary
*
Offline Offline

Activity: 1428



View Profile
September 05, 2015, 12:54:13 AM
 #712


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

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

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
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
September 05, 2015, 01:17:13 AM
 #713

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

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

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

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
September 05, 2015, 01:18:40 AM
 #714

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

FixtItForU  Wink

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
Agaguk24
Full Member
***
Offline Offline

Activity: 217


View Profile
September 05, 2015, 01:21:57 AM
 #715

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

canth
Legendary
*
Offline Offline

Activity: 1428



View Profile
September 05, 2015, 01:23:55 AM
 #716


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

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
Legendary
*
Offline Offline

Activity: 1428



View Profile
September 05, 2015, 01:24:36 AM
 #717

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
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
September 05, 2015, 01:43:10 AM
 #718

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

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

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

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

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

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1778


http://DashNdrink.com


View Profile WWW
September 05, 2015, 01:51:56 AM
 #719

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!   Smiley

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.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
newb4now
Hero Member
*****
Offline Offline

Activity: 658


View Profile
September 05, 2015, 01:54:16 AM
 #720

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

My guess is March 2016
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!