I seems that an issue posted on the bitcoin git is not the correct way to do this. Seriously, quit trolling. It doesn't matter where. I'll firstly look at it from a technical point of view:
The getmemorypool command is an interface to allow anyone to create any type of block they like that bitcoin will validate with very generic rules. It's a mechanism to export part of bitcoind's functionality as an API so that external software can use bitcoind's implementation of transaction acceptance rules. This allows someone to bypass the limited set of approved transactions that are within bitcoin and create non-standard and possibly non-functional transactions and put them permanently in the block-chain. This mindset is extremely dictatorish. There is no organization/person to "approve" transactions allowed. The current status quo of the bitcoind developers controlling things in practice is a bad thing which needs to be solved by more implementations and miners/users stepping up to customize their own rules. Is this where bitcoin is now heading?
No desire to attempt to enforce the types of transaction and only add new types with general consensus? It better be. Replacing the Fed with Gavin isn't exactly a good thing (no offense, Gavin). However, for the actual reason why it has been created:
It was created to allow merged mining with namecoin, so the namecoin devs did not have to modify the bitcoin code each release.
It is also an issue in my opinion that the reason was not part of the pull request and clearly avoided. No, it was created for p2pool, which had previously been making blocks without any transactions at all, thus harming the Bitcoin network. getmemorypool gives p2pool access to transactions it knows are safe to put in blocks. The side effect namecoin merged mining has for the block-chain is to add around 46 extra bytes to each bitcoin block created with merged mining. 29 actually. The namecoin web site also hides this fact by denying that any extra data is put into the bitcoin block-chain on their main page about merged mining http://dot-bit.org/Merged_MiningI have requested around 2 weeks ago for that error to be corrected and no one has done so. It's a wiki: correct it yourself. The point (I presume) is that it isn't extra data. It's just part of the standard Bitcoin protocol being used. On the other hand, there is quite a bit of actually extra data required in the Namecoin blocks. Not only does this sanction putting non-bitcoin, namecoin data in the bitcoin block chain, but it effectively says that any other alternate chain can do the same thing also. Actually, the data put in the coinbase isn't even namecoin-specific. That same 29 bytes is designed to support up to 32 different aux chains, and could reasonably be extended to more in the future. I'd say that disallowing this commit would put out the word that bitcoin does not want any extra non-bitcoin data thrown in the bitcoin block-chain and that clearly seems to be an issue of note to some around. "Bitcoin" is not an entity, and Satoshi himself was the original innovator behind (and explicitly endorsed) merged mining. The problem with going for a middle ground is that what amount of extra non-bitcoin data is considered OK?
If 46 bytes is OK, then why not 56 bytes or 106 bytes or ...
Clearly a line needs to be drawn, but I can't see any line making a statement other than to set the boundary at zero. The line has been drawn in the Bitcoin protocol since the first block: there are 100 bytes for miners to put whatever arbitrary data they want into blocks. The original uses were (block 0) political propaganda and (bitcoind code) extranonce, but it was intentionally designed to be arbitrary for future extensions. |
|
|
|
|
Eligius is now merged-mining enabled fwiw
|
|
|
|
How about just sell the namecoins for us and pay everyone per share in BTC. No need for accounts or logins.
Not everyone doesn't want NMC either  |
|
|
|
I would still like to see option two. It keeps in tradition with having minimal interfacing with the website. Just point your miners and mine, no accounts, log-ins, etc... True... Maybe usernames can be "BTC+NMC" or "BTC+" (to use the same key; export/import). But either way, we need another solution for the already mined NMC. |
|
|
|
Got it, thanks. So is it going to be easier to have someone use a miner that supports sending an extremely long HTTP auth field or exporting and importing keys if they really want namecoins? Possibly one or the other, but not likely both... Possibilities I see: - Send to the Bitcoin key on the Namecoin network (ie, key export/import) on demand
- Require miner that can send a long username
- Provide a web interface for account options (including Namecoin rewards and changing minimum payout)
I like the lattemost the best  |
|
|
|
How about a BTC address.NMC address as user id. If a NMC address is not provided then more for you or split between those who do care for them.
Many miners can't send usernames that long. If you export your Bitcoin key and import it to Namecoin, that works reasonably. Can it be expected that every single user will do this? If no will coins go to waste using this method? How about a NMC Address in the password field? Half the "problem" is that some people simply don't care for Namecoins. So I want to avoid wasting them if possible. Username and password are the same exact field in HTTP auth. |
|
|
|
How about a BTC address.NMC address as user id. If a NMC address is not provided then more for you or split between those who do care for them.
Many miners can't send usernames that long. If you export your Bitcoin key and import it to Namecoin, that works reasonably. |
|
|
|
Namecoin is, as previously said, going to the pool's wallet and will be distributed in a yet-to-be-decided way, and your input on specifically HOW to distribute it is welcome. From the timestamp of merged mining start, all btc pool earned divided by personal btc earned to get % of nmc each user should get. Basicly , any option is better than merged mining without getting nmc,s. Perhaps, but many users don't care about nor want NMC... what then? Maybe until I get a better system in place, I can do a daily or weekly distribution to interested users based on their contributions... need a way for users to express interest and prove they contributed tho. |
|
|
|
i guess i figured that i have to w8 to get auto paid to my wallet using btc, but what about nmc i earn, where can i view them and how do i payout them ? You can see Bitcoin info at http://eligius.st/~artefact2/5/YourAddressGoesHereNamecoin is, as previously said, going to the pool's wallet and will be distributed in a yet-to-be-decided way, and your input on specifically HOW to distribute it is welcome. |
|
|
|
That doesn't support anything but proxy, and is in fact the exact code my merged-mine-manager is based on.
1. ask proxy for actual aux using getaux method 2. use this aux in getworkaux(aux) for asking directly bitcoind for new work (no mm call here) 3. filter out shares with lower difficulty than min(bitcoin difficulty, namecoin difficulty), send the rest to proxy. It still make almost no load to proxy 4. If your pool detect that namecoin or proxy crashed, use latest aux for all getwork requests, so you don't need proxy. 5. If you receive share during proxy outage, call getworkaux('submit', <datastring>) directly to bitcoind to submit a block 6. Profit! (And without any custom code) Not the same thing. It still requires the messy bitcoind patches, and you need to integrate it with your pool software. :p |
|
|
|
It is impossible and unreasonable to force everyone to have the exact same system clock.
I think that Lolcust and ArtForz provided a good counter-example by their GeistGeld alt-chain that uses SNTP for time synchronization. The objective is not "exact-same" system clock, but the system clock differences that are within currently acceptable norms: I think it is still one minute in the insurance industry and in something close to one second in the finance industry. Notice that I didn't say it's impossible/unreasonable to actually have the "exact" (within reason) same clock. I said it's impossible/unreasonable to force it. But anyhow, it is indeed an off-topic discussion for this thread, which has nothing to do with block times. :p |
|
|
|
Well so far it seems to work... Really? What big pools support it? Where is the data showing there's been no loss of Bitcoin blocks/hashpower? I've in fact heard reports to the contrary... The only risk i see is that you can risk to lose your work on that pool but as long as you accept that risk, i think it's fine Due to the panic-rush of it going live before being documented, I have deployed my alternate implementation to Eligius. Unlike most pools (ie, those using the proxy), Eligius does not have this risk. |
|
|
|
That doesn't support anything but proxy, and is in fact the exact code my merged-mine-manager is based on. |
|
|
|
Why custom? Vince's implementation inserts a proxy between pushpool and bitcoind, adding yet another untested point of failure and bottleneck.
Since merge-mine-proxy 0.2.2 there's chance to use this proxy only for share submits and ocassional aux update by pool software, which cannot be bottleneck at all. However yet another custom implementation is giving some chance that those versions become incompatible  . In fact, people have already begun reporting issues with it.
Because they're using naive way of putting merge-mine-proxy between pool and bitcoind. It's not necessary at all. Eligius's implementation puts all the merged-mining stuff BEHIND bitcoind, where it can be ignored if it malfunctions (while Bitcoin mining goes on as usual).
Which can be done also with vinced's proxy version without a problem, as I did. Pleae don't spread the FUD . Or maybe because nobody knows where this "merge-mine-proxy 0.2.2" is, if it's even publicly available? |
|
|
|
Following Gavin tagging 0.5rc1, I have tagged the stable git tree "v0.4.1rc1". If you are able, please compile and help test. See the doc/build-*.txt files in the source tree for instructions on compiling. Binary releases for at least unix and mac will be available only if someone steps up to the task. There are no major changes from version 0.4.0, only bugfixes. None of the features from 0.5 are supported, only those in 0.4. Run: git shortlog --no-merges v0.4.0.. ... to get a complete list of changes, and thanks to everybody who is contributing! Edit: The stable branch is on Gitorious |
|
|
|
The argument that I have: it appears that "getmemorypool" is a step towards allowing the miner to record a reasonably accurate time of finding the block. Which is in turn a step towards more tight and accurate timekeeping in the whole block chain.
Your patch just perpetuates the existing bad situation where the block times are untrustworthy and acausal. Block times will always be untrustworthy to a degree, and are already trustworthy to a degree. It is impossible and unreasonable to force everyone to have the exact same system clock. "getwork" does not enforce the time header, anyhow, so "getmemorypool" does not change this reality in any way. (that is, "getwork" allows miners to change the time at will) |
|
|
|
We're now testing a CUSTOM implementation of merged mining with namecoins. What is merged mining? Basically it means the pool gets some Namecoins in addition to the Bitcoins we're already getting, at no cost to us. In return, the namecoin network gets more hashpower confirming their transactions/domains. Why custom? Vince's implementation inserts a proxy between pushpool and bitcoind, adding yet another untested point of failure and bottleneck. In fact, people have already begun reporting issues with it. Eligius's implementation puts all the merged-mining stuff BEHIND bitcoind, where it can be ignored if it malfunctions (while Bitcoin mining goes on as usual). Unlike most merged mining pools out there, I have taken great efforts to ensure it does not affect the Bitcoin mining in any negative way. Distribution of earned Namecoins is still to be decided. Suggestions welcome. Long-term plans is to have it work the same as the Bitcoin mining, but that requires a rewrite (which I'm actually started working on!). Also, on the rewrite... current plans are to support TWO reward systems: - PPLNS or (new idea) Proportional × 8
- ESMPPS or CPPSRB
|
|
|
|
No, getmemorypool has nothing to do with setworkaux, coinbases, or merged mining. It's a JSON-RPC command that was merged with even less review than coinbaser, and is only used by a single pool.
Huh? getmemorypool discussion is/was here: https://bitcointalk.org/index.php?topic=39088.0I'll just note that I'm damned if I do pull stuff that has some discussion here (and no objections raised), but damned if I don't pull stuff that first had no discussion, and then had a little discussion with some dissent. 1-2 people supporting getmemorypool vs 9 supporting coinbaser. hmm. What dissent? I see questions, and some "no" votes (strangely, most of which just appeared today), but no arguments against this. |
|
|
|
Does setauxwork interact with the new getmemorypool RPC command at all? Should it? No, getmemorypool has nothing to do with setworkaux, coinbases, or merged mining. It's a JSON-RPC command that was merged with even less review than coinbaser, and is only used by a single pool. And should there be a listauxwork RPC command? Possibly as a debugging tool. |
|
|
|
setworkaux looks pretty much like what I'd imagined. You might want to split the command line option out, as that's a separate and unrelated change. They're very much the same change: they both together support customization of the coinbase transaction. BTW, what's the backwards-time detection stuff about? I know time can sometimes go backwards on some machines, but you could add a comment explaining why this code is there (was it observed in the wild on eligius machines)? Also it doesn't currently log anything when extraNonce overflows - is that an exceptional condition or something that's expected to happen normally? If the former (it's a bug) maybe assert/terminate. If the latter does it need to be logged? If it's unknown, logging for a while seems to make sense. Just a safety precaution. I don't know if it's possible or ever occurs. (otoh, it's very easy to see many existing code paths in bitcoind cannot possibly occur... ) |
|
|
|
|
Show Posts
