|
..."address using `addmultisigaddress` command then that address is attached one particular account which is saved in wallet.dat file"...
Just a quick note since not at a real keyboard, but I'm not clear if you are talking about Bitcoin core accounts or not, but Bitcoin core accounts may not work how you think, and they are deprecated and will be removed relatively soon.
|
|
|
|
Their FAQ has some explanations about the disparity you see which it sounds like Jhanzo was referencing, particularly the bold portion below: https://support.xapo.com/why-can-t-i-see-my-wallet-balance-on-a-blockchain-explorer/view=faqWhy can't I see my wallet balance on a blockchain explorer?
Xapo protects your privacy by keeping your wallet balance and your wallet transactions private so no one can see them in the public blockchain. You can use your Xapo wallet with the confidence that no one will know your wallet balance or your wallet transactions.
Xapo uses dynamically generated wallet addresses. These are public addresses meant to be shared with anyone you'd like to receive funds from. While you can use the same address multiple times, if the address remains unchanged, anyone you transact with could know the amount of funds you have by simply using a blockchain explorer. We implemented a two-step solution to avoid that from happening.
Each time someone sends bitcoins to your address, a new wallet address will generate, replacing the old address (you will see it by clicking "My Address" button in the web app). This ensures that the person to whom you've sent funds will know only one address, corresponding to a single transaction.
If someone sends funds to an older, previously generated address, you will still receive those funds to your wallet, as we keep all bitcoin addresses ever associated with your account available, just in case you ever plan to reuse or receive ongoing payments to a single address.
The second step involves pooling your wallet funds. As soon as funds arrive to your bitcoin wallet address, we move those funds to a common pool. This prevents anyone from going to the blockchain and seeing the amount of BTC in your addresses or discovering where your are transferring them from. Since the funds are pooled amongst other individuals funds, it is extremely difficult for someone to identify specifically where the original funds that you received were sent from. |
|
|
|
Shouldn't difficulty increase as time goes on?
It usually does, but not always...in a year it has gone from 377... to 1445...: Aug 02 2016 201,893,210,853 -5.43% 1,445,207,896 GH/s Jul 18 2016 213,492,501,108 0.04% 1,528,238,850 GH/s Jul 04 2016 213,398,925,331 1.88% 1,527,569,009 GH/s Jun 21 2016 209,453,158,595 6.83% 1,499,324,110 GH/s Jun 08 2016 196,061,423,940 -1.63% 1,403,462,340 GH/s May 24 2016 199,312,067,531 2.60% 1,426,731,353 GH/s May 11 2016 194,254,820,283 8.73% 1,390,530,167 GH/s Apr 28 2016 178,659,257,773 -0.01% 1,278,892,782 GH/s ... Dec 31 2015 103,880,340,815 11.16% 743,604,444 GH/s ... Aug 22 2015 54,256,630,328 2.95% 388,384,088 GH/s Aug 08 2015 52,699,842,409 0.81% 377,240,166 GH/s ... Oct 23 2014 35,985,640,265 2.81% 257,595,247 GH/s See https://bitcoinwisdom.com/bitcoin/difficultyamong other places |
|
|
|
If for some reason -upgradewallet doesn't work, the source for the older versions is available. Likewise, pywallet is an option to extract the keys if needed. E.g. these are links to the pages where various versions are available: https://github.com/bitcoin/bitcoin/tags?after=v0.3.23https://github.com/bitcoin/bitcoin/tags?after=v0.5.0rc3so you could download, compile, then send to a new address. Or go version 0.3.x to 0.4.x (which, iirc is where the format changed). Whatever you do at this point, make a few backup copies of your wallet.dat just to be safe. |
|
|
|
I am not dismissing concerns about bandwidth or disk space. I am merely pointing out that arguments that don't take into account exponential increases in capacity in both bandwidth and storage space with stable or decreasing costs are (a) purposefully avoiding reality, (b) purposefully trying to mislead people, OR (c) trolling. If you or anyone wishes to code the "distributed file system" and integrate it with Bitcoin Core and convince people it is a better solution so that a majority if people adopt it, please go ahead. Is there a technical paper of how this would work in bitcoin and an analysis as to how it would provide the same security that Bitcoin does now? I am sure that any well-tested code that the people who are complaining about the block chain size (and the like) are willing to commit to Bitcoin Core to decrease the sizes would be more than welcome. Danny is right, and that is just the average.
xfinity runs at least 88 Mbps right now or 8.8 MBps => 528MB/minute = >31GB/hour => 744GB/day.
AT&T Fiber (GigaPower) 300Mbps = about 2.5TB/day.
In 1980 one was lucky to get 300bps (or 180bps). No one serious thinks this has peaked.
So now bandwidth is being dismissed by the same flawed arguments as the disk space?  Completely ignoring data caps and low speed restrictions imposed by providers. Completely ignoring that only first world countries have these sorts of high speed infrastructures (the US is hardly the worst performer in the world). Completely ignoring that most people want to run more than just one application that sucks up all their bandwidth. Completely ignoring that while writing a technology cheque way into some mythical rose-tinted future, the only ones that are likely to be able to afford it are corporations, governments and fat cats. Bitcoin wasn't around in 1980 and has gone from zero to datacenter in a couple of years (let alone 40) due to the resources required to run the system and we are supposed to believe the tech available to the average Joe will be good enough in another 10 when it's struggling now? Makes my blood boil!  |
|
|
|
How do you download tons of Gigabyte?
... According to speedmatters.org, average USA broadband speed is 11.7 Mbps. ... Danny is right, and that is just the average. xfinity runs at least 88 Mbps right now or 8.8 MBps => 528MB/minute = >31GB/hour => 744GB/day. AT&T Fiber (GigaPower) 300Mbps = about 2.5TB/day. In 1980 one was lucky to get 300bps (or 180bps). No one serious thinks this has peaked. |
|
|
|
The question will be whether this was a "hack" or an inside job with "hack" as the excuse. ;-) All too often it is the later while blaming the former. One hopes that as part of their business they included insurance for this type of event. |
|
|
|
One question, you also had said previously that you had imported some keys. Was this one of them? definetely he used compromised private key. no doubts Obviously. The question is (and was) where he got them and why he imported them? |
|
|
|
I don’t know if the is the right list, but I hope someone can advise.
In the early hours of this morning I sent 1.01 BTC from my Xapo wallet to the address 12iocUthp58E72ZksRmToDFPfM1WCPKv91. This is an address in my Bitcoin Core wallet, running on my laptop, for which I control the private key. My client had been running all day and the blockchain was synced and up-to-date.
The instant that this amount was received into the above address (before the transaction was even confirmed) the entire amount was then sent to another address 1aa5cmqmvQq8YQTEqcTmW7dfBNuFwgdCD which I have never heard and do not have the private key for, something which I did not think was possible.
What the hell happened and where is my Bitcoin?
One question, you also had said previously that you had imported some keys. Was this one of them? And as DH asked above, where did those keys come from? |
|
|
|
...One option is to switch to Ethereum which has an impeccable development team and has announced plans for unlimited scalability...
"impeccable" - in some random persons opinion. In that same way, "the Fed has a impeccable leadership team," assuming you believe some random writer at the NY Times, like perpetual inflation at the whim of a random person who happens to be appointed at this point in time. Rules that can be changed on a dime are not rules. Rules that can be changed when someone doesn't like the outcome of the rules, aren't rules and set terrible precedent going forward. The "easy" solution in the short term is often a bad solution long term. "unlimited scalability" - let's see how that turns out. Bitcoin could have unlimited* scalability (and did for a while and was hit with spam) but with unlimited scalability the block chain would be in the multi-hundred TB range by now. There is a cost to everything, someone will pay it one way or another. TANSTAAFL. *no such thing in reality |
|
|
|
|
How do you limit it one pubkey_address per "node"?
e.g. I don't see anything preventing node X from creating Y million pubkeys for their node and treating their node as 1 million individual nodes for this purpose, assuming they are a large pool this seems doable. And with IPv6, tor, dhcp etc, tying it to a single IP address doesn't seem like a solution. A single pool hashes these puzzles during the mining phase and treats themselves as a large cluster of nodes vs one single pool?
And how do you stop hash power "hopping" from one node to another depending on who is allowed to mine a block?
:-)
|
|
|
|
|
Do you have a transaction number or did it not get that far?
If it didn't get that far, it sounds like a "Circl" problem (not sure if that is supposed to be Circle or this is some service), although I am not sure what that is. If so, you'd have to talk to them.
|
|
|
|
Thank for the answer.
Note that making a backup once is NOT enough! By default it contains 100 private keys, once you've used them all it creates new keys, which means you need to make a new backup!
It seems my understanding was faulty. I though it's like for ssh, you have one key and it's used all the time. But now I see that I was wrong. When do the private keys are being used? is it a key for every transaction? A nice change for 0.13.0 will be that by default this behavior will change with HD support |
|
|
|
The biggest reason against raising the block size limit is the risk of Denial of Service attacks. The idea of "just change one constant" comes from ignorant and naive people who do not understand how Bitcoin works on a technical level.
The issue is that of signature hashing for signature operations (sigops). Right now, sigops-to-verification-time is a quadratic relationship, meaning that as you increase the number of sigops in a transaction, the time to verify that transaction squares. For example, doubling the number of sigops in a transaction (as with a 2 Mb increase) will require quadruple the amount of time to verify the transaction. Bump up block size limit to 4 Mb (thus bumping the sigops limit to 4 times of what it is now) means that a transaction with the max sigops will require 16 times as long to verify as a transaction with max sigops now.
This sigops issue is one of the biggest problems when it comes to scaling as it becomes possible to cause nodes and miners to have to verify huge transactions and waste time, time in which another miner could find another block. Furthermore, to solve the issue becomes a major pain. There could be a maximum transaction size, but that isn't really ideal (although AFAIK that is what Classic decided to do). Alternatively the signature algorithm could be changed, but in a hard fork scenario, that is just a nightmare to deploy as any unconfirmed transactions at the time of deployment suddenly become invalid.
There was a discussion about creating a transaction that could take up to 10 minutes to verify (on a current machine, not an 8080 or 6502). As knightdk says, changing the block size itself is easy, it is dealing with the ramifications of those changes and ensuring that they are as well understood that is the complicated and time consuming part which needs to have a lot of testing. If it were 2010 it would be much easier to change since there wasn't as much riding on it, but with a $10 billion market cap in 2016, it takes a much more judicious and contemplative approach. The block size will increase, it is just a matter of time. |
|
|
|
|
Make a backup or two. And glad it worked out.
|
|
|
|
Is it normal that my Mac nearly overheats from downloading this Blockchain?
The fan is meanwhile blowing full speed and still I can nearly bake an egg on the alu housing...
Bitcoin Core is pretty hardware intensive, especially when it has to index the blocks (as with downloading or reindexing). I wouldn't say that this is normal per se, but it certainly is not uncommon nor unexpected. Hello Knightdk, After two day's the blockchain still is not fully loaded. This morning the macbook reported me that Bitcoin Core program was terminated cause of "no more free memory" with a red stop sign. I have 250 GB SSD, little to no programs on system, little amount of pictures, no video's, but still it say's that all my memory is used. The block chain still to be pulled in, is of last 6 days. Now trying to make space. Hi, If the message really is "no more free memory" that should be referring to memory, e.g. RAM, not disk space. However with 8GB of RAM, you should not be running out of memory. Was that the exact message? And, how much free disk space do you have? (That was one reason I asked earlier if you had an external hard disk drive attached because it was possible that you had done so in order to hold the block chain and avoid running out of disk space). It is possible that since the program quit because you had no more free memory that it isn't current and you might need to do a rescan. One suggestion for you to consider would be to dump the private keys from your wallet.dat files and then find the address that had your balance and use a different lightweight wallet (e.g. one that doesn't need the entire block chain). This would avoid all the delays doing a rescan or re-downloading the block chain. |
|
|
|
|
Show Posts
