The transaction fee is not based upon the value that you are transacting, but rather on the size of the transaction in bytes. The size of the transaction in bytes is determined by the number of inputs you are spending and the number of outputs. If you have many small inputs, your transaction will be larger and thus you will be paying a higher transaction fee.

You can choose the transaction fee rate that Bitcoin Core uses from the GUI. Just click the "Choose" button next to the where it says "Transaction Fee" at the bottom of the send window.

If you go into the console tab, you will see a message from the server. This will usually include the user agent of the server you are connected to and that will tell you whether they are Bitcoin Core, UASF, BU, Bitcoin Classic, etc. If you do not see that there, then connect to one until you see a user agent that you like.

The safest thing to do is to use Bitcoin Core as it is a full node and gives you control over which chain you want to use (via the invalidateblock and reconsiderblock RPC commands).

It depends on your wallet software. If you are using Bitcoin Core, then you are fine.

If you don't spend your Bitcoin, no, there is no risk. Bitcoins at rest (i.e. remain unspent) are not at risk.

There are instructions for verifying the release signatures here: https://bitcointalk.org/index.php?topic=1588906.0

AFAIK, there is no write up of how pruning is implemented. You will have to look in the source code for that. Since manual pruning is now available via an RPC command, I would recommend that you start looking there to see what it does to prune: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/blockchain.cpp#L849

No.

Nothing. Many of the Core developers believe that both BIP 148 and Segwit2x will fail. In the event of a chain split, there will be an alert posted on bitcoin.org (there's going to be one anyways because of the possibility of a chain split) with instructions on how to make your node follow the chain you want it to follow. It's very easy to do by using the invalidateblock RPC command.

How did you make your wallet? IIRC that only happens if you create the wallet from imported addresses.

If your wallet is a watching only wallet, then your wallet does not contain any private keys. This means that you won't be able to send transactions or sign anything.

How did you create your wallet?

It looks like your node crashed while the database was still open so the database has been corrupted. Try starting Bitcoin Core with the -reindex option. Right click the shortcut you use to start Core and choose "Properties". Then in the box labeled "target", add -reindex (with a space between that and what is already in the box). Then click OK and double click the shortcut to run Core. When it is started, open up the properties dialog again and remove the -reindex so that you are not reindexing every time you start Core.

Post your debug.log file.

Pruning will be more taxing on your disk as it has to constantly read and write to the disk far more than without pruning. This is because it deletes things on the fly. That means that, for each block, it will need to additionally compute what blocks should be deleted, look up where the block is, delete it, and remove it from the database. That will use extra CPU, RAM, and disk IO as there are simply more things that Core is doing in order to prune.

There is only one lightning network, not a class of networks called lightning networks. The lightning network is specific design for a network of payment channels. Users open payment channels with other users (only 2 parties per channel) and can route payments to other people through channels that are already open.

No, nor is it a network of payment channels. Segwit is unrelated to payment channels.

No. Segwit does many things, but it does not actually decrease any space. It explicitly will increase the size of blocks.

First of all, segwit defines new output types. These output types put their signatures and any scripts in a new field in the transaction format known as the witness. This fixes the transaction malleability issue. Then segwit  redefines the metric for block size maximum to be something called the block weight. The block weight applies a "discount" to the witnesses. The effect of this is as if transactions with witnesses are smaller than their non-witness counterparts, so more transactions can fit in a block (note this is not actually what happens).

No. The deployment plan for segwit is that if 95% of the blocks in a 2016 block difficulty retarget period signal for segwit, then segwit will become locked in (a 2016 block grace period for everyone to upgrade) and then activate. Segwit is a soft fork so not everyone must upgrade.

On August 1st, BIP 148 (which was not written by the authors of segwit nor is it endorsed by them) will activate. What BIP 148 specifies is that all blocks after August 1st must signal for segwit, otherwise the block is invalid. This is also a soft fork as not all nodes must upgrade. However, all miners must upgrade in order to avoid a chain split. If miners do not upgrade, then there may be a chain split and then there will be two "bitcoins".

No. What happens to the marketcap and value of the "bitcoins" is completely unknown.

That will be decided if a chain split happens and if it persists. There is no plan for a chain split to happen.

That's incorrect. You would actually have to change a lot of code to change the default unit (at the very least, all of the display code, not necessarily consensus code). All values in Bitcoin are actually in satoshis, not BTC. This makes it so that we never have to deal with decimals, only integers. Only for display purposes (for us humans because big numbers are hard to understand) are things in BTC.

You clearly have not thought through all of the considerations involved in changing the block size. There is not just disk space considerations. You also have to consider that all nodes on the network need to download that block, check all of the transactions in it, and then broadcast it to their peers (so sending multiple hundreds of MB every ten minutes). I don't think many people have internet connections that provide enough bandwidth to allow them to download 100 MB of data (aka one block) in a reasonable amount of time (reasonable being on the order of a few hundred milliseconds since we're talking about computers here). Since block propagation time will likely increase, orphan rates will increase too as miners will have more time to mine a block at the same height as one that was already found.

Then there's the quadratic sighashing problem. A 1 MB block can take 30 seconds to validate because of the quadratic sighashing problem (also remember that, to a computer, seconds is a very long time). Since the problem is quadratic, just increasing the block size to 100 MB means that a block could take 30 * 100^2 seconds to validate, which is 300000 seconds, ~3 and a half days.

There are also several other considerations too like the time it takes to do the initial sync (which includes downloading the blockchain and then verifying all the blocks and transactions), the CPU and RAM resources required to process the block, etc. So if you think increasing the block size to 100 MB is a good idea, please, think again and actually consider everything that goes into sending, receiving, storing, and validating blocks, not just storing blocks on disk.

Please do not hijack other people's threads with your own question/issue. Make a new thread instead. I have split your post into a new thread for you.

---

Check that your router is forwarding post 8333 to the right IP address. It sounds like it is set to forward port 8333 to your laptop's IP address, not your Raspberry Pi's. The router does not automagically know which IP address it should forward a port to, so you must tell it.

The SHA256 of the file on virustotal matches that in the SHA256SUMS.asc file, so the download is legitimate. The executable is fine and safe. The detections on virustotal are false positives. Bitcoin Core is often flagged as a virus because it looks for a wallet.dat file (so usually considered a coin stealer) and it contains mining logic (so also considered a bitcoin miner). These are true, but are also integral to Bitcoin Core functioning properly; it is the software the makes the wallet.dat file that many viruses try to steal. It also contains logic for mining blocks, but this is only for testnet and regtest networks now. If you have verified that the sha256 of the file matches the sha256 in SHA256SUMS.asc and you have verified the PGP signature in SHA256SUMS.asc, then the file is safe and not a virus.

That is off topic for this forum. I don't know why, as I don't use litecoin. It would be better to ask that question in the altcoin section.

Update your source code to the latest version from litecoin's github repo and then build it.

If 6btb.com is the website which has your "personal deposit address", then that is the service that you are using. Since they are just a service, you do not have control over the spends from 1Eh6Me7Kvq3sxVd7AVMBU1vJHtgiw2TYQe (nor are you supposed to). The address belongs to the service, and if they need to send Bitcoin to someone, they may choose to spend the coins from that address. This does not mean that they are stealing your money; rather they have recorded your deposit in their internal database system and credited your account on their system. The Bitcoin now belongs to them, and they owe you the amount that you deposited. If you withdraw from the service, you will likely be paid from addresses which are not your "personal deposit address".

What wallet or service are you using?

The activation of BIP 91 itself could cause a chain split since it requires all blocks after it activates to signal for segwit. Since only 80% of the hashrate supports segwit2x, these is a possibility that the remaining 20% won't be signalling for segwit following BIP 91's activation and thus cause a chain fork (their blocks would be invalid without segwit signalling).

A couple of corrections

BIP 148 will activate SegWit by November, not necessarily in November.

Note that the split will possibly happen when the Median Time Past is after August 1st, so the split would likely happen ~1 hour after midnight UTC as the MTP is usually 1 hour behind real time.


You should also include information about Segwit2x which will activate segwit via BIP 91 and then hard fork 12960 blocks after Segwit is activated.

No, they are not different; they are the same. The "official" UASF binaries can be found here: https://github.com/UASF/bitcoin/releases (and these are the ones linked to from other places).