Pages:
Author

Topic: ... - page 17. (Read 61003 times)

legendary
Activity: 4690
Merit: 1276
August 26, 2015, 11:40:05 AM
why are you here?  You clearly have something else under centralised control - that isn't bitcoin - that you want - go chase it.

As a comp sci prof, I don need any excuse to take an interest in computer science projects, and debate them in forums and such.  But I also consider part of my job duties to advise the taxpayers who pay my salary about computer-related risks and scams; and surely you must agree that "scam" and "risk" command very big fonts in the bitcoin word cloud.

Thanks for being honest.  I inferred that you see it as a duty (and a self-serving one) to destroy an autonomous solution which threatens your sponsorship in even a modest way.

Throwing your weight behind a solution like XT which is pretty much guaranteed to end up augmenting rather than threatening anything about the public/private (state/corporate) partnerships which animate our fiat currency systems makes perfect sense.

The systems you champion with it's gigantic web of derivatives and such are getting due for the re-set which is part of the formula.  Tough break for your side that crypto materialized out of the ether when it did.  I don't blame you for trying to neutralize the threat, but I'll do my best to see that your efforts won't succeed.

While I am drifting off-topic and into the metaphysical, let me add that at this point we are all just playing pocket-pool.  It is in the recovery phase when the rubber meets the road.  Without something like crypto, whatever the state decides to re-build will be what the masses have to accept.  With crypto and some of the 'elements' that the Blockstream guys are working on, there are viable and preferable alternatives for a variety of functions currently performed by the state and they go far beyond just money.  That should put the fear of God into your run-of-the-mill statist.

newbie
Activity: 14
Merit: 0
August 26, 2015, 11:18:52 AM
Things that restrict and limit you are always camouflaged as tools crafted to make you safe, it is disgusting approach. What we are seeing now is a lot like government action against bitcoin, including the core protocol.  Undecided
legendary
Activity: 2576
Merit: 1087
August 26, 2015, 11:11:26 AM
Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume your stupid.
A few things:
1) blocks can be anywhere from a second to well over an hour, so no, your stats are only theoretical expectations.
2) XT being 75% doesn't mean it can't lose - there's a reason why core uses higher than 75% ...
3) 'XT' have stated they will use block markers to force people to stay on XT and not switch to Core, if however, Core is above 50% and gets ahead of XT, everyone on XT will be royally screwed Smiley
4) It only takes one 'XT only' block to be mined to keep everyone using XT off Core

but more importantly, XT wont happen.

Yes my stats are based on averages. The stats are theoretical probabilities, you can throw variance in there as a red herring but it doesn't alter the fact that after an hour there is virtually no chance of core having a longer chain. I think you do understand this, and so you *are* being disingenuous.

I get you don't want bigger blocks,  but its clouding your ability to see the truth.

How exactly do you *know* XT won't happen? I certainly don't know if it will or it won't.

You talk of centralised control as if core isn't already? This fork is exactly the essence of decentralised. Why are you so afraid of it?
hero member
Activity: 910
Merit: 1003
August 26, 2015, 11:01:05 AM
why are you here?  You clearly have something else under centralised control - that isn't bitcoin - that you want - go chase it.

As a comp sci prof, I don need any excuse to take an interest in computer science projects, and debate them in forums and such.  But I also consider part of my job duties to advise the taxpayers who pay my salary about computer-related risks and scams; and surely you must agree that "scam" and "risk" command very big fonts in the bitcoin word cloud.

Quote
None of what you stated there is bitcoin.

Like any species or company, bitcoin must be able to evolve, or it will become extinct.  Bitcoin would still be unquestionably bitcoin with 1 MB size limit or with 8 MB limit, just as it was bitcoin with 32 MB limit until late 2010.  That is because bitcoin is not a protocol or an implementation, but is a set of people cooperating with somewhat compatible goals.   Bitcoin will be what those people decide that it is.

Bitcoin is an open source project without any official leadership: not just by Satoshi's choice, but because it must be that way to be decentralized.  Blockstream's pretense to be "the guys who define what bitcoin is"  is totally against that idea.   When they say "changes must be decided by consensus" they clearly mean "consensus among us Blockstream developers", not among the users, miners, or other independent developers...
legendary
Activity: 1442
Merit: 1001
August 26, 2015, 07:39:44 AM
So you completely missed the entire point of what I said ... the issue is they are using a too low 75% ...

...
BIP101 activates *only* if XT has >75% of hashing power.
...
False.

Bitcoin mining is random statistics.
It's not 10 minutes per block, every block.

Edit: and to give an example:
My pool mined 17 blocks at under 30% difficulty - yep luck was on a roll when that happened.
At the time, if there was any voting happening, for that period of time my pool would have effectively voted at over 300% of it's hash power.

Have you actually done the math? The likelihood that luck plays a major part in 750/1000 blocks is not high at all. http://bitco.in/forum/threads/triggering-the-bip101-fork-early-with-less-than-75-miners.13/
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 26, 2015, 06:04:03 AM
...
Quote
Quote
that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.
No it can't. Nothing controls the fees that pools/miners will accept but each pool/miner themselves.

Yes, bitcoin still has several design flaws that need to be fixed before it can achieve its design goal.  Like that one. Or the lack of inflation or demurrage, that got it appropriated by a legion of speculators and snake oil salesmen.
So why are you here?
You clearly have something else under centralised control - that isn't bitcoin - that you want - go chase it.
None of what you stated there is bitcoin.
hero member
Activity: 910
Merit: 1003
August 26, 2015, 05:40:50 AM
whoever paid for those SPAM attacks

Those were not spam attacks.  They were stress tests.  Rude and inconsiderate, with reproachable motives, but mere stress tests.  A spam attack will be quite different (and worse).

Quote
Nah, [ damage to bitcoin's image ] is what XT has done to BTC already ...

Another inversion of the facts... It was Adam Back, Ph. D.,  who screamed to the world that raising the size limit and/or having an alternative to Core would destroy bitcoin.  Well, it seems that some part of the world believed him...

However, this price drop is still a "minor correction".  Wait until 2016, when the world will realize that bitcoin is useless for e-payments because no one can bear the delays, AND for any sensitive non-payment use too, because it can be easily crippled by a spam attack.

Quote
[ The five largest Chinese miners already accepted larger blocks ] were approached directly by the XT goons and their response?

Yes, Gavin actually talked to them, as well as to the other major players.  That is what Adam calls "populist tactics". While the Blockstream devs intended to introduce changes by a different political process: secure commit control of the Core, and buck the community.

Quote
Quote
that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.
No it can't. Nothing controls the fees that pools/miners will accept but each pool/miner themselves.

Yes, bitcoin still has several design flaws that need to be fixed before it can achieve its design goal.  Like that one. Or the lack of inflation or demurrage, that got it appropriated by a legion of speculators and snake oil salesmen.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 26, 2015, 02:47:45 AM
We do need to have in place shortly the ability to increase the block size....

And thats what is happening - no argument there.

Quote from: kano
so that some time down the track when the pools/miners believe it would be ideal to increase it, that will be possible without the crap that is going on now.

So its just a question of scheduling? Fair enough. But if the larger portion of Miners and Pools want them sooner than you, you will support them, right?

I don't support the client changes in XT and I don't support the BIP101 central control and scare tactics increase of block size.

I do support BIP100 since it does not use central control to decide block size.

BIP100 allows for what you said.
sr. member
Activity: 400
Merit: 250
August 26, 2015, 01:50:46 AM
locking out people from the blockchain is unbearable. I hope XT won't see consensus...

Well, as was pointed out earlier.... I don't have a problem with nodes deprioritizing IPs that are attacking them. But why do it with a centralized blacklist compiled by a third party? This is bitcoin ffs. Since when do we seek out centralized solutions, particularly when they are entirely unnecessary? Makes one wonder.....
legendary
Activity: 1764
Merit: 1000
August 26, 2015, 01:35:16 AM
locking out people from the blockchain is unbearable. I hope XT won't see consensus...
hero member
Activity: 546
Merit: 500
Warning: Confrmed Gavinista
August 26, 2015, 01:30:13 AM
We do need to have in place shortly the ability to increase the block size....

And thats what is happening - no argument there.

Quote from: kano
so that some time down the track when the pools/miners believe it would be ideal to increase it, that will be possible without the crap that is going on now.

So its just a question of scheduling? Fair enough. But if the larger portion of Miners and Pools want them sooner than you, you will support them, right?



legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 26, 2015, 12:24:00 AM
Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income
Most miners know that, if the network is allowed to become congested, it will become unusable, and very vulnerable to spam attacks, even by attackers with modest budgets.
Well at least whoever paid for those SPAM attacks got their money worth with you: believing in the dire straights the XT goons want people to think are already here Smiley

Quote
Then adoption will drop, public image will be in sambles, and the price will probably crash.
Nah, that's what XT has done to BTC already ...

Quote
Bigger blocks will at least remove one obstacle to further adoption growth, and will make spam attacks at least 10 times more expensive, and their effects shorter-lived. 

Methinks that most miners, like most services and exchanges, will see the economic advantages of increasing the block size.  (The five largest Chinese miners already did.)
They were approached directly by the XT goons and their response?
To use a non-XT voting method to vote for a block size ...
We don't need a bigger block size now.
We do need to have in place shortly the ability to increase the block size so that some time down the track when the pools/miners believe it would be ideal to increase it, that will be possible without the crap that is going on now.

Quote
Whatever vaues, formulas, and schedules the various miners use to set the block size limit, they had better result in the same number, at least for a few months after the forking time. 

It does not matter if some miners are running code that accepts 8 MB forever, while others will accept 8 MB until 2018 and then accept 16 MB.  Until 2018 they will be in agreement, and until then they may change their software again.
Read BIP100 ... seems you didn't bother to do that ...


Quote
Quote
[ ... ] contrary to the design of Bitcoin.  Design changes that drastically reduce transaction free rewards will only result in failure in the long term for any fork using those changes without resolving the problem they cause.  The solution is to simply not apply such changes to start with.

Amazing how one can turn the facts so completely upside down. 

The design of bitcoin did not have a significant block size limit.  Satoshi assumed that the network would never be congested, and all transactions with sufficient fees would be processed in the next block, apart from propagation delays.   This assumption was so obvious that it did not even have to be stated explicitly.  Only a fool would design a network to be operated in congestion mode.
Only a fool would believe it is already in "congestion mode"
and
Only a fool would look at a design and ignore the implementation.

Quote
Keeping the 1 MB limit until the network becomes congested would be a huge, disastrous change in bitcoin.  Some transactions would be delayed for hours or more, no matter what fees they pay.
Your problem is your lack of temporal relevance.

Quote
Increasing the block size limit would be preserving it as it was designed and as it worked for the last 6 years. 
Sorry, that '6' you are trying to use as hyperbole fails.
Halving only occurs every ~4 yours ... (210,000 blocks)

Quote
Quote
Bitcoin is designed to shift from block reward to transaction fee reward.

Indeed, but that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.
No it can't.
Nothing controls the fees that pools/miners will accept but each pool/miner themselves.
hero member
Activity: 910
Merit: 1003
August 25, 2015, 10:46:20 PM
Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income

Most miners know that, if the network is allowed to become congested, it will become unusable, and very vulnerable to spam attacks, even by attackers with modest budgets.  Then adoption will drop, public image will be in sambles, and the price will probably crash.  Bigger blocks will at least remove one obstacle to further adoption growth, and will make spam attacks at least 10 times more expensive, and their effects shorter-lived. 

Methinks that most miners, like most services and exchanges, will see the economic advantages of increasing the block size.  (The five largest Chinese miners already did.)

"Big blocks" does not mean unlimited block size.  For practical programming and resource planning reasons, the block size limit must be fairly constant and not too big.  At present, 2 MB would be sufficient to avoid congestion for another year or two, but would offer little protection against spam attacks.  The popular 8 MB limit would be good for several years.

Whatever vaues, formulas, and schedules the various miners use to set the block size limit, they had better result in the same number, at least for a few months after the forking time. 

It does not matter if some miners are running code that accepts 8 MB forever, while others will accept 8 MB until 2018 and then accept 16 MB.  Until 2018 they will be in agreement, and until then they may change their software again.

Quote
[ ... ] contrary to the design of Bitcoin.  Design changes that drastically reduce transaction free rewards will only result in failure in the long term for any fork using those changes without resolving the problem they cause.  The solution is to simply not apply such changes to start with.

Amazing how one can turn the facts so completely upside down. 

The design of bitcoin did not have a significant block size limit.  Satoshi assumed that the network would never be congested, and all transactions with sufficient fees would be processed in the next block, apart from propagation delays.   This assumption was so obvious that it did not even have to be stated explicitly.  Only a fool would design a network to be operated in congestion mode.

Keeping the 1 MB limit until the network becomes congested would be a huge, disastrous change in bitcoin.  Some transactions would be delayed for hours or more, no matter what fees they pay.

Increasing the block size limit would be preserving it as it was designed and as it worked for the last 6 years. 

Quote
Bitcoin is designed to shift from block reward to transaction fee reward.

Indeed, but that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.
legendary
Activity: 4690
Merit: 1276
August 25, 2015, 09:55:22 PM

No.  Chains that cointain illegal blocks are ignored only by software that considers such blocks illegal.  But, for players that are running software that accepts big blocks, big blocks are legal.  Is it clear now?

Ya, clear that you selectively editing and are talking nonsense to cover up your mistake (or lack of understanding.)

Quote
Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

No, it is not "Core" that will do that, but "any miner who is running software that does not accept big blocks".  That software can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit.  Miners that accept big blocks may be running the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.

That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings.  The only thing that really matters is how many miners will accept big blocks at some point in the future.

Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.  

If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too.  Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.

If the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.  

As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.

If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.

Miners will mine where they can make money.  The effort and hence the difficulties will be less on less valuable forks (or core) so they can mine more per unit time.

Your wishful thinking about how 'miners better follow a lead' is nothing more than that and has no basis in reason and no predictive power of future reality.

I suggest that you consult with someone who knows a little about crypto-currencies and try to pick up some clues.  This might allow you to take a position and maybe you will not always be nervous and uptight about your state sponsored mainstream-land pension.  It may help uncloud your analytical abilities.  Even that might not be enough though.  Frankly speaking, I don't really see that you have the mental horsepower to do well in anything which is at all abstract or requires anticipating the future accurately.

Quote
the mining effort will be primarily driven by the market value of the product.

The preferences of the "economic majority" will surely influence the miners' decisions.  But, once a significant majority of the miners has decided that they will accept big blocks, after the first big block gets mined the "economic majority" had better be already accepting them too, or start accepting them right away.  While the miners can wait a few weeks before selling their mined coins, the "economic majority" cannot stop using bitcoin for a week, in the hope of winning the strong-arm duel.

Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.


"economic majority" is simply a throw-away buzzword invented to impress the mouth-breathers (but it works on comp-sci proffesors also it looks like.)

I will tell you that my own gauge of the value of core Bitcoins will _increase_ if/when the XT drones are led away by some pied piper.  I doubt that I am alone among hodlers in this.  If so, the value of core Bitcoins might hold up surprisingly well and any miners who had been throwing hashes at XT (or some other similar alt fork) will come rapidly back.

sr. member
Activity: 504
Merit: 250
Earn with impressio.io
August 25, 2015, 09:14:08 PM
I'm a bit ignorant to the technicals. Does anyone know how much it might cost to mount a somewhat permanent DDOS attack on bitcoin nodes from TOR nodes? Is it conceivable that if the XT fork prevails, under these conditions, that TOR nodes could effectively be blocked from propagating bitcoin transactions? Could this be used to prevent access to dark markets?

Even in the best case scenario, if it were used only for DDos, it would effectively shut down shared IPs including Tor exit nodes and proxy servers, impairing innocent users from being able to use them.  

The attraction to TRY to use this to shut down dark markets would be very tempting by those trying to do so, creating an incentive to use DDos to blacklist Tor IPs.  Ironically, this incentive would INCREASE DDos attempts, rather than reduce them.  

To the extent that these parties desire to remove anonymity from Bitcoin, this is a very enabling capability. 

While blacklists might appear on the surface to protect miners from DDos, they create a new avenue of DDos where the target becomes shared IP addresses. 
sr. member
Activity: 400
Merit: 250
August 25, 2015, 08:52:56 PM
Curious as I am not a coder:

How can we stop DDOS attacks on BTC without blacklisting the DDOS servers (or however this is actually being done)?

There must be a better way than putting in what I can only describe as 1984 Code.

You have to block bad IPs by IP.  The question is HOW you determine what a bad IP is.  If that is a pre-defined list you are asked to "trust", you've introduced discrimination and trust into the network at the same time, both principles counter to Bitcoin freedom -- which is designed to be TRUSTLESS.  This foundational concept is very clear in Satoshi's paper:

"the main benefits are lost if a trusted third party is still required"    

You can, however, detect malicious traffic in real-time, and temporarily lower the priority of that IP.  In this case, you do not trust any third-party to provide IPs, or discriminate against any externally defined group of IPs.  Rather, like "intrusion detection", you trust only what your eyes see right in front of you -- clear evidence that an IP that is currently behaving abusively.  There is no reason bitcoin cannot use intrusion detection techniques to detect malicious traffic. 

Spot on. That's what I see -- there is nothing wrong with deprioritizing traffic that is mounting a DDOS attack. There is something wrong with coding a centralized blacklist into the protocol. Play with semantics all you want, and rationalize how its intent may be noble -- it is a blacklist.

I'm a bit ignorant to the technicals. Does anyone know how much it might cost to mount a somewhat permanent DDOS attack on bitcoin nodes from TOR nodes? Is it conceivable that if the XT fork prevails, under these conditions, that TOR nodes could effectively be blocked from propagating bitcoin transactions? Could this be used to prevent access to dark markets?

Pardon my ignorance if I am being foolish......
sr. member
Activity: 504
Merit: 250
Earn with impressio.io
August 25, 2015, 08:36:14 PM
Curious as I am not a coder:

How can we stop DDOS attacks on BTC without blacklisting the DDOS servers (or however this is actually being done)?

There must be a better way than putting in what I can only describe as 1984 Code.

You have to block bad IPs by IP.  The question is HOW you determine what a bad IP is.  If that is a pre-defined list you are asked to "trust", you've introduced discrimination and trust into the network at the same time, both principles counter to Bitcoin freedom -- which is designed to be TRUSTLESS.  This foundational concept is very clear in Satoshi's paper:

"the main benefits are lost if a trusted third party is still required"    

You can, however, detect malicious traffic in real-time, and temporarily lower the priority of that IP.  In this case, you do not trust any third-party to provide IPs, or discriminate against any externally defined group of IPs.  Rather, like "intrusion detection", you trust only what your eyes see right in front of you -- clear evidence that an IP that is currently behaving abusively.  There is no reason bitcoin cannot use intrusion detection techniques to detect malicious traffic. 

Considering it may be a proxy used by legitimate users, you only temporarily lower its priority to permit the misbehaving source to possibly drop off, permitting healthy traffic to be prioritized again once the malicious source drops off.  

We do not need to trust blacklists, whitelists, or any other list in order to combat DDos.  Bitcoin is and must remain a trustless network.

 
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 25, 2015, 07:44:19 PM
...
Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.
...
Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income contrary to the design of Bitcoin.

Bitcoin is designed to shift from block reward to transaction fee reward.
Design changes that drastically reduce transaction free rewards will only result in failure in the long term for any fork using those changes without resolving the problem they cause.
The solution is to simply not apply such changes to start with.

The BIP101 hard coded block size growth is also based on an invalid extrapolation, due to insufficient data.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
August 25, 2015, 07:40:16 PM
^^^ "Very skeptical of bitcoin's long term success" ^^^ (i.e. actively trolling for it's demise since learning of bitcoin)

... pushing for divisive XT, nuf said.
hero member
Activity: 910
Merit: 1003
August 25, 2015, 07:30:09 PM
Weren't you supposed to be some sort of a comp-sci professor?  I don't know how to be kind about it, but your students are getting screwed...

Indeed. Students who are used to uncritically memorize and repeat what the textbooks say often get screwed in my courses.

Quote
Note that to a satoshi-based cyrpto-currency solution the proper terminology is 'longest valid chain'.  Bloat-blocks or any other illegality is simply ignored.

No.  Chains that cointain illegal blocks are ignored only by software that considers such blocks illegal.  But, for players that are running software that accepts big blocks, big blocks are legal.  Is it clear now?

Quote
Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

No, it is not "Core" that will do that, but "any miner who is running software that does not accept big blocks".  That software can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit.  Miners that accept big blocks may be running the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.

That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings.  The only thing that really matters is how many miners will accept big blocks at some point in the future.

Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.  

If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too.  Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.

If the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.  

As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.

If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.

Quote
the mining effort will be primarily driven by the market value of the product.

The preferences of the "economic majority" will surely influence the miners' decisions.  But, once a significant majority of the miners has decided that they will accept big blocks, after the first big block gets mined the "economic majority" had better be already accepting them too, or start accepting them right away.  While the miners can wait a few weeks before selling their mined coins, the "economic majority" cannot stop using bitcoin for a week, in the hope of winning the strong-arm duel.

Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.
Pages:
Jump to: