What do you mean by DECENTRALIZED? The same way as p2pool: miners can make their own work. |
|
|
|
This would replace the existing JSON-RPC getmemorypool command? It should be mostly compatible. bitcoind would probably want to add the "mutable" key to inform miners they can change anything. And a meta-question: are there any other implementations that will be supporting external mining via JSON-RPC soon? There's no reason to go through the whole BIP process to make a change or improvement to one implementation. Eloipool also supports getmemorypool now. |
|
|
|
|
Eligius is experimental, and I don't consider it appropriate to guarantee any single behaviour. My current project for Eligius is enabling miners to do realtime auditing and block customization (like p2pool).
|
|
|
|
next-test is a branch of the mainline bitcoind & Bitcoin-Qt with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETToday's next-test includes the following pull requests (green are merged now; red are disputed): Bugs found: |
|
|
|
Yeah, it was more meant as a critique: if the bitcoin protocol was properly designed it would allow for alternate coins WITHIN the protocol to "make inflation possible".
Satoshi proposed this shortly before he disappeared. Unfortunately, it never got implemented for Bitcoin (yet). Today, it is alive and well in the form of merged-mining. |
|
|
|
|
FWIW, I had intended to give up and withdraw BIP 17 last week, but decided against it due to multiple people PMing me saying they read the BIPs and agree. So I'm giving it a bit more time in hopes the tide turns enough that we don't get stuck with BIP 16.
|
|
|
|
When you make protocols/APIs based on "could" you sometimes try to solve everything. I think bitcoin urgently needs a low bandwidth protocol that can scale to millions of transactions per day without needing terrabit internet / petabyte harddrives. Everything else is prio 2, like extensions; which if they are added should not be "hardcoded".
In my 10 year time as programmer I have learned to discern between generic and applied code. Unless the BIP 16/17 application is implemented in a broader generic solution that doesn't make the protocol that much heavier and already has many other vital applications, it should be carefully be considered.
I'm just suggesting the developers focus on the complex and hard to solve core matters, and let the community build the "nice to haves".
The point of BIP 17 is that it is generic... |
|
|
|
Also, there ARE other solutions to the P2SH need/problem.
Is there a problem? or do you have yet another solution in need of a problem to solve? Yes, the problem with BIP 16 is obvious and I and others have discussed it enough. Read the BIP, or at least genjix's summary. |
|
|
|
If you guys haven't already, you might want to read my short post on how Namecoin might have been better from a few months ago. I'm not really interested in the concept so much, so I did not read the 4 pages of prior discussion. If anything I say is redundant, please feel free to ignore it. My comments on the wiki/main page: - If the initial "block hashing algo" is defined in terms of merged-mining (and only merged mining - even if the "parent" is a minimal not-a-block), it's not intrusive; this was Satoshi's original recommendation before Bitcoin took off
- Merged mining does not in any way make the aux chains dependent on the parent chain.
- scrypt is an inferior proof-of-work than SHA256, as there is a large gap between commodity hardware (CPUs and GPUs) and specialized hardware (ASICs) in terms of performance
|
|
|
|
I have written a short (57 line) one-user proof-of-concept getmemorypool proxy, and included it in Eloipool's serve_getmemorypool branch. By using this locally, you can add code to audit the blocks in any way you want. Due to Eligius currently requiring the "test_" prefix, you will need to add it to the gmp-proxy.py file (prepend "getmemorypool" and "submitblock"). Please contact me on IRC if you would like to help take this to the next level. To use (after the edits just mentioned), just run ./gmp-proxy.py http://youraddress:x@mining.eligius.st:8337 Then connect your miner to localhost on port 9332 Edit: Note that this uses Eloipool's JSONRPCServer class, which I optimized to handle heavy loads. Unfortunately, there is no way to do this in a Windows-compatible manner, so this gmp-proxy.py will not work on Windows yet. It might be possible to grab an old thread-based JSONRPCServer from earlier Eloipool versions, but I haven't tried it. |
|
|
|
For testing purposes only (ie, I don't guarantee this works yet), Eligius now supports getmemorypool-based mining. Currently, miners are not allowed to modify anything except nonce/ntime, but it does at least enable auditing what goes into the blocks you're working on in realtime (and possibly switching to another pool if anything looks awry). Since this is untested, and not supported by any miner (as far as I know), I have renamed the JSON-RPC method to "test_getmemorypool" for now; please get in touch with me on IRC if you want to work on a miner/proxy implementing this. Probably the best starting points for implementing a proxy are either the p2pool client (Python2/Twisted) or the BitPenny client (C++). See also for technical details: Alternative to getwork for miners/proxies
|
|
|
|
I think it would be a good idea to add a "target" like "getwork" has, so that the server can control the difficulty for its clients. I agree, this is a major oversight of mine. Also, perhaps the procedure should have a different name, since it is not the same as the "getmemorypool" of bitcoind? I consider it to be the same, just with slightly different semantics based on what the server needs/allows/supports. Perhaps the data from the server should also provide info on which modifications of the data will be accepted. An array of strings in the key named "mutable"? Possible fix for the first two points: all the transactions could be replaced by just coinbase and its merkle branch when the data cannot create a block and the miner just needs to prove it is doing work. More efficient but it means supporting 2 ways to deliver work. Well, the 2nd way could be as simple as truncating the block data after the first transaction, and providing the merkle links between coinbase and root. One problem I can think of is if the miner gets a transaction from a local bitcoind that is on a different fork than the server's bitcoind. In that case you might get a transaction in a block when it already exists in the parent block. But I think duplicate transactions are simply ignored and do no harm, right? No, they invalidate the block. A miner would need to always be working on the same parent as the pool. BitPenny fails over to solo mining when there is a desync. |
|
|
|
Not a problem.  But note this is in a non-master branch of Eloipool and not live on Eligius just yet. I'd like to allow miners to add transactions or other coinbase content (msgs/data), but the current code does not support actually submitting via getmemorypool yet. If the server allows it the miner could exclude transactions (maybe you want to demand a minimum fee), or even add transactions the server hasn't seen. The server could also allow the miner to modify the coinbase, although BIP-16/17 style voting may be a bad idea if the server doesn't actually support the things the miner is "voting" for. Yeah, we should probably come up with a standard format for flags so pools can filter out ones they don't support. This would also allow the miner to create its own work, thereby drastically reducing server load. You only need a new set of data once per block change. Not quite. With payouts in the coinbase, I need to expire work every 2 minutes regardless. And merged-mining adds its own twist. The main thing it enables is real-time auditing, and allowing miners to add their own transactions. Can we make this a standard and get more miner and pool backend authors supporting it? I suggest building something similar to bitpennyd that miners can use with getwork. |
|
|
|
|
The funny thing is, since this was announced 2 years ago, I happily woke up to my node implementation working for the first time ever (I didn't bother wasting time on hacks that were going away in less than 20 days)
|
|
|
|
You will enter the payout queue for Namecoins once you reach 42.95 NMC (2^32 / 1e8). This is actually obsolete info. Fixed (5.36870912 NMC). |
|
|
|
FWIW, Eligius continues to offer no fee SMPPS which has maintained the same payout as straight PPS longer than any other pool. Yes, except the pool op is well known for using his miners' hash rate in a very cavalier fashion and denying the fact afterwards. The only reason I migrated my miners from Eligius was your dishonesty about the whole matter, Luke - if you break the trust so easily I don't want to have anything to do with your pool. Denied because it isn't true. Use whatever pool you want, but stop with the lies and FUD. |
|
|
|
|
Show Posts
