This thread has become a place for spammers to spam exactly the same thing, so it is being locked.
|
|
|
It doesn't make a difference. It is not the number of addresses that increases the UTXO set, it's the number of UTXOs. Creating a change output, regardless of the address associated with the output, creates one more UTXO which is added to the UTXO set.
On a technical level, there is no such thing as an address. Bitcoin does not use addresses, it uses UTXOs. Addresses only tell wallet software what type of transaction output it should create and the data that goes inside of it. It does not matter whether you have received 100 UTXOs at one address or 100 UTXOs at 100 addresses, it is still 100 UTXOs which are exactly the same size and it is still an additional 100 UTXOs added to the UTXO set.
What would help with UTXO set growth is to have better coin selection algorithms which more favor consuming lots of UTXOs and creating fewer outputs, i.e. algorithms which avoid the creation of change outputs.
|
|
|
Is there any compression used in blocks in their native format?
No, and there is not much that can be compressed. Most of the data in Bitcoin is pseudorandom so it compression algorithms can't compress it that much.
|
|
|
You can't use 0.96.3 with Core 0.15.0.1. Use 0.96.4 RC1 or downgrade Core.
0.96.3 includes the incompatibility fix required for 0.15.0.1, so it can be used.
|
|
|
Does receiving multiple times to the same address reduce the tx size when sending money from that address? I assume not, because transactions refer to other txes rather than addresses. But maybe there are still opportunities to optimize something away?
No, it does not. On a technical level, addresses do not exist. What exists are transaction outputs. Receiving 100 times with 100 transaction outputs associated with the same address is no different from receiving 100 times with 100 transaction outputs all associated with 100 different addresses. When you spend those 100 outputs, the fee will be the same regardless of which addresses you used.
|
|
|
So a non-listening node will forward blocks? Even if the user hasn't opened the port?
Yes. Listening and non-listening nodes do exactly the same thing. They still send and receive blocks and transactions from their peers and will relay blocks and transactions to their peers. The only difference is that listening nodes allow other nodes to make the connection to it. The name inboud only means that someone else initiated the connection. The name outbound only means that you initiated the connection. Otherwise both connection types are exactly the same and the nodes do exactly the same things with both connection types.
|
|
|
Post your entire debug.log file. It is likely that you will need to reindex and possibly redownload the blockchain.
|
|
|
Knowing how to write C++ (main codebase) and Python (test framework) is almost a requirement to contribute to Bitcoin Core. At the very least you need to be able to read C++. Even if you can't write C++, if you can read it, you can still contribute by writing documentation. A good place to start is to first understand how Bitcoin work's conceptually. Then go through the open issues list: https://github.com/bitcoin/bitcoin/issues and find things that you think you would be able to do and that you think are interesting. Some of the things that we consider to be easier are labeled as "good first issue".
|
|
|
The software is incredibly large and complicated. Writing a walkthrough would require much too much time for very little reward. Instead of asking an extremely broad question, you should instead start at the entry point of the program and follow the code yourself. Ask specific questions when you don't understand anything, not ask super broad generic questions. The entry point of bitcoind is here: https://github.com/bitcoin/bitcoin/blob/master/src/bitcoind.cpp#L188
|
|
|
It looks like bitcoind was unable to write to the file blk01001.dat in the blocks folder inside of your datadir. Make sure that you have enough disk space and that the user bitcoind is running under has permission to write to that file.
|
|
|
Are you asking for someone to do this for you or are you asking how you should go about doing this?
|
|
|
Your questions are extremely broad. There are thousands of functions in Electrum's source code, we can't possibly explain what they all do to you, that is just too much time with little reward. Start from the program entry point: https://github.com/spesmilo/electrum/blob/master/electrum and read through it. If you have questions about how something works, ask a specific question, not a super general "explain everything to me" question.
|
|
|
This thread has been derailed for quite a while now so I will be locking it.
|
|
|
Is it correct saying that on the 1st August BTC was upgraded to segwit1x and the split off chain known as Bitcoin cash was given a 2mb increase to its block size (but didn't get the segwit1x upgrade)?
No, that is not correct. Segwit (not segwit1x, whatever that means, nor segwit2x) activated on August 24th. Bitcoin Cash forked from Bitcoin on August 1st and increased its block size to 8 MB. Also for the coming November fork is it correct that BTC which now has segwit1x will not change and the split off coin B2x (or whatever it will be called) will be given the segwit2x upgrade? So B2x would now have the extra space on the block given by segwit1x and also increase to a 2mb block size given by segwit2x.
That is partially correct. B2X, is activating the Segwit2x idea which doubles the block size. The maximum block size for segwit2x is actually 8 MB as Segwit already increased the maximum block size to 4 MB.
|
|
|
Use multiple terminals and remove daemon=1 from your bitcoin.conf file. When bitcoind crashes (probably a segmentation fault), the error will be printed to the terminal that it is running in. With daemon=1, we won't be able to see what that error is.
Also, did you compile this yourself? If you did, what exactly were the commands that you ran? If you did, did you make any changes to the code, and if so, what were they?
|
|
|
This thread is attracting a lot of spam and a lot of people are apparently incapable of reading the OP's question which is in the post not the title, I am locking this thread.
|
|
|
This thread is just becoming a place for people to spam without reading the thread.
Locked.
|
|
|
But isn't this the case with the block files too?
If I opened Bitcoin Core client today and synced it, and I tried to access Bitcoin Cash with the Bitcoin ABC client and I put the blocks folder there in the ABC folder, my blocks would have newer blocks that never happened in the Bitcoin Cash chain.
So I open ABC with these block files and it reaches past the day of the fork... what happens with the existing block files that don't correspond to the BCash chain? It just starts downloading and they get overwritten?
They are validated and ignored. The files are not deleted, they just remain there taking up space. Bitcoin ABC would ignore those blocks (it will validate them, remember their location on disk, and remember their validation status) and continue with download the Bitcoin Cash chain. Because you don't provide the chainstate databases, it will build the chainstate from scratch by going through all of the block files. Why is this different with the chainstate files.
The chainstate files are for the databases which contain the UTXO set and the validation statuses of every block and the current state of the known blockchain. However when you switch to a different blockchain with the same chainstate database, you may confuse the software because it thinks the blockchain it has is valid (that's what the database says) when it is actually invalid to the software. This could cause lots of problems.
|
|
|
Is there any way to run it on a Cheap VPS? 200GB is much...
You can certainly run Bitcoin Core without using 200 GB of disk space. However Bitcoin Core will likely need more computing power than a cheap VPS can provide. I dont want to ruin my 40/2 connection. Is there Any way to throttle the outgoing internet for this node on a rasp PI?
Yes, read https://bitcoin.org/en/full-node#reduce-traffic
|
|
|
|