Many people took this stand against SOPA yet they make a hero of a guy who :-
1) robbed many people of Bitcoins and CoiledCoins
2) Has 51% attacked a chain using mtgox/eligius resources.
3) Filed fake DMCA claims to try to silence/censor something they don't like.
4) Likely culprit in other attacks on other coins This is all libelous lies. I don't know anyone here who made a "hero" of Luke-Jr for his 51% attack on CC.
Most people actually found it repulsive, so I don't know where exactly you are getting that from. First, it wasn't a "51% attack" in the sense most people take that to mean: I didn't steal any coins, time-travel, or anything of the sort. Second, more people did express support of my CLC shutdown than complained about it (the complainers were basically just a small handful of scammers who I had foiled, and made numerous venomous libel posts giving some people the impression there was a problem with it) Bitcoin is about absolute freedom (mostly in regards to data), which is why it boggles my mind that someone who preaches freedom of all data, would go ahead and do a DMCA takedown on an infant open source e-currency... No, Bitcoin is about a decentralized currency. Anything more is subjective. "Absolute freedom" is absolute evil. Bitcoin provides a useful monetary system for the Tonal number system, which is my primary reason for involvement. |
|
|
|
Still pretty lame and the DMCA is a draconian tool, which is constantly abused, like in this case.
No, this case is clearly proper use of the DMCA for good. Unfortunately, solidcoin.info was moved outside the DMCA jurisdiction, so I need to figure out German law to resume. |
|
|
|
but would it actually matter if you have the public key or not to find the private key from data + encrypted data?
Bitcoin does not use encryption. If you have data + signature, you can already find the public key. |
|
|
|
6,Reporting temperature/safety measurements can allows cgminer to shut off the FPGA if it gets too hot. 6 needs additional hardware, but we notice that the normal error rate is less than 0.1%, if the error rate goes high, that means something goes wrong. But by then, it's too late (and the FPGA destroyed), right? is there any reference docs about "noncerange extension" feature?  It occurs to me that I'm not really aware of how FPGAs handle SHA256 internally; if it doesn't use the normal uint32-based algorithm, it might not be practical to implement. |
|
|
|
is there any known problems on the present simple protocol ? I think the current protocol is workable, but could be improved... - Detection via the USB product/device ids is crucial to automatically adding it to cgminer.
- If that's not practical, detection via a probe command (be sure to ignore BFL's!) is second-best, so we can reuse the same -S parameter.
- If the FPGA can send back a "I'm done" message, it would probably make it easier to do more efficiently.
- In case you (or someone else) produces protocol-compatible devices in the future, you may wish to provide a way to probe the number of FPGAs on the board and their speeds.
- It would be good to have the ability to specify exact nonce ranges, so cgminer (or another miner) can support the noncerange extension in the future, or even split up work internally (a single work is sufficient for up to 4 GH/s).
- Reporting temperature/safety measurements can allows cgminer to shut off the FPGA if it gets too hot.
|
|
|
|
sorry to bother you, but may i know if it's possible to add a support to Icarus mining board? i'm really not good at software coding. I wrote the BitFORCE driver for cgminer. I would be happy to implement Icarus support too if someone sends me one (or can offer a comparable deal to BFL's preorder). Contact me privately, if so. (for reference, I live in the US) |
|
|
|
Eligius is losing his hashing power. No FUD needed. Eligius hashrate is the same as it has been. Blocks have variance as usual.  p2pool is growing. This is good, but p2pool can't really replace traditional pools yet. It's more of a substitute for solo mining (and puts it within reach of a few more miners). And FWIW: Eligius supports P2SH via BIP 17, not the broken-by-design BIP 16. If you care about bitcoin, boycott anything supporting BIP 16 and merge BIP 17 yourself. |
|
|
|
Eloipool - FAST Python3 pool server- First poolserver to use getmemorypool for internal work generation (note: PSJ and ecoinpool do this too, and announced first)
- Optimized merkle tree generator, does only the minimum required steps to create lots of merkle trees fast.
- Keeps a fixed-size buffer full of up-to-date merkle trees ready to ship off as soon as a getwork requests them
- Builds a fixed-size buffer full of clear (zero transactions, just subsidy) merkle trees ready to ship off immediately with longpoll replies (so miners can start working on the new block even before bitcoind has figured out which transactions to use)
- Support for more getwork extensions than any other public poolserver (update: ecoinpool caught up
 ) - Uses chunked HTTP transfer encoding to prevent proxy/firewall timeouts on longpoll connections.
- Coinbaser support, along with gotwork, for reliable generated payouts and merged mining
- Asynchronous JSON-RPC server using epoll to optimally handle even heavy loads.
- Interactive Python 3 console so you can inspect and modify the pool while it's running.
- Free software (open source) under the AGPLv3 license!
- Restart pool server (including upgrades) without miners losing work.
- Modular and highly configurable share logging using fast formatting functions, including support for PostgreSQL, MySQL, SQLite, and plaintext files.
- Anonymous or authenticated miner users.
- Support for X-Forwarded-For reverse proxies (and trust controls).
- Dynamic share targetting enabling fractional, power-of-two (zero bit count), and bdiff rounded miner targets.
- gzip HTTP response compression to save bandwidth without sacrificing functionality.
- Support for miners using next-generation getblocktemplate decentralized mining protocol and (pre-BIP draft) stratum mining protocol.
- Experimental support for creating "sub-pools" based on any upstream getblocktemplate server.
Now running live on:
|
|
|
|
Will the proposed new long bitcoin addresses be mandated for everyone going forward, or will the long addresses only be used by people who chose multi-sig? I definitely share the concern over difficulty in copy-paste, QR codes, eye-scanning etc. due to really long addresses.
What kind of address length are we looking at with each of the proposals? BIP 13 (P2SH address format, used by all BIP 12, 16, and 17) addresses are (almost?) always 34 characters, similar to current addresses. The Address wiki page has been ahead of the game for a while now. |
|
|
|
Bugs still showing up in BIP 16 sounds like the "deadline" was too rushed. Unless Luke's code is equally well tested and has not been turning out to be buggey we should probably push back the "deadline" to end of next month instead of end of this month? BIP 17 doesn't change nearly as much as BIP 16, so it's much easier to audit and test. |
|
|
|
hm i liked gavins approach of changing things very conservatively. that on the other hand doesnt sound so conservative  BIP 16 is not at all conservative. BIP 17, on the other hand, is. Let's do a brief comparison to disspell any FUD on the matter of even implementation simplicity (protocol simplicity should be obvious from reading the BIPs): *** bitcoind v0.3.19 and v0.3.20
BIP 16: 5 files changed, 946 insertions(+), 435 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.3.21
BIP 16: 5 files changed, 919 insertions(+), 429 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.3.22 and v0.3.23
BIP 16: 5 files changed, 886 insertions(+), 409 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.3.24
BIP 16: 5 files changed, 888 insertions(+), 398 deletions(-)
BIP 17: 5 files changed, 133 insertions(+), 14 deletions(-)
*** bitcoind v0.4
BIP 16: 5 files changed, 840 insertions(+), 386 deletions(-)
BIP 17: 4 files changed, 118 insertions(+), 15 deletions(-)
*** bitcoind v0.5
BIP 16: 5 files changed, 836 insertions(+), 388 deletions(-)
BIP 17: 5 files changed, 139 insertions(+), 34 deletions(-)
*** git master (this one including wallet integration, not just protocol changes)
Remove* BIP 16: 9 files changed, 48 insertions(+), 509 deletions(-)
... then add BIP 17: 8 files changed, 446 insertions(+), 49 deletions(-)
Overall replacement: 7 files changed, 126 insertions(+), 190 deletions(-) As to the recent major bug in the BIP 16 implementation, it destroys any transaction fees in mined blocks. This is entirely unrelated to BIP 16, but affected because BIP 16 requires a major refactoring of the code. Because BIP 16 requires this refactor to implement in bitcoind, this bug affected all the backports too. |
|
|
|
Upgrading to Eloipool, my new poolserver written in Python 3 this week seems to have gone mostly smooth. Hopefully it will solve the pushpool-related issues including however we were being DoS'd. However, I did notice that older versions of PhoenixMiner had trouble with the new longpolls, so I've special-cased them for now. Please report any problems here or on IRC, so I can investigate. Thanks to lemmi who wrote the 'midstate' Python module in C to provide midstate to miners that can't make their own. If anyone else wishes to contribute (including other pools), please get in touch! |
|
|
|
one of the reasons bip17 is not well accepted is because it will take more time to implement and test - delaying the introduction of P2SH. BIP 17 is already implemented, and easily tested. The delays at this point are because people won't let BIP 16 go. |
|
|
|
Just FYI: I contacted the top ten mining pools (as listed in the stickied threads in the Mining Pools subforum) directly via email way back in October, copied the email to them in the Mining Pools forum, and kept them 'in the loop' on all of this. This was about OP_EVAL (BIP 12). All communications about BIP 16, if any, were kept secret until I brought it into public light... I don't recall getting any myself, despite running one of the top 10 pools. |
|
|
|
At the very least BIP 17 is harder to test-- Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist). BIP 17 can be easily tested by setting the activation time to 0 and running on testnet. Such clients will reject all non-compliant blocks, and should be sufficiently secure. The only problem your bot made was looking at them in Block Explorer. The principal concern that Gavin has is related to upgrade and executing well tread code paths in the implementation. That's half the problem. The BIPs are about protocol changes, and the specifics of any one particular implementation should be ignored. Also, the BIP 17 implementation in bitcoind changes significantly less code, and doesn't really execute any new code paths (all the "questionable" code paths mentioned are already enabled). |
|
|
|
Sooo…it seems like the consensus is BIP-16. Don't know where you got that idea. |
|
|
|
Where do you dig up this FUD?
It becomes inevitable wherever you are involved unfortunately. Your use of weasel words and language tricks give me cause for distrust. For example, if Gavin were to say (just as an example) "I have never DDoSed anyone in my life", I would take it at face value. However, if you say the same thing, I must spend time figuring out different meanings that the same phrase could have, because you likely mean "I personally have never DDoSed anyone in my life, but I have paid someone else to do it for me" instead. Sounds like a personal problem. |
|
|
|
Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it? He was trying to, but I brought it out to public light because of its problems. What problems? Being entirely inconsistent with the Bitcoin design, and breaking it with magical special cases. BIP17 is your attempt to push through code which has not been proven secure, presumably in order to compromise the integrity of the system. Where do you dig up this FUD? BIP 17 is no less secure than BIP 16, and probably more secure in practice. I feel that his introduction of the additional BIP17 was intended solely to slow progress toward greater security. To what end, I don't know. But having more than one standard is guaranteed to cause a split among miners, which is the security problem you mentioned. No, the slowdown you're thinking of is people continuing to push BIP16 even after a better replacement has been proposed. |
|
|
|
Why couldn't Gavin have just pushed the change through without making this hate topic, see if any of the mining pools rejected it? He was trying to, but I brought it out to public light because of its problems. |
|
|
|
Testing is actually one of the reasons I don't like BIP 17; it is harder to test, because it is much easier to steal BIP-17 transactions if the network hasn't yet upgraded (Luke has had to test BIP 17 on the main network instead of testnet because I wrote a BIP-17-stealing robot and ran it on testnet). Alternatively, testers could just as well run BIP 17 on testnet with an activation date of 0; then they'll reject non-BIP17 blocks. Satoshi himself made changes to the way the scripting language works after a series of 'ghastly exploits' were discovered back in 2010 after the first slashdotting. I'm so stubbornly against BIP 17 because it basically reverts one of the changes he made (separating execution of scriptSig and scriptPubKey-- take that discussion to another thread in Dev&Tech if you want to argue more about it, please). Just to clarify, BIP 17 does not in any way revert this change. scriptSig and scriptPubKey are still executed separately. There is just a new single value passed from scriptSig to scriptPubKey, just like the stack we already pass. |
|
|
|
|
Show Posts
