Let's say my first graph looks like this
TX11 (9 sat/B) -> TX21 (9 sat/B) -> TX31 (9 sat/B)
Now I want this graph be replaced by this graph
TX12 (10 sat/B) -> TX22 (10 sat/B) -> TX32 (10 sat/B)
That graph is confusing. In the first graph, where's TX 12 to TX 20 and TX 22 to TX 30? If it's meant to be: the transaction on the right is the child of the transaction on the left, then it's better to use an example like this: TX 1A (9 sat/B) -> TX 2A (9 sat/B) -> TX 3A (9 sat/B) In the second graph, you may tell the replacement by changing A to B: TX 1B (10 sat/B) -> TX 2B (10 sat/B) -> TX 3B (10 sat/B) However, if I understand you correctly, when I broadcast the first RBF transaction TX12, the miner does not yet know that I am up to also replace TX21 and TX31. So he wants me to pay a transaction fee of like 30 sat/B for TX12 which is not what I want, It's more than just 30sat/vB. The replacement has to pay at least the total " absolute fee" amount paid by all of its children transactions, its original absolute fee and its own bandwidth ( +1sat/vB equivalent). Not the fee rate ( like 'sat/vB') but the absolute fee ( 'n sat/vB' x 'n vBytes') paid by those transactions. So if those transactions varies in sizes and/or if it changed in size, it wont be the straightforward sum of all their fee rate. Is there a solution to my problem? The solution is to mine blocks. The rule above is only " standard rules" ( policy) so if you're a solo miner, pool owner or affiliated to one, you can ( ask to) replace TX 1A, TX 2A and TX 3A with TX 1B, TX 2B & TX 3B in your/their candidate block without following the rule above. you can even set 0sat/vB if you want to, since it doesn't break any consensus rules. |
|
|
|
AFAIK it should just take the two positional arg's numeric values right after the command, each separated by whitespace. You can also try to use --named arg and specify the command parameters' names. Like for example: $bitcoin-cli --named verifychain checklevel=1 nblocks=0 |
|
|
|
As for disabling dumpprivkey, it's a safety feature since clients that does that with non-hardened addresses have been doing it with risks.
safety for who though? are we saying that we don't trust the users themselves to not run "dumpprivkey" on all their addresses and post the results here on the forum or something? Not entirely that, it's the difference in the derivation used in legacy and descriptor wallets; Specifically, non hardened derivation from the chain index to address index which falls to the " weakness" in the link in my previous reply. It's the consequences of exposing a single private key. And since the extended public key is already easy to get into; With non-hardened derivation, all of the associated private keys of its parent extended key could be compromised alongside with it. that's where we come to the problem. i don't my "own script" i guess that means i need to go satoshi mode and figure out how to write one...that's alot of trouble to verify the wallet but i guess it is what it is. In that case, how do you verify that the dumpprivkey result derives the correct address without a script the you own or at least audited? If you're using other's tools or wallets that you haven't audited, then that didn't verified anything since you're also trusting that the result of the other software is correct. |
|
|
|
Then why is the price feed not up to date?
I launched by dusty Mycelium Wallet to test this and it also showed the last " BTC-to-USD" price that it displayed at that time. ( $52k) Not just the one displayed but all of the other sources are outdated when the drop-down menu is expanded. My internet isn't even slow nor enabled Tor connection in Mycelium's settings. I think that this is a common thing but barely noticeable to users who are frequently opening the app since the fiat price could be outdated only by a few minutes. If you just opened the wallet after idling for a while ( when price was $63k), that may be the case. But after some " random clicks" to check settings, etc. and a restart, it's updated to the recent price and the ticker updates every few seconds. It fixed itself so it's impossible to tell the issue exactly; my best guess are: issue with their server where the exchange rate are fetched and/or the app's cache. 
I'm not proficient with their source code's language but others may be able to tell the issue with it. Link: github.com/mycelium-com/wallet-android |
|
|
|
you can't even see anything. you just have to trust it is working correctly.
Use listdescriptors, take note of the results. Now use getaddressinfo "address", and check if its parent descriptor matches one of your wallet's descriptor. To get the private descriptor, use listdescriptors true to list the same results above but with the " master private key" instead. With those info, use your own script to derive the address from your master private key with the provided derivation path in the descriptor. As for disabling dumpprivkey, it's a safety feature since clients that does that with non-hardened addresses have been doing it with risks. See: learnmeabitcoin.com/technical/keys/hd-wallets/extended-keys/#weaknessProbably related to those " unexplained" hacks that we've been seeing in Electrum or other clients sometimes. Im not forcing you to use Bitcoin Core though, it's up to you to choose your Bitcoin client. |
|
|
|
Now the larger question - is this node (testnet) any good? I want a real node to make real transactions rather than a "sandbox".
The Drive is actually good in the long run but I have no idea on the specs of your " old laptop". Anyhow, Bitcoin Core doesn't require the latest hardware so that setup should also work in mainnet. It's just syncing to the network ( mainnet) that may take longer than usual in old hardware specially with HDD and low RAM. Set your configurations like dbcache to a suitable size to speed it up. ( not too low/high based from your RAM) If " good" as in " safe", you should verify Bitcoin Core based from the per OS instructions provided in the download page. link: bitcoincore.org/en/download |
|
|
|
URL: 127.0.0.1, port 8332 (standard)
Data Folder: D:\Bitcoin\testnet
Use Proxy (no)
You should set TestNet's RPC connection port rather than MainNet's. It's " 18332" by default but you can set your preferred port in your bitcoin core's bitcoin.conf file with rpcport=18332 or as a command line option. Another is when you've set rpcuser and rpcpassword in Bitcoin Core; in that case, it should also be set in Sparrow. |
|
|
|
If it's the script that they used, after an approximate of 360 days,
you can spend the output(s) as a simple single-sig (CHECKSIG) without even requiring Blockstream's public key like that of a 1-of-2 MultiSig.
If this is the case, the answer is closer to "it become Single Sig" than "it become 1-of-2 MultiSig".
Another thing that I guess is that the tool can be used to recover the second private key instead of using Blockstream server for the signing, making it possible for the person to be able to use the key that the server supoose to use for the signing. A good guess, but my post is rather based from their FAQ which states that they are using OP_CSV and a period of 365 days for the output to be spendable by the user's key alone. So I'm confident that it's close to the provided script, ( may be using relative lock time ("365d") than relative block height ("51840")) and all the recovery software does is to construct the script with the user's keys derived from his mnemonic and create transactions set with the correct nSequence from associated UTXOs that it found. And a slight correction, Blockstreams public key is still required in the " redeem script", but the condition that should be fulfilled is still OP_CHECKSIG, not the OP_CHECKMULTISIG on top. |
|
|
|
-snip- I want to know if the recovery tool is used, the wallet will still remain 2 of 2 or become 1 of 2 when the 2FA is disabled.
This is tricky to answer since their new script is more than just 2-of-2 MultiSig and no recovery tool can edit UTXOs. It actually has a ELSE condition that when a certain time/block has passed, the script in it will be valid rather than IF. Without looking at their low level documentation, I believe that the locking script is something like this: ( or close) IF
2 <Your pubKey> <Blockstream's pubKey> 2 CHECKMULTISIG
ELSE
"51840" CHECKSEQUENCEVERIFY DROP
<Your pubKey> CHECKSIG
ENDIF If it's the script that they used, after an approximate of 360 days, you can spend the output(s) as a simple single-sig ( CHECKSIG) without even requiring Blockstream's public key like that of a 1-of-2 MultiSig. If this is the case, the answer is closer to " it become Single Sig" than " it become 1-of-2 MultiSig". |
|
|
|
Does anyone know the best way to fetch UTXOs from specific addresses? via API calls or any other way?
Have you tried any of the famous blockexplorers' APIs? For example, Blockstream's public API: blockstream.info/api/address/1BitcoinEaterAddressDontSendf59kuE/txs/chain Returns with the latest 25 transaction of the specified address. To continue to the next set of transactions, add the last txid from the result above. ( check if it's the transaction's txid, not its input) e.g.: https://blockstream.info/api/address/1BitcoinEaterAddressDontSendf59kuE/txs/chain/fab012bec43a909d787e95a1afcbced1a66fb1a6a62d0d22cad9578c560627cc |
|
|
|
Cheers, that will be my next move.
If you open that file as text as instructed, you'll see something like this: <?xml version='1.0' encoding='utf-8' standalone='yes'?>
<assembly
xmlns="urn:schemas-microsoft-com:asm.v3"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
manifestVersion="1.0"
>
<assemblyIdentity
name="Microsoft-Windows-Crypto-keys"
.
. The gist is; not every file that's named " crypto" is related to Bitcoin or Cryptocurrency, In fact, every wallet file or backup format are rarely named with the term " crypto" in it. It's turning into a good read, Cheers  My addition to the linked topic is you should enable " show hidden items" when manually searching for wallet files since those usually located in hidden directories like " AppData". You may also consider using another PC to search and just mount your drive so that it wont have to create unnecessary 'writes' to the disk in case the file that you're looking for are deleted. That way, you'll have a better chance to restore deleted files intact. And you should also create a " disk image" ( Google it) for backup purposes. |
|
|
|
Devastated, not sure if there is anything I can do?
I'm sure Blockchain will wash of their hands of this at this point.
Nothing you can do. They are definitely ready for those kind of scenarios since their Term of Service implies that they aren't liable in case of " hacking". Read their " User Agreement page", specifically " 15.6 Limitation of Liability" part ( D). Link: blockchain.com/en/legal/terms |
|
|
|
I need to understand I was scammed or not I don't think you were scammed. You said that you checked your addresses on the blockchain and that the bitcoin is still there. If you are 100% sure that those addresses are yours and they still hold the coins you deposited, I am quite certain it isn't a scam. -snip-That's unless the client is just showing addresses that the hacker owns and not the ones generated from his seed phrase and passphrase. Since he didn't mentioned that he spent before ( only "login"), so we can't confirm that he actually owns those addresses. In that case, there's no reason to spend it until the hacker is ready to move his scammed coins. So I think it is still necessary to check his old Electrum download's signature to be able to deduce that from the possible scenarios. Plus since OP is thinking of a possibility that he might be scammed suggests that there may be a third-party involved in this. @phoenixantii care to add some info? |
|
|
|
Full node is not working because port 8333 is not open.
Please be specific on the way that it's not working. Like, not connecting at all or has outbound connections but no inbound connections? Because if it's just about failing to open port 8333, your node should've at least outbound connections. If it's not connecting to any peer, try to check your " debug.log" file for related errors because it could be caused by something else. Your debug.log file is in your bitcoin datadir. |
|
|
|
I have core v25 connected to my fulcrum server with sparrow wallet.
Hmm, If it's Fulcrum, then there shouldn't be a " mirrored" watch-only wallet in Bitcoin Core since it doesn't work like EPS or Sparrow's direct connection to Bitcoin Core. What I'm thinking is you might have previously connected Sparrow to Core using either options ( not Fulcrum) which created a watching-only wallet. Thus the wallet where you're seeing the sending transactions. But now that you're using Fulcrum, your new descriptors from the other ( new?) hardware wallet aren't imported to that existing watch-only wallet. Any tips would be appreciated!
If the above scenario is correct, you can manually import your new wallet's public descriptors to that watching-only wallet. You can get it from Sparrow Wallet: " Settings Tab->Export>Output Descriptors" Then import the Bitcoin Core-compatible descriptors to Bitcoin Core using importdescriptors command. |
|
|
|
No, I'm not talking about ThunderHub. You said to set the receiving capacity more than the sending capacity. This is exactly my problem.
That suggestion depends on your needs, I didn't directly said to increase your receiving capacity. If you think that your current receiving and sending capacity are enough, then it's already good. Because I can't do it. Haven't you said that " the swap is done"? This is probably just language barrier. |
|
|
|
The private key I'm looking for is: KxEd..............B9L
and the one I'm getting is: 33.................3cZ
That's because WIF isn't just ECDSA Private key encoded to base58. ( you've asked ChatGPT?) It needs to have a " network byte", " compression flag" ( to tell clients to derive compressed pubKey) and a 4-Byte " checksum". To do that, you can also use " bitcoinlib.encoding" and import " double_sha256" to calculate the checksum. With that, add these to your code: ( remove 'print' if you do not want to output those) .
.
.
from bitcoinlib.encoding import double_sha256
.
.
.
# Prepend Network Byte and Append Compression Flag
prvKey_data = (b'\x80' + key.private_byte + b'\x01')
print("prvKey_data:",bytes.hex(prvKey_data))
# Calculate the Checksum
checksum = double_sha256(prvKey_data)
print("checksum:",bytes.hex(checksum[0:4]))
# Replace this part:
# private_key_base58 = base58encode(key.private_byte)
# With this:
private_key_base58 = base58encode(prvKey_data + checksum[0:4])
|
|
|
|
How can I determine the capacity allocated to receiving more than the sending capacity?
Uhh.. It's in one your screenshots, open the one that is showing your channel. ( the first link maybe) Your sending and receiving capacity is displayed as " Can send" and " Can receive". Or are you talking about ThunderHub? If so, that should be asked in a new topic in the board that I've mentioned. |
|
|
|
-snip- I use the ThunderHub interface. Did you work with it? What do you think about it ?
Unfortunately, I don't use ThunderHub LN Node Manager. Since it's not about Electrum anyways; You can post it as a new topic in " Bitcoin->Development & Technical Discussion->Wallet software" board. Hello, the swap is done. I want to balance the receive and send capacity -snip- Even if you did that, it will be only temporary since your receiving and sending capacity will be readjusted according on how much you send or receive Bitcoins though your lightning channel( s). ( if you are already aware that, disregard the note below) You need to target capacities according to your projected use-case. e.g.: if you will be receiving more than sending, then allocate more receiving than sending capacity. |
|
|
|
Sparrwor writes:
Unfortunately, Bitcoin Core stores your public keys and funds unencrypted on the computer that runs it. If that computer is regularly connected to the Internet, it is at risk to hackers - making you a target once your balance is discovered.
Ah, they mean that if some hacker got his hands into your xpub and with it, saw that you have certain amount of Bitcoins; That information: " you possessing N number of Bitcoins" will be the basis of hackers to make you a target, specially if it's a significant amount. It's not necessarily mean that they'll use the xpub in Bitcoin Core directly to hack your Specter wallet. Nevertheless, take note that the xpub is not entirely safe if you've been exporting individual private keys from Specter, even prvKeys of the unfunded addresses. ( AFAIK, there's no option to do that in Specter, just like in Bitcoin Core's descriptor wallets) Because a child private key can be used together with its parent " extended public key" to compute its pair " extended private key". But if you haven't exported any private key and exposed it to the internet, then this shouldn't be an issue in your case. |
|
|
|
|
Show Posts
