Topic: Decentralized mining protocol standard: getblocktemplate (ASIC ready!) - page 2. (Read 32344 times)

Well good to see your rational analysis is missing reality.

The comment above, which you clearly didn't read, was about miners.

cgminer supports both GBT and Stratum.

Little Luke-Jr's complaint about GBT in cgminer was that it gets too much work - when it gets work as often as Stratum does.
However, that directly equates to the statement that his miner increase transaction confirm times.
Which, I guess I also need to explain to you, is bad for BTC.

His excuse is actually that GBT sends too much data.
Since that is also exactly what that statement equates to.
If Stratum and GBT get/receive the same amount of work, then according to Little Luke-Jr, that is GBT getting too much work.
So for the good of BTC it is actually better to use cgminer Stratum than his GBT implementation since the biggest proponent of GBT says that transaction confirm times should be longer and has programmed his miner to make sure they are.

Looking at the opposite issue:
Little Luke-Jr set his miner to get the Stratum transaction list MORE OFTEN than it gets work.
Which is totally STUPID since the transaction list is static for each item of work.
Yes he really does do totally MIND NUMBINGLY STUPID things.
He also put this up as a pull request in cgminer - which of course was ignored.

Bottom line is:
If you want MANY gigabytes of transactions sent to your miner every day, then yes use GBT on cgminer.
If you don't want MANY gigabytes of transactions send to your miner every day, then yes us Stratum on cgminer.

Think about that when you consider things like 3G/4G ...

--

So, I'd actually like to know which pools have been putting bad transactions into their blocks for the last 4 years?

Did anyone actually do ANY analysis of this?

Of course there is the possibility of pools putting transactions into their blocks that could be bad, or even using their pools to attack alt-chains like Like-Jr did and GBT doesn't stop that from happening - gee I wonder why that wasn't an option in GBT.
However, any pool stupid enough to put bad transactions in their blocks, would be easy to prove that it did it and unless they LIE as well as Luke-Jr and try and cover everything up as he does, they would get caught out.

You can already do a full block analysis on any block as it is generated using an active bitcoind and a bit of code to watch the transactions that come and go and that end up in each block.
There is no trick to doing this at all.
Just requires a small amount of coding.

Should be interesting to see how it goes.

My prediction: nothing happens at all.

But to be rational about it, it comes down to a fight over wanting to do it transparently or wanting to do it more obscurely. Personally, I'll take transparent over obscure any day...

Guys, this makes perfect sense. When his protocol/JesusHolyMiner fails when the ASICs hit and he just can't remain competitive, he gets to blame his failure on the Graet, Kano, and everyone else ganging up on and trolling him to death. It's not that he wrote an inferior product, or that his product even has any issues whatsoever, it's that he is nothing more than a victim of cyber bullies who are jealous and threatened by his competition. 

Just you watch. I give it less than 60 days.

Yes he has plenty of evidence ... it's called psychological trauma.

Did you confess to doing it too much?

Luke, what did I tell you about trolling on the forum?

This is perfectly valid and on-topic question. Please step away from personal acusations and stay on-topic as well.

My point was that it doesn't matter whether pools support miners adding/removing transactions yet. Even without that, miners can obviously control the blocks by choosing which ones to mine since it's transparent.

So, how are we stupid beings supposed to know the "truth" if you don't tell it to us?

And your evidence of this...?

A few months ago, I might have agreed. But he's been getting pretty deep into Kano/Con's troll camp for a while now, constantly spreading FUD and other lies, with utter disregard for the truth.

Uhm, a "little" over the top.  Don't you think? I'd say Graet is pretty well-respected. Calling him a troll brings your credibility into question.

Ahhh got it
anyone that is interested in a question is a troll unless it conforms to your views

thanks for not answering - it is what I expected and does your credibility even more harm.

this is a shame as it is harming Bitcoin - something you so quickly accuse others of.

Please answer questions re: GBT honestly, there is much interest in the community.


EDIT: the question is very relevant considering the FUD you spread trying to discredit other peoples work

Is that an example of going the extra mile?

I think that comment was a bit unnecessary.

No, I just continued ignoring known trolls such as yourself.

The question is also irrelevant.

I think luke-jr must have stopped looking in that thread.
Quite a few people are interested in the answer it seems
An honest answer would be appreciated
Thanks
Graet

... no response.

Listing a billion transactions that failed means nothing.
Most of the failed transactions most likely are simply a chain based on a few failed transactions.
The failed transactions that are the cause would have to be transactions that were sent out BEFORE the later matching transaction that won by going into a block

So basically to do ANY useful analysis to see if finney attacks can be related to the FUD you are bandying about: "MANY",
you would have to find the cause of the transactions - the transactions that all parent transactions are committed into a block, but that transaction itself failed BUT was valid otherwise.
Then you'd have to find the transaction that was sent out AFTER this transaction and committed into a block that caused that other transaction to never be committed.
Then you would have found ONE successful finney attack (though it could also be an SD correction to fix a mess up in SD)

Saying 'many' people pull off finney attacks is FUD
... and your a pool OP ... Jesus found a good replacement.

The risk of attempting a successful finney attack is simple - you need to put a transaction into a block and the txn must replace another valid txn already out there (0 confirmed)
Firstly to do this either you would have to rely on a VERY LARGE amount of luck to expect to find a valid block in the near future and use GBT (since the other protocols wont allow you to supply transactions) ... and yeah the luck option is not gonna happen ...
OR you would have to withhold the block that has the new transaction replacing the old transaction
e.g. then that old transaction SD bet would have to lose (and you wait to find out) and then if the bet fails, allow the block out.

Now looking at this without psychosis involved:
If your bet wins you would have to withhold the block permanently or your bet would be undone ... so you have to make big bets.
You would have to do it regularly to get the chance of winning a big bet
You would need a lot of hashing power.

Now who has a lot of hashing power? A pool.
... and as soon as a pool starts doing this sort of crap they will be found out ... so again it's pointless.

Though there is one pool that is known in the recent past to have been using merged mining to do things behind the backs of the community mining on that pool: Eligius.
... and ever since has been trying to hide this fact ...

Perhaps avoid pools is too strong of a response.  Perhaps ignore the odd transaction (assuming all GBT pools ) would be a better response?

So if I create two contradicting transactions, send one to pool X and the other to other nodes on the network, then miners would see pool X as the odd man out and stop mining there?

I'm not trying to be annoying, I'd just like to see one example where this works and isn't easily abused.

My thinking so far is that the best we can do is "allow small forks because they happen naturally, but never help create large forks." Perhaps that's good enough.

But we can. Even without a local bitcoind, miners can setup multiple pools and the miner can avoid pools that have an odd contradicting transaction compared to all the others.