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. |
|
|
|
Split into 2 parts
First 35 characters : 5KJyGeq5gngHP25WMwpNb2jGwRGGerdras
Last 17 characters : Y7rBzKXFVBZ7ZkWBn
Now my question is that how can i Calculate the exact first part of this address.
because i know if i get the first part then remining 17 will be find with brute force.
Considering the title of this thread and the " first part" which the sample address doesn't have, I think this is a typo. Looks like he meant " first part of this private key" instead if " address". Even so, the question is still unclear since he didn't mentioned from which data will it be calculated. |
|
|
|
The issue was opening a channel between two Electrum wallets (e.g. "Electrum wallet 1" as your Electrum wallet, "Electrum wallet 2" as remote node).
Means that "Electrum wallet 1" should be able to open a channel by using "Electrum wallet 2" 's nodeid (and IP).
Ok than i missunderstood this, u mean the direct connection between 2 wallets with the same ln node or. I tried this out with an same endurance Node on both (local/remote) sides. Works flawless but may u mean anything else No, if you follow the previous conversation, it'll point you to the quoted reply in the post at the top of this page. It's all about direct connection between two Electrum, so there'll be no other node like " endurance" in between. If endurance node is involved, it's now: between Electrum1 and endurance; and, between Electrum2 and endurance This reply: -snip-
Thanks, that helped. Now I have the choice between two options one of which is Remote Node ID and this is exactly what I would like to use. But I'd like to have channel exclusively between two wallets I own, no middle-position node in between. Is that possible or the only way for me to have my wallets LN-connected is to establish connection of each of two wallets to one and the same known peer?
As you can see, what you've tried is always been possible and the " only way" if direct connection wont work. What he want is a direct channel between his two Electrum wallets, which doesn't work. |
|
|
|
-snip-
Would this work also on a non blank wallet? Or will it cause problems to have multiple active descriptors? There'll be only one active parent descriptor per script type of receiving and change derivation paths. If you imported another with " active: true", the original descriptor of that script type will be deactivated. For more details, go to my reply in your other post: /index.php?topic=5409926.msg61174577#msg61174577 |
|
|
|
Would this work also on a non blank wallet? Or will it cause problems to have multiple active descriptors?
Since it's not a blank wallet, it will be pre-loaded with active descriptors for Legacy, P2SH-SegWit, Bech32 ( SegWit) and Bech32m ( Taproot), plus another set for change. If you set a new descriptor as active ( the tutorial doesn't include active flags), it will deactivate the previous active descriptor of the same type, but your wallet can have multiple active descriptors as long as those are for different script types and for change ( internal) or not. Importing more descriptors will work but only the active descriptors will be used when prompting for a new address/change. The non-active ones will still be scanned for transaction/balance. |
|
|
|
Shutting down or closing Electrum while forward swap is ongoing will be an issue since your Electrum client acts as your lightning node.
-snip-
One more question, just to make sure that I'm understanding things correctly. I assume that this would also happen if I should do a “Reverse swap”. But would it also be the case outside of “swaps”, say if the party I'm sending an LN payment to is offline, or if I shut down after sending an LN payment but before they receive it (for whatever reason)? It depends on the timing. Because in 'Reverse swap', you'll just have to successfully send your lightning part of the swap to Boltz ( +fee that they'll use) and then an inbound on-chain transaction will be broadcasted. Since your part of the swap are all through lightning, it will take only a couple of seconds; once the on-chain transaction was broadcasted, you can safely close electrum while it's waiting to be mined. So in Reverse Swap, you only needs to wait for the on-chain transaction to be broadcasted ( status: "Unconfirmed", not "Local"). At that point, it's okay to close Electrum unlike in Forward Swap where you'll have to wait for your outbound transaction to confirm before Boltz initiate to send your lightning funds. |
|
|
|
Same here like I've mentioned, that confirmed that I'm not the only one having trouble establishing a channel between two Electrum.  Then i had the ability to spend and recieve ( even without an invoice ) between 2 testnet wallet without any problems. The issue was opening a channel between two Electrum wallets ( e.g. "Electrum wallet 1" as your Electrum wallet, "Electrum wallet 2" as remote node). Means that " Electrum wallet 1" should be able to open a channel by using " Electrum wallet 2" 's nodeid ( and IP). There hasn't been any issue with sending/receiving through lightning between two Electrum wallets as long there's enough channel capacity. |
|
|
|
I think I've figured out the problem and it's not what you think :-)
let me give you a little bit of background:
In order to crate a this particular wallet I was using "Brain wallets" (which is basically a sha-256 of a text), but I was using simple words like "black" and "white".
I think this simple "words" are part of a databases of "simple" KEYS, which could be easily generated from any source of "public common passwords".
That's because you didn't mentioned it in the first place. If so, anyone would figure that it's the problem since it's the very issue why brainwallet was discontinued. Even if it's a complex set of phrase ( actual phrase, not random words) or small set of random words, the outcome would be the same. For reference, there's list of cracked brainwallets: http://bitcointalk.org/index.php?topic=4768828.0 |
|
|
|
A good indicator of which members have a good reputation within the forum community is the number of merits a particular member has received.
Better yet, use the number of merit received by the particular reply as the indicator of a good advice. Because the merit displayed below the username can be misleading to newbies, it'll need a bit of research to see if most of it are " airdropped" or " earned" merit. |
|
|
|
I think his question is related to his other thread: http://bitcointalk.org/index.php?topic=5417467.0which is about recovering the old mined 50bitcoins of his " friend". Unfortunately, the block's ( 4111) coinbase transaction and the " generated" transaction displayed in his wallet doesn't match. |
|
|
|
This is a brand new address that I've created on a wallet that I'm developing and imported the WIF in electrum. Try to create a new key from your wallet, derive the testnet bitcoin address and fund that address without importing the WIF prvKey to Electrum. See if the funds will still be wiped out. If it does, then there's something wrong with your wallet. If it didn't, then it's your " Electron" or something between the WIF export->import. |
|
|
|
-snip-
Concerning connection issues, I can't see that it should have been the case at my end (unless... shutting down the computer? - I had understood that this could be a problem if I had my own node, which is not the case). If it's at Boltz's end that the problem lies, the fact is that Electrum doesn't give us another option. -snip-P.S. I hope this reply gets accepted - my previous reply got me a warning from a moderator which I wasn't able to understand for lack of familiarit with the terminology. Shutting down or closing Electrum while forward swap is ongoing will be an issue since your Electrum client acts as your lightning node. Electrum's lightning feature isn't custodial so it needs to be active to be able to receive lightning funds. But yeah, swap services doesn't always have a reliable connection. I've been experiencing downtimes sometimes or channel capacity issue in other instant exchange service and I think Boltz isn't an exception. For the mod's note, they just combined your two-in-a-row posts. |
|
|
|
So I get that you need to make a backup of the wallet every time you open a channel. But are these backups encrypted?
-snip-
Those are just " channel backups" which doesn't contain the wallet itself. I believe it's encrypted by the wallet's xpub ( CMIIAW) and it can't be imported to other wallets due to failure in decryption. For the save backup, it'll be the same as the wallet. If it's encrypted, the backup will be encrypted. |
|
|
|
|
Show Posts
