|
Why did you use BItcoin Core 0.8? Everything that is in 0.8 is available in the most recent release of Bitcoin Core (and the master branch). You should use those instead. Those also include things such as better cross compilation, increased performance, and many security and bug fixes.
|
|
|
|
I was not here for long time. I hope bitcoincore.org is not just another scam site
Bitcoincore.org is Bitcoin Core's official site. W're moving away from using bitcoin.org for Bitcoin Core. You can check that SHA256SUMS.asc is signed with Wladimir's release key which can be found here, here, and here (it's the same key in 3 difference places). Also bitcoincore.org is stated as the new Bitcoin Core website on bitcoin.org's Bitcoin Core page. Will try Bitcoin Core 0.16.0 Research Chemical 3
RC stands for Release Candidate  |
|
|
|
Can I send bitcoins from a standard wallet (starting with 1, i.e: 1dr4Jindendl....) to a SegWith address starting with bc1?
Yes. If yes, can I do it on electrum?
Yes. |
|
|
|
Your wallet is corrupted, kind of. I have seen this behavior before in other wallets and, if the problem is what I think it is, it has been fixed in Bitcoin Core 0.16.0. Try using Bitcoin Core 0.16.0rc3 available from here: https://bitcoincore.org/bin/bitcoin-core-0.16.0/test.rc3/
If this does not work, make a backup of your wallet and try starting Bitcoin Core with the -salvagewallet option. |
|
|
|
If I understand correctly, I didn't even need to mess with the sbtc core wallet. I should just be able to convert into legacy priv keys and do the job with those.
No, "legacy" private keys will correspond to non-segwit addresses. You will need to convert the non-segwit address into a segwit address. You can use the sbtc core wallet and use the addwitnessaddress command once you import the WIF private key. |
|
|
|
@achow101 Thanks, How are wallets actually loaded into memory? if the wallet.dat file is ~1.5M will the entire file be loaded into process memory (will that take ~1.5M in memory)?
All of the wallet data is read off disk and loaded into memory at start. So if your wallet is ~1.5 MB, then it should consume ~1.5 MB of memory. It won't. |
|
|
|
Is there anyway to use the same blocks or block files for other every coin that has a QT wallet?
There is a way using symbolic links, but I wouldn't recommend it as it will likely just corrupt your block files. So in practice, there isn't. All you an do is copy and paste the data directory. When you do that, you have to make sure that the data directory you copy does not have blocks that would be invalid to the forked coin, i.e. there are no blocks after the forking point. |
|
|
|
This topic has been moved to Trashcan. Duplicate |
|
|
|
I would like to disagree with you but I found in the past that the "Ban" button comes in to play so best not to say anything
that might upset the moderator.
Feel free to disagree. I'm fine with having a discussion. But its not okay when the discussion turns from actually talking about a topic constructively to trolling, mudslinging, and flaming. |
|
|
|
|
There's technically no limit, but of course you do have memory limits, so at some point you will run out of memory if you load too many wallets.
|
|
|
|
|
Please post the full debug.log file.
|
|
|
|
|
The biggest differences are related to syncing performance, which is going to be significantly worse for you with address indexing enabled. There were also some database changes but that's not really a problem for you.
|
|
|
|
So, if I manually establish connections to other nodes, a properly working configuration should remember those prior-connected nodes, and reconnect on restart ?
Even if the connects are unfunded ?
It should. |
|
|
|
I know. but unfortunately I was looking for an immediate solution, since the new wallet features are not yet implemented.
No such immediate solution exists. Finally, do you by chance know of any other full node server alternatives other than Bitcoin Core that supports full node and multi-wallets with RPC? (I was hoping for a similar full node like ethereum geth where I can create separate independent (encrypted) accounts/wallets)
You can try btcd. I don't know if they support the functionality that you want, but it is a full node. Was this idea abandoned back in 2012 and now re-implemented (maybe?)
Most of the functions in that PR are being reimplemented or have been reimplemented. |
|
|
|
I think it would be best, if wallets like Electrum calculate 2 fees by default. One for sending the money as fast as possible and another to send the money within 24 hours.
Not all people needs to send their money right away, so the option is needed. And if more people use this option transaction fees would fall. If the average transaction fee lowers, fees for fast transactions will also fall as a result.
Fee estimators do that. Most of them (including Electrum and Bitcoin Core) have some option to let you select different speeds. |
|
|
|
|
Those files were split into validation.{cpp, h} and net_processing.{cpp, h}.
For lines that you have to change, many of them still exist just in different places. So you can use grep to search for them.
|
|
|
|
How do I see a list of already generated addresses,
There should be a command for (I don't remember what it is). You can list commands using the help command. where is this data stored ?
Also, what happens when I fund a channel, and lightningd crashes ? Are the funds gone ? Does it remember I had the channel open and funded ?
Finally, when I manually connect to servers using the cli, is there any way to have it remember them when I relaunch lightningd ? Sorta plays into the hesitation of losing funds if it crashes; is it not supposed to remember prior connections ?
It has its own data directory where there is a database file. All of that information is stored in the database and will be loaded next time you start so that everything persists between restarts. |
|
|
|
|
Addresses cannot be deleted; in fact on a technical level, there are no addresses.
What that chart shows is how many unique addresses contains coins. Recently many people have been moving their coins to segwit wallets which means that they are consolidating their coins into fewer addresses. Furthermore, many people have been doing such consolidations to avoid paying higher fees in the future.
|
|
|
|
It's that Core's fee estimation (like Electrum) is bad.
Compared to other fee estimators, it's very good. Note that Electrum basically uses Core's fee estimation (the estimation from the Electrum servers which use Core as the backend). Which leads me back to square one: How are people estimating their fees with Segwit? There's gotta be a better way.
Many people look at fee information charts like https://dedi.jochen-hoenicke.de/queue/#24h and choose a fee rate based on what outbids most transactions. Unfortunately this kind of pattern seeing and the processes that the human brain does in order to make such a decision is hard to do algorithmically. Note that just doing that in software is actually very gameable and ignores a ton of other information that helps make a better fee rate prediction. |
|
|
|
|
Show Posts
