Bitcoin Forum
February 18, 2019, 09:11:36 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 [61] 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 ... 551 »
1201  Bitcoin / Bitcoin Technical Support / Re: Pruned mode syncing doesn't cache file writes? on: October 21, 2017, 04:58:18 PM
RAM is not a problem. Bitcoin Core anyway never used much more than the 300MB you see in the screenshot.
Then you have probably set the parameter incorrectly. How did you set dbcache? Can you post the contents of your bitcoin.conf file? Can you post the contents of your debug.log file?

I'm not sure how it works internally, click "Help > Debug window" to see it's Memory usage for the Memory Pool, I always assumed that's the amount of cache it uses (but I'm not entirely sure), and memory pool doesn't have so many unconfirmed transactions.
The mempool and the dbcache are unrelated to each other. They have their own memory allocations and are configured with different options.


OP, what kind of HDD do you have? What is your CPU? CPU can also be a major bottleneck given the amount of computation that needs to be done to validate blocks.
1202  Bitcoin / Bitcoin Technical Support / Re: bitcoin core directory reset on mac on: October 21, 2017, 04:50:57 PM
Start Bitcoin Core with the -choosedatadir option. You can either start it from the terminal (not sure how you do that on Macs) or add choosedatadir=1 to your bitcoin.conf file. If you add it to your bitcoin.conf file, you will want to remove it later and delete the bitcoin.conf file from your Application Support folder. Once Bitcoin Core has started with that option, you will be given a dialog to choose your datadir again.
1203  Bitcoin / Bitcoin Technical Support / Re: Bitcoin Core error on: October 21, 2017, 05:27:17 AM
Bitcoin Core is probably not synced yet so you do not see the transaction in your wallet. You will not see it until Bitcoin Core has fully synced the blockchain.

If you are worried about the disk space usage, you can run Bitcoin Core in pruned mode. Go to Settings > Options and click the button for Open Configuration File. Add the following line to the file and save it:

Code:
prune=550

Then restart Bitcoin Core. This will prune the blockchain so it will only use a few GB at most, not 150 GB. Note that you will still need to wait for it to sync the blockchain. It will still consume >150 GB of network data, just that the vast majority of that data will be validated and then thrown away once Bitcoin Core is done with it. Syncing will still take a long time.
1204  Bitcoin / Development & Technical Discussion / Re: Is the feature "reclaiming disk space" really implemented in Bitcoin Core? on: October 21, 2017, 05:23:55 AM
Ok as far as I understand, you have to download the whole ~150GB blockchain nevertheless, then enable pruning afterwards to be left with a couple of gigabytes of blockchain data.
No. You can enable pruning at any time and it will reduce the amount of space used on disk to a few GB at most. You do not, at any point in time, need to have the full blockchain on disk.

The other part that I understand is that not all nodes can have pruning enabled, some nodes must keep the whole blockchain anyway. All this makes pruning much less effective.
That is correct.

By reading #7 of Satoshi's white paper, It seems that current pruning functionality is not working as intended.
No. Pruning is working exactly as intended. Pruning and what Satoshi said in the whitepaper are two completely different things.

So why don't we just store coinbase transactions and UTXOs? Am I missing something?
Because without the full transaction history, that data can be forged. You can't know whether a UTXO is legitimate without knowing the transaction that created it and what that transaction spent. You need the full transaction history to verify the validity of a UTXO. With UTXO commitments (which do not yet exist) we could do that, but we will need a fork to enable such functionality.
1205  Other / Meta / Re: Who do i need to talk to regarding account recovery? on: October 21, 2017, 05:19:45 AM
Contact the administrators, Theymos and Cyrus. Also read http://fonstavka.com/index.php?topic=497545.0
1206  Bitcoin / Armory / Re: ArmoryDB.exe has stopped working on: October 20, 2017, 09:51:13 PM
Upgrade to Armory 0.96.3 available here: http://btcarmory.com/0.96.3-release/
1207  Bitcoin / Armory / Re: Can not send my bitcoin with Armory - someone help me please on: October 20, 2017, 09:50:27 PM
What version of Armory and Bitcoin Core are you using (do no just say "latest", give a version number)?


Version:

Armory 0.96-beta-a3d01aa722
Bitcoin core 0.15.0
Upgrade to Armory 0.96.3, available here: http://btcarmory.com/0.96.3-release/
1208  Bitcoin / Armory / Re: Can not send my bitcoin with Armory - someone help me please on: October 20, 2017, 07:40:45 PM
What version of Armory and Bitcoin Core are you using (do no just say "latest", give a version number)?
1209  Bitcoin / Development & Technical Discussion / Re: How do I configure bitcoin-qt to see all transactions? on: October 20, 2017, 07:40:12 PM
In Bitcoin Core, go to Settings > Options and click the button "Open Configuration File". Add txindex=1 to the text file that is opened and save it. Then restart Bitcoin Core, it will say that a reindex is required, click OK. The blockchain will be reindexed and the transaction index will be built so that you can request any arbitrary transaction.
1210  Bitcoin / Development & Technical Discussion / Re: Question regarding Lighting Network on: October 20, 2017, 07:36:32 PM
I've read it will solve the transaction volume (and fees) problem and that Bitcoin could be then used for daily transactions.
At the same time, it looks like Lighting network only makes sense if transactions are bidirectionnal. For instance I don't see why it's useful to pay the grocery store or my rent to my landlord, since they won't send me money on their side.

Am I missing something?
Yes, you are.

The lightning network is useful for paying the grocery store or your landlord because you do so on a repeated basis. Instead of making 1 on-chain transaction for every single payment to the grocery store or to your landlord, you can use LN to essentially batch your payments so you are paying them but only need to make 2 on-chain transactions over a course of a year, for example (instead of 12 monthly rent transactions).

Furthermore, your landlord or your grocery store is likely to be a hub with many open payment channels with other people. So if you wanted to pay someone or receive money from someone, instead of making an on-chain transaction to pay that person or making a payment channel with them, you can route a payment through your landlord or your grocery store to that person. For example, say your neighbor wants to pay you some Bitcoin. He can either make an on-chain transaction sending you money, or he can use his currently open LN payment channel with the landlord and route the payment through the landlord. This essentially means that he gives the landlord money over his payment channel with the landlord and then the landlord sends you the same amount through your payment channel with the landlord.
1211  Bitcoin / Bitcoin Technical Support / Re: Pruned mode syncing doesn't cache file writes? on: October 20, 2017, 03:33:44 AM
dbcache was set to 3000. I don't think I saw the process use anywhere close to that much memory, but I'll look more closely next time.

Is dbcache only for the UTXO set? Is it for reads or writes?
The dbcache is used for holding the UTXO set in memory. Once the dbcache is full, the UTXO set will be flushed to the disk. Having a higher dbcache means that it is flushed less so it will reduce disk IO from the UTXO set side of things. However during the syncing process, blocks are being written and deleted from disk so that is a major source of disk IO and slowdown.
1212  Bitcoin / Development & Technical Discussion / Re: Is My Address Hanging Out?? on: October 20, 2017, 12:39:23 AM
1: By just creating a watch only wallet.  Does this expose my bitcoin address, (thus tying my public key to my IP address)? Is anything "transmitted" or is this passive?
It is entirely passive. Nothing needs to be sent anywhere nor registered anywhere.

2: As long as my local blockchain is up to date, can I do step 1 (create unsigned trans.) without being on line? If so does my local blockchain need to be fully caught up or just past my last transaction?
You do not need to be fully synced to create an unsigned transaction. However if you are not fully synced, you could potentially have a problem where the inputs that you are spending are already spent in a transaction that is later on in the blockchain. If you are already fully synced, you can go offline briefly to make the transaction, but I don't see why you would want to do that because nothing is ever transmitted for an unsigned transaction.

3: To sum up, can I get to where I ONLY expose my Bitcoin address at #3.
You have to expose your Bitcoin addresses in order to receive Bitcoin to spend, so no, that's not really possible. If you ignore that, then yes. In fact, you will always only expose your addresses (ignoring the receiving part) when you broadcast a signed transaction.

Note that it is practically impossible to figure out the IP address of the node that a transaction originated from. Transactions are not tied to IP addresses and Bitcoin addresses are not tied to IP addresses. The IP address that you see on block explorers like blockchain.info are the IP addresses of the node that first relayed the transaction to blockchain.info's node. That node is most likely not the node that created the transaction.
1213  Bitcoin / Bitcoin Technical Support / Re: Pruned mode syncing doesn't cache file writes? on: October 20, 2017, 12:33:53 AM
Increase the size of the dbcache by starting Bitcoin Core with the -dbcache=<n> option or adding dbcache=<n> to your bitcoin.conf file where <n> is the amount of RAM in MB that you want to dedicate to the database cache. Increasing this will reduce the amount of disk IO that is done as the database will be flushed less frequently. A dbcache of ~6000 should allow the entire database cache to be held in memory so only on flush is required.
1214  Bitcoin / Armory / Re: Armory 0.96.3 stuck in "Organizing Blockchain" on: October 19, 2017, 09:08:55 PM
Then I tried to start Armory, but I don't think I've ever got past the infamous "Organizing Blockchain" step that goes on forever (side note: If I understand things correctly, Armory added this horribly slow step in order not to copy over the entire blockchain. Personally, I was happy with the duplicated blockchain from before, because it was fast and I have disk space).
You are not understanding correctly. The previous system was much much slower than the current one. Just because you are experiencing this issue does not mean that everyone else is too and that the process must be slow for everyone. The original design was way worse and performed horribly compared to the current system.

I've read through many posts describing similar issues, and tried various things, but to no avail. One workaround had an interesting result though:

- I ran `bin/bitcoin-qt` on its own, letting it sync.
- I then ran the ArmoryDB command line on its own (without starting Armory itself):

> ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/home/user/.bitcoin/blocks" --datadir="/home/user/.armory/" --dbdir="/home/user/.armory/databases"

This command printed a bunch of "parsed block file #<number>", and then nothing at all for a very long time (20h or so), and then it seemed to have finished. I got excited, killed the process, and started Armory itself, but it seemed to start re-processing every block from the beginning, and got stuck on "Organizing Blockchain" again.
Do this, but instead of killing it, start ArmoryQt. Also remove --cookie from your command.

According to your logs, it was able to parse all of the data but for some reason everything it did was not saved to the database. You may have killed the process too early before everything was done.
1215  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.0.1 Released on: October 19, 2017, 07:45:00 PM
Quote
warning fee estimation is currently not possible

i guess it is  because of the fork coming in 25th ??
No, that has nothing to do with fee estimation. In order for the fee estimator to work, you need to have your node be one for some time. It needs to have received several blocks with a mostly up to date mempool in order to actually estimate fees. This is because it will compare what in its mempool got into a block and how long that took to happen, so it cannot use historical blockchain data.
1216  Bitcoin / Bitcoin Technical Support / Re: Some questions about the Lightning Network on: October 19, 2017, 05:26:32 PM
I've been wondering about something related for a while now: as far as I understand LN, a payment can go through different payment channels to connect Bob and Alice. That means several people are involved. What if one person decides to close a channel, even though it will cost him money? Does that mean all connected channels also have to close?
No. Payments are not dependent on channels remaining open after the payment has completed (i.e. the HTLCs* have been fulfilled).
I think you misunderstood me: I know the payments are safe, but the channel has to close. If the users want to continue using it, they'll need to open another channel, making on-chain transactions with on-chain fees to do so.

*Hashed Timelock Contracts (wiki)
Payments to one person do not necessarily have to follow the same route. A different route can be chosen to route around the fact that someone has closed a channel. One person closing a channel in the route just means that that route can no longer be used. All of the other channels in that route can remain open.
1217  Bitcoin / Armory / Re: Command Prompt Window on Windows on: October 19, 2017, 05:21:59 PM
What version of Armory are you using (don't just say latest, give a version number)?

Armory 0.96
You should use Armory 0.96.3. That should fix your problems with Bitcoin Core 0.15.0.1. There are known issues with older versions of Armory and Bitcoin Core 0.15.0.1.
1218  Bitcoin / Bitcoin Technical Support / Re: Bcoin vs Bitcoin core integration/staging tree on: October 19, 2017, 05:18:14 PM
Do you (or others on the list) know the status of particular JSON-RPC extensions?  We're thinking of tapping into that, somewhat similar to this proposal:
 
  http://wiki.opendaylight.org/images/9/9d/JSON-RPC.pdf

It sounds like we'd need formal approval for an extension to be used.  Or, is this simply an internal network optional that we can modify as we'd like?
If it is not part of the JSON-RPC 2.0 specification, then Bitcoin Core probably does not support it.
1219  Bitcoin / Bitcoin Technical Support / Re: Some questions about the Lightning Network on: October 19, 2017, 05:15:38 PM
I've been wondering about something related for a while now: as far as I understand LN, a payment can go through different payment channels to connect Bob and Alice. That means several people are involved. What if one person decides to close a channel, even though it will cost him money? Does that mean all connected channels also have to close?
No. Payments are not dependent on channels remaining open after the payment has completed (i.e. the HTLCs have been fulfilled).
1220  Alternate cryptocurrencies / Altcoin Discussion / Re: Segwit2X - (Gold Fork) Date on: October 19, 2017, 03:33:01 AM
Segwit2x and Bitcoin Gold are two completely different things.

Both are hard forks and they are set to activate by block height. Because they are activating by block height, predicting the actual time of activation is somewhat difficult. There is no pre-announced date of fork because that date is not concrete.

Bitcoin Gold will fork at block 491407.

Segwit2x will fork at block 494784.
Pages: « 1 ... 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 [61] 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 ... 551 »
Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!