I'd really like to see something like this get in, but I agree with Steve - it's not clear why this is different to what Vince has already done.
Vince's stuff is a mess of unreadable code, that requires putting a proxy (additional point of failure/bottleneck) in front of bitcoind. This approach is much simpler (at least insofar as modifications to bitcoind) and has no effect on the stability of the primary Bitcoin mining operation (since the merged-mining manager runs parallel to bitcoind, not in front of it). These changes are also more abstract, not necessarily tied to merged-mining specifically. |
|
|
|
|
Gavin has apparently decided (for no reason) that he isn't going to merge this, even though this thread met his requirement of having "community support" for the new "setworkaux" JSON-RPC method. I doubt I'll bother maintaining this through the next version, so I guess pester Gavin if you want it (or hope it gets merged to post-0.5 git before it needs yet another rebase...)
|
|
|
|
Can not compile cgminer-2.0.5: make[2]: Entering directory `/home/administrativo/cgminer-2.0.5'
CC cgminer-main.o
main.c: In function ‘main’:
main.c:5418:12: error: ‘struct cgpu_info’ has no member named ‘gpu_engine’
main.c:5419:12: error: ‘struct cgpu_info’ has no member named ‘gpu_memclock’
main.c:5420:12: error: ‘struct cgpu_info’ has no member named ‘gpu_vddc’
main.c:5421:12: error: ‘struct cgpu_info’ has no member named ‘gpu_fan’
main.c:5422:12: error: ‘struct cgpu_info’ has no member named ‘gpu_powertune’
make[2]: *** [cgminer-main.o] Error 1
make[2]: Leaving directory `/home/administrativo/cgminer-2.0.5'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/administrativo/cgminer-2.0.5'
make: *** [all] Error 2
Ubuntu 11.04 32 bits. CGMiner 2.0.4 compiles just fine. What can I do?! Thanks! Thiago Still no solution? It's fixed in git. |
|
|
|
Thing is, we have already had months to work on things, and no one has till it is almost here. No. We don't get to start working until there is proper protocol documentation in place. |
|
|
|
|
Just to be clear, my merged mining implementation AIUI will require two very minor changes to bitcoind, and will not put the Bitcoin mining operation at risk. While the coinbase component (part of Coinbaser, ready for pulling on GitHub) is complete and obviously simple, the part that is lacking is resubmitting new shares to the side MM managing daemon. This is also a fairly trivial change, but without specs to build the external MM manager and test it, I am not comfortable with calling this piece "done".
|
|
|
|
|
New BETA mine-at-your-own-risk PoolServerJ on port 8999. I plan to restart this pretty often while it's testing, so be sure you have failover to the pushpool!
It uses the same share databases and bitcoind as pushpool, so it's still Eligius-Su.
|
|
|
|
Ok, ported coinbaser to Windows. Surprisingly, the problem wasn't popen, but fdopen (for TCP support). |
|
|
|
So, how do you intend setworkaux to be used?
From the code: setworkaux <id> [data]
If [data] is not specified, deletes aux. |
|
|
|
As it is your patch makes a user-visible problem hidden under the additional layer of obfuscation and randomness. People tend to notice unapproved fees draining their balance. The current situation is "always say yes" only in bitcoind. The bitcoin client pops up a dialog box. This only affects bitcoind. Also, new version requires an undocumented -nosafefees option for that. |
|
|
|
Bitcoin shouldn't accept them automatically because people will then use the alternative characters in vanity addresses, and old clients (including many sites that verify addresses without using Bitcoin) won't be able to accept these "new" addresses.
Well, that's the point of the final poll option-- that in a few years, these could be adopted as valid. |
|
|
|
I don't think there should be any way for users to override required fees until "stuck" transactions can be reversed.
This wouldn't change anything user-facing (ie, GUI). |
|
|
|
No, that would be an unrelated change. Right now, the code just does a while(notEnoughFees) { addFees(); findCoins(); }
Are you proposing an iterative solution to a non-monotonic non-deterministic optimization problem? Do I understood you right? I'm proposing moving "do I accept this fee" logic outside of the "always say yes" we have right now, nothing more. |
|
|
|
I voted no because of the fine-print in your original post. The poll was, as stated, unrelated to the "fine print". You asked for consensus on JSON-RPC changes, which has nothing to do with the fine print. I think setworkaux is OK, but I don't like "doesn't work on windows" changes to support one mining pool. It might work on Windows with a few changes, but I don't have a Windows system to test on. http://msdn.microsoft.com/en-us/library/96ayss4b(v=vs.71).aspxAlso, there's nothing Eligius-specific about it. |
|
|
|
(stating how much fee is "required")
This would require replacing a PRNG in the stochastic knapsack solver. Currently there is a call to rand() there. This isn' reproducible and testable. Maybe you can think of some repeatable PRNG that is explicitly seeded off with something that will every time select the same coins from the same wallet and thus require the same fee? No, that would be an unrelated change. Right now, the code just does a while(notEnoughFees) { addFees(); findCoins(); } |
|
|
|
Per the old bitcoin: URI scheme, amounts should specify a unit. The current implementation of bitcoin-qt, however, only correctly handles amounts as BTC without a unit. What would be the ideal behaviour, in the community consensus, when encountering a URI that does specify a unit? Previously I had suggested a units= (e.g., units=mbtc), but there were reasonable arguments as to why that was not a good solution: - http://bitcointalk.org/index.php?topic=6206.msg91910#msg91910Yes, that's why the URIs specify the units in a descriptive form rather than symbolic.  |
|
|
|
|
I'd love to hear why someone voted No.
|
|
|
|
|
Show Posts
