Why do coins encourage early adoption? (A lot)

[markm]

you don't need Asic against 51% can set rules in wallet

You can? I didn't know that. Link to the whitepaper?

-MarkM-

[BlueDragon747]

you don't need Asic against 51% can set rules in wallet

You can? I didn't know that. Link to the whitepaper?

-MarkM-

here is some other info while I find my source
http://arxiv.org/abs/1311.0243v1
http://bitcoinmagazine.com/7953/selfish-mining-a-25-attack-against-the-bitcoin-network/
http://motherboard.vice.com/blog/bitcoin-isnt-broken-despite-a-potential-flaw

I am trying to find the link about the modifications to reduce issue of 51% I was only reading it about a week ago

here is Gavin talking about it but not the paper yet
http://gavintech.blogspot.co.uk/2012/05/neutralizing-51-attack.html

[markm]

That doesn't protect against 51%, all it does or even tries to do is lower the chance of selfish mining being used to allow even less than 50% to sucessfully attack.

-MarkM-

[BlueDragon747]

That doesn't protect against 51%, all it does or even tries to do is lower the chance of selfish mining being used to allow even less than 50% to sucessfully attack.

-MarkM-

that why I say any problem add new rules to the wallet and I do have the recommendations here somewhere

[Cognate]

Not to contribute to the off-topicness of my own thread but,

I can't get the miner to run for Blakecoin.

I downloaded the alternate cgminer and whenever I open my .bat file it just closes instantly.

-----

setx GPU_MAX_ALLOC_PERCENT 100

setx GPU_USE_SYNC_OBJECTS 1

/cgminer --blake256 -o stratum+tcp://stratum.blakecoinpool.org:3333 -u username -p password -I 12 -g 2 -w 256 --thread-concurrency 8192 --gpu-engine 1040 --gpu-memclock 1500 --gpu-powertune -20 --auto-fan

Did I miss a step?

----

Can't really read any of the read me files on my computer (it is a new computer with no programs installed) and I'm a little lazy... looking for the easy way out. Ideas? =P

----

I personally like the idea of Blakecoin but dunno guess I'll try to get some coins into the wallet and see if I stick with it. As it is now I'm just picking up a little bit of everything and hitting the early adopter coins hard because that is how you're supposed to do it sadly. I don't like the idea of people amassing tons of coins in the first week while people later grind out a week for 10 coins.

[markm]

That doesn't protect against 51%, all it does or even tries to do is lower the chance of selfish mining being used to allow even less than 50% to sucessfully attack.

-MarkM-

that why I say any problem add new rules to the wallet and I do have the recommendations here somewhere

You seem to imagine you can prevent 51% vulnerability by adding a few rules to the client?

Now you are seeming like you outright do not even grok how blockchains even work.

-MarkM-

[BlueDragon747]

Not to contribute to the off-topicness of my own thread but,

I can't get the miner to run for Blakecoin.

I downloaded the alternate cgminer and whenever I open my .bat file it just closes instantly.

-----

setx GPU_MAX_ALLOC_PERCENT 100

setx GPU_USE_SYNC_OBJECTS 1

/cgminer --blake256 -o stratum+tcp://stratum.blakecoinpool.org:3333 -u username -p password -I 12 -g 2 -w 256 --thread-concurrency 8192 --gpu-engine 1040 --gpu-memclock 1500 --gpu-powertune -20 --auto-fan

Did I miss a step?

----

Can't really read any of the read me files on my computer (it is a new computer with no programs installed) and I'm a little lazy... looking for the easy way out. Ideas? =P

----

I personally like the idea of Blakecoin but dunno guess I'll try to get some coins into the wallet and see if I stick with it. As it is now I'm just picking up a little bit of everything and hitting the early adopter coins hard because that is how you're supposed to do it sadly. I don't like the idea of people amassing tons of coins in the first week while people later grind out a week for 10 coins.

put the settings in a cgminer.conf

Code:

{
"pools" : [
	{
		"url" : "stratum+tcp://stratum.blakecoinpool.org:3333",
		"user" : "UserName.WorkerName",
		"pass" : "WorkerPassword"
	}
],

"intensity" : "9",
"auto-gpu" : true,
"expiry" : "120",
"failover-only" : true,
"gpu-threads" : "2",
"log" : "5",
"no-restart" : true,
"queue" : "3",
"scan-time" : "30",
"worksize" : "128",
"temp-hysteresis" : "4",
"blake256" : true,
"vectors" : "1",
"no-submit-stale": true,
"kernel-path" : "/"
}

try that tweak the intensity once it is running  

[BlueDragon747]

That doesn't protect against 51%, all it does or even tries to do is lower the chance of selfish mining being used to allow even less than 50% to sucessfully attack.

-MarkM-

that why I say any problem add new rules to the wallet and I do have the recommendations here somewhere

You seem to imagine you can prevent 51% vulnerability by adding a few rules to the client?

Now you are seeming like you outright do not even grok how blockchains even work.

-MarkM-

the whole wallet is network rules!

only risk is a hard fork!

I could put ip block ban or drop addresses from being valid with rules so it is limitless, making them work without bugs is the hard bit

none of these issues have or will stop Bitcoin from adding rules did you read:
http://gavintech.blogspot.co.uk/2012/05/neutralizing-51-attack.html

[riffraffselbow]

hey blakecoin evangelist guy who keeps posting the same copy-pasted info:

What value does "hashing faster" actually provide? block retargeting means that we can stick to whatever time-per-block we want, so why does checking a bunch more nonces for the target per second have any inherent value?

Or do you just like to spam that because people are easily wowed by big numbers?

[markm]

I could put ip block ban or drop addresses from being valid with rules so it is limitless, making them work without bugs is the hard bit

Okay now you have proven that you do not grok.

Please, go do your homework.

none of these issues have stopped Bitcoin from adding rules did you read:
http://gavintech.blogspot.co.uk/2012/05/neutralizing-51-attack.html

I will go read that now, or possibly go discover what thing that I already have read you are imagining indicates tracking/blocking IP addresses will help.

-MarkM-

EDIT: Here is the content found at that link:

Code:

 Responsible disclosure. And email spam.
The "development" page at bitcoin.org got a section on Responsible Disclosure of security vulnerabilities a few months ago.

So, of course, the email address that is used to report vulnerabilities has been getting more spam these days. Not a big deal, it just means two minutes of work once a week to make sure there are no real reports and delete the 5-10 spam messages.

One spam message caught my eye today, just because a security researcher just might start their email with "I have reviewed your website":

    From: "Paul"   <PaulWilsire@gmail.com>
    To: "Bitcoin-security"
    Date: Wed, 2 Oct 2013 14:32:55 +0100
    Subject: [SPAM] Website Evaluation 

     I've reviewed your website and would love to setup some time to go through my findings with you (no cost). You could be ranked considerably higher in the search engines for the keywords that matter to your business.

    I found errors in your websites code (on-site optimization) as well as a lack of substantial, quality backlinks (links pointing to your website from sources with authority). These two primary issues are holding you back from the top spots in Google that your competition is currently holding.

Paul Wilsire is a big fat liar-- there is no way he reviewed our website. Google "bitcoin" and the first result is Wikipedia. The second is bitcoin.org.

If you're thinking of hiring somebody to do search engine optimization for you, then google their name, and see how well they've done SEO'ing themselves. "Paul Wilsire" doesn't seem to exist, according to Mr. Google....
Posted 3rd October by Gavin Andresen 

Weird. But not helpful.

[BlueDragon747]

hey blakecoin evangelist guy who keeps posting the same copy-pasted info:

What value does "hashing faster" actually provide? block retargeting means that we can stick to whatever time-per-block we want, so why does checking a bunch more nonces for the target per second have any inherent value?

Or do you just like to spam that because people are easily wowed by big numbers?

the larger the hash set the better mean average for block find e.g more guesses of block hash at a given difficulty

the Blakecoin network/wallet retargets every 20 blocks to try and keep a 3 minute per block

1 cpu miner could keep Blakecoin alive compared with Scrypt based coins

[BlueDragon747]

I could put ip block ban or drop addresses from being valid with rules so it is limitless, making them work without bugs is the hard bit

Okay now you have proven that you do not grok.

Please, go do your homework.

none of these issues have stopped Bitcoin from adding rules did you read:
http://gavintech.blogspot.co.uk/2012/05/neutralizing-51-attack.html

I will go read that now, or possibly go discover what thing that I already have read you are imagining indicates tracking/blocking IP addresses will help.

-MarkM-

EDIT: Here is the content found at that link:

Code:

 Responsible disclosure. And email spam.
The "development" page at bitcoin.org got a section on Responsible Disclosure of security vulnerabilities a few months ago.

So, of course, the email address that is used to report vulnerabilities has been getting more spam these days. Not a big deal, it just means two minutes of work once a week to make sure there are no real reports and delete the 5-10 spam messages.

One spam message caught my eye today, just because a security researcher just might start their email with "I have reviewed your website":

    From: "Paul"   <PaulWilsire@gmail.com>
    To: "Bitcoin-security"
    Date: Wed, 2 Oct 2013 14:32:55 +0100
    Subject: [SPAM] Website Evaluation 

     I've reviewed your website and would love to setup some time to go through my findings with you (no cost). You could be ranked considerably higher in the search engines for the keywords that matter to your business.

    I found errors in your websites code (on-site optimization) as well as a lack of substantial, quality backlinks (links pointing to your website from sources with authority). These two primary issues are holding you back from the top spots in Google that your competition is currently holding.

Paul Wilsire is a big fat liar-- there is no way he reviewed our website. Google "bitcoin" and the first result is Wikipedia. The second is bitcoin.org.

If you're thinking of hiring somebody to do search engine optimization for you, then google their name, and see how well they've done SEO'ing themselves. "Paul Wilsire" doesn't seem to exist, according to Mr. Google....
Posted 3rd October by Gavin Andresen 

Weird. But not helpful.

someone best tell Gavin that the 51% can't be fixed with rules!
https://bitcointalk.org/index.php?topic=78403.msg874553#msg874553

I have a academic paper that also talk about it but can't find it will post here when I do though

[markm]

hey blakecoin evangelist guy who keeps posting the same copy-pasted info:

What value does "hashing faster" actually provide? block retargeting means that we can stick to whatever time-per-block we want, so why does checking a bunch more nonces for the target per second have any inherent value?

Or do you just like to spam that because people are easily wowed by big numbers?

the larger the hash set the better mean average for block find e.g more guesses of block hash at a given difficulty

the Blakecoin network/wallet retargets every 20 blocks to try and keep a 3 minute per block

1 cpu miner could keep Blakecoin alive compared with Scrypt based coins

More bullshit.

One CPU miner did keep BBQcoin (an scrypt coin) alive sometimes, as people would come and go during the year it was being CPU-mined. As long as one core was mining it, it was alive, so that others could fire up their client to do a transaction and turn it back off again and the transaction would still go through; and if they chose to have mining enabled during those few minutes it took to post a transaction they would likely find one or more blocks since until they fired up their client, possibly defaultign to using more than one core, the network had been plugging along on just one core.

Usually more than one was mining it though, just because hey it costs almost nothing and could be valuable someday.

(Those people who CPU mined it that year did in fact get rewarded very well when the coin came back into the limelight, far more money than a few GPUs made mining other coins that year.)

-MarkM-

[riffraffselbow]

hey blakecoin evangelist guy who keeps posting the same copy-pasted info:

What value does "hashing faster" actually provide? block retargeting means that we can stick to whatever time-per-block we want, so why does checking a bunch more nonces for the target per second have any inherent value?

Or do you just like to spam that because people are easily wowed by big numbers?

the larger the hash set the better mean average for block find e.g more guesses of block hash at a given difficulty

the Blakecoin network/wallet retargets every 20 blocks to try and keep a 3 minute per block

1 cpu miner could keep Blakecoin alive compared with Scrypt based coins

But if a scrypt coin tanked in network hashrate and the diff tanked to 0.0002414 or whatever that magic number is, why couldn't a cpu support that?

[markm]

someone best tell Gavin that the 51% can't be fixed with rules then uh!
https://bitcointalk.org/index.php?topic=78403.msg874553#msg874553

I have a academic paper that also talk about it but can't find it will post here when I do though

And even more bullshit, did you even read it?

It is talking about transaction-denial attacks.

So basically Gavin is saying that if you have over 51% it would be stupid to do a transaction denial attack because it would be very obvious and the code could easily be fixed to insist that blocks contain transactions.

So if you do get 51% of the hashing power, it would be much more profitable to do one of the other things that someone with the majority of the hashpower can do than it would be to deny all transactions other than your own or to not include transactions in blocks.

Wow so much fail, I hope no one imagines this guy knows what he is doing.

-MarkM-

[BlueDragon747]

So basically Gavin is saying that if you have over 51% it would be stupid to do a transaction denial attack because it would be very obvious and the code could easily be fixed to insist that blocks contain transactions.

so you can change the rules in the wallet like I was saying  

Quote from http://gavintech.blogspot.co.uk/2012/05/neutralizing-51-attack.html:

"Neutralizing a 51% attack

A "51% attack" means a bad guy getting as much computing power as the entire rest of the Bitcoin network combined, plus a little bit more. The Bitcoin wiki has a good summary of what a 51% attacker can and cannot do.

One of the things a 51% attacker can do is prevent any transactions or new blocks from anybody besides themselves from being accepted, effectively stopping all payments and shutting down the network.

That would be bad.

But it would also be obvious it was happening, and pretty easy to defend against. As I said on the Bitcoin Forums:
Something like "ignore a longer chain orphaning the current best chain if the sum(priorities of transactions included in new chain) is much less than sum(priorities of transactions in the part of the current best chain that would be orphaned)" would mean a 51% attacker would have to have both lots of hashing power AND lots of old, high-priority bitcoins to keep up a transaction-denial-of-service attack. And they'd pretty quickly run out of old, high-priority bitcoins and would be forced to either include other people's transactions or have their chain rejected.
The code already has a notion of "bitcoin priority" that it uses to prevent transaction spam (sending gazillions of tiny transactions to yourself, just to make everybody else do the work of validating and storing them); extending that to influence the chain-fork-selection code wouldn't be hard.

The devil is in the details, of course, and the risk of introducing a new chain-acceptance rule (high) have to be weighed against the chances that somebody rich and irrational will try to pull off the attack (low, in my opinion, but  maybe I'm not sufficiently paranoid about Big Banks or Big Government using Dirty Tricks to shut down Bitcoin). Maybe I'll code it up and keep it as a "Not To Be Used Except In Case of Emergency" branch.

Posted 1st May 2012 by Gavin Andresen"

[markm]

Terminal fail. Goodbye.

-MarkM-

[BlueDragon747]

I am not saying that the network could not come under attack and I am not saying the network would not be effected by an attack I am saying you can put rules in to fix the problem which is what Gavin also said, and yes he also said after a proven attack not before as it could cause more issues than it could fix

so for example if an attack was happening I could change the magic numbers for the network and ignore the broadcasts of the attackers network, I would also add other rules in the chain-fork-selection code to fix it or block bad nodes from joining, and add new checkpoints to invalidate the bad long chain of the attacker

I guess you also don't see threats like GPU SAT solvers as an issue for the difficulty rules used in the wallet
http://jheusser.github.io/2013/02/03/satcoin.html

this would result in higher difficulty = easy mining as the high difficulty would only limit inputs to the search

[markm]

Cute.

I moved all the coins I had created for my players to Open Transactions, because blockchains are just too insanely, ridiculously expensive to even begin to pretend that there is some slight chance of being able to secure them.

(Miners want to be paid every coin that will ever exist, plus transaction fees on top of that?!?!? How insane is that??!?)

The intent is that someday, when the problem of whether alernative blockchain can in fact be secured and if so how they can secured has been solved, they can migrate back to blockchain form.

GrouPcoin is their "canary in the mine", but even if it does turn out to be feasible to secure GRouPcoin (that is, if it does turn out to be possible to get a large enough amount of bitcoin mining to add GRouPcoin into its merge, which first requires convincing them to merged mine any coin(s) at all as even those who do merged mine usually are not merging the full collection of merged mined coins), it still might not be feasible to secure any arbitrary other chain because whatever arguments end up convincing most bitcoin miners to include GRouPcoin in their merge might not apply to some all or any other chains.

Maybe really GRouPcoin is not the best canary even because look at how reluctant miners still are to include CoiLedCoin and GeistGeld in their merge.

Those that merge at all, that is. Are most bitcoin mining rigs merged mining at all? Or is most of the hashpower still not merging anything alongside bitcoin at all?

Until we can be very confident that we can secure a blockchain it would be something along the lines of criminally negligent to expose those coins to the risks of deploying them in the form of blockchains.

-MarkM-

[BlueDragon747]

Cute.

I moved all the coins I had created for my players to Open Transactions, because blockchains are just to insanely, ridiculously expensive to even begin to pretend that there is some slight chance of being able to secure them.

(Miners want to be paid every coin that will ever exist, plus transaction fees on top of that?!?!? How insane is that??!?)

The intent is that someday, when the problem of whether alernative blockchain can in fact be secured and if so how they can secured has been solved, they can migrate back to blockchain form.

GrouPcoin is their "canary in the mine", but even if it does turn out to be feasible to secure GRouPcoin (that is, if it does turn out to be possible to get a large enough amount of bitcoin mining to add GRouPcoin into its merge, which first requires convincing them to merged mine any coin(s) at all as even those who do merged mine usually are not merging the full collection of merged mined coins), it still might not be feasible to secure any arbitrary other chain because whatever arguments end up convincing most bitcoin miners to include GRouPcoin in their merge might not apply to some all or any other chains.

Maybe really GRouPcoin is not the best canary even because look at how reluctant miners still are to include CoiLedCoin and GeistGeld in their merge.

Those that merge at all, that is. Are most bitcoin mining rigs merged mining at all? Or is most of the hashpower still not merging anything alongside bitcoin at all?

Until we can be very confident that we can secure a blockchain it would be something along the lines of criminally negligent to expose those coins to the risks of deplying them in the form of blockchains.

-MarkM-

here is the paper I was thinking about earlier(section 6)
http://arxiv.org/pdf/1311.0243v5.pdf

I agree that securing the blockchain 100% from every attack is not realistic, things go wrong and all code has loop holes or bugs that can be exploited but I think a few more things have issues than just who has biggest hashing power as it is expensive in terms of compute to do the 51% especially if the developer is active and resisting the attacker with code updates.

the longest chain and the difficulty are the most problematic code in the wallet for attacks from either a large compute attack or SAT solver but it is possible to fix the issues but as you have pointed out in the fix you might also toss out some genuine transactions that get incorporated by the attacker

yeah the other problem with most scrypt coins is the lack of possible merge mining having to pick and choose is wasteful on compute and even on Bitcoin very few pools do more than merged mine Bitcoin/Namecoin   

also you have yet to mention possible issues with the public/private key pair as in recent years this is looking much weaker than ever before, no one is yet using newer methods like MQQ(Multivariate Quadratic Quasigroups)

anyways MarkM you are well informed and it sounds like your users coins are safe with your implementation which is a lot better than most  

Happy Christmas Everyone