In an ideal world, bot nets would be useless for mining coins. Problem is, you'd have to have something like a captcha that could not be faked. That way each person would be equal, none of this 'He who has the most cash/bot-net/farm/whatever wins'.
The bot net would set up a site with naughty pics, for free but surfers must solve a captcha to see them, then let the surfer solve your captcha. This was a new bot trick in 2007  |
|
|
|
I guess it would be trivial to port this over to Tenebrix.
I haven't tried yet but would be surprised if it's not trivial: - PUBKEY_ADDRESS in base58.h (Ltc: 48, Tbx: 127, Fbx: 95) - checkpoints.cpp - hashGenesisBlock, nSubsidy, nTargetTimespan, nTargetSpacing and pchMessageStart (magic network number, Ltc: 0xdbb6c0fb, Tbx: 0xd9b4daf9, Fbx: 0xdbf9dbf9) in main.cpp - the Genesis block in main.cpp - GetDefaultPort in protocol.h - config file and data folder name in util.cpp Name of the executable in bitcoin.pro Name of the ".pid" file in util.cpp This should be enough for basic function, unless some blocks fail the security tests (like block 3075 in Fairbrix) and need an exception. - pnSeed in net.cpp Perhaps we should bring back IRC node discovery, it seems reliable (once again). |
|
|
|
Another reason is that you want to be able to process arbitrary data, like by downloading a web page. Otherwise your oracle has to be specifically programmed to know about every possible kind of event, which sucks. Now, what the hash-checking scripts design does is let you have an arbitrary program structured like this: var event_a = get_nonce(0);
var event_b = get_nonce(1);
if (wget("...").contains("blah")) {
reveal(event_a);
} else {
reveal(event_b);
}
Another way to process arbitrary data is to regularly publish a list of questions and ask miners to act as arbiter by encoding a few extra bits per block. Vanitygen abuse perhaps? Assuming it's about typical general interest prediction market stuff like Dems win/Reps win, BTCUSD higher/lower than last year, major city nuked/not nuked, etc. What percentage of pools, and miners voting by proxy, would participate? Can be a small minority, just significantly more than those who would actively sabotage it and you have your oracle built directly into the client with no need to access outside data sources. |
|
|
|
Or maybe some flunkies are just being paid per MB of anti-BTC video uploaded and their handlers either don't notice or don't really care.
This, or... gold bugs gone mad? The "doing the exact same fucking thing over and over again. Expecting shit to change" kind of insanity. I can hear Vaas's voice in my head  |
|
|
|
I found a Fairbrix client based off of 0.6.3
Very old version actually.  New one is this: https://github.com/wiggi/fairbrix-0.8-coincontrol-testNothing really interesting, mostly a 1:1 conversion of the current Ltc development version with coin control. Notes: v0.8 complains about using just "1" for both username and password, so something like this # bitcoin 0.8 requires rpcpassword != rpcuser
rpcpassword=foobar
rpcuser=1
rpcport=8645
server=1 is needed in fbx.conf Stable nodes: addnode=54.245.186.179
addnode=198.154.60.61 If you allow incoming connections (i.e. open port 8591) don't use "maxconnections=...". It's buggy and prevents peers from dl'ing the blockchain. I did some obvious tests: dl/reindex blockchain, mine with cpuminer and reaper, send coins from and to old client versions, import v03 and v06 wallet, send from encrypted wallet etc. No problems so far. |
|
|
|
|
These things are uploaded daily but have no views. Who in their right mind would
search for "bitcoin today" instead of just "bitcoin".
|
|
|
|
|
It's a "healthy correction". At 6000 XRP/BTC ripple was valued almost the same as all bitcoins including unmined ones,
this was just not reasonable.
|
|
|
|
Simple solution: Disable updates
Nooo... malware will try to fetch your wallet more vigorously than MS. (or evil government) |
|
|
|
Does anyone know if there is still a visual block explorer for Tenebrix?
not visual but works like a charm (znort's blockexplorer with a small patch for TBX/FBX): https://github.com/wiggi/blockparserhttps://github.com/wiggi/blockparser/commit/57f396533d9c35d87ea0c98a4f85e94cfed0edd3note: the uncommented line in Makefile must go first, like this -DTENEBRIX \
# -DLITECOIN \
# -DFAIRBRIX \ not this # -DLITECOIN \
# -DFAIRBRIX \
-DTENEBRIX \ Otherwise it will parse bitcoin. (Is this standard makefile behavior?) First 2 lines in allBalances.txt: ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Balance Hash160 Base58 nbIn lastTimeIn nbOut lastTimeOut
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
5702126.98450000 ca7de646208f051206b54af9fde9eff3c8c0e655 tRPHNC7AuyQWvg6y6zK5C8g93Vutr8J7YB 5 Mon Apr 29 13:29:42 2013 1 Tue Oct 4 13:15:30 2011
1999499.00000000 fd2130b2e590fddb4c91510098552ec5901135e0 tW12mRSDu6ioP3NmHCdHvjxLFDgffwQoJw 1 Tue Oct 4 13:15:30 2011 0 Thu Jan 1 00:00:00 1970
|
|
|
|
the problem is that hoarders still have coins in very old blocks. so pruning will only work on blocks where every single transaction is 'spent'
Won't help with hoarders in very old blocks but... the one transaction that makes an entire block 'spent', or rather the last x transactions for each block, could get incentivized. Like, another free 27kb/block reserved only for these transactions. Easy and painless soft fork. Or even a small negative fee. Would miners do this? (for the greater good) |
|
|
|
I'm a total noob with this code (although I do code). Any help would be greatly appreciated. I did look at the INSTALL file as suggested in the error message, but I still couldn't figure out what is wrong. I loaded mingw, pearl, set the path, opened minGW and unpacked the files exactly as prescribed, but it bombs at the configure step.
Try reinstalling Mingw/Msys. (Online installer can randomly skip a component or two. The only way to notice is to inspect its log file.) |
|
|
|
|
Awesome. Not sure if the "very expensive high security tamper proof hologram to secure each private key" method is practical...
|
|
|
|
yeah 2 billion sounds insanely high lol
Silly me, got confused with hashrate and difficulty chart. So, 200 million+ with current steep trend. |
|
|
|
Especially the latecomers
As OP is already in sarcasm mode, we'll likely have to wait until late 2014 when IX/I0 are finished with their subsidy. (to have a fully minted crypto-coin in the world) |
|
|
|
if you can use trend lines on this on (as opposed to price chart more like 2,000,000,000+ (<- edit: 200,000,000 of course, not 2 billion) (i.e. 2,000,000 GH/s) 76k May low and 124k June low are not even a month apart. |
|
|
|
Dust will be all we have.
If all dust is systematically consolidated into larger coins (compared to "never mix coins from different sources and let the dust gather dust"), would this result in more database operations/larger blockchain files for all full clients? (more inputs/tx on average) Blockchain would be better prunable if dust is consolidated, of course. |
|
|
|
How much is "*lots* of RAM" in the warning for --detailed?
It likely will finish on 8GB but I wouldn't do this to my HDD, and ./parser allBalances >allBalances.txt (without -d) is about as memory-demanding as ./parser allBalances -a200000 -d >allBalances.txt upgrade plan: now: 16GB Q1 2014: 32GB |
|
|
|
22.5 percent probability OP isn't about the band  (avatar brings it down from 75) |
|
|
|
|
You place buy order, get filled, then people want to dump...
How can you possibly profit from this, by selling to the guy who topped you?
|
|
|
|
Try using Anonymouth?
Interesting concept, but to be useful it needs to catch every unusual word, all grammatical mistakes, basically need to understand natural language. The other, simpler way would be: force the writer to use controlled/simplified natural language, then apply synonyms and grammar reshuffling at random. But AFAIK such a program doesn't exist. |
|
|
|
|
Show Posts
