the password has changed.
What do you mean the password has changed? You changed it? or the wallet is not accepting it?  the -reindex option does not alter the password. It simply throws away the chainstate and the block index and rebuilds it all from scratch by re-indexing the blocks already on your disk. |
|
|
|
[But why? Even if it takes days to get confirmed why is it forbidden by nodes?
To go back to this point... and a quick "history" lesson. The concept of "dust" and the resulting implementation of the "minDustRelayFee" was to prevent 'spam'... there was an instance back in the day where the network was "attacked" (some say 'tested'  ) by someone sending vast amounts of very very very small transactions. Think about it... if you wanted to "DoS" Bitcoin, what better way than to flood the network with 100000's of transactions... which would cost you next to nothing if you could send just 1 sat, and use something less than 1 sat/byte. Thus the minimums were set. Yes... currently it's 546 sats. It's (148+34)*3=546 sats for legacy transactions. For segwit it's (67+31)*3=294 sats. https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L16[/quote] SegWit... making nice and easy explanations "difficult" since 2017  Seriously tho, thanks for expanding on my quick and dirty explanation... I think it is an important point that SegWit has more benefits than just "smaller fees"  |
|
|
|
OmegaStarScream is correct... Here is my original (unconfirmed) transactions:  Bumping the fee with the "final" box checked, it marks the transaction as "RBF: False":  But if I leave the box empty, it marks the transaction as "RBF: True":  |
|
|
|
Wait, what dust outputs means? Too few bitcoins?
Yes... currently it's 546 sats. The vast majority of nodes will reject any transaction that creates an output that is less than this amount. That includes "change" outputs! Oh, no I didn't know that. Can't you sign messages with wallets?
Yes, have a look under "Tools -> Sign/verify Message"... Note that this doesn't involve creating or sending a transaction. It's just digitally signing a given message with a given address. |
|
|
|
For the Ledger no... you basically just need to go into the Settings in "Ledger Live" and enable "Developer Options"... Click the "cog" in the top right corner:  Click on "Experimental Features":  Then turn on "Developer mode":  Once you've done that, you should be able to see BTC Testnet in the Manager:  Install the App on your device and you'll then be able to create a BTC Testnet account within Ledger Live. From there, it basically works the same as any other Ledger account, so you can get your receive address and then hit up a Testnet faucet to get a small amount of tBTC (or hit me up ) |
|
|
|
¯\_(ツ)_/¯ Did you try PMing the OP to see what they had to say about it? In any case, unless something magical happens in the next 24 hours, like a €2000 increase in price, I don't think your prediction is going to be close... much like mine!  |
|
|
|
I've heard that older versions of Electrum's HD wallets allowed importing of private keys. Does anyone recall what version of Electrum discontinued the ability to import private keys into an HD wallet?
Not 100% sure on that... doesn't seem to be anything specific regarding this in the historical release notes... But, I believe that the last version that supported importing private keys into a "HD" wallet was 1.9.8... so it was when the upgrade to version 2.0 happened that the ability to import keys to an HD wallet was removed. |
|
|
|
Yes, this is why you need to think in terms of fee rate... not total fee amount... I'll use a somewhat extreme example to illustrate: TransactionA: 50,000 byte transaction that pays 1 sat/byte = 50,000 sats to the miner in fees TransactionB: 226 byte transaction that pays 100 sat/byte = 22,600 sats to the miner in fees Now, you might think, well obviously take the 50,000 sats! But theoretically, you could fit another 220 of the smaller transactions in the same "space" in your block... and then you would get: 221 * 22600 = 4,994,600 sats!!?! So, when you have a lot of transactions to choose from, it is (generally) the fee rate that makes the difference as to whether or not a transaction will be prioritised. Obviously, if you don't have many transactions to choose from, the fee rate becomes less of an issue, which is why when there are not a lot of unconfirmed transactions and they can all fit, the miners will just include everything to get as much fee value as they can! |
|
|
|
I'm not sure where that logfile has come from... but it is showing an old, outdated version of Armory... running on Windows: 2020-01-02 09:28:19 (INFO) -- ArmoryUtils.pyc:1271 - Armory Version : 0.96.3
2020-01-02 09:28:19 (INFO) -- ArmoryUtils.pyc:1272 - Armory Build: : 2b65ac0648
2020-01-02 09:28:19 (INFO) -- ArmoryUtils.pyc:1273 - PyBtcWallet Version : 1.35
2020-01-02 09:28:19 (INFO) -- ArmoryUtils.pyc:1274 - Detected Operating system: Windows
2020-01-02 09:28:19 (INFO) -- ArmoryUtils.pyc:1275 - OS Variant : 7-6.1.7601-SP1-Multiprocessor Free
But you say you're now running on Linux? So, I don't think these logfiles are at all relevant to your current issue. So, pathing, the perennial bugaboo of Armory support; I have both core and Armory pointed to an alternate location, /media/BITCORE/ but both seem to still write some data to /home/usr/.bitcoin and /home/usr/.armory. It appears that while Bitcoin Core is indeed using /media/BITCORE, your Armory install is NOT set to use this directory... and is writing to /home/usr/.armory 2020-05-12 17:09:11 (INFO) -- ArmoryQt.py:1891 - Setting satoshi datadir = /media/BITCORE/Blockchain
2020-05-12 17:09:11 (WARNING) -- SDM.py:402 - Spawning DB with command: ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/media/BITCORE/Blockchain/blocks" --satoshi-port=8333 --datadir="/home/stg/.armory/" --dbdir="/home/stg/.armory/databases"
2020-05-12 17:09:11 (INFO) -- ArmoryUtils.py:689 - Executing popen: ['ArmoryDB', '--db-type="DB_FULL"', '--cookie', '--satoshi-datadir="/media/BITCORE/Blockchain/blocks"', '--satoshi-port=8333', '--datadir="/home/stg/.armory/"', '--dbdir="/home/stg/.armory/databases"']
nuke DB...right...I remember something about that, of course that was on windows...hmmm
In Armory, Goto "Help -> Rebuild and Rescan Databases"... Click "Yes" and then shut down and restart Armory. |
|
|
|
I like that you're cautious... but it seems that you might have moved somewhat into "paranoia" territory! If you want to generate "single private keys" to create paper wallets, then DON'T use websites like bitaddress.org unless you are actually downloading the code and running it offline on an airgapped computer or "LiveOS". When dealing with "private keys" and trying to use/spend from them manually, you're more likely to lose funds, unless you are confident with how all this works. Instead, you're much better off letting a well known and popular (and preferably open source) software wallet like Electrum, create and manage your private keys for you. Once you gain a bit of experience with Bitcoin, then by all means, experiment with ways to securely generate private keys offline (flipping coins, rolling dice etc) and create/use paper wallets... but I certainly don't recommend that new users start out with paper wallets. There are a number of traps that can catch you out and lead to loss of funds... and not just through theft! |
|
|
|
Reffering to the OP the date you gived is completely pure speculation;
No. It's not. Did you try clicking the giant "I'm In" button that is in the OP? Prior to the competition closing (the page has now changed), but it previously said that your were predicting the price as at 15th May @ 12:00 GMT. Sadly, for whatever reason, possibly just a simple oversight... they didn't really make this super clear and obvious in the OP  Additionally, calling it "guess the bitcoin halving price" was somewhat misleading, given that the halving occurred several days ago, and the prediction date is still 1.5 days away |
|
|
|
Thank you again, sorry for this inquiry Ive just feeling excited when the product arrived and wanna know some details ahead, so when I try it, at least I do know the stuff to use it properly.
The best piece of advice I can give you, is to "play" with your hardware wallet before you commit funds to it. Get comfortable with generating a wallet, restoring a wallet, setting up a passphrase and/or secondary PIN, installing apps, uninstalling apps, using the seed check app to confirm you have the correct seed mnemonic etc... maybe even enable "developer mode" and install the Bitcoin Testnet app so you can test sending and receiving transactions without fear of losing any "real" money. If you do decide to try out testnet, hit me up for some tBTC (by PM) |
|
|
|
And so the 1st test begins:
Really going to be interesting to see how it all plays out. There are so many ideas about what has the biggest effect on speed/time when it comes to syncing... Personally, I run my Bitcoin Node on an old i5-3570k, with 8gigs RAM and the blocks live on an old HDD. I used to have ADSL2+ (would get 1.5MB/sec downloads on a good day)... now I have Fibre... I also recently migrated the "chainstate" folder to my SSD. I don't really have many issues aside from the looming prospect of running out of storage space Mind you, I haven't had to do a full sync from the genesis block in quite a while! |
|
|
|
Yeah, I had a few issues with Armory, Bitcoin Core and Windows 10. I believe the culprit is Windows 10. There is something funky going on behind the scenes with ports and processes that seems to cause issues. I spent ages trying to get "online" and then I had issues with it being "online" but unable to receive new block data etc. This current setup I use of not using .conf files, setting paths in the GUI and running Bitcoin Core GUI manually before starting Armory is the only "stable" combination I've been able to find! |
|
|
|
|
That's the Armorylog.txt and it looks fine. Nothing untoward showing there. Can you post the contents of the dbLog.txt?
|
|
|
|
|
Have you tried removing the armoryqt.conf and setting up your paths in the Armory GUI settings like I described in my post above? If so, what happened?
|
|
|
|
Is there a log entry when it finishes syncing and is on the current block?
Yeah... try searching for the first "UpdateTip:" record in the debug.log that says "progress=1.000000", after the node was started up. 2020-04-19T14:59:15Z UpdateTip: new best=000000000000000000058a121d528381db4b076ef68c30b769066f92bab1cd77 height=626706 version=0x20400000 log2_work=91.873412 tx=522195769 date='2020-04-19T14:14:27Z' progress=0.999981 cache=34.9MiB(256790txo) warning='65 of last 100 blocks have unexpected version'
2020-04-19T14:59:16Z UpdateTip: new best=0000000000000000000f07e447142f811d24c5c1784b23661ea28f2fe3ffcecc height=626707 version=0x20000000 log2_work=91.873432 tx=522197017 date='2020-04-19T14:15:40Z' progress=0.999981 cache=35.6MiB(262972txo) warning='64 of last 100 blocks have unexpected version'
2020-04-19T14:59:18Z UpdateTip: new best=00000000000000000005c9bb64ec93eaf645a027ee0c3e2c5e0653a374a5c782 height=626708 version=0x20000000 log2_work=91.873452 tx=522197418 date='2020-04-19T14:16:19Z' progress=0.999981 cache=36.3MiB(268132txo) warning='64 of last 100 blocks have unexpected version'
2020-04-19T14:59:19Z UpdateTip: new best=0000000000000000000ffd6e3f9cd137309333609a60045e0a27e18a2ad38947 height=626709 version=0x20000000 log2_work=91.873472 tx=522200472 date='2020-04-19T14:49:32Z' progress=0.999996 cache=37.2MiB(275481txo) warning='63 of last 100 blocks have unexpected version'
2020-04-19T15:00:46Z UpdateTip: new best=0000000000000000000ec003631af9681a550b0fa08cfbff8aef4832e51a63e4 height=626710 version=0x27ffe000 log2_work=91.873492 tx=522203095 date='2020-04-19T15:00:22Z' progress=1.000000 cache=38.0MiB(282765txo) warning='63 of last 100 blocks have unexpected version'
You can see that it was "fully synced" at 2020-04-19T15:00:46Z |
|
|
|
I find bitcoinfees.earn.com is generally pretty poor with their estimates... their "recommended" fees are usually grossly overestimated and much higher than really required. For instance... Bitcoinfees.earn.com is currently suggesting: "The fastest and cheapest transaction fee is currently 116 satoshis/byte, shown in green at the top."  I'd recommend using the 3rd graph here: https://jochen-hoenicke.de/queue/#0,24hCheck to see what the fee rates are around the 0.5mb-1mb level... and use that if you want "next block" type confirmation times... which would be around 50 sats/byte at the moment.  |
|
|
|
This last part is very interesting, Casa gives a small incentive for users to run a node. I don't know if that still exists, but it is worth checking.
Small is right... and also, the only way to sign up for that was by purchasing a Casa Node (essentially a RaspberryPi4 with a 1TB SSD and some custom OS on it)... at the "cheap" price of $399 annual subscription!!?! In return you can "make" 10,000 sats/week? |
|
|
|
|
Show Posts
