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

This isn't possible even in theory.

They also didn't happen, or are being presented by Kano out of (important) context.

What in specific would you like a response to? Kano spouts so much lies and nonsense that I generally ignore his posts.

Well following your link I've read a lot there of you trying to tell everyone else what they should do.

You wouldn't happen to be Luke-jr would you ...

Anyway, you've made no case either - you've simply stated you don't care what rules Luke-jr has in GBT.

I will point out the following:

1) Luke-jr's pool uses rules to ignore transactions that he will not divulge
2) Luke-jr used his pool's hashing power (without the knowledge of the miners) to effectively kill off an alt-coin
3) Luke-jr had a performance improvement for the BFL device driver for cgminer that he used himself but didn't release

The simple issue is that everyone has their own opinion of what they think is best ... yet you seem to not care what rules are in the software you use ... yet you also seem to care that you don't know the rules that pools are using.

Your argument's main point is in fact also your own ignorance of that point - that you have access to know something that you don't even care to check before you use it.

My initial statement was to simply point out that the comments about GBT being better than Pools due to 'decentralization' were only valid when solo mining and not better than P2Pool (and worse than P2Pool when not solo mining)

That fact that you blindly trust Luke-jr - well good for you.
I have learnt from dealing with him that I certainly should not do that.

Now to top that off, since you say that you can check these things, I will also point out that you can check these things with any pool.
The transactions available on the network at any particular time are visible to everyone.
The transactions placed in every block mined are also visible to everyone as soon as the block gets into the block chain
You can clearly see for every block mined, what transactions were selected and what were ignored ... if you wish to.

To correctly state your question:
What are the rules that BarbieMiner uses to select the transactions to put into the GBT blocks?
No doubt you don't already know what they are ... without at least first looking them up now ...
You see the point of my statement?

Edit: and to add to that ... once you finally bother to look up and learn what rules he uses, do you know how to change it to suit what you think it should be?

... actually - no - who actually sees what goes into the blocks?
The software you mine with decides - and if you use the gbt luke-jr implemented - then luke-jr decides for you ...
Did you read the gbt code he wrote when you mined with his BarbieMiner?

That depends on your point of view. As a pool operator or miner with ultimate trust to the pool operator you are right. From the perspective of a miner that cares about what goes into a block it is important to see the complete information.

With Stratum, the pool operator is the one that creates bitcoin blocks and makes the rules. The miner is paid for doing some work for the operator. With GBT the pool operator is a work dispatcher but miners create the bitcoin blocks and make the rules. I don't regard more information and control as a waste of resources.

The issue is quite simple.

If you personally want 100% decentalization then you must either solo mine or use P2Pool - not GBT to a pool.
GBT to a pool is not 100% 'decentalization'

However, with 30MH/s, you will possibly never get any BTC solo mining.
Your average expected time to find a block at the current difficulty is 5062 days ...

As for pools in general ... luckily, people are allowed to choose hey?
BTC isn't a Luke-jr dictatorship (even though he wants to force that on everyone)

So why were you already pool mining if this is an issue for you?

If decentralization was in ANY way relevant to your comments then you would have been solo mining or using P2Pool.

... which have been around for a long ....... time ...

Well, it is not "few kbytes saved versus save the network". I had quite long discussion with gmaxwell yesterday on -dev and I simply don't see any real attack vector which can be performed just because pool send merkle branch instead of transaction hashes (and this is REAL difference between Stratum and GBT). The only real attack vector which we found is that CIA will kill me, Tycho, Eleuthria, Graet, Inaba and some other pool operators, overtake our pools AND users won't notice anything and they'll keep on hashing invalid/broken blocks for CIA.

So from my view, GBT is wasting resources for no real gain.

kuzetsa, meet Luke

I just edited slightly, making the ((...snip...)) in the channel log thingy more obvious by inserting additional vertical whitespace (newline) above and below (3x newline padding instead of
"singlespaced" newline)

Just want to assert: There was no misquote, just an omission for the long duration of "you're wrong, no you are, no you"

--- luke. feel free to fill the ((...snip...)) with what I left out.

My main thought is that I prefer stratum because it gets fewer stale / invalid / orphan or whatever they're called. Stratum was working and had an installed userbase and is ASIC ready, predates GBT, etc.

Longpoll over HTTP-type transport is making GBT less attractive to me than stratum. Any mining protocol using a full TCP transport or even a non-stateless version of udp, etc. (basically, anything with an active connection, therefore by definition not http) will allow for incremental changes to the workload and immediate notification of new block.

There is no reason GBT's features can't be overlaid onto stratum or other non-HTTP mining protocols. (or the reverse for that matter, nothing TOO major that locks GBT's underlying structure to using HTTP)

Before all of this drama started I had planned to be in bed by 30 minutes past midnight. That was 3 hours ago. guess I'll just end with this:

Luke, I've been using IRC since the mid 90s. New to bitcoin and I don't need threats like this when I'm still a n00b because your agenda is threatend or whatever it was that upset you. please be cool.

That is the trade-off.  GBT is far more compatible with existing software.  Stratum is a wholly new protocol requiring wholly new transport implementation, but it gains some efficiency over HTTP.

Perhaps, but implementing Stratum is a lot of work (at least on the miner end). Better for pools to support both IMO; at least that gives the miners a choice of whether they want to retain control or blindly hand it over to the poolop.

I see more GBT deployment than Stratum, thankfully.

P.S. Since the mods here don't do their job, I have to point out that kuzetsa is misquoting me.

The pragmatic solution is to support both GBT and stratum, in mining software.

Both are already deployed, and stratum seems to currently be winning the race for deployments.

GBT is supported in bitcoind and p2pool, and has gone through the BIP process and more review, so a choice seems valid.  GBT is also more easily deployed in existing software, as it uses the more standard HTTP JSON-RPC that miners are familiar with.

Angry neighborhood bastard mod here.

Luke, what did I tell you about trolling the noobs? Cut it out before one of the admins decide to either scammer/troll tag you or ban you.

No real explanation given. Just that I'm irrational.

Often as I truely am irrational or even confused, this seems more like  "argumentum ad hominem" to me.




...Edited to add:

Forgot to datestamp.

Local time rolled over from wednesday. Now it is Thursday, september 27th 2012




Consider my official response "No"

I'll not be bullied into censoring this.

Feel free to take it up with freenode staff or law enforcement.

I'm confident that I know my local laws:

• I live in a "one party consent" jurisdiction for purposes of recording a phonecall.
• Your channel is public (not passworded, nor invite only, etc.) and freenode has no such policy as you described.

Longpolling is a very elegant and useful... hack.  It is a hack because HTTP clients typically initiate requests, and elicit server responses.  This HTTP client behavior does not cover server-initiated messages that the client is not expecting.

Longpolling says "wait, until the next server-initiated message to me"

Most custom designed protocols support server-to-client asynchronous messages, so there is no need for the hack.

Yes, of course.

Unfortunately, I haven't optimized GBT in BFGMiner at all yet, so I doubt it would compare well vs Stratum proxy. It would be interesting for someone to make a quick port of the Stratum proxy to GBT (python-bitcoinrpc + python-blkmaker should do it very easily) to compare with. Of course, you'd also need a biprotocol pool, which AFAIK doesn't exist yet.

If I understand correctly GBT also supports LP, doesn't it? Did you make use of LP with getwork and GBT in your test?

Since stratum is working over a plain TCP connection, one could say that the equivalent of LP is just a simple TCP "message" like any other one, isn't it?

It would really be interesting to see the stale ratio of GBT+LP vs Stratum over one week on the same pool/same connection.

stale/reject ratio is basically 2 things: 'LP' issues and processing work for too long according to how long the pool will accept the result (and the protocol may allow that all the way up to an LP)

3 different protocols still have that same requirement: accept work or reject it.

There are of course 3 factors in it:
1) The mining software
2) The protocol
3) The connectivity between them

If the miner/protocol/pool is rejecting more work then there is some issue that needs to be resolved.
(or the design is a POS)
As I stated, I get around 0.3% stale with a standard pool protocol
(I can also add that my pool connect is half way around the world, so that should be close to about as bad as it can be)

However, comparing cgminer+getwork/LP+a standard pool
is indeed quite valid.

What other comparison could be made?

Fake up some excuse for bad performance?

His figures are showing his miner+his protocol+his pool are clearly worse than the setup I described ... and I will add that ~0.3% or better is not unexpected from people using cgminer+getwork/LP+'choose random pool'

So I'm not sure where the apples and oranges are ...

kano, now you're comparing apples and oranges. Stale ratio is affected by many factors and there's no obvious reason why GBT should be worse than getwork.