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

Since the point of get_transactions is simply to confirm the merkle branches, you only need to allow it once per stratum template push. All the stratum pools so far only push a new template every 30 seconds. Limiting get transaction requests to 1 for each template would only allow the miner to ask for it once every 30 seconds.

By the same token, GBT pools should limit how often users can ask for a template since that does send out all the transactions.

Too bad you're more interested in ignoring me than having a productive discussion, or you'd have noticed I pointed out exactly why that isn't true.

Must I quote myself?
That IS correct.

I was exploring the possible issues with implementation of GBT and got attacked as though I was trying to spread FUD about GBt. Nowhere did I imply this is what all miners would be doing.

You've ignored the reverse situation.

With GBT (all current implementations) the pool must always do this.

With Stratum it is optional and yes some users could request it always.

Since it is an available option, then the pool must consider the load of allowing it.
(... and yes I mean they MUST consider the load, not that they should ignore implementing it ... though any that don't would be easy to identify ... due to their failure to respond any miner that requests it)

Surely you could keep requesting get_works with a script, why would you need any hashing behind it?

As with the get_transactions, surely you'd just place a limit on requests poolside, and ignore those that seem unreasonable?

When Luke was working on GBT and we were working on implementing a working vardiff, I had some concerns from a security standpoint.  The Stratum get_transactions also raises some red flags for me, can you address security/throttling measures in place to prevent get_transactions being used a DoS method to overload a pool?  Anything that leaves arbitrary data requests up to the client is an avenue for exploit and it is one of the reasons I have been so adamantly against user defined difficulties.  If I want to DoS your pool, I crank up a couple of 1.5 TH minirig, set my difficulty to 1 and ask for getworks. 

Same kind of problem with get_transactions:  I'm pissed at you, so I just request all the get_transactions you'll send me over and over and over.

Well, we're just talking about a first draft, it doesn't have to be perfect - the rest of the community will probably have things they want added or changed before the final anyway.

It's a step forward, at least; but the design here still encourages miners and pools to avoid (or bill extra for, as you mentioned) decentralization. I don't think "common miners" should be encouraged to centralize.

It's not either one or the other. The BIP process generally involves documenting and implementing a first draft, and then discussion to come up with a final standard solution that meets everyone's needs. Eligius had GBT since the first draft in February, but the protocol continued to change significantly as other developers contributed to it before reaching its current form.

No, I'm just busy. Writing sane documentation (in english) is pretty hard for me, so I need a lot of time to finalize something.


You didn't respond to Stratum's "get_transactions" extension explicitly. Can I ask you what's your opinion to this? I think it solves exactly that issue with blind trust for picking transaction by the pool, without unnecessary overhead for common miners.


I don't think so. I prefer coding, not discussion. We can spend months on discussions or we can both show our solutions and let others to decide.

Being polite and working together towards a common goal is crap? I am surprised that you participate in an open source project.


You like to make a lot of demands, don't you?

ckolivas wrote that if the miner selects transactions you have to send in every transaction with every share. This is incorrect and has been discussed enough already, I think. You said that GBT, a protocol, makes decisions on which transactions to include. How does a protocol make a decision like that? And GBT being "an abortion", I don't think that's entirely correct either.


I never said I designed GBT. I said I suggested a few improvements for it. And what does religion have to do with this?

You told me to "fuck off" because I don't contribute. I was merely stating that my contributions are already in the spec. Where are yours?


You picked 15 random blocks from BitMinter. They were 5 big blocks, 5 medium and 5 small. And so you come to me and demand an explanation? I find that utterly unreasonable.

If you don't like pools that filter out transactions, then talk to them, not me. I don't put any limits on transactions.


No, you said that, not me. What I said was that I include all the transactions bitcoind gives me, without filtering out the free ones or putting any limit on the number of transactions, like some pools do.

GBT and bitcoind are not the same thing. If a bug in a web server makes it give you half a file, do you blame HTTP?


Maybe that would be a good improvement for GBT. If the miner doesn't care about seeing the transactions or filtering/adding transactions, request a merkle branch instead that you can use to create a merkle root for mining. Not a single transaction goes over the wire, other than the generation tx.


Of course HTTP is a constant connection. Use persistent connections, and pipeline requests for speed. My miner uses 1 long poll connection and 1-3 connections to get work and send in proofs of work. For the work connections it will pipeline up to 10 requests at a time. All the connections are persistent. They get closed only if they have been sitting idle in the connection pool for a while.

The advantage of Stratum is that it is designed to be two-way from the start. Long polling in HTTP feels dirty and hackish.

The advantage of HTTP is all the network infrastructure, proxies, libraries that exist, and all the knowledge that developers have about this protocol. When you already know the protocol, you have a library for using it that you already know well, then it is much easier to get started.

Allowing miners to modify transactions is not implemented in miners yet at all. Block Proposal only makes sense as part of that. I do have it implemented for the Eloipool<->bitcoind link.

There is a Bitcoin development mailing list specifically for discussing all things related to Bitcoin development. GBT had a number of threads of discussion on it since February.

Why?
That's fine, Stratum seems like a logical place to start for a new standard. It would have been nice if these things had taken place during the GBT standardization, but that's in the past now. How goes getting StratumMP BIP process off the ground? Are we still waiting on genjix?

You keep saying this, and I keep having to correct you: No, the main focus of GBT was from the start was pooled mining. Citing the Motivation section of BIP 22 from all the way back in the original February draft... "There is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold. By exposing the details of the block proposals to the miners, they are enabled to audit and possibly modify the block before hashing it."

This is just trolling.

Lulz - I can post at 2.6 and still see you've posted crap.

Post some grounds for your delusions or ... yeah I've already said it ... oh great you even quoted it below

Give some grounds for this crap

I was in this discussion long before you and made contributions before anyone had this in production. With every thing I didn't like I sent in a suggestion for how to improve it. Many, if not all, of my suggestions went in the spec. Now you are telling me to fuck off, because I don't contribute? I think we have different opinions about what a contribution is.