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

I'm going to just chime in to address this particular comment, if for no other reason but to discredit the kano.

In a conversation yesterday evening this particular issue regarding Eligius was discussed on IRC, and kano was given a link to the post on this forum from months prior stating that these actions were being taken on Eligius.  Now, since I personally pointed this out to him, this post of his is clearly after I pointed this out (October 31, 2012, 10:05:21 PM is after both October 30, 2012, 11:57:55 PM and also well after the original post date below), and yet he still publicly says that this information was "not divulged before"? Well sir, you deserve to be called a liar, and it should be obvious that you are simply trying to discredit the work of others in the community, to what end I do not know.  Want the proof?  I'm not going to just make accusations without proof.  Here it is:

Bitcointalk post from June 17th 2012: https://bitcointalk.org/index.php?topic=23768.msg968819;topicseen#msg968819  This post clearly states publicly what the pool operator at the time decided to do with Satoshi Dice transactions and limiting the transaction count.


For reference, here is a snippet of IRC log from yesterday evening (timestamps in UTC-0400):
(anyone is welcome to entirety of this several hour conversation upon request.)

Tired of all the childishness around here, especially now that I've taken over management of Eligius.  Apparently that means that I get to field the BS that kano usually directs towards Luke-Jr, and I'm not going to tolerate that kind of trash.  It gets really old and is very counter productive.  Stop with the FUD because you're just making yourself look stupid.

-wk

This is my opinion based on what I have read in the threads here, I have no experience developing code for these mining protocols so you take my opinion for what it's worth. (not even a satoshi) :p

With that said it's easy to conclude that since cgminer and others have implemented stratum over GPT kind of gives my opinion a bit of legs to stand on. 

In reality, GBT is much less work for pools/miners/software developers to implement, and does everything Stratum does with a little more overhead (that probably won't be a problem for a while).
I agree GBT could benefit from adopting some of Stratum's design concepts (I wish slush participated in the GBT BIP process so these could have been integrated from the start!), but in practice we have plenty of time for that before it's an issue.
IMO, most likely the next-generation mining protocol to replace GBT (and Stratum) will use a persistent TCP connection, fully transparent, and probably based on the original Bitcoin p2p protocol (it has some convenient overlap, and eliminates the small JSON overhead both GBT and Stratum are subject to) - and maybe even a p2p-friendly design.

Thanks I will keep reading and Kano's posts.



Good points, I'm not against GetBlockTemplate (GBT) I just want something that works for everyone not just those with a mensa membership card. :p  lol With that said, I understand that bitcoin is a complex protocol to begin with and we don't want pools to consolidate and use the hashing power for evil once there is nothing anyone can do about it.  However that is not an issue right now so stratum is fine transition from GPU/FPGA mining to ASICs.  In the future we will need GBT.

Bottom line I want GBT but stratum gets the job done faster and with less work for pools, miners and software producers.

...And where do I fit in? Despite what it may look like, this is a technical discussion about the disadvantages of GBT.

Hey D, big fan.

That being said, Luke's right. Kano's in this for profit more than love (obvious from his post history here if nothing else). In addition he tends to bend the truth past the breaking point quite often. These two statements are fact I'd encourage you to verify their veracity for yourself.

The following is my personal opinion which I happen to believe is right:

The reason that LukeJr supporters tend to discount poster like Kano is the simply because Luke has a technical mind, understands how things work and also is a proponent if not an advocate of the bitcoin network's need to be transparent. That's basically what this entire post is about... Luke (and myself and anyone who loves liberty) would rather take a slightly less streamlined process that we can see through than trust a pool op to inform us of what's happening. So sure, Stratum is less bandwidth at the cost of giving the pool op the ability do whatever they want behind it and the miners never knowing. It makes me wonder what they'd like to hide.

Also, I'd call it trolling when Kano comes here to decry the 'bad design' of GBT when the real issue is exactly what I've posted above... at the very least he's dishonest for not simply making his case for what it is... the desire to open a wedge into bitcoin that can be exploited later either by himself or others... without those of us actually doing the work knowing about it.

I may not agree that it's an issue but Kano is not a troll for voicing his a opinion.  I have a YouTube channel and I get a lot of trolls and Kano sounds nothing like the trolls I get.  I got so many I did a video for them...

http://www.youtube.com/watch?v=8sQaIeHvuM0

It was funny and even the trolls loved it.

Ignoring is the standard appropriate way to deal with trolls. I just put that out there so newbies know why he isn't getting a response.
There's no basis to Kano's accusations in any case, so not much really to say about them other than that they're lies.

Calling people names does not prove you are correct.

People called me a troll and liar because I said money is created when people go into debt at a bank.  So does someone calling me a name make it true?  Is the documentation found in Modern Money Mechanics created by the banks a lie?

"Of course, they do not really pay out loans from the money they receive as deposits. If they did this, no additional money would be created. What they do when they make loans is to accept promissory notes in exchange for credits to the borrowers' transaction accounts."
Modern Money Mechanics

I understand the truth of our monetary system and this is why I like bitcoins as a solution to our unfair monetary system.  So lets forget the name calling and find out the truth.

Finally I am not sure if it's a bad thing that miners are ignoring transactions as that's part of the market saying... hey you are not paying me enough to include your transaction!

There will always be miners that work for low to no transaction fees because they believe in the system, thus there is no need to be a "government" and attempt to force good behaviour.

Just my 2 satoshis

So now that yet again Luke-Jr has called me a liar ... which is a common thing for you to do and you have never once proven that true when you have said it ... though I have proven it true in reverse about you ... where is the lie in my post?

The only point you have made is that GBT is a protocol and the implementations are the fault of the implementers ...

So who implemented them?

You in your cloned BarbieMiner, you in your pool, and ... "someone" in bitcoind.

I guess the other place to look will be P2Pool - but I don't know if that just gets the results from bitcoind or if it processes those results.

BitMinter blindly accepts the results from bitcoind (according to DrHaribo's response)

--

Luke-Jr if you are going to use you standard method of distributing FUD by hiding behind definitions of words then I guess you are really saying the GBT is simply an idea and no use in the real world.

The implementations are what use it and if the implementations are bad for BTC then GBT is bad for BTC.

The two first implementations I listed are also by you ...

--

I've explained to you and also mentioned to Gavin a suggestion about the problems with bitcoind and dealing with large blocks.
Specifically that each block transferred from one pool to another sends way too much data that most bitcoinds already know and does way too much work that the bitcoinds have already done.
That's as far as I went - and seems a good enough solution.

(Edit: and GBT doesn't even use this simple and obvious idea)

I don't deal with bitcoin code development directly, there are just way too many issues with doing that and I have (made clear) elements of it that I disagree with and twice when I've raised those issues they have been shot down.
Fine - I disagree with the devs - so I don't think throwing code in that direction would be productive.
Ideas and issues are what I do throw in that direction.

Meanwhile, your solution at your pool was to reduce the number of transactions per block to 32 and ignore full paying transactions (Satoshi Dice) and who knows what else because of that.
I guess the reason you would not divulge that information before was that people would then know that your own pool was ignoring full paying transactions and that would show you as the hypocrite you are.

--

Anyway, I've reset both my bitcoinds and will see how big the memorypool is again in a week or two.

One of my 0.7.0 bitcoind started:
09/22/12 08:30:55 Bitcoin version v0.7.0.3-g0a4e67a-beta ()

It first reached 4000 after less than 4 days:
09/26/12 00:04:23 CTxMemPool::accept() : accepted 8f15d5ec48 (poolsz 4000)

The last time it was under 1000: (one month after it started)
10/22/12 13:35:31 CTxMemPool::accept() : accepted 0a8e298047 (poolsz 999)

The last time it was under 2000: (two days after that)
10/24/12 15:41:28 CTxMemPool::accept() : accepted f14b7e229c (poolsz 1999)

The last time it was under 3000: (almost 8.5 hours after that)
10/25/12 00:02:21 CTxMemPool::accept() : accepted 879a991172 (poolsz 2999)

... and it kept growing ...

As I said, there is no existing implementation of miner-side transaction control yet.

Kano is a troll and basically a liar.

GBT is a protocol, it doesn't and can't "ignore transactions".

Bitcoind, by default design, has always ignored spam transactions when it can detect them.
The Bitcoin protocol, by Satoshi's original paper design, specifically depends on miners choosing to ignore transactions that don't meet miner-defined policies.
But again, one of this has anything to do with GBT; transaction acceptance works exactly the same whether you use getwork, GBT, or Stratum, except that GBT moves the final decision for which transactions to include to the miner (note that no mining software supports changing the pool's decisions yet, but I plan to have future versions of BFGMiner support adding more transactions from bitcoind to collect on fees).

bitcoind has always made a decision about which transactions to include in a block. That has nothing to do with GBT which is just a different API for getting this (and other) data out of bitcoind.

By the way, kano, if you have a suggestion for how bitcoin can be improved, you can set up a pull request on github and I'm sure the bitcoin developers will consider it.

If GBT is planning on going anywhere, this has got to get fixed. Ignoring transactions is bad.
If this doesn't get fixed, I doubt pools will support GBT.

Waiting to see how LukeJr responds.

So ... I've had a go at a pool OP about ignoring transactions and found to my surprise they aren't the ones choosing the transactions.

GBT is.

Here's a run of 15 block for the said pool and look at how bad this is for the bitcoin network - shocking in my opinion:

Bitcoind's GBT is deciding the txns, and it's regularly making small blocks when the bitcoin network constantly has a very large number of outstanding transactions (>4000)

This of course means that everyone's bitcoind is sitting there with a list of many thousands of unconfirmed transactions waiting to go into blocks ... and it is bitcoind's own GBT that is part of the cause of it ...


6 blocks (1/3) in there you could consider large (>100 txn),
6 blocks (1/3) are very small (~10k or less and few txns)

Is this basically saying that GBT doesn't adhere to the fee structure of bitcoind?

Is GBT's aim to have every bitcoind on the BTC network constantly running large (>4000) txn memorypools and keep them growing?

...

I will also point out that the Eligius pool has for many months restricted all it's blocks to a limit of only 32 transactions and to ignore transactions that pay full fees if they are near the lower limit - as stated by the new pool OP.
The old pool OP is the same proponent of the so called decentralisation holy grail GBT ... that is CLEARLY showing itself to be bad for BTC and the BTC network.

I see the link there as expected, not surprising.

The argument given for the 32 transaction limit was that it reduced the risk of orphans (which of course it does) however, the issue there is that larger pools with better software did not have the orphan problem Eligius had and instead of fixing the performance problems of the pool software, Eligius' solution was instead to detriment the BTC network by reducing the number of transactions being confirmed and thus extend confirmation times.

Even the new pool op has clearly stated that his intererst is in short term return, not considering the bad long term effect of such short sighted decisions.
i.e. a quick buck with risk of long term problems vs a long term strategy that will also pay much better in the long run.

I've seen Luke-Jr make many arguments about what's good for BTC but only to find that he himself is a proponent of doing thing that are quite simply and clearly bad for it - and it seems that GBT follows this same path also.

Edit: this also explain why people mining with GBT aren't having the expected network problems of receiving hundreds of transactions with every request for work - since GBT ignores most transactions.

Easy way to see it: ./bitcoind getblocktemplate | grep sigops | wc
Sometimes you get a lot and sometimes you don't get many at all - even though if you check your debug.log it will show thousands of unconfirmed transactions (poolsz)

Getting off-topic here, but Eloipool has always ignored passwords entirely, and only used username for share logging (ie, no checking against a db).

I see your point.


It was used for HTTP reuse of code but I guess with a new protocol it's not needed anymore eh?  I can't think of any reason why we should have miner passwords.   LOL

Win is when Stratum undergoes the BIP process and gets feature parity with GBP. As I understand it, slush is taking it down that road now.

Yes, I did that about a year ago...

Easier than the alternatives

Eh, why do we need passwords?

I did that on a Asus EEE and it took 2 weeks!
When I turn it on after a day it's about 1 hour to catch up.

Crazy!

Anyhow: Luke-jr!

Personally I think stratum is better, however, if you want to win create a pool back end that's easy to use.   Better doesn't matter when it comes to wanting to accomplish a task.  I want a pool, and so does many other people!  So create a sold backend that's easy to config and setup and you win.

I know you have created Eloipool but I'm willing to bet it's not so easy to setup.

Another option is to create vm for people to download with everything working only thing that the end user needs to do is add a username and password to the worker table and they can mine and shares can be obtained from the shares table.

Just my 2 Satoshis.

Are you using the "royal" "I" in this case?  Because I did no such thing - I can stand up a new pool on my local network in about 30 minutes if all the pools suddenly went down.  But anyway, comparing an A64 X2 to an ARM processor is not exactly a fair comparison.  Go ahead and try to load the blockchain on an old netbook and see how far you get before everything grinds to a halt.