Approximately one month on from my last update and the bot has pretty much recovered from the previous loss... so, that's something:    Took just shy of 2 months to recover that one (loss was around the 24th May)... Still 0.01286123 BTC down (~34%) from when I started on "The Platform"™ (and ~0.075 BTC down (~75%) on my original 0.1 BTC "investment"!) I shall ignore the account some more and see what it looks like in another month or so when I remember about it after one too many beers   |
|
|
|
EDIT: tried a "normal" wallet, couldn't replicate the issue there either... It was either a glitch, something i did wrong, or it only happens with wallets with manually imported private keys...
I actually noticed this "bug" on 4.0.1, then upgraded to 4.0.2 and saw the exact same behaviour... That's why i opened this topic.
Very very odd. So, I tried with a wallet with imported keys and I still can't replicate it there either. Very strange... must be some little quirk with your setup/wallet that is causing it to happen??!?  The exclamation mark results in following error:
You can't put the exclamation in the actual value box any more... that's what the "max" button is for... but you can put the ! mark in the "Pay to" field after the address:  But I honestly don't think that is going to change anything for you with regards to this particular issue... as far as I can tell, using the "!" is functionally the same as clicking the "max" button |
|
|
|
Interestingly... I can't replicate this bug. I just tested it with 2 different wallets (one on mainnet, one on testnet) and set it up to send all the funds using the max. If I adjust the fee slider it doesn't create any new outputs... it still only has the one output??!?  Also, the "change" address that your wallet is generating is highlighted in "green"... which neans that it is a "receive" address doesn't it? Is that wallet a "standard" wallet with seed etc, or imported with private keys? |
|
|
|
As far as I'm aware, there was no 0.19.2... they went straight from 0.19.1 to 0.20.0. As for the error... does your Bitcoin Core instance currently have transactions that you're created using your SegWit address(es)? If so, that might be screwing things up... |
|
|
|
As far as I can see, your copper membership is showing up just fine:   The system probably needed you to make at least one post for it to update your stats or something... |
|
|
|
I would say that the actual root cause of all of these "Newbies can't..." views, is the very erroneous view that this forum is a money-making/get rich quick opportunity... Users sign up here thinking they will make "Easy $$$"™ by joining up to campaigns and making a few posts/tweets etc... only to find that newbies can't join campaigns... and then they discover they need "merit". Suddenly, they realise that their "Easy $$$"™ quest has turned into an "arduous" ordeal to try and get 1 merit point.  And then the inevitable "It's impossible for Newbies to get merit/rank up" type thoughts and posts start. |
|
|
|
No issues here using Mycelium on Android 10 on a Nokia 7 plus or on an old Google Nexus 7 Tablet using Lineage OS. What device/android version were you attempting to connect with? "No Server Connection" and the associated issues syncing transactions/0 balance seems to have been an ongoing issue with Mycelium for quite a long time now. I'm wondering if it is just a problem with their backend server infrastructure not being able to service all the requests and so people end up being unable to connect/sync? The fact you were still having issues with when using different networks (with VPN/TOR etc) means that we can probably rule out some sort of filtering/network blocking... |
|
|
|
Sounds like a simple file permission issue... likely related to C:\ being somewhat protected by the system or possibly antivirus/antimalware programs getting jumpy about .dlls being placed on the system drive... Did you initially run the installer with admin privileges? |
|
|
|
Why did they release such a version without having significant test?
The thing is... the software was tested! It's just that no "good people"™ saw the potential of the server message being abused in such a way. It wasn't until "bad people"™ actually started abusing it that the developers realised the issue and patched it. Unfortunately, that's just the way these things work... It reminds me of some programming assignments I did back at University in my first year... simple stuff like design a number selection menu etc... I'd code it up and test it, pressing numbers and selecting menu items and it would work great... then I'd give it to my girlfriend (who was not tech savvy) and she would promptly "break" it by trying to type letters or special characters because she thought differently to me and it just didn't occur to me that when presented with menu items 1-4, someone would type a "J" Having her test all my code probably earned me at least 10% extra marks on most of my assignments!  |
|
|
|
Can you tell what version of Electrum you are using and in which device exactly?
Why are you resurrecting a thread that is 4 years old? The OP was posted in June 2016!!?! I highly doubt that any issue the OP had 4 years ago is relevant to today's version of Electrum. |
|
|
|
I checked "Spend only confirmed coins" in Electrum properties
Can you provide a screenshot of your Electrum "Transactions" preference tab settings? I've not personally had any issues with 3.3.8 and freezing addresses/"spend from" doing unexpected things... so I'm wondering if there is a combination of settings that might be causing this? |
|
|
|
I have tried the link it was so helpful, only two wallet were selected for me, bitcoin core and bitcoin knots, I have not read anything about bitcoin knots before, I will prefer bitcoin core.
Bitcoin Knots is a fork of Bitcoin Core created by luke-jr that provides "alternative" features... From the official website: Bitcoin Knots began in 2011 December as Bitcoin Next-Test, a derivative of Bitcoin Core's "master" branch with upcoming and proposed features merged in manner as unbiased as possible toward the changes themselves. In 2014, due to time constraints and a desire to maintain a more stable and well-maintained derivative, I began instead to base the branch off the latest stable release, and include only modifications that both looked reasonably safe and I did not personally consider problematic or flawed; along with this change, since it was no longer an unbiased derivative, I renamed it to Bitcoin Core "ljr", and later Bitcoin LJR. With 0.12 in 2016, the project was once again renamed (to "Bitcoin Knots") and has a goal of being a general enhanced derivative of the reference Bitcoin Core software. So, it's basically Bitcoin Core with extra bits I'd recommend you start with Bitcoin Core and become familiar with it... and then perhaps investigate Bitcoin Knots if you find there are features that it has (check the website for the extensive list) that you want/need but aren't in Bitcoin Core. |
|
|
|
It would indeed appear to be the reason why ElectrumX is disconnecting the client... The "soft" limit is when throttling starts to occur and the "hard" limit is when you get disconnected: As the total cost of a session goes over the soft limit, its requests start to be throttled in two ways. First, the
number of requests for that session that the server will process concurrently is reduced. Second, each request starts to sleep a little before being handled.
...
Once the hard limit is reached, the session is disconnected. So, not only will it eventually disconnect you, but due to the throttling it'll slow down your syncing when you hit the soft limit. additionally... If a session disconnects, ElectrumX continues to associate its cost with its IP address, so if it immediately reconnects it will re-acquire its previous cost allocation
So, you will just continuously get disconnected once you hit that hard limit I'd suggest setting the soft and hard limits up to a value of 100000000 and the bandwidth cost to 1000000... that should hopefully stop ElectrumX from reaching the hard limit and disconnecting your client |
|
|
|
Electrum isn't really designed for wallets containing 1 million addresses... I would think that the issue is most likely that the Electrum Server isn't handling the sheer volume of requests very well. Either break your wallet file down into multiple wallets containing less addresses (ie 10 wallet files with 100,000 or 100 files with 10,000 addresses) or move to a completely different option as I suspect you're likely to continue to face these problems if you need/want to track such a large number of addresses. (why? ) You could also try a different Electrum Server option: https://github.com/romanz/electrsI use this one, but have less than 100 addresses, so I can't comment on how well it will handle trying to sync 1 million. |
|
|
|
It is dangerous to rely on Exodus wallet to secure a lot of money, and since you use hardware wallet, I assume you are saving a lot of money.
Also, USDT is on several platforms, so it is better to use trust wallet with it and send it to Trezor Hardware wallet.
It's not really "dangerous" if you're using a Trezor (or other compatible hardware wallet)... in general, the software wallet you are using in combination with a hardware wallet is not that important, provided of course that you pay attention to what the hardware wallet is displaying/telling you in regards to the outputs being created/sent... and addresses being generated for receiving etc. The obvious downside to Exodus is simply that it dictates fees... there isn't even any "low priority", "high priority", let alone a "custom" setting... and from what I've seen, the fees it suggests "enforces", are generally over-estimated which will result in extra costs. |
|
|
|
Private Key -> ONE WAY hash -> Public Key -> ONE WAY hash -> Address I know you know and that you've just made a typo, but for the sake of other users reading this thread, private key to public key is via a one way elliptic curve multiplication, not a one way hash. Thanks for the heads up... yeah, was typing slower than I was thinking and my brain had already moved to the "one way hash" part of Pubkey -> Address which is where the OP seemed to be getting stuck I've corrected it now. |
|
|
|
Have you looked at Coinb.in? It's raw transaction creation tool will accept a redeem script (also address or WIF Key)... However, I've not tested it with "custom" redeem scripts like your example, but it is worth testing out to see if it is able to handle it. |
|
|
|
It would appear that you may need to add a lot more than 10 to find your "missing" address... from the Wasabi docs: https://docs.wasabiwallet.io/FAQ/FAQ-UseWasabi.html#what-derivation-paths-does-wasabi-useWHAT DERIVATION PATHS DOES WASABI USE?
Wasabi follows BIP 84: Derivation scheme for P2WPKH Based Accounts, so the main path is m/84'/0'/0'. On TestNet and RegTest Wasabi uses m/84'/0'/0', and not the standard m/84'/1'/0'. Due to the CoinJoin implementation, the key depth can be rather large, thus when recovering the gap limit should be elevated to at least 100.
If o_e_l_e_o's suggestion didn't work... try: for i in range(0, 100): wallet.create_new_address(True) If that still doesn't work, then you might also want to try (in case they're using receive addresses as change addresses): for i in range(0, 100): wallet.create_new_address(False) |
|
|
|
1) I ask a guy to give me his public key.
...
Since only if he owns the address, he can decrypt the message, why can't we simply skip the step 1?
Because, as the others have mentioned, there is simply no way to get the public key from an address... (ignoring that you could go trawling through the blockchain for transactions where that address was used to provide an input, and get the public key from the transaction data). Private Key -> ONE WAY hash elliptic curve multiplication -> Public Key -> ONE WAY hash -> Address You can only go from left to right... you can't go the other way. If the person you're attempting to send the message to doesn't provide the public key, there is no way to encrypt the message so only their private key can decrypt it. EDITED for the sake of correctness. |
|
|
|
Specifically, you need to make sure that it has this commit: https://github.com/romanz/electrs/commit/e55381fa6643661c0dad2c454415ed997084a13dYou can see in the commit notes (and the associated Electrum git issue) that without this modification, the client will get disconnected from electrs Hopefully MyNode fix this issue for you, as saldubiense mentioned above, it should be as easy as updating their electrs to the latest version. I was having similar issues with my local version of electrs and Electrum until I updated my local copy of the electrs git to include the latest commits and then rebuilt it. |
|
|
|
|
Show Posts
