|
You won't get the same addresses since Armory does not use BIP 32.
|
|
|
|
i want to ask something about pruning, how much time can pass before i need to resync again after pruning with a wallet?, what i mean is, if i have two wallet, and i sync first with both of them, then i do pruning with one, let's say the main one, and i prune the other again after one month, do i need to resync again?
That is not how pruning works. Pruning is not wallet specific. You will probably need to resync when you switch wallets, but I think it is dependent on how many days of blocks are kept when you pruned. |
|
|
|
|
New wallets are HD by default. You cannot convert a non-HD wallet to an HD wallet.
You have to create the bitcoin.conf file by yourself. It isn't automatically generated.
|
|
|
|
What are the chances to ever hit the limit of generated addresses in an non HD wallet? i suppose the program tells you when you need a new wallet?
There is no address limit. You keep generating addresses forever. |
|
|
|
when we sign a message, we can retrieve the pubkey from the sig
Why the bitcoin does not use the same technique in tx signature?
so the transaction would be smaller because you wouldn't have to contain the pubkey
It has been briefly talked about before. The issue is the additional overhead required to do so. Someone could give you a bunch of invalid transactions so you need to spend a lot of computing power to get the pubkey and then check that that maps to the address. That could become a DoS attack. The current system does the low computational cost action first of hashing before the more intensive task of verifying. |
|
|
|
So the moment I receive the first SW transaction, I will need to upgrade the offline machine. OK, inconvenient but unavoidable, I'll do that when (if?) it looks like SW is about to activate.
You will only receive a segwit transaction if and only if your wallet is upgraded. Legacy wallets will not be able to receive segwit transactions because the way those transactions work is that you the receiver must tell the sender to send to a segwit script. Those segwit scripts are only created in the new wallets. |
|
|
|
Another good contribution to the system achow! So if I understood everything correctly,once a generated address receives the coins,the embedded function auto generates a new bitcoin address ? Awesome!
It actually pregenerates a list of 1000 addresses from an xpub or just takes the list that you enter and will get the first empty address from that list. With an xpub, it should generate another 1000 after the list runs out, with the entered list, it will go with the last address after after the list runs out. P.S : Might as well wanna update the form a little bit.
What's wrong with it? My crappy web design skills? |
|
|
|
instead its any previous 2016 blocks directly before the current newest block, as of the start date..
Technically not any previous 2016 blocks but rather the previous difficulty retarget period which is 2016 blocks. i picked 440,000 as a number .. but stupidly devs chose to use a unix timestamp as the start point (i laughed)
when counting blocks a rational thing would be to use a blockheight as a starting point. afterall timestamps are useless in most cases
The timestamps are a bit weird but it still makes some sense given the blocks contain a timestamp and that predicting what block number will be exactly one year from now is pretty hard to do because of block time variation. Although I do agree that having a set block height start time would be better. |
|
|
|
|
Try deleting everything in the data directory except for the wallet.dat file.
|
|
|
|
Could you tell some reasons advantage of not address for donations. Since the address is publicly visible anyway.... what privacy benefits are we getting here
First, not everyone will actually know your donation addresses unless they are checking it every single second. Otherwise they could in theory miss when someone donates to you. Thus it will be impossible to know how much money you have actually made off of donations, which helps with privacy. Secondly, avoiding address reuse helps with protecting against quantum computers and any potential vulnerabilities with ECDSA where the private key could be extracted from the public key. |
|
|
|
I had to reinstall my windows, and no am I trying to install my Bitcoin Core. First, I wonder why there is 2 shortcut, Bitcoin Core and Bitcoin Core (testnet)?
This was recently added. Just ignore the testnet shortcut, you probably won't need it. I have problem to start up my wallet. Got this error:
:30 Misbehaving: 54.186.37.39:8333 (66113000 -> 66113100)
2016-10-28 10:41:31 ERROR: ConnectBlock: Consensus::CheckBlock: bad-txnmrklroot, hashMerkleRoot mismatch (code 16)
2016-10-28 10:41:31 ERROR: ConnectTip(): ConnectBlock 00000000000003f0c8eb69f33b0899e96d87065c0c3c674f5af8ec8c0b48d541 failed
2016-10-28 10:41:31 ERROR: ConnectBlock: Consensus::CheckBlock: bad-txnmrklroot, hashMerkleRoot mismatch (code 16)
2016-10-28 10:41:31 ERROR: ConnectTip(): ConnectBlock 00000000000003f0c8eb69f33b0899e96d87065c0c3c674f5af8ec8c0b48d541 failed
This is after I used my wallet back up.
Anyone know what to do to fix it?
You have a corrupt block. The easiest solution is to delete the entire "blocks" folder inside of the Bitcoin Core data directory and then let Bitcoin Core resync the whole blockchain. |
|
|
|
Thank you for the timely reply and explanation. It's helping me understand a bit more though it is still a challenge for me to comprehend the intricacies of coding. I'm just a plain ol' user.
When I run ArmoryQt with the shortcut arg (specifying Bitcoin and Armory alternative/non-standard database directory paths) after starting and syncing Bitcoin Core 0.13.1 (not managed by ArmoryQt), the client opens with the ArmoryDB CLI dialog and does nothing else after the third line:
...and of course, ArmoryQt consequently gets stuck at this point without any progress...and offline:
Can you post the log files? Though I don't think it's related to my particular issue, I'm curious as to why there is a "slash" (/) instead of a "backslash" (\) between "Roaming" and "Armory" on the first line of the CLI dialog (directory path).
That shouldn't matter. The backslash and forward slash are treated the same. From what I can surmise, perhaps the ArmoryQt shortcut arg (directory locations) is not being passed on when it automatically spawns an instance of ArmoryDB, thereby not finding the specified database directories. It's most likely a far-fetched assumption on my part but if it is so, can you suggest a workaround?
I doubt it. Just out of curiosity, was there a reason/purpose of the binary split since it was working just fine up to 0.94.1?
The main reason is to make the litenode feature work. Litenode is where you run the client remotely and have it connect to an ArmoryDB instance on another machine. I think the idea is to shift Armory towards an Electrum-like architecture where you have clients and servers. |
|
|
|
Armory 0.95 is not working for me. Due to some changes in 0.95 (e.g. Client and Database split), I assume that my arg in my ArmoryQt shortcut target which is set to point to alternate database directories for both Bitcoin Core and Armory is no longer valid (it was working just fine with 0.94.1). What do I have to do to get 0.95 working without changing my current alternate Bitcoin Core and Armory database locations/directories.
This is my current Armory shortcut target arg that worked quite well with 0.94.1:
"C:\Program Files (x86)\Armory\ArmoryQt.exe" --satoshi-datadir="D:\Bitcoin" --datadir="D:\Armory"
That should be fine. What is probably broken is the fact that goatpig forgot to include guardian.exe which is what spawns the bitcoind when Armory is set to auto manage it. Also, on the btcarmory site under "Notable Changes", it says:
"Client no longer requires a local Bitcoin node to operate as P2P has moved to ArmoryDB"
...while under "Full changelog/Added", it also states:
"ArmoryDB requires the presence of a bitcoin node on localhost:8333 and access to raw blockchain data like before".
I'm confused. Do I still or do I not have to manually fire up and sync Bitcoin core 0.13.1 before running Armory 0.95 as I did before with Armory 0.94.1? I'm running W7 x64 BTW.
Sorry for my cluelessness as I am very coding-illiterate.
There are two parts, the DB (ArmoryDB) and the client (ArmoryQt). ArmoryDB requires a local Bitcoind. ArmoryQt can connect to any instance of ArmoryDB, both remote and local. That does not require a local bitcoind. ArmoryQt will automatically spawn an instance of ArmoryDB of it does not detect one locally and a remote one is not specified. Thus, if you are just running ArmoryQt without doing anything to ArmoryDB, then you will still need to run Bitcoin Core locally. tl;dr yes you still need Bitcoin Core locally. |
|
|
|
|
There is no "Bitcoin data structure". In fact, there is no such object as a "Bitcoin".
What you are talking about are multiple data structures, each one with different properties. There are the blockchain, blocks, transactions, and transaction outputs.
|
|
|
|
|
Try commenting out (with a # in front of the lines) those lines in the bitcoin.conf and see if it will work then.
|
|
|
|
|
Due to the block serialization changes introduced in Segwit, any version earlier than 0.95.0 will not work with Bitcoin Core 0.13.1+ after Segwit activates.
|
|
|
|
No such luck. I even tried reindexing my Bitcoin database and then ran ArmoryDB. ArmoryQT in debug mode spams out... (DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception
(DEBUG) SDM.pyc:794 - generic jsonrpc exception Armory 0.93.3 and 0.94.1 work fine, but not 0.95.0 That error is due to it being unable to connect to Bitcoin Core's RPC server. What version of Bitcoin Core are you using? What is inside of the bitcoin.conf file? |
|
|
|
abandon trasaction is greyed out, i cant click it
Then start Bitcoin Core with the -zapwallettxes option. See https://achow101.com/2016/07/Bitcoin-Core-Troubleshooting#option-startup for help with that. With Bitcoin Core, you can right click the transaction in the list and choose "Abandon transaction". Then send your Bitcoin again with a higher fee.
How do you know the new transaction will use the same inputs? If it doesn't use the same inputs then it isn't a double spend. IIRC Coin selection is fairly deterministic. Given the same set of UTXOs and the same outputs, it should be choosing the same UTXOs as inputs. Increasing the fee should not affect that too much unless dust UTXOs are being spent. |
|
|
|
It might be an idea to mention to MacOS/OSX users: support for 10.7 is dropped in 0.13.1 and 0.13, this has only just been established I think. 10.8 is now the minimum OS version for Macintosh users.
It's right there under "Compatibility". The last paragraph. |
|
|
|
|
Show Posts
