Managed to get a cross-compiled static EXE for Windows users; it's linked from the 2nd page of the registration (ie, when you need to use it).
Thanks for putting it up, and thanks to whoever compiled it as well. I did that, too... in case you wanted to donate for it  will this force me to convert the wallet with my current pool btc address to bitcoin client v0.5rc? The wallet format only changed between 0.3.x and 0.4.x; 0.5.x does not change it. Either way, backup your old wallet-- I take no responsibility if it gets corrupted through some weird bug. |
|
|
|
|
Managed to get a cross-compiled static EXE for Windows users; it's linked from the 2nd page of the registration (ie, when you need to use it).
|
|
|
|
comments on IRC [12:11:04] <Grinder> yeah, I know. I just like trolling. |
|
|
|
Your being an OS racist by making us give a bitcoin signed message to add a namecoin address ! How many windows users have the neccesary compilers and libraries to compile their own binary? How many Windows users have namecoin? At the time, it was my understanding (from the Namecoin docs) that only Linux was supported. Since the password field is not being used why not have the namecoin wallet address input as that? That might be an option when the rewrite is done with an automated infrastructure, but wouldn't help for past work/shares, and not viable for doing payouts by hand. Also, there'd be no way for miners to confirm their software is submitting it properly (many cut off username+password too short for two addresses) |
|
|
|
And those blocks without magic prefix are accepted by the rest of the nmc network? If so that's my concern dealt with.
That's weird. What is the prefix for, if Namecoin doesn't actually need it? It was originally proposed as a way to prevent multiple MM hashes in the same coinbase. After a few people (myself included) made a fuss over the inelegance of it, I presume it was changed to the current (not too much better) method of forcing a specific slot in the aux merkle tree. |
|
|
|
i tried to build bitcoin in linux (mint in vm) and it looks like libdb4.8++-dev is only available in squeeze and it depends on libdb4.8-30-2 and mint has libdb4.8-30-9 and lots of stuff depend on it. Going to try to download squeeze vm image tomorrow ...
If you're still using bdb 4.7, you want to build it with that... |
|
|
|
|
I'll see about finding someone who can make a Windows binary... :/
|
|
|
|
Version 0.5?
The latest version is 0.4.0
You can get 0.5.0 rc1 from https://github.com/bitcoin/bitcoin/tags0.4.0 does not support the signmessage RPC Commandline is required for namecoin in general, not just mining them. |
|
|
|
Where do i find my signature?
You generate it with bitcoind 0.5 using the command it tells you. |
|
|
|
Click here to register your account for receiving namecoins!Namecoins that would otherwise be allotted to unregistered accounts will be distributed between miners who are interested in getting namecoins, and myself (as compensation for the time I put into our stable merged mining implementation). Please note that Namecoins are only available for namecoin users, and cannot simply be "cashed out" directly (I can't stop you from selling them, but you will need a namecoin client to do so). Miners have at most 1 week to complete the process, after which I will consider them "non-interested".
|
|
|
|
*If* a reasonable limit on coinbase outputs could be added then for what it's worth I'd be happy to add my vote in favour on the change. Without said limits then my vote is in favour of the 'setworkaux' part of the change only. And what reasonable limit would that be? There are at least legitimate circumstances for having tiny-amount outputs (I always include a single 1 Satoshi output so it shows up on my pool's listtransactions). I suppose there could be a hard-cap on total count of outputs, but what should that be? Maybe 1% of the current block size limit? That gives 294 outputs max at 1 MB (the current hard-coded block size limit)-- an average of ~0.17 BTC each. Well I can see two approaches to determining limit. Both have issues but just because it's tricky to enforce a limit sensibly isn't a good reason to allow open slather... 1/ Tx outpoint size is relatively constant. Yes it can vary but for 99% of use cases it will the same type of script which is the same length. So from simple easy to enfore rule that would probably be the better option. I notice eligius already has some notion of a payout queue and I thought that might be somehow related to this issue. I was quite suprised when I started looking a eligius coinbases to find the number of outputs was always far far less than what I'd guess yr total miners would be. That's actually what got me thinking about this as a potential problem. When I saw that I thought you were limiting it for that very reason. The original reason for that was simply to help miners avoid a lot of tiny payouts they have to pay large fees to spend. 2/ min tx value would be easier from a pool ops point of view. And whilst the size of the outputs would be more variable it would at least prevent extreme accidental abuse. As I said, valid values can be as low as 1 satoshi... |
|
|
|
And those blocks without magic prefix are accepted by the rest of the nmc network? If so that's my concern dealt with. Yes, they are. *If* a reasonable limit on coinbase outputs could be added then for what it's worth I'd be happy to add my vote in favour on the change. Without said limits then my vote is in favour of the 'setworkaux' part of the change only. And what reasonable limit would that be? There are at least legitimate circumstances for having tiny-amount outputs (I always include a single 1 Satoshi output so it shows up on my pool's listtransactions). I suppose there could be a hard-cap on total count of outputs, but what should that be? Maybe 1% of the current block size limit? That gives 294 outputs max at 1 MB (the current hard-coded block size limit)-- an average of ~0.17 BTC each. |
|
|
|
The remain concerns are: Does the -coinbase <cmd> enforce either a minimum tx output value or a max number of tx outputs? If not it should. The primary use case for this for pools to payout their miners and have invalid blocks dealt with automagically. It there are no limits it's only a matter of time before some pools start paying out tiny balances to masses of miners. This could bloat the coinbase a lot unless I'm missing something. There is nothing anyone can do to stop block-makers from producing tiny coins. Coinbaser does prevent invalid outputs, though-- if the output is not consistent (ie, tries to pay too much, to an invalid address, etc) it fails over the the default behaviour. My second concern is that Luke has made the following comment in the wiki: Insert exactly one of these headers into the scriptSig of the coinbase on the parent chain. vinced's code always inserts an OP_2, 0xfa, 0xbe, 'm', 'm' in front of it, but you don't have to. As far as I can see this patch doesn't deal with validation of the aux blocks. Presumably this will be left to vinced's original code as you'd require an update to all namecoin miners to alter it's validation rules. So the question is, will the absence of OP_2, 0xfa, 0xbe, 'm', 'm' before the aux header prevent vinced's validation from working? If so then the rpc call should check this and return an error if it doesn't. No, the reason I changed this to say optional is because I am successfully using it on Eligius without that magic prefix. Furthermore, while the name "setworkaux" might be the source of confusion, it can be used for adding any arbitrary data to the coinbase, not just for the particular iteration of merged mining. There can very well be future functionality (like advertising your fee schedule, for example) using the coinbase as well. |
|
|
|
If BTCs were to drop at 10c usd we would still have a fairly large % of population with free electricity that would not stop mining. Very few people have free electricity. |
|
|
|
Any word on merged mining?
Eligius has it. |
|
|
|
Based on the usual math, the share value for Namecoin comes out to be 0.00053170 NMC per share. However, since I am not expending resources longpolling for namecoin, it has a higher stale rate than Bitcoin (or maybe just because of poor luck), and we have only made 90% of the expected earnings. If we did SMPPS for Namecoin, that puts us at 0.00047853 NMC per share right now. Until the rewrite (with full Namecoin accounting) is complete, I'd have to manually calculate and process rewards and payouts of Namecoins. Therefore, whether early-merged-mining is handled as SMPPS or not may depend largely on the miners' interest in actually getting them. I have setup a poll to determine interest. If you want Namecoins (or even if it doesn't), please vote! |
|
|
|
I've completed a very rough draft of a complete sane merged-mining implementation for Eligius. By sane, I mean it adds no potential harm to the Bitcoin mining operation. This goal is accomplished by making minimal changes (only 2 simple small patches) to bitcoind, and having it ignore problems with the merged mining manager. The code is all MIT licensed for anyone to use, but I am posting it primarily for new developers who want to prove their skills and get involved more with bitcoin development. Parts 2 and 3 of this implementation are functional, but incomplete. They need some cleanup before they can be merged to mainline codebases (bitcoind and merged-mine-proxy). I'm available on IRC if anyone tackling this needs mentoring/assistance. It is made up of 3 parts: 1. Coinbaser -- relatively simply branch/patch for Bitcoind to allow mutations to the coinbase transaction; it wasn't merged to 0.5, but ready to go as soon as 0.5 final is released (as a feature in 0.6); stable and well-tested 2. "gotwork" outbound JSON-RPC call -- very simple patch for bitcoind to make an outbound "gotwork" JSON-RPC call whenever a work is submitted; needs cleanup, but otherwise works; there is a single hash/dictionary parameter with "hash", "header", and "coinbaseMrkl" keys 3. Hacks to merged-mine-proxy to run parallel to bitcoind -- this hack only supports a single aux chain, and will need its own merkle root maker to support more; it needs cleanup to be made compatible with the current merged-mine-proxy usage |
|
|
|
|
Show Posts
