I forgot to mention that writing " 1/2" and " 2/2" as the cosigner wallets might mislead the readers that you're talking about two unrelated MultiSig wallets. Because in MultiSig; m/n, " m" sets the number of required signatures and " n" indicates the number of cosigners. A better term would be " cosigner 1" and " cosigner 2" of a (2/2) MultiSig Electrum wallet or similar. |
|
|
|
ah... I actually found that donation address but I taught it's for hosting Bitcoin.org website itself. Didn't think it goes for the development of the Bitcoin Core If it does I'll use that one. ps. found the Electrum @ThomasV address in your signature.  hardcoded in the software, so I've everything I need. THX Your hunch is correct, it's for bitcoin.org, not for the development of the reference client. For the hardcoded Electrum address, it's not meant to be a donation address. It's for message signing purposes in case there's a new version to be announced to Electrum clients ( for clients who turned it on). Because the " version" (electrum.org/version) that Electrum provides have to be signed with either of those addresses for verification purposes. If you need to contact ThomasV ( ecdsa) to get a donation address, here's his bitcointalk profile: ThomasV / GitHub profile: github.com/ecdsaThese links might be useful: |
|
|
|
-snip-
Ran the reindex but sparrow still wouldn't connect. Also tried rescan also with no luck. I was able to get sparrow to connect again by deleting the sparrow wallet folder in Bitcoin core. I tried to reproduce this by purposely corrupting the wallet.dat inside " bitcoin/wallets/sparrow" folder and it indeed failed to connect. Got this line in sparrow's log file: ...
JSON-RPC error: RPC error response: RpcError { code: -4, message: "Wallet file verification failed. \"M:\\Bitcoin\\wallets\\sparrow\\wallet.dat\" corrupt.
Try using the wallet tool bitcoin-wallet to salvage or restoring a backup.", data: None } So, it appears that sparrow is reliant to a mirrored watching-only wallet.dat file in Bitcoin Core. But that doesn't mean that your block index/chainstate wasn't corrupted by the abrupt shutdown as well ( it's fixed by reindex). Anyway, since the core issue is the frequent power loss, then a UPS with big backup battery is indeed the best solution. |
|
|
|
This should be documented somewhere on Electrum's website - or even better, as a tooltip in the "Pay" tab - if it's not already there.
The closest thing in the GUI is the " Send queue" invoice for max amount which has " max(!)" as the indicated amount. But tooltip, I can't find any. Where did you find this information anyway? From the source code?
I've been using that with " pay to many" for years and IIRC, there are older threads that mentioned the usage of "!" as amount ( not in bitcoinelectrum) In fact, I've suggested something similar before, like for example: https://bitcointalk.org/index.php?topic=5338398.msg57040834#msg57040834 |
|
|
|
... who could be behind such an enigma?
Someone who wanted to advertise their network by using a potentially historical bitcoin block. But they messed up the arrangement of their OP_RETURN transactions and made a gibberish text art instead of the intended " ZN" ( as seen in the reddit post). If they have utilized CPFP to group the set of transactions together, it would have been mined with the correct arrangement and without any unrelated txns in between. That's a takeaway that whoever did it isn't a seasoned Bitcoin~er. |
|
|
|
So I had a very brief power outage today and now sparrow won't connect to the node again. So strange. My only guess is that because bitcoin core didn't shutdown properly it's causing some issue. Am I just going to have to reinstall bitcoin core everytime my pc shuts down abruptly?
If the issue only a corrupted file brought by the abrupt shutdown and only in Bitcoin Core, then --reindex might solve the issue. It's a command-line option and not a command so; to use it, Bitcoin Core should be started with that parameter ( instructions). |
|
|
|
Edit: I misinterpreted getmempoolinfo. With a getrawmempool, it returns an empty array. So... no mempool for non-synced nodes?
getmempoolinfo should also return with empty " size" if it's empty. This is a wild guess but I think you've used getmemoryinfo instead of getmempoolinfo the first time you tried. |
|
|
|
No, it's the signing key of SHA256SUMS.asc for v0.21.2. You should " manually" import that other key from bitcoincore.org's repository, the one I've linked which is the RSA key 90C8019E36C2E964: 01EA5486DE18A882D4C2684590C8019E36C2E964 Wladimir J. van der Laan (Bitcoin Core binary release signing key) It's a separate key from the one you got from bitcoin repository. |
|
|
|
Can this checksum be omitted in some way to save space? For example, after decoding the address with base58, can the last bytes be omitted?
-snip-
I would prefer being able to start the process knowing only the address string, not the public key (or the public key hash from a ScriptPubKey). Since you prefer the address, omitting the checksum will cost you to re-compute it to rebuild the address. That includes computing the checksum which needs SHA256D and base58 encode. That's basically same as having only the HASH160 of the public key ( plus the network bytes "00"). In that case, you can just save the HASH160 ( 20Bytes) of the public key instead to save more space. |
|
|
|
You can't post the encrypted messages before the "reveal date" because the recipients will be able to decrypt it right away.
The idea is not to let the recipients to know about using their public key until OP wants to call them to check it was signed for them. Okay, so it's not about your second reply. Even so, the non-recipient participants/users will have to trust the recipient of the message to show the correct message, since they wont be able to decrypt it by themselves. Sounds reasonable enough if used together with the forum's trust system but involving trust is kind of a drawback. |
|
|
|
-snip-
I actually used that once like three years ago. As far as I can remember, it wasn't complicated. But what's the difference in terms of security? You wont be able to use that in the use-case described in the OP. You can't post the encrypted messages before the " reveal date" because the recipients will be able to decrypt it right away. Your first option, Bitcoin signed message will work since you can immediately post the valid signature for the message that isn't revealed yet. |
|
|
|
The one with the biggest amount of transactions is 2,945 tx on it, and tx are each 10 minutes. so, taking about seconds i would say:
2954/60=4.92 transactions/second.
2954/60=49.23.... typo? 2945/10/60 is closer to your total. If we're comparing it with Visa, then Bitcoin is still faster since sending a transaction to mempools only take a second. Yes, it's at risk of double-spend while unconfirmed but that's also the case with banks transfers which have a way longer reversal/chargeback window. @ lhrbeijing For the lightning network, it can't be answered since transactions are done in between channels and their routes. But considering that the speed of each lightning transaction only take seconds, it would be far higher than onchain confirmed transactions. |
|
|
|
Alternatively, it can be done by providing the criteria's hash beforehand. The hash can prove that you have not changed the criteria since everyone can compute the its hash once it's revealed. I'd recommend SHA256 for this. For example, the criteria is: 1. very big
2. very yellow
3. very good If you compute the SHA256 hash of the criteria ( as text, exactly as written above), you'll get: 63203a91c71aea8bdbfbdb62926c83a65df94c660721209b9b9f5b8ce4b522aaWhen you revealed the criteria, users can verify if it's really the criteria that you've used by checking if its SHA256 hash matched the one you've provided beforehand. Note: Some sha256 tools parse the new lines ( enter) as space and some omit it; so during the criteria reveal, it's best to suggest open-source hashing tools to have a consistent result, eg: github.com/emn178/online-tools ( has a web version). |
|
|
|
it seems that sometimes the pool popup appears also when u close the wallet and not reopen it, weird.
I tried to reproduce this and it did popped-up after closing the wallet after a few repeats. I've also saved the log and for some reason, cosigner_pool's " listener" started only after closing the cosigner wallet. Might be useful if you decided to open a new issue: 20221027T054506.765925Z | INFO | gui.qt.main_window.[wallet_multisigsegwit2] | close_wallet <snip>electrum\testnet\wallets\wallet_multisigsegwit2
20221027T054506.766924Z | INFO | plugins.cosigner_pool.qt.Plugin | starting listener
20221027T054506.767923Z | INFO | util | unregistering callback <bound method Abstract_Wallet.on_event_adb_removed_verified_tx of <electrum.wallet.Multisig_Wallet object at 0x0750FC10>>
20221027T054506.767923Z | INFO | util | unregistering callback <bound method Abstract_Wallet.on_event_adb_added_verified_tx of <electrum.wallet.Multisig_Wallet object at 0x0750FC10>>
20221027T054506.768924Z | INFO | util | unregistering callback <bound method Abstract_Wallet.on_event_adb_set_up_to_date of <electrum.wallet.Multisig_Wallet object at 0x0750FC10>>
20221027T054506.768924Z | INFO | util | unregistering callback <bound method Abstract_Wallet.on_event_adb_added_tx of <electrum.wallet.Multisig_Wallet object at 0x0750FC10>>
20221027T054506.768924Z | INFO | util | unregistering callback <bound method AddressSynchronizer.on_event_blockchain_updated of <electrum.address_synchronizer.AddressSynchronizer object at 0x0750FBF8>>
20221027T054506.768924Z | INFO | wallet.Multisig_Wallet.[wallet_multisigsegwit2] | taskgroup stopped.
20221027T054506.775919Z | INFO | storage.WalletStorage | saved <snip>electrum\testnet\wallets\wallet_multisigsegwit2
20221027T054506.775919Z | DEBUG | util.profiler | WalletDB._write 0.0060 sec
20221027T054509.663497Z | INFO | plugins.cosigner_pool.qt.Listener | received message for e5a34dc730a17a829095b2b3d31ce9a2dff90d30c66852afc4c6a9dbd015cf57
20221027T054509.663497Z | INFO | plugins.cosigner_pool.qt.Plugin | signal arrived for e5a34dc730a17a829095b2b3d31ce9a2dff90d30c66852afc4c6a9dbd015cf57 |
|
|
|
Yes, the change will be sent to " bc1qh8...". Additionally, while using that workaround, ( like in the coin control tutorial) I'd recommend you to enable " Advanced transaction preview" so you can review your transaction before proceeding to send it. That way, you'll see if the other output is going to the correct address with the correct amount, you can also close it if there's something wrong. You can enable it in " Tools->Preferences->Transactions->Advanced preview" or clicking " Advanced" instead of " Send" when sending funds. Take note that in the advanced preview, you'll have to click: 'Finalize', 'Sign' and 'Broadcast' to send a transaction. Coin control is only necessary if you have more than one UTXO in the " Coins" tab; otherwise, you don't have to do it if there's only one UTXO or you want to consolidate your UTXOs. It's the list in your Electrum's Coins tab ( "View->Show" Coins to enable the tab), like this example screenshot from bitcoinelectrum.com:  |
|
|
|
could some one reproduce this or any clue why it's so ?
I can reproduce it in testnet, Electrum v4.3.2. But IIRC, it's always been the case in the older versions ( at least from what I can recall in my previous test) For others who want to try reproducing the issue: If the other cosigner(s) is open while a cosigner sent a transaction to the cosigner pool server, it wont get prompted for a new partially signed transaction until the wallet get closed and reopened. -edit-I've tried to open the second cosigner in v3.3.8 and it worked without reopening the wallet. But AFAIK, it's always been the case somewhere in v4.x.x, I'll try another older version. -edit2-Same behavior in v4.2.0 & v4.0.6, cosigners have to be reopened to retrieve the partially signed transaction. But works in v4.0.1. Unfortunately, I can't find a relevant commit in cosigner_pool plugin history ( link) and there's no similar open issue in GitHub, perhaps you might want to open one, the Devs might be able to fix/find-out the issue: github.com/spesmilo/electrum/issues? |
|
|
|
-snip-
Does "!" always consolidate all the coins to the change address, if coin control isn't used? That's only the case in normal send, this method is using " pay to many" where there's a "!" amount among the outputs. "!" is the same as clicking " Max" which will use all of the available balance. Electrum will only select UTXO if there's no "!" amount; in which case, it will automatically select a change address. The previous solution is more of a workaround since there's currently no option to manually set a change address. |
|
|
|
Yes, just pick your preferred change address and instead of inputting the " amount" in the designated text box, use " pay-to-many", so 'pay to' should look like this ( e.g.: when sending 0.01BTC): payment_address,0.01
change_address,! "!" indicates that the rest of your funds will be sent to that address. You also have to use coin control if you have more than one coin ( UTXO) available or "!" will consolidate all of your coins to your change address. |
|
|
|
When I setup the node I followed the tutorial on bitcoin.org and did the port forwarding. The node I still receiving incoming connections fine. I followed the sparrow tutorial and all info is still correct.
The node is running on a PC with windows 10 and sparrow is on a pc with windows 11. I haven't changed anything but sparrow just won't connect now. Any suggestions?
How about the guide above it about setting a static IP: bitcoin.org/en/full-node#configuring-dhcp? By saying " still receiving incoming connections", do you mean you're still getting " Inbound" Peers or not? Because if not, my best guess is your set 'rpcbind' IP address didn't match after getting a new IP address. |
|
|
|
|
Show Posts
