Can you please tell me what is testnet wallet, i saw (testnet application + bitcoin wallet application) in Android !?
Are you wanting a link to an actual testnet wallet for Android... or are you just wanting to know what a "testnet wallet" actually is?  If you want a link, Mycelium has a "Testnet" version: https://play.google.com/store/apps/details?id=com.mycelium.testnetwalletIf you want to know what "Testnet wallets" actually are, they're simply bitcoin wallets configured to work with the Bitcoin Testnet blockchain, instead of the "mainnet". If you want to know more about Testnet and what it is, start here: https://en.bitcoin.it/wiki/Testnet |
|
|
|
Actually, only litecoin has its own electrum. Nope... There were also Electrum forks for: - Bitcoin Cash (Electron Cash) - Bitcoin SV (ElectrumSV) - Vertcoin (Electrum-vertcoin) - Bitcoin Gold (ElectrumG) - Bitcoin Diamond (Electrum-BCD) And others that I'm either forgetting or that I have not seen mentioned... In fact, if you look at the "old" ElectrumX code (before the author drank the koolaid and decided that BSV was all that and a packet of crisps)... you can see all the various altcoins that it supported. You'll be please to note that DOGE coin is in that list: https://github.com/kyuupichan/electrumx/blob/eac2b7db8cb80394e7bc0e40696ab2dc8caed051/electrumx/lib/coins.py#L1151So, that's one less thing to worry about if you want an "ElectrumDOGE"  |
|
|
|
Have you tried it without the \ escape characters within the PHP? I suspect that they are not required... the \" stuff seems to be a "console" requirement... I would expect that the json_encode() function would take care of the escaping/formatting required, so maybe try something like: $method= "start";
$params= "addr(1CUTyyxgbKvtCdoYmceQJCZLXCde5akiX2";
// request is converted in JSON
$request = json_encode(array(
'method' => $method,
'params' => $params,
));
Failing that... debug and just dump out the value of $request before executing it... you'll likely see some weird escaping happening would be my guess... like, it'll be escaping the \'s or something stupid like that. |
|
|
|
i have 74 USD in my block chain
when i try to transfer it says 66$ available for transfer
when i try to send there is 8 USD regular fee(mining)
Is your wallet balance made up of lots of smallish amounts of Bitcoin that you've collected from faucets/bounties/other micropayment jobs etc? If so, that would go some way to explaining the rather large-ish fee that the wallet is calculating... it will result in your transaction having a large data size (regardless of the amount of BTC being transacted)... and because fees are calculated as sats/byte (or BTC/kB)... a large data size = large fee  Additionally, the network has been quite busy the last few days. Consequently, there has been an increase in the number of transactions being made... which usually results in the mempool getting flooded and there being a large number of unconfirmed transactions. When that happens, people start paying higher and higher fees in an effort to get quicker confirmation... And before you know it, 100+ sats/byte fees... In addition, the blockchain.com wallet is terrible at fee estimation... it has been for a long time... it either grossly underestimates resulting in stuck transactions... or it grossly overestimates and users end up overpaying by a significant amount. Check current mempool and fee metrics here: https://jochen-hoenicke.de/queue/#0,24hhttps://mempool.space/https://bitcoiner.live/If your wallet is not suggesting fees similar to the ones suggested by these sites... you need a new wallet! or perhaps one that lets you set "custom" or "manual" fees  |
|
|
|
I guess it depends on what you're actually trying to deduce... If it is how many transactions involve "OP_DUP OP_HASH160 <e1da068feab51a9473ca2f2b552175226bf3810e> OP_EQUALVERIFY OP_CHECKSIG", then yes... If it's "how many transactions involved coins being spent from or sent to a script that can only be spent by signing a transaction with privkeyX (and only privkeyX)"... then the logic holds. Again, as I said, it was huge oversimplification. It's like if you google "cute puppies" but google shows you "bitcoin price" instead!
No... I think it would be more like if you searched "cute puppies"... and you got "cute puppies and kittens" |
|
|
|
What OS are you running this on? And what language are you using for making the call? It's likely, as NotATether has suggested, an "escaping" issue... I've had so many issues with Bitcoin Core and getting the JSON formatting "just so" |
|
|
|
This does not answer to the question: "how to know how much an address own" or at least "how to know the source of a transaction".
It only gives you the sum of all the BTC spent by an address (in the case of the 'addr' command)
I think you're a little confused as to what scantxoutset is showing. It is scanning the UTXO set... which is the set of all unspent transaction outputs. It returns the UTXOs currently controlled by the descriptors that you provide... in other words "how much the address own". My example address (as of 2021-02-04 23:20 UTC):   Is that not exactly what you're after? If I do the math on a real wallet, the total_amount is the sum of all VOUT which is not what is left unspent in the wallet, but what was spent (out) of the wallet.
No... those "vout"'s are the vout's from the txid's that created that particular UTXO... which sent it to that address (They're not vout's spending from the address) Note listunspent "address" will list all the unspent UTXO from the wallet. Can be entered into the console. Sum of them will give the total of the unspent UTXO available.
Note that listunspent only works on addresses that are "in" your wallet.dat... it will not work for "external" (aka "random") addresses.  |
|
|
|
Then sadly, there is no chance for recovery. The 12 words recovery phrase is the key to recovering your wallet... without it, you have zero chance of recovering that wallet. Data recovery on mobile devices is not "impossible", but it is generally more difficult than attempting it on a desktop pc or laptop. You'd definitely need to stop using the device immediately... and most probably need to take it to a data recovery specialist... however, their costs are likely to far outweigh the $500 worth of BTC that you're attempting to recover. |
|
|
|
Did you do all of the steps that escobol mentioned in their earlier post: check pip2 install registrar==0.0.3.4 ------ Checked on new/clean Ubuntu 18.04 LTS In terminal: sudo apt-get update sudo apt-get upgrade sudo apt install python-minimal sudo apt install python-pip sudo apt-get install libssl-dev libffi-dev pip2 install registrar==0.0.3.4 The important one is: pip2 install registrar==0.0.3.4 |
|
|
|
Can someone tell me how these errors occur?
It's simply because of the way the block explorers are interpreting the transaction data... or improperly interpreting the data, as the case may be. Block Explorers 1&2 are only looking for the address (ie. the hash of the public key)... so they only see 2 transactions for that address, 1 in, 1 out and attribute the address to have a balance of zero. Block Explorers 3&4 are looking for any transaction that has the public key... unfortunately, the public key (0243c17584f2a00d7c22429e1444e2a94cae0a657b9a58ee6a87c33ef7bca97245) was used in a "spending script that required multiple sigs spend" (it's a precursor to the more common "multisig" that we have today)... so these explorers are seeing all these "extra" transactions where the public key was used as part of this type of multisig... but the address does not have exclusive control over those coins, so they shouldn't be showing as being part of the balance of that address. Lastly, Block Explorers 5&6 are seeing the transactions for both the address and the public key... but only where the coins were sent to just that address or that public key (ie. not the "multisig" transactions.), so they arguably give the "most correct" answer. In short, some old transactions that are now effectively "non-standard" today, confuse block explorers made to parse what are considered to be "standard" transactions. (NOTE: This is a huge oversimplification.) |
|
|
|
Let's try with some basics... does your "encrypted private key" start with the characters "6P"? If it does, you have a BIP38 encrypted private key. There are not many options readily available for dealing with these. The easiest is to use bitaddress.org as suggested by TryNinja in their earlier post. If your private key does not begin with "6P" then you have have some other type of encryption... what is the first character of your private key? NOTE: as always, do NOT post your private key anywhere! |
|
|
|
Thanx! Ive installed latest Bitcoin qt to my iMac - but i cant find Settings->Options->Size option to set prune (instead of windows version, where its easy to find) there is only Summary, Send, Recieve, Transaction panel
Mac's have that weird "one title bar for everything" approach... so it won't be on the panel that shows "summary, send, receive, transaction"... you need to look at the title bar at the very top of the desktop... (next to the "Apple" menu? it's been a while since I used a mac ) There you should find the "File", "Settings", "Window", "Help" menus displayed... |
|
|
|
Do you have example of command that works? I read the description of scantxoutset, but there's no example and i'm confused about 2nd parameter.
Which bit is confusing you? Scans the unspent transaction output set for entries that match certain output descriptors.
Examples of output descriptors are:
addr(<address>) Outputs whose scriptPubKey corresponds to the specified address (does not include P2PK)
raw(<hex script>) Outputs whose scriptPubKey equals the specified hex scripts
combo(<pubkey>) P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH outputs for the given pubkey
pkh(<pubkey>) P2PKH outputs for the given pubkey
sh(multi(<n>,<pubkey>,<pubkey>,...)) P2SH-multisig outputs for the given threshold and pubkeys
In the above, <pubkey> either refers to a fixed public key in hexadecimal notation, or to an xpub/xprv optionally followed by one
or more path elements separated by "/", and optionally ending in "/*" (unhardened), or "/*'" or "/*h" (hardened) to specify all
unhardened or hardened child keys.
In the latter case, a range needs to be specified by below if different from 1000.
For more information on output descriptors, see the documentation in the doc/descriptors.md file.
More reading on descriptors as indicated in the descriptors.md file: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.mdThe simplest is addr(): scantxoutset "start" "[\"addr(1CUTyyxgbKvtCdoYmceQJCZLXCde5akiX2)\"]"
{
"success": true,
"txouts": 70264820,
"height": 668945,
"bestblock": "00000000000000000008fa308c94179d3b6c4d4501cde114d14b33593bbeae59",
"unspents": [
{
"txid": "f9a7240ad23bc84044ab83b593e11dd6686a2cfbc13731944259a6ee0f10295f",
"vout": 1,
"scriptPubKey": "76a9147ddb236e7877d5040e2a59e4be544c65934e573a88ac",
"desc": "addr(1CUTyyxgbKvtCdoYmceQJCZLXCde5akiX2)#nsvz5zvh",
"amount": 2.15076162,
"height": 668945
},
{
"txid": "4aa8d886f4a799b08b0063562f76dfd1bbe200ca3dc2bf39935f341fa9e44ffa",
"vout": 1,
"scriptPubKey": "76a9147ddb236e7877d5040e2a59e4be544c65934e573a88ac",
"desc": "addr(1CUTyyxgbKvtCdoYmceQJCZLXCde5akiX2)#nsvz5zvh",
"amount": 1.14902796,
"height": 668944
}
],
"total_amount": 3.29978958
}
|
|
|
|
For example an armed robber breaking into your house where you'd have enough time to broadcast that signed transaction (assuming you have wallet software handy and the tx was stored electronically!) but you would not have enough time to download Electrum, verify it, import your private key, fill in a receiving address that you have to recall from your head or notes, then then enter a password you made up to sign the transaction because you wouldn't put your cold storage at risk by not password-protecting a temporary wallet (right?) and finally broadcast the transaction before he comes to you and interrupts this demands at gunpoint that you send it all to him. TBH, that's a pretty ridiculous scenario... I doubt the first thought in most peoples mind when an armed robber is attempting to break into their house is "I must broadcast that signed transaction I had laying around all these years and send those funds away". I would think it more likely that it would usually be "call the police"... or "get my gun/bat/knife/blunt object" etc.  Having unbroadcast, signed transactions should be a tool for "urgent" situations. |
|
|
|
That's correct... Bitcoin Core does not support the BIP39 "seed mnemonic"... instead, it relies on making backups of the wallet.dat as the recovery method. Essentially, you just make a copy the wallet.dat file... however, it should be noted that you should not do this while bitcoin core is running!... you could make a corrupt backup if the application is in the middle of writing data when you copy the file. Instead, you should either use the "File -> Backup wallet..." option in the GUI:  or the backupwallet option available on the console or with bitcoin-cli... or shut bitcoin core down and then copy the file manually. |
|
|
|
One of the rules is that the fee for RBF transactions must increase. If you spam the transactions and don't increase the fee, they'll be rejected. So, at some point, you either run out of available coins to increase the fee, or one of the transactions gets confirmed which would immediately invalidate all the others and end the attack. Additionally, if you send another transaction using RBF, the "original" transaction is then dropped from the mempool. You can see the specs in BIP125: One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if,
1. The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
2. The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions. (An unconfirmed input spends an output from a currently-unconfirmed transaction.)
3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.
4. The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
5. The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.
If you're not trying to RBF, and simply attempting to double-spend... then the transaction is generally just rejected outright, because you're trying to double-spend you'll get "txn-conflict" type errors because a transaction spending the same UTXOs already exists. |
|
|
|
Yes, the feerate isn't necessarily "bad"... just the "timing" of the transaction There has been a mini bull run over the last 10 or so hours... and consequently, the network has become really busy again, driving up fees  Depending on what happens from here, your transaction will hopefully confirm within the next couple of hours... but, if things continue to heat up and the price keeps climbing... all bets are off! https://mempool.space/ gives a relatively nice overview of what is happening... and https://bitcoiner.live/ is another one I came across recently that uses statistical modelling to try and guess the best fee rates... after all, that is what all the fee estimates are... "guesses!" |
|
|
|
You appear to be having the same problem as https://github.com/bitcoin/bitcoin/issues/16091 , try the solution listed there which is to run 0.21 with the -upgradewallet switch and see if you can open the wallet file in that newer version. And again, as always... when trying to extract info from wallet.dat using scripts and/or using commands that can make irreversible modifications to wallet.dat like -upgradewallet, make sure you're working on copies of the wallet.dat... don't work on the original of your wallet.dat files! |
|
|
|
Is the original transaction currently showing up in your wallet transaction history? If not, do you know what the original transaction ID is? If you can get hold of the original raw transaction (by using the original transaction ID), you could try rebroadcasting it through your Bitcoin Core... this should hopefully put the (still unconfirmed) original transaction back in your transaction history. You should then be able to simply right click on that transaction and select "increase transaction fee". That would save you from a lot of the issues you're currently experiencing. Also, in the future, I suggest not using abandontransaction and zapwallettxes unless you're 100% sure that they are required for what you're trying to achieve. |
|
|
|
|
Parent TX = Which transaction created that UTXO that you're trying to spend?
ZC Parent = Zero Confirmation Parent... ie. is the parent transaction unconfirmed or confirmed?
|
|
|
|
|
Show Posts
