Luke still implying the choice was transparent, when the choice was default and obfuscated. Poorly documented, yes. But definitely not obfuscated. Go troll somewhere else. Luke, you're saved, brother. No sin on earth can keep you from glory. Revel in it and be glad. P.S. Nobody is saved until they die in a state of grace (ie, free of mortal sin), and even then they only enter Heaven when they are made perfect by God. |
|
|
|
Actually, I was just catching up on some reading regarding the blacklisting issue. Then I wondered if arbitrary blacklisting of addresses or other "hanky" (my word) could/would be done on pools you were involved with. I don't really have a stance one way or the other as long as it's disclosed. I understand your logic behind it, but my view point is it should have been vetted before publishing. It was always disclosed, both for Eligius (for years now) and Gentoo (although ambiguously to someone not familiar with "Luke-Jr's patches", which I hope to improve on). It's also not arbitrary, but based on clear technical reasoning. Not to imply your choice was on a whim. "arbitrary: unrestrained and autocratic in the use of authority." And believe it or not, you don't have to defend or justify yourself to me. Your skill set, expertise and passion for bitcoin is more than I would ever wish to have or understand. Ah, I think most people take it as "based on random choice or personal whim, rather than any reason or system". Hardly use of authority either when people can choose whether or not to use it, but *shrug*. :p |
|
|
|
Actually, I was just catching up on some reading regarding the blacklisting issue. Then I wondered if arbitrary blacklisting of addresses or other "hanky" (my word) could/would be done on pools you were involved with. I don't really have a stance one way or the other as long as it's disclosed. I understand your logic behind it, but my view point is it should have been vetted before publishing. It was always disclosed, both for Eligius (for years now) and Gentoo (although ambiguously to someone not familiar with "Luke-Jr's patches", which I hope to improve on). It's also not arbitrary, but based on clear technical reasoning. |
|
|
|
Is Lukejr involved with Eligius? I read he was out of it, but wanted to get confirmation.
I write the code, wizkid057 runs the pool. Why do you think it matters? |
|
|
|
i wanna request if possible to include my miner on support list...
my miner is Scrypt Dragon LTC miner 32m
the website is :http://www.lketc.com/goods/show-641.aspx
please advice me possible ro tun my machine using this BFGMiner
Dragon Scrypt miner 32m
You'll have to talk to nwoolls, and probably give him one to develop/test with - also likely need specifications from the manufacturer. |
|
|
|
Hey I'm still curious about the multisig abuse. Why would someone create a multisig address that nobody has the keys for, in essence locking those funds up forever? Are they just a nuisance (spam) or is there some kind of malicious intent I'm not seeing here?
Also how would you know if nobody has the keys for the multisig? Is there some kind of verification on your part? I don't how that would work. For example, a 1-of-20 multisig where the first key is the real owner, and the other 19 are strings of data that can't even be valid keys. They only need the 1 valid key to spend it later. |
|
|
|
(...snip...)
[...] commit history available to see which thing was added when and why.
Do you have a repository for this patchset somewhere?
Preferably with concise, yet still informative commit messages for each change as it was made?
Access to that information would be great for anyone who needs to help with the maintenance on this ebuild for the purposes of splitting things off to their own self-contained patches so each use flag has its own patch.
The patch is my 0.9.x-ljr branch. You'll find splitting it up is not so easy (you'll get merge conflicts with different combinations). I haven't checked yet, but is this most of the relevant code from your patch? https://github.com/luke-jr/bitcoin/compare/bitcoin:0.9.3...0.9.x-ljr?diff=unifiedThat should be identical to it. |
|
|
|
If there are any further issues with weird patches enabled by default in the official gentoo build we should just re-open the bug. No, please file a new bug for new issues. Perhaps, sure. At least I guess that'd make sense if it's actually a new & completely unrelated issue... But if the issue is the same substance ( an ebuild with patches which breaks the expected behavior in one or more ways) it would seems appropriate to reuse the existing bug ID. For future reference: Please don't add monolithic "change all of the things" patchsets, as they're harder to debug when everything is just shoved together into a single patch with no commit history available to see which thing was added when and why. Do you have a repository for this patchset somewhere? Preferably with concise, yet still informative commit messages for each change as it was made? Access to that information would be great for anyone who needs to help with the maintenance on this ebuild for the purposes of splitting things off to their own self-contained patches so each use flag has its own patch. The patch is my 0.9.x-ljr branch. You'll find splitting it up is not so easy (you'll get merge conflicts with different combinations). |
|
|
|
It's better to until the proposal to reduce bitcoind initial download size mentioned by Gavin recently has been implemented. Otherwise, downloading more than 20G bytes itself is formidable already.
If you're talking about the invertible bloom filter stuff, that's not about reducing the size of the block chain but is about reducing the amount of data that needs to propagate when a new block is found. Bloom filters are as far as I know part of the push for an SPV client. This stuff is better discussed outside of this thread though as it is not specific to Counterparty. No, I am talking about this https://bitcoinfoundation.org/2014/10/a-scalability-roadmap/The download is still 20 GB even if you discard most of it later. |
|
|
|
Sorry, but there is nothing relevant there, except for the mention that the tube does not work with Eligius.  Too bad... See section 5b |
|
|
|
If there are any further issues with weird patches enabled by default in the official gentoo build we should just re-open the bug. No, please file a new bug for new issues. |
|
|
|
One good thing that will come out of this that BTC cartel will realize that XCP is actually enhancing its usability. We will have less of Lucas Jr. types trying to police the transactions.
Actually Eligius (Luke Jr pool) is the first to process OP_RETURN 80 bytes transactions. Wow, didn't know that. I remember him coming over in this thread several months back and being very aggressive and threatening. That was when I realized the problems of BTC centralization by the cartel. Counterparty is still in the blacklist of his bitcoind. Only the format harmful to Bitcoin. Didn't you change to OP_RETURN months ago? |
|
|
|
One good thing that will come out of this that BTC cartel will realize that XCP is actually enhancing its usability. We will have less of Lucas Jr. types trying to police the transactions. Actually Eligius (Luke Jr pool) is the first to process OP_RETURN 80 bytes transactions. Is that already in place? From what I understand that those changes would take a while to be implemented by Eligus This one is fairly simple, though nothing is in place yet (these changes are being made to a new 0.9.3-based codebase, while Eligius is still running 0.8.x). If anyone would like to help in general (not just Eligius), make a thread polling miners on their interest in doing this sort of thing and I can link it from the merge request. |
|
|
|
same problem like 4.8.0, i need to add #skipcbcheck for mining at nicehash bfgminer.exe --scrypt -S opencl:noauto -S zus:all -o stratum+tcp://stratum.nicehash.com:3333#skipcbcheck -u 14ZnSvrougVEgQfSLKWYHHzNYcET3j9hRa.1 -p x --set zus:chips=6 It's not a problem, it's expected. |
|
|
|
I have had a memory leak since using version 4.7.0. This is running as a proxy only on a Windows 7 x64 machine. The memory use grows to over 600Mb over about 2 days. It is a proxy for 4 Raspberry Pi's using Cgminer 4.3.4 with the Bab driver. About 2.2Ths. I restart it and repeat. This behavior is happening with the 32 and 64 bit versions. Pool is Ghash.io (I know...)  Also, I do not know if this memory use issue started with 4.7.0 as I replaced 3.10.0 with it. Version 3.10.0 did not do this. Can you bisect it? |
|
|
|
Can anyone tell me how to use the unsafe:N command?
I have some of the small rockminers running at 290 along with some of the 110 GH units. Due to the 290 clockspeed set they are only hashing around 81 each. When I try to go in and adjust them up to 350 it returns the dangerous clockspeed and use the unsafe:N to force.
Thanks.
--set rkm:clock=unsafe:350 |
|
|
|
- Standard transactions:
- OP_RETURN: allow up to 80 bytes
Hello Luke-Jr pardon my ignorance & my french Does that mean that Eligius will allow counterparty-XCP transactions (if encoded in OP_RETURN) or do you still plan to filter them out (I think you are treating them like spam because they're still multisig transactions) ? [/list] OP RETURN would be appropriate. Abusing multisig is not. So for those who aren't entirely sure what they're talking about (myself) what would constitute a violation of multisig? And how would this affect using a p2sh wallet? Or does this have nothing to do with p2sh wallets? Multisig is fine. Hiding data by pretending it is multisig when it is not, is a problem. The conclusive results do nothing to hinder P2SH multisig use. |
|
|
|
is it a good assumption the payout queue is down  Doing some maintenance That last payout, seems to be taking a long time to verify, its only been seen by 1 peer after 4 hours. Makes no sense since every Eligius payout is in a block. So, wherever you got that information from is providing useless info... Could only part of the block take longer to confirm than other parts? Nope. Uhhh... yes? Generation transactions always take >=100 blocks to confirm, while others are subjective to wallet/human decision on when they confirm. Everything in the block receives the same numbet of confirmations though, which is what I was getting at. Confirmation is a (fuzzy) boolean, not a number  I blame the core devs then for having a "confirmations" field in listtransactions RPC. I think that one is Satoshi's fault. :p |
|
|
|
Did they not want to pay you to maintain a working version for the Titan, which is not running well and they can't seem to tell us why? They didn't ask, and I didn't ask. I understand and appreciate that you are not supporting that version. Could you chime in on if you think the version they have running is causing issues concerning coins with fast blocks and fast diff changes? or even merge mining seems to slow down the hashrate. No idea, the whole "not supporting" is basically just making a note that I don't have one, don't know the platform at all, and cannot answer questions about it at all - it's not that I don't want to, just that I don't have anything to go on. But maybe KnCMiner's engineers or other users can answer your questions here or elsewhere |
|
|
|
|
Show Posts
