It's not very safe because it requires Java installed on your machine to work.
What?? Having Java enabled in your web browser may not be safe, but there is absolutely nothing wrong with having Java installed on your PC. Dangers occur when there are vulnerabilities discovered in Java (happens too often...), and you or your browser runs a malicious app. There is no reason to believe MutliBit is a malicious app, so as long as you disable Java in the browser (which in Windows can be done easily via the Java Control Panel app) you are safe from these types of attacks. Maybe there are other reasons not to like MultiBit, but the fact that Java in the browser might not be safe? That isn't a reason.... |
|
|
|
|
New competition in the multisig wallet provider space is a good thing.
"Calvin", however, has made a number of fairly dubious claims, and that's left me, at least, feeling rather uncomfortable with FrozenBit.
It will be interesting to see how things progress from here. I think you'll have a tough time getting over the negative image he's left FrozenBit with, but for what little it's worth I wish you the best.
If I might offer a small bit of advice: the more open you are, the better. For example, even if you don't choose to open source all of your code (which is perfectly fine when it comes to the server-side code IMO), placing the code which you do decide to open source up on GitHub (or similar) earlier rather than later would be a good thing.
Best of luck...
|
|
|
|
In the future I imagine nodes might probabilistically check a random subset of transactions, and broadcast "this transaction is fraudulent" if they find anything wrong. If you imagine a million nodes, each fully validating one-in-ten-thousand transactions then you get each transaction validated on average 100 times. Aaaaaaaand... The total work is O ( nodes * txs ) If the number of transactions validated per node is inversely proportional to the number of nodes (even if it's a manually configured constant), we're at O ( txs ). |
|
|
|
...
But since I am getting an error message that is different only when I use my password, a typo seems very unlikely.
...
I agree. Thanks btchris,
I was able to locate those files, but I cannot import the private ".key" backup files because it is password protected.
When entering my password for importing or exporting private keys it will come back with the message "The wallet password is incorrect"
Now I'm confused-- did you create a new wallet with no password first? The idea was to try importing the .key file into a brand new wallet with no password, but the error message "The wallet password is incorrect" only occurs for me if I try to import a .key file into a wallet that already has a password. |
|
|
|
As long as you didn't create a bunch (100ish) of new addresses or outgoing transactions, restoring from your backup has a much better chance of restoring your funds if the backup isn't encrypted.
Unfortunately that isn't true. Dooglus is right, and I was wrong. Thanks for the correction, dooglus. (I should have known better, I've read that code before....) mricha, my sincere apologies for the false sense of hope. I'd suggest you start by reading one of DannyHamilton's excellent posts in this thread, perhaps this one: https://bitcointalk.org/index.php?topic=85495.msg6591146#msg6591146. If you can remember enough details of your password, it may be possible to find it, but what you've remembered so far probably isn't specific enough. I'd be happy to help you try a brute forcing tool (such as those mentioned above) if you can remember enough details. bool CWallet::EncryptWallet(const SecureString& strWalletPassphrase)
...
Unlock(strWalletPassphrase);
NewKeyPool();
Lock();
...
bool CWallet::NewKeyPool()
...
BOOST_FOREACH(int64_t nIndex, setKeyPool)
walletdb.ErasePool(nIndex);
setKeyPool.clear();
...
|
|
|
|
How screwed am I, on a scale of 1 to 10?
With 1 being least and 10 being most screwed... around 8ish I'd guess, maybe higher...  Also, I backed up my wallet on a flashdrive. I'm not sure if the most recent backup file was before or after I encrypted the wallet. If it was before I encrypted the wallet, it was also certainly before I received the .3164557 BT in funds. If I attempt to restore from the backup will it wipe out all the funds I've gotten since?
As long as you didn't create a bunch (100ish) of new addresses or outgoing transactions, restoring from your backup has a much better chance of restoring your funds if the backup isn't encrypted. Take a backup of your existing wallet.dat file first, and then restore the older backup. If there is zero balance, close Bitcoin and try running it with the -rescan option, e.g. go to Start -> Run, and type "C:\Program Files\Bitcoin\bitcoin-qt.exe -rescan". Hopefully this helps... |
|
|
|
Hi everyone, Armory is now in Debian Sid. If nothing goes wrong, Armory will be in testing (Jessie) around November 4, which is in time for the November 5 freeze. That means that Armory will be in Jessie when it becomes the new stable release. You can install Armory right now on your Debian Sid system by running the following command: sudo apt-get update && sudo apt-get install armory Joseph Wow... I was a doubter that this would happen, and I'm very happy to be wrong! Thanks! |
|
|
|
If government goes for core dev team it will kill it easily. You don't need to attack the application, get people who works on it and you are done.
You don't even need to kill it. Just install enough hooks and backdoors and whole purpose is defeated. No one really checks what is running except few developers, there are no audits or checks and balances to insure code integrity.
When you say "the government", you're implying that the US, the Netherlands, and Belgium will join forces to extort all of the core devs (to say nothing of other eyes on the project) to insert a back door? If that's likely to happen (it's not), I doubt any additional audits (which could also be influenced in the same way) would be of any help. (I agree you're correct in principle though.) It remains the only implementation with a miner, yes?
So, also a single point of failure.
Putting aside the unlikelihood that all versions, forks, and clones of Bitcoin Core have been backdoored (in a way that apparently can't be reversed), btcd is at least one full-node alternative, re-implemented from the ground up, which supports getblocktemplate: https://github.com/conformal/btcd/wiki#Mining. It's quite an ambitious project, you should take a look. |
|
|
|
If you haven't already, I would: 1. Try to locate and open your backup wallet, see here: https://multibit.org/en/help/v0.5/help_fileDescriptions.html2. If that doesn't work, create a new wallet (and give it a description just so you don't confuse it with the original). 3. Hopefully locate one of your private ".key" backup files (see link above). 4. Import the keys into the new wallet (Tools -> Import Private Keys). If either of these work, could you compare (just out of curiosity) all of the addresses in the non-working wallet and the working one to see if there are any differences? (except for the one new address that's automatically created for you in a new wallet, that is) |
|
|
|
Ack. Good catch. I tend to check all the new downloads before pushing (or immediately after) version updates to make sure it was all smooth. It seems I actually did it right but they pulled the rug out from under me... thanks for finding that commit that changed and vindicating me from fault  Looks like they changed it two days after initially posting it. Your only fault was updating the Armory links too quickly after release |
|
|
|
lol @ grandma-cap for Bitcoin
We agree, in this case "grandma" is substituting for "bitcoin enthusiast" WRT bandwidth availability, I think.
I'm guessing he was thinking that our enthusiast might be living with grandma, or maybe is grandma, IDK?
Some people want everyone to run a full node. I'm suggesting that's not a good idea. We should not limit bitcoin growth such that everyone can run a full node. Not everyone needs to run a full node to benefit from bitcoin. A "bitcoin enthusiast" is not everyone. See Gavin's definition I just quoted above. Without at least some limit, bitcoin nodes become centralized. Also, the suggested exponential upper limits seem very unlikely to limit bitcoin growth. |
|
|
|
Much mining can be done with a single node. Costs are discrete between nodes and mining[,] and [those costs are] asymmetric.
...
People look at hashrate to determine network health and not so much at node population and distribution, but both are essential.
(Text in brackets added by me to indicate what I understood you to be saying.) Agreed. If costs for node maintenance overwhelm the expected rewards at <x hashrate / y nodes then we lose all mining under that hashrate irrespective of other costs, and we lose nodes per hashrate.
We lose nodes per hashrate, which is bad and leads to (or rather continues the practice of) miners selling their votes to node operators, but I don't see how we lose hashrate, we just centralize control of hashrate to amortize node maintenance costs (still bad). In later years, there is a very long chain, and most coins transacted will be the most recent.
...
We don't know how it will play out, its uncharted territory. #3 is more about not creating a perverse incentive to unbalance this that doesn't materialize until the distant future than about encouraging compensation through artificial constrain on supply.
So long as the grandma-cap can be maintained, it seems like all of your discussion would already be covered. The hope has always been that new techniques (IBLT, tx pruning, UTXO commitments, etc.) will keep this possible. However there is no way to see into the distant future. Any chosen grandma-cap could be incorrect, and any cap more restrictive than that to meet #3 could also be incorrect. I don't disagree that #3 is desirable, only that it may not be implementable. Having said that, as long as a more restrictive cap has little to no chance of interfering with #2 (never prevent a miner from including a legitimate tx), I'd have no problem with it. 3) provide conditions conducive for node maintenance and mining when the transaction fees are supporting the network by avoiding perverse incentives.
TL;DR - This goal implies the "only permit an exponential increase in the max blocksize during periods of demand" rule in your initial example, correct? |
|
|
|
I'd rather not implement a grandma-cap on bitcoin's growth. Grandma doesn't need to run a full node. She can use an SPV or other thin client.
lol @ grandma-cap for Bitcoin We agree, in this case "grandma" is substituting for "bitcoin enthusiast" WRT bandwidth availability, I think. I'm guessing he was thinking that our enthusiast might be living with grandma, or maybe is grandma, IDK? Actually I picked the term up from NewLiberty's post, but yes that's what I was assuming it meant. Should the term "grandma-cap" make it into the BIP? |
|
|
|
My (ideal) goals, in particular, would be to (1) never kick out grandma, and (2) never prevent a minor from including a legitimate transaction. (edited to add: those are in priority order)
We share these design goals, and priority. They aren't comprehensive for me though. I'd add (at least) 3) provide conditions conducive for mining when the transaction fees are supporting the network 4) avoid future changes on the same issue. And of course avoid introducing new unmitigated risks (more of a criteria than a goal). It seems to me that (1) and (2) could both be implemented with either the static (Gavin's) method or some reactive method, although the I suspect the reactive method can do (1) more safely/conservatively. If a reactive method can do (2) safely enough (I suspect it could), I'd prefer it. A reactive method seems much more likely to meet (4). If I understand you correctly, (3) takes us back to an artificial cap on block size to prevent a perceived, as Gavin put it, "Transaction Fee Death Spiral." I've already made my rant on that subject; no need to repeat it. I'm of the opinion that reaching consensus on (3) is more important, and possibly more difficult, than any static-vs-reactive consensus. (3) is an economic question, whereas static-vs-reactive is closer to an implementation detail. |
|
|
|
If we wanted to be brutally pedantic on ourselves we could kick around the definitions of who grandma might be, and what makes a transaction legitimate, but I agree with the sentiment entirely.
I'd rather not implement a grandma-cap on bitcoin's growth. Grandma doesn't need to run a full node. She can use an SPV or other thin client. Although we can argue about details, we (or at least I) have been using "grandma" as shorthand for "Bitcoin hobbyist", which Gavin had equated to "somebody with a current, reasonably fast computer and Internet connection, running an up-to-date version of Bitcoin Core and willing to dedicate half their CPU power and bandwidth to Bitcoin." Is that reasonable? |
|
|
|
That's an excellent point. I wonder if maybe we can simply make the installer not overwrite shortcuts if they already exist, but only add them if they don't. Alternatively, it would be nice to have the dbdir set in the settings. I bet that explains a lot of support tickets we get when users upgrade -- nothing changed, it just overwrote their CLI args that they normally use...
I think your first alternative looks better since it would cover more use cases, but either would work for me. Of course there's also the Windows registry, but that seems an unwise option for multi-platform software... This is OT, but has someone noticed this easy-to-fix bug which could use some attention? |
|
|
|
|
Speaking of database locations...
With Armory, I know that either --datadir or --settings would have to remain a command line option so that ArmorySettings.txt can be located, but it would be kinda nice if --dbdir could be settable via File -> Settings and stored in ArmorySettings.txt. That way I wouldn't have to remember to update all the start-up shortcuts each time I upgrade Armory. Just a thought...
|
|
|
|
NewLiberty, thanks again for taking the time to explain your point of view. The reason, by the way, I was asking the earlier questions was because I actually didn't know the answers. In particular, this answer (happily) surprised me: Excluding DOS flooding or other malicious actors, do you believe it would ever be a beneficial thing to have the blocksize limit hit?
Primarily the limit is a safeguard, a backstop. It is not meant to be a constraint on legitimate commerce. It also serves to facilitate adoption and decentralization by keeping the ability to participate affordable. Backstops are beneficial when hit, if they are protecting grandma from getting hit with the ball. Regarding Nielsen's law: Yes, I disagree.
Both Block size and transaction fee may be better tools than Nielsen's law, the combination may be even more so. Dismissing inquiry on the matter, is a missed opportunity.
I don't disagree that Nielsen's law is inaccurate, however I remain quite skeptical that there's something in the blockchain that can more accurately predict grandma's computing resources. Having said that, I think I'm misunderstanding your goal here (and I'm maybe OK with that): it seems as though you're not interested in using grandma's computing resources as a block size limit, you'd prefer a much lower bound at times when transaction volume isn't growing. My biggest concern with the alternatives discussed in this thread isn't the potential for unchecked growth, but rather the potential for miners creating forced artificial scarcity (hence my first question, for which I expected a different response). For example in the first algorithm you suggested, a majority mining cartel could artificially limit the max block size, preventing a mining minority from including transactions. It's this lack of free-market choice that I'd disagree with. If the difference between average block size and max block size were a magnitude or two of order away, I'd find it much more agreeable. My (ideal) goals, in particular, would be to (1) never kick out grandma, and (2) never prevent a minor from including a legitimate transaction. (edited to add: those are in priority order) |
|
|
|
Thank you.
Would you agree, if it were possible (although it is not), that the blocksize limit should somehow be automatically tied to "the bandwidth and disk space an average enthusiast can afford"?
Yes. Though you should also recognize that block size and bandwidth use are not so tightly tied. Network and disk compression can compress data, the block size is measured after decompression. Fair enough- block size may not be the best parameter to tweak to maintain the stated "bandwidth and disk space" goal, but it is a technically simple parameter to tweak. Do you believe that there exists somewhere in the blockchain a metric, let's call it X, which would serve as a good predictor of "the bandwidth and disk space an average enthusiast can afford"? I think this is the same question, though you may disagree: Do you believe that this metric X has a causal relationship with "the bandwidth and disk space an average enthusiast can afford"? The Socratic inquiry is a bit pedantic, don't you think? Skip to your point please. Very well. No metric that can be gleaned from the blockchain has a causal relationship with "the bandwidth and disk space an average enthusiast can afford", and therefore any such predictor has a high danger of being either too restrictive or not restrictive enough. Using Nielsen's Law also has a danger of being inaccurate, however given that it has at least been historically accurate, I find this danger much lower. Do you disagree? (let's leave ossification out of this just for the moment, if you don't mind) |
|
|
|
Thank you.
Would you agree, if it were possible (although it is not), that the blocksize limit should somehow be automatically tied to "the bandwidth and disk space an average enthusiast can afford"?
Yes. Though you should also recognize that block size and bandwidth use are not so tightly tied. Network and disk compression can compress data, the block size is measured after decompression. Fair enough- block size may not be the best parameter to tweak to maintain the stated "bandwidth and disk space" goal, but it is a technically simple parameter to tweak. Do you believe that there exists somewhere in the blockchain a metric, let's call it X, which would serve as a good predictor of "the bandwidth and disk space an average enthusiast can afford"? I think this is the same question, though you may disagree: Do you believe that this metric X has a causal relationship with "the bandwidth and disk space an average enthusiast can afford"? |
|
|
|
|
Show Posts
