Now though when I run bitcoin-qt everything is as it should be for approx 40-50 min's until it crashes. I could probably even send the little bitcoin I have in that wallet out to somewhere else if the mining fee wasn't as high as it is. But then again I wonder what might happen if that transaction didn't confirm within the 40-50 min window before my node crashed again. But other than that it syncs up and then connects to approx 8 inbounds and 8 outbound peers at the beginning, shows my balance and runs properly for about 45mins then gives the fatal internal error. The wallet dat file is encrypted but is in the bitcoin folder and I have checked that my user has read and write access.
So the wallet is from your local computer and not the 21 raspi? If so, the raspi is completely irrelevant to this discussion. I read back thru the debug file to the 7th of this month which I believe is when I tried to connect the 21 pi and found a line in there that said "possible stale tip detected" I'm not sure what that means
It means nothing. That error is benign. but it occurs to me that I only put a days worth of the debug log file in the Pastebin would it be more helpful if I loaded more of the debug file?
Yes. |
|
|
|
Very nice. Do you have a screenshot that shows how different wallets will be managed? I mean how the GUI will look like? im curious about that since im used to always using the same wallet with Core. How will the different wallet files be managed? I mean how the filenames will look like if they are all on the same folder? wallet001.dat, wallet.002.dat... or something?
There are no different wallets or wallet files. If you use Bitcoin Core 0.16+, your wallet will automatically begin using segwit unless you tell it not to by setting the addresstype option to legacy. |
|
|
|
This topic has been moved to Trashcan. Insubstantial and low effort |
|
|
|
|
It will sync faster and have less disk I/O if you increase the dbcache. This requires more RAM though. Raising the dbcache to anything larger than 8000 MB (-dbcache=8000 is large enough to store the whole thing in memory and then flush right at the end so there's significantly less disk I/O then. Of course you will need plenty of RAM in order to set the dbcache to that high.
|
|
|
|
I can work with I have, but would rather have it working on my windows 10 machine since that is where my Armory wallet is running.
I then went over to my windows 10 machine and tried btcpp-cli-win64 and this is the error I got:
btcpp-cli-win64.exe - Bad Image
C:\Users\@@@@@@\AppData\Local\Temp\_MEI77402\VCRUNTIME140.dll
is either not designed to run on Windows or it cointains an error. Try
installing the program again using the original installation media or contact your system administrator or the software vendor or support.
Error Status 0xc000000d
Try installing the Visual C++ Redistributable available here: https://www.microsoft.com/en-us/download/details.aspx?id=52685. That should hopefully add the VCRUNTIME140.dll it wants to your system. |
|
|
|
Some people are asking for Gemini do this. And I see that is not so common. I know that batching transaction will be slower. But there are other problems for exchanges do this? Is there any risk?
It's mostly just slightly harder to implement. There's also a privacy risk because the receivers in that batch can see how much money everyone else in the batch is withdrawing, but they don't really know who those people are, so that's not much of an issue. |
|
|
|
Error: could not find paymentrequest_pb2.py. Create it with 'protoc --proto_path
=./ --python_out=./ paymentrequest.proto'
Oops, I screwed up the build. I uploaded new builds (replacing the old ones), try those. |
|
|
|
The thing is, I don't feel confident using segwit until at least May when Core will release 0.16
Bitcoin Core 0.16.0 will be released sooner than May. It will probably be released in February as we are already in the feature freeze stage since the segwit wallet PR has already been merged. |
|
|
|
|
Please use Google and read one of the other billion threads about quantum computing and Bitcoin.
|
|
|
|
Oh ok, but how do I tell my wallet software?  What wallet software are you using?  |
|
|
|
I downloaded btcpp-cli-win64 this time. Norton didn't like and removed, so restored and gave it trust in file insight. Double clicked it and launched fine. Created invoice for bitpay, and on invoice clicked copy to reveal the uri. Copied uri from invoice, but wouldn't let me paste into the tool---so typed it. When i hit enter the tool closed.
That is the furthest i've gotten on any of my attempts. I didn't get error msg, or crash report, but if you tell me where to look, i'll find it then post.
Open up a command prompt or powershell in the folder containing btcpp-cli-win64 (with nothing in the folder selected, hold shift then right click, choose "Open command prompt" or "Open powershell"). Type btcpp-cli-win64 to run the program from there. Follow the instructions, and if it fails, post the output. There should be a python traceback if it fails. |
|
|
|
I'm on my windows 7, I downloaded btcpp-qt-win64, I went to norton file insight and trusted it and double clicked to launch. rather than opening, it hung and i got the windows message to close program or look online for solution. I didn't get the error message like i had been, but here are the details from crash report:
Problem signature:
Problem Event Name: APPCRASH
Application Name: btcpp-qt-win64.exe
Application Version: 0.0.0.0
Application Timestamp: 5a2e9fe6
Fault Module Name: Qt5Core.dll
Fault Module Version: 5.9.3.0
Fault Module Timestamp: 5a0c7e9d
Exception Code: c0000005
Exception Offset: 00031c31
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Strange. Are you able to use the command line version? |
|
|
|
 Here. I mistakenly selected TREZOR and at the botom wre displayed trezor addresses and I put all my tokens in TREZOR adress, instead I should click the LEDGER and deposit in Ledger addresses. And now cant withdraw them...do you know how? Those are not TREZOR addresses but rather addresses using a derivation path that is default for the TREZOR. Since it is just a derivation path, your ledger can sign for those keys. You just need to tell your wallet software that you are using a Ledger and that the derivation path is m/44'/61'/0'/0 instead of the Ledger default. |
|
|
|
|
What do you mean by "created trezor address with ledger nano s"? Do you mean you imported your trezor seed onto the ledger? Or do you mean something else? How did you do this?
|
|
|
|
|
createmultisig does not add the address to your wallet. So the multisig address is not part of your wallet and thus not listed in listunspent.
To add it to your wallet, you need to use addmultisigaddress.
|
|
|
|
|
What do you mean by "making electrum/core segwit compliant"? Do you mean how to make a segwit wallet with these software?
|
|
|
|
I'm only guessing, but so far the only thing I can think of is when I tried to hook up the 21 ras pi that is where the driver power state failure happened and the blue screen from that event is what might have? caused the corruption of the files or just the wallet data?
If you pulled the power from the raspi and then took the wallet file off of it afterwards, that could have caused it to become corrupted as the database is still open and there are other files that you need when the wallet database is still open. Have you tried just powering on the raspi again and seeing if you can access the wallet there? |
|
|
|
double clicked to launch, starts to open then closes with message saying missing .dll file.
What .dll file does it say is missing? |
|
|
|
I was hoping that some developer would want to work on failure modes. Look for root causes of bugs. But nobody seems interested.
The root causes are usually out of our hands. In many cases it is hardware failure. Bitcoin Core does a lot of disk I/O and uses quite a bit of memory and processing power. So often times hardware issues (typically in memory issues or disk issues) are the root cause of such problems. I suggest that you run some hardware diagnostics on your machine and see if anything turns up. |
|
|
|
The data in these "Block.dat" files is not raw text anymore
It never was in the first place. but it seems like i need to read the files using
Berkeley-DB format which does not compile for me so does anyone know where I can download a Berkeley-DB Dll that
will work in VS .Net or any short cuts using .NET file streams
I think Berkeley-DB for the file format has been dumped and they now use LevelDB that is something
that Google started but getting a copy that will compile and works in MS-Dot.Net is no easy task
The blk*.dat and rev*.dat files - the files that actually contain the block data - are not database files. They are just files with the raw blocks dumped into them. You don't need BDB or LevelDB in order to read them. Those databases are stored separately. The format of the blk*.dat files is network magic (4 bytes) followed by length of the block in bytes (4 byte unsigned integer) followed by the block itself serialized in network format. This repeats until the file reaches a certain size. Then the next numbered file is used. |
|
|
|
|
Show Posts
