Kim DotCom is a disgusting bloated fat pig. He peddles in illegal stolen wares. He profits from the illicit use of other people's creations. Most around here don't like copyright, but it remains legitimate law. Nerds love 'free' movies, but it is killing the people who produce movies just like the music industry.
Do we really need to have bitcoin involved in more criminal uses? Do we really want to associate bitcoin as this go to tool for assholes who want to steal?
Bitcoin will be great as soon as we get rid of the anarchy assholes think its primary use is to traverse the law.
Kim Schmitz is merely a dirty filthbag. I don't accept him as an ambassador for Bitcoin. That kind of propaganda doesn't work any more. Nobody believes it (if they ever did), and it does the opposite of "winning hearts and minds". The next generation of developers is going to grow up seeing legal denouncement of their projects as professional validation, and having their software banned a rite of passage. |
|
|
|
Go for a blockchain.info wallet instead. Not actually sure where it's hosted but I trust it and it's very secure if you take advantage of all the security features. If you're worried about snooping or safety of the sites you use I'd just recommend keeping your coins on a desktop wallet instead.
Ughh.... have you somehow missed all the threads of people getting hacked and losing their BTC at Blockchain the last 3 months due to poor security there? They are literally at the very bottom of my list of sites to trust at this point. Also they are not worth recommending until they stop reusing addresses. |
|
|
|
to be my online wallet Once you've decided to use an online "wallet" at all, it almost doesn't matter which one you pick because it's a bad idea all around. If you want convenient spending, you can get that from a mobile wallet, or a browser-based wallet. What is a browser-based wallet you speak of? Thanks for all the replies guys.  Kryptokit and Dark Wallet are two examples. |
|
|
|
This commit is in dev, and dev is unstable currently. Oops - somehow my local repo ended up with confusing upstream tracking branches. |
|
|
|
|
Compiles, indexes blockchain and runs.
So far, so good.
|
|
|
|
to be my online wallet Once you've decided to use an online "wallet" at all, it almost doesn't matter which one you pick because it's a bad idea all around. If you want convenient spending, you can get that from a mobile wallet, or a browser-based wallet. |
|
|
|
Also your master branch as of 25248a752364afa91b4701f5b28b203ecd8364f2 doesn't build: make -C cppForSwig
make[1]: Entering directory 'redacted/src/BitcoinArmory/cppForSwig'
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c UniversalTimer.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BinaryData.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c lmdb_wrapper.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c StoredBlockObj.cpp
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BtcUtils.cpp
lmdb_wrapper.cpp: In member function ‘bool LMDBBlockDatabase::getStoredTx_byHash(BinaryDataRef, StoredTx*, BinaryData*) const’:
lmdb_wrapper.cpp:2627:54: error: invalid initialization of non-const reference of type ‘BinaryData&’ from an rvalue of type ‘BinaryData’
BinaryData& gettxhash = getTxHashForLdbKey(hint);
^
g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BlockObj.cpp
Makefile:87: recipe for target 'lmdb_wrapper.o' failed
make[1]: *** [lmdb_wrapper.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory 'redacted/src/BitcoinArmory/cppForSwig'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2 |
|
|
|
|
Regarding the BDM errors, I've seen them happen a few time now, and the pattern is they occur when starting up Armory after it hasn't been running for ~1 week, with bitcoind running constantly in the background (not under Armory's control).
|
|
|
|
|
Let them have their fun.
Just remember to keep your bitcoins on the blockchain, and only accept bitcoins on the blockchain as payment.
|
|
|
|
Honestly I think new non-P2SH outputs should be made invalid at some point in the future not because of illegal activity but because if used for arbitrary data it bloats not just the blockchain but the far more critical UTXO set. On the other hand, if those pubkeys are actually pubkeys and not arbitrary data, you can do Diffie-Hellman with them. That's a useful property. |
|
|
|
Nothing can save Greece. They want to consume more than they produce, forever. There's no way to make that happen anywhere in the world |
|
|
|
|
Fed policy is, "how can we enrich the insiders by screwing everyone else?"
|
|
|
|
|
With as many people predicting a stock crash, I wouldn't be surprised to see another QE appear just in time to screw everyone who is sensibly short.
|
|
|
|
i foresee the Trezor replacing the offline wallet and its pc and being more secure since the offline wallets can be susceptible to a USB malware attack. as far as i know, there is no way to get privkeys off a Trezor so in that sense it is safer I think this is a dangerous assumption to make. Trezor has a larger attack surface than an offline laptop, since you have to plug it in directly to a potential hostile machine every time you use it. You can reduce your attack surface with an offline laptop by using CD-R media instead of USB drives, or maybe by using the audio cable transfer method. |
|
|
|
|
By "third time" I mean 2020.
|
|
|
|
what is bitcoin's function?
Money |
|
|
|
|
In order to serve its function, the Bitcoin doesn't need a permanent record of every transaction that has ever happened - it needs an unimpeachable proof that the supply of Bitcoins has been maintained as promised (this is another way of saying "preventing double spending").
Every node keeping a permanent record of every transaction ever is the simplest way to generate the proof.
It does not necessarily follow that this is the only way of possible way of preventing double spending.
|
|
|
|
|
Oh, good - this debate again.
Maybe people will stop complaining after the third time.
|
|
|
|
This is what it boils down to: scarcity. There’s no room in Bitcoin for inflation of any kind. Other applications and whatnot can be built on top of it as is. It’s for the world to adapt and conform to Bitcoin, not the other way around.
I don't see transaction volume increase as a change in inflation so much as a change in velocity. Henry Hazlitt who is credited with bringing Austrian Economic theory to the English speaking world, would I think agree that is not something that ought to be artificially influenced either by constraint or encouragement. Hitting the limit would be an artificial constraint, removing it ahead of (3) would be an encouragement, but for inflation it is a no-op. With some people, watching them wield economics terms of art they do not understand is like watching a child run with scissors. |
|
|
|
That's not clear at all. https://gist.github.com/oleganza/8cc921e48f396515c6d6"Message X should be provably recent and alternatives should be practically impossible to produce."
Practical impossibility can be reframed in terms of "opportunity cost": there are limited physical resources and those should have been largely allocated to X than to Y so we can see that X sucked in all resources from any alternatives. Because if it didn't, then there is a huge uncertainty about whether remaining resources are used for alternative Y or they do not interfere with the voting process. Is it possible that X did not suck in a lot of resources while alternatives are still not possible? Then it would mean that X logically follows from whatever previous state of the system and there is no voting process needed.
Therefore: message X should be provably recent and should have employed provably big amount of resources, big enough that there are not enough resources left for any alternative Y to produce in a reasonably short time frame. Also, the message X should be always "recent" and always outcompete any alternative. Because we cannot reliably compare "old" messages: is Y an "old" one that was just delivered now, or was it produced just now after resources spent on X were released?
This logically leads us to the following: we should accept only the messages with the biggest Proof-of-Work attached, and that proof-of-work should be the greatest possible ever, so there would not be any possibility for any alternative to be produce in the short window of time. And that proof-of-work must be constantly reinforced or the value of previous consensus begins to fade quickly as the opportunity for alternatives grows. If most of the planet's double-SHA256 capability is being used to mine Bitcoin, then choosing messages with the most accumulated proof of work satisfies the requirements for consensus. We need, at a minimum, a majority of *active* hashrate to not "attack" the network. You're trying to accomplish more than what is possible. The best achievable guarantee for mining is: "ought to find it more profitable to play by the rules." There is no technical solution available to counteract attacks by highly-resources entities who do not care about profit. The only thing we can do is to make Bitcoin so valuable that the opportunity cost of not playing by the rules is high enough to deter such attackers. |
|
|
|
|
Show Posts
