Almost immediately after publicizing their support for Gavin Andressen’s BIP 101 and Bitcoin XT, Coinbase was removed from Bitcoin.org. The de-listing of Coinbase’s bitcoin wallet platform followed a major upheaval in the Bitcoin community, as many of its members began to contest against Bitcoin.org’s unsupported decision to remove the world’s 2nd largest bitcoin wallet application from its website. http://www.newsbtc.com/2016/01/10/bitcoin-org-violates-its-mission-statement-to-censor-coinbase/I think their argument would be that Bitcoin XT is a fork and therefore and alt-coin and therefore not bitcoin and therefore they are no longer supporting bitcoin. Right or wrong, I believe that is what they would say at least in part. |
|
|
|
Thanks guys. Such huge numbers it's difficult to fathom, but that really helps put it in perspective.
And that is the problem. It is very difficult to fathom the size of the space even looking at the numbers. It is easy to think, oh, the number is twice as long, so twice as hard, so I'll just search twice as long when in fact it is nothing like that. Without consciously thinking about it it is hard to grasp. Even thinking about it, the scale is just so immense it is hard to appreciate. Shoot, even looking at the math it is hard to appreciate the enormity of it. Glad Shorena and Danny beat me to the math!  |
|
|
|
If you intend on continuing any type of darknet market activities I highly reccomend learning to use tails or something similar. You are just begging for a repeat of this situation if you continue to use Windows for these types of things.
Definitely good advice. Or if you are handling a substantial number of bitcoins, buy a PC to use only in off-line mode. And don't use Windows with it. |
|
|
|
...
Then just format the hard drive and reinstall your OS. Since you are trying to delete your private keys anyways, that will take care of that for you.
...
If you already have a backup, keep it. If you can make one, do so. It doesn't hurt to have it so that if they send coins to that address you (or someone) can sweep them and not let the scammers keep them. If you wish to make their life more difficult in terms of using that key, post both the private and public key here. Then someone will no doubt monitor it and try to beat the scammers before they make bitcoins from it. |
|
|
|
Yes, Core 0.11.2. I start it on and off when I need to do something with my wallet. Usually it catches up several days and then I do a transaction. This particular transaction was sent with 0.00013 BTC fee which seems reasonable?
It does in the abstract, but that is just abstract. Currently, Bitcoin Core uses an algorithm to monitor the network and see how long transactions take to confirm and then uses that to determine what fee is needed to get a transaction to confirm quickly. If it doesn't have sufficient information since it had just been started, it could be miscalculating. If you have the tx id, that might be helpful ;-) |
|
|
|
Hi,
I sent a transaction using 0.11.2 and the recommended fee for "normal" confirmation time over 6 hours ago and it's still unconfirmed.
Has the default fee become too low somehow?
Cheers
What wallet software are you using? Bitcoin Core? What version? If so, did you let it run for a while so it could determine what the optimal fee was? |
|
|
|
|
Is there a reason you are downloading the block chain vs just running Bitcoin core? Since 0.10.0 it hasn't been any faster to do so, and may be slower.
|
|
|
|
Was trying to find out how the guy is doing this without any success, this is just driving me nuts.
He has more hashrate than you and is mining more blocks than you in some period of time but he is not broadcasting them or network has issues with data progagation. Then he broadcasts all new blocks or network data propagation improves somehow. He is possibly an owner of all full-nodes on network except yours so data propagation is up to his likings. But in any case, he has more hashrate than you. What doesn't make sense is that even if he had more hashrate than me, he would find the first block faster but then difficulty would adjust right away and finding the next block will be equally as hard as finding it in my chain (yes thats how broken it is) and then it is only a luck game. So on this alt, difficulty adjusts after each block? Perhaps he has a modded octocoind that doesn't adjust on each block? So perhaps he just mines a long chain without broadcasting it and without the difficulty readjustment, then broadcasts it which orphans everyone else's blocks? Higher hash rate, greater total difficulty, he wins? |
|
|
|
How can someone achieve that? I am running a pool which represents 70% of the coin's network hashrate, I can find few sequential blocks then this miner will mine the next block and orphan all of my previous blocks.
Additional information:
- My blocks are broadcasted/propagated normally (checked that)
- Changed IPs, Changed daemon versions and nothing helps
- Made a separate network that gets connected to the mainnet once every few hours, and this also didn't help !!!
How the heck did this miner achieve this and what can I do about it ?
What coin is this? |
|
|
|
|
You can also try checking to make sure all your drivers are up to date - see Device Manager, assuming this is Windows. Likewise, it doesn't hurt to use chkdsk to see if it is a hard drive issue and you can try running Windows Memory Diagnostic.
These should at least help you try to find anywhere you are having the issue.
|
|
|
|
Having a bunch of "free space" that's unused due the cap being too big brings a lot of problems and possible exploits. What centralizes Bitcoin is not being able to run a node in your computer, not the nonsense you are talking about. Bitcoin will never scale to worldwide levels by raising blocksize.
There is no free space. Damnit you guys really have no clue about the blocksize debate and comment on it. The cap limit is not a default setting. Blocks wont become 8mb size, and 7.5 mb will become empty. Blocks will remain the same 0.5mb, but it just lets the maxium reach 8mb if it needs to. Now i dont think 8mb should be increased immediately, but it should be written into the protocol to increase at some point. I dont like the command & control aspect of the development. There should not be a need for development anymore. Add a final BIP into it, and then its over. Developing it further just gives more power to the developers and it creates a centrally planned currency, that is nothing better than fiat. I know there's no "default setting" and free space is just a way so say it, but yes having that "extra space" brings some problems. In any case 8mb or 20 solves nothing in the long term. Right now those values are absurd, in the future, we'll see how the average internet connection/hardware deals with those, but the main point is, Bitcoin will never scale to worldwide levels without something like the Lightning Network. At some point software solidifies, protocols need to stop being exposed to hard forks, and 1mb seem to be enough (+ sigwit) until we get LN. Only people clueless in scaling software of this nature would claim that doing hard forks periodically is a good idea. TCP/IP solidified and then we developed layers on top, the same will happen with Bitcoin. I don't care if it happens with 1mb or 2 or 8, in the long run we will encounter the same problem and only LN can save our asses if we want to go global, something big block guys don't seem to get (unless they are ok with the nightmare of huge datacenters running nodes + the aforementioned problem of periodic hard forks). I agree. At some point, bitcoin will be too entrenched to do hard forks unless absolutely necessary - e.g. some huge break in ECDSA, perhaps proving P=NP would make things absolutely necessary. LN, sidechains, segwit and similar proposals are ways to alleviate the pressure on block sizes and accomplish a lot of experiments without having to change the core protocol regularly. As above, I'd think about it like TCP/IP vs SMTP/DNS/FTP/IMAP/NNTP/SSH/DHCP/HTTP and the like. Much will be built with bitcoin's blockchain and on top of it due to the security that the value of the bitcoin ecosystem provides. |
|
|
|
You could have a block that is corrupted on disk which might mean re-downloading the block chain. Mine always crashes around the same block. Then starts over from block 1, 'reading the blockchain', with 1 core. Which takes forever, and then gets an error and aborts again after 10 hours or so. like this 2016-01-05 11:53:27.625338 LoadBlockIndexDB: last block file = 410
2016-01-05 11:53:27.629531 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=94, size=60445069, heights=391569...391856, time=2016-01-03...2016-01-05)
2016-01-05 11:53:27.629589 Checking all blk files are present...
2016-01-05 11:53:27.700450 LoadBlockIndexDB: transaction index enabled
2016-01-05 11:53:27.700552 LoadBlockIndexDB: hashBestChain=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 date=2009-01-03 18:15:05 progress=0.000000
2016-01-05 11:53:27.701030 init message: Verifying blocks...
2016-01-05 11:53:27.701201 block index 16563ms
2016-01-05 11:53:27.701415 No wallet support compiled in!
2016-01-05 11:53:27.701433 init message: Activating best chain...
2016-01-05 11:53:27.764422 - Load block from disk: 0.36ms [0.00s]
2016-01-05 11:53:27.764506 - Sanity checks: 0.03ms [0.00s]
2016-01-05 11:53:27.764534 - Fork checks: 0.03ms [0.00s]
2016-01-05 11:53:27.764586 - Connect 1 transactions: 0.05ms (0.050ms/tx, 0.000ms/txin) [0.00s]
2016-01-05 11:53:27.764602 - Verify 0 txins: 0.07ms (0.000ms/txin) [0.00s]
2016-01-05 11:53:27.764653 - Index writing: 0.05ms [0.00s]
2016-01-05 11:53:27.764678 - Callbacks: 0.03ms [0.00s]
2016-01-05 11:53:27.764695 - Connect total: 0.30ms [0.00s]
2016-01-05 11:53:27.764710 - Flush: 0.01ms [0.00s]
2016-01-05 11:53:27.764725 - Writing chainstate: 0.01ms [0.00s]
2016-01-05 11:53:27.764782 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 log2_work=33.000022 tx=2 date=2009-01-09 02:54:25 progress=0.000000 cache=
0.0MiB(1tx)
It verifies the blocks starting from 1, with a single core. Attempting a 'bitcoin-cli stop' says that it's currently reading block index, lol. I had more success w/ the XT client, but I don't think they're really much different at all? |
|
|
|
Doesn't the blockchain need Bitcoin to function and visa versa?
Right now the value of Bitcoin helps secure the block chain. It isn't "needed" in a strict sense to function, but to function securely in a distributed environment, the value provides the incentive to do so. |
|
|
|
Well, the first one says there is no such directory as C:\Users\New What is the name of the user you are using? You can find it like this according to this depending on windows: Follow these steps to find out what "User" name you are currently logged in under, on your laptop:
Press the Ctrl + Alt + Delete keys simultaneously.
Windows Task Manager will pop up on the screen (see picture below): Click on the Users tab. Look under the User heading for your currently logged in account. from: http://library.queensu.ca/libguides/computers/windows-username-check.htm : |
|
|
|
You might try moving this into here since that is the multibit section. ;-) https://bitcointalk.org/index.php?board=99.0Hi
please help me understand this.
1. during the installation of multibit HD i wrote down the so called "wallet words".
2. with this wallet word i can restore my wallet.
Q1: if i forget the password of the wallet i can restore it with the wallet words?
3. to every BTC-Address there is a pair of keys.
Q2: is this correct?
4. i have a wallet and within this wallet i can have any number of addresses.
Q3: correct?
Q4: all these addresses are restorable with the wallet words?
Q5: which part/files do i have to backup exactly?
and the last question.
Q6: if know the wallet words. i make a backup today. tomorrow i generate a new address to receive a payment. then my pc gets lost. can i claim the BTC a received with the address generated after the i made the backup?
thanks a lot.
|
|
|
|
No worries, thanks for replying.
I have Core already installed and replaced the wallet.dat file with mine backup. I've rescanned and it's now downloading 5+ years. Seems to be going fairly quick.
It will go quick......'for now'. Wait until you hit 2 years to go  Boom! Yeah you're right. Stuck in the mud now. Wow, I wish there was a better system for this. :-) It's worth it in the end, the security & having control of your private keys is worth the wait rather than using online wallets etc. You can export the private keys from Bitcoin Core and import them into a different wallet. You don't need online wallets or things to be fully sync'd to export the keys. |
|
|
|
... I can't wait to see BU (fail to) deal with 16/32MB blocks trollishly construed so as to take hours or days to verify. ... This is an important point - and the one I've thought it safe to ignore here, but if you have people picking a larger sized block, without BU building in safeguards, it will be dangerous to the network if people are not aware of the consequences. Even 2 MB blocks can have transactions that can take 5-10 minutes to verify. |
|
|
|
This. Right now the only difference is a nice front end to change a parameter (ignoring again other issues to keep the network secure). Even a non programmer can edit it easily. "user-selectable blocksize cap" aspect -
1) So I fire up 2000 nodes, all selecting 200MB as cap.
2) I make the miners belive this is the prefered block size.
3) They all start producing 200MB block.
4) I fill up the blocks for the next 10 days
5) Bye bye 75% of all network nodes
6) I pretty much run the network
Here's the difference with Core: 1) So I fire up 2000 nodes, hire a coder to mod the Core code to set 200MB as cap. 2) I make the miners belive this is the prefered block size. 3) They all go "yayyy tons of fees!" and hire a coder to mod the Core code so they can start producing 200MB block. 4) I fill up the blocks for the next 10 days 5) Bye bye 75% of all network nodes 6) I pretty much run the network Not that you could actually do (2) anyway, but that's just me defending Core again. As I mentioned, this is just a bit more convenient in BU. Someone with the resources to spin out 1/3 of the total number of nodes now on the network, and mining pools that are actually mining the blocks now, are going to find it trivial to do (1) and (3) right now, in Bitcoin with Core, if they wanted to. The convenience of BU is not going to be of any noticeable help, and even if you think it is, that horse has left the stable - the miners convinced can just download BU. Under that view, all that was necessary to kill Bitcoin was to release BU. That can't be right. |
|
|
|
Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something? Well, that is already the case. BU just makes it more convenient. It is far easier and less expensive to spin up a bunch of nodes than replicate replicate the hashing power. Would you agree or disagree? They don't even have to break off and form their own chain. They can just recompile with a parameter changed to accept larger blocks. And then in theory that larger block would be orphaned and it would go back to the main chain eventually. (There are other considerations for say allowing 200MB blocks with regard to just changing that parameter, but safe to ignore them in this reply I think). |
|
|
|
|
Show Posts
