Here's my entry for "Hand-Drawn Art" Category: Roobet Username: nc50lcBitcoin Address: bc1pp2sq0td55g7y595hecg50r93fyajcddp5ct8jlmvhyahfhau546srcfu5m
| Scanned Image: | Camera Capture (low lighting): | |  |  |
( Materials: Pencil, Pen and Colored Pen | B5 Size Paper - Sketch Pad)
Note: feel free to copy the posting (BBCODE) format but don't forget to replace my username, bitcoin address, links and images. |
|
|
|
There is 1 node with multiple wallets. Each family member uses the same node. I opened the "lightning terminal" then navigated to Connect => Lightning node connect, created a new connection choose "custodial account" and scanned the QR with ZEUS wallet. the node, channels, liquidity is same for everybody. How about channels?
Does each of your family members has separate channels connected to different lightning nodes?
Okay, so the statement in the OP now checks out; it's a " custodial account" setup where your node is the custodian. AFAIK, each custodial account should have a " virtual balance" that's managed by your lightning node rather than actual channel capacity. Unfortunately, now that it's clear, I came up with the same question why it was routed. Is this consistent to other transactions between your custodial accounts? If not, investigate the wallets where it occurred, both sender and receiver. |
|
|
|
I have one node and this node has multiple wallets for family members.
How about channels? Does each of your family members has separate channels connected to different lightning nodes? As far I know in this setup the sats of the family members are sitting on my node until they are sent outside, I thought that transaction between the family members would be just some "accounting entry" on my node without sending out and in the sats through some other nodes.
It's the channels that hodls the bitcoins, not the lightning node. The lightning wallet just shows the accumulated capacity if the channels it manage but it's actually broken down per channel. Sending requires the node to calculate an optimum route from your channel to your brother's channel. So my guess without any info about your setup: it may have found that routing it through the channel connected to ACINQ's node is cheaper than Bratislava. Or there's an option that disables routing through your node so it used other channel's node to route. |
|
|
|
Note that this worked for wallets created even some after some years because I reckon doing this and it worked. Not sure if this works with modern wallet.dat files but should be good for your case being a 2010 file.
The new SQLite " descriptor" wallet.dat files also contain that human-readable string followed by an address. So ( only) for initial checks, that method should still work. This way you can save yourself having to sync the node to find out. But to be 100% sure I guess you should.
Syncing is still more reliable. Because if the wallet.dat is a backup when the wallet isn't used yet or the funded address is used after the wallet backup is created, you'll only get false-negative result with that " text editor method". |
|
|
|
My question:
1. Aside the unspendable 50btc, can the remaining btc be spent assuming Satoshi has the private key?
2. If Yes, give your reasons. If No, also share your reasons
3. Are the unspendable coins limited to only the first block (Genesis block) ?
4. If the first reward (50btc) was intensionally transformed to unspendable coins by Satoshi, does that mean that our current developers or miners can also do thesame ?.
- 1. & 3. Yes, just the genesis block's coinbase transaction output, not those other transactions.
And it's not even related to the address in question because it's P2PK; "Pay-to-Public-Key" which basically means (in layman terms) that it's sent to a public key rather than an address.
Most Blockexplorers just link P2PK outputs to the address derived from its public key. (your screenshot)
So the main reason for this topic doesn't make sense in a technical perspective.
- 2. Since yes, those other UTXO are unrelated to the transaction output in the genesis block, those are basically regular outputs.
If someone owns the private key or if someone managed to produce the same hash from a different public key that they own, they will be able to spend it.
- 4. No one asked if it's purposely made non-spendable.
And if you mean by "do the same" to new coinbase transactions or ordinary transactions, then no.
It's not transformed in some special way, the output is the same as other P2PK outputs.
But the problem is any client that the majority of Bitcoin nodes use is designed to not include it to the UTXO set (chainstate),
so even if you can spend it, nodes wont find that UTXO from their database.
|
|
|
|
File "electrum\util.py", line 1131, in make_dir
PermissionError: [WinError 5] Access is denied: 'C:\\Windows\\SysWOW64\\electrum_data'
Why would you put an Electrum-portable executable in " SysWOW64" folder? Of course, it wont be able to write the datadir in that protected Windows installation directory. You can either: - Move the portable electrum exe to a "normal" folder like "C://Program Files" (requires Administrator access) or to other partitions like "D:/".
There, Electrum-portable will be able to create its "electrum_data" datadir where settings, wallets and other data will be saved.
- Or download and use the "Installer" (install it) or the "Stand-alone executable" so that the electrum datadir will be saved to its standard directory which is in "%appdata%" (roaming appdata)
Not mandatory for new Electrum download, but recommended: bitcoinelectrum.com/how-to-verify-your-electrum-download/
|
|
|
|
To add taproot support, what do they need? Is Taproot so difficult to implement?
Depends on the number of developers working on it, but it's not as simple as adding another address type since it uses a different signature scheme than the older script types. Based from the commits list, there are only 2 to 3 active Electrum core developers with a few PRs from contributors. If it's just sending to TapRoot and creation of imported ( non-HD) watch-only wallet containing TapRoot addresses, then it's already implemented. Would support for descriptors be one of the requirements for P2TR addresses to be added to Electrum?
The core developers aren't fond of discussing about its progress here: github.com/spesmilo/electrum/issues/7544But if you check Electrum's milestones backlog ( link), you can see that they're going after output descriptors. First part towards that goal is already merged: output script descriptors, part 1: change API of transaction.py #8230 |
|
|
|
|
At this point, I'm convinced that the last few arguments are just pure misunderstanding due to mistranslation.
What I got from your last reply is you're talking about being able to receive through your lightning channel after doing a reverse swap which is what's to be expected.
But the previous reply sounds like it required you to send small transactions before you can preform a reverse swap.
The issue is practically solved by the looks of it, it's just "language barrier" like my previous assumption.
|
|
|
|
unfortunately i still miss the support of silent payments...
This requires TapRoot to be implemented first so you might not see 'Silent Payment' related updates in the next release or until TapRoot support is implemented. But Electrum is slowly getting there since some of the necessary TapRoot-related code are already implemented, just not being used yet. For Silent Payment specifically, there's only this one Feature Request: [ Feature Request ] Implement BIP352 sendingtoday the 3.5.5 version of Electrum has been released Typo here. |
|
|
|
-snip-, this wallet is mainly on xverse and imported to electrum, i tried adding 5 new accounts in xverse and i still didnt find it in any of those new or old existing addresse's.. and i couldn't view all my receiving wallets in electrum,,
That's because Xverse ( inaccurately) labels each of the derived receiving addresses from your seed phrase as " Accounts", So when you create Account2, it'll only show your second address as Account2's address. And it does not use " Change Address" so the output of your CPFP transaction in Electrum wont show in Xverse no matter how many accounts ( receiving addresses) you generate. what i did is electrum combines all amounts in all different address under the same seed into 1 transfer, so i made a transfer with the full amount in that seed to an other address and it turned out that the transaction added that amount to a new address, it was hidden in a new account that i couldn't find,, now its processing the transaction..
Send " Max" worked since it didn't generated change. But in cases where the user doesn't want to spend all of the UTXO just to spend the associated UTXO with the change address; The 'Coins' or 'Address' tab ( View->Show Coins/Addresses) can be utilized for " coin control" to select that specific UTXO to spend in that max send transaction. |
|
|
|
And so on… it takes up all the rows A1-A2000 on most of the files. It’s only data in the A column on the csv file.
That could happen when a " .txt" file's extension is renamed into " .csv" file. Each line of the text file will be inserted into the first column ( A) of its csv file counterpart. That's unless the csv file is specifically written on its column A exclusively. And since your old post was deleted, I'll re-insert my reply here in your new thread: the guy i bought it from transferred it off a 8gb flash drive straight into my computer.
-snip-
This still needs its own topic, so please consider starting your own thread if you want to push the discussion towards that bought csv file. Its similarity to OP's " probably bought wallet/file" doesn't make this on-topic. By the way, 100% of those 'for sale' wallet.dat or " lost" backup files are scam, don't expect anything from it. As you can see in others' replies, the consensus here is you're most likely been scammed. |
|
|
|
A few years ago, I made an armory account -snip-
How about your " Printed Paper Backup"? The one containing the " Root Key" which should be enough to restore your wallet to Armory with a new password that you want. Armory kinda forces you to create a backup during wallet generation, skipping would require user confirmations with warnings about skipping it. ModuleNotFoundError: No module named 'cPickle'
That is a module used by the Gurnec's ( old) version which isn't available ( renamed) in Python 3.x Use the updated version by 3rdIteration linked in BlackHatCoiner's reply. If you still want to use that old version, use older version of Python ( v2.x) instead, but that's not recommended. Additionally, if you still haven't: you must install the requirements first before you can use BTCRecover. Use the list provided by BTCRecover in " requirements.txt" file. Example: python -m pip install -r "path_to_requirements.txt" |
|
|
|
|
I can't reproduce this in RegTest, Bitcoin Core v27.0
Steps done are: Create a descriptor wallet with default args -> receive BTC -> generate coins (using another wallet) it until it has 6 confirmations.
getbalances shows it under "trusted" balance.
listunspent command shows the UTXO.
It's working as intended.
The only way it happens at my end is when I purposely lock that specific unspent transaction output with lockunspent command.
Can you try listlockunspent?
|
|
|
|
-snip- This could be as simple as a built in fee to break the reward among X miners that scales to the amount of miner addresses within the pool, or a new way of operating the bitcoin mining entirely.
Unfortunately, that's entirely at the pool's software side. As far as the Bitcoin network is concerned; how miners and pools work to find a valid hash isn't important Because nodes only need to verify if the newly broadcasted block is valid, e.g.: its block header's SHA256d hash is lower than the target, etc. The network doesn't know if it's from a pool with 15 miners, a huge pool with 1000 miners or a solo miner aside from " hints" in the coinbase transaction that the miner/pool may include of their own accord. |
|
|
|
-snip- Beyond this, several answers report that the reindex cannot be cancelled, so I am unsure of how to solve this issue. Is my node fried? Is there a way to change my 'dbcache' mid download
It should continue where you left it. Probably, those reports have restarted Bitcoin Core without removing --reindex arg, doing so will restart the reindex process from start. If you closed Core properly ( ./bitcoin-cli stop) and considering that there's no other issue, then, your node should resume the progress when you shutdown your node. But it should be SOP to check the logs before using commands like --reindex since it may not be the best solution that you need. And now, there should be an indication why it's stalled or at least tell that there's no issue but slow sync progress. |
|
|
|
Hello. Without doing anything, after a while, when I went to the Lightning Swap section, I was surprised to see that it was possible to increase the receiving capacity. It was probably just your connection to Electrum's official swap server or a temporary issue in the server. ( as seen in the screenshot) -snip-
It should be noted that you need to send some small transactions to activate the receive transaction.
Sending a small amount has nothing to do with being able to reverse-swap ( Send LN -> Receive on-chain) since all it needs is enough sending capacity on your channels. And your on-chain wallet isn't limited by you channel( s) on how much it can receive from the reverse-swap. |
|
|
|
This almost made it to Bitcoin Core's next major release v28 but was dropped from the priority list to be replaced by another update. There's a " Tracking Issue" for those who want to see when this will get implemented in the reference client, currently at 4/15 tasks completed. Link: BIP352 tracking issue (issue# 28536) |
|
|
|
But it's strange my friend said he only received 0.00023053 BTC. So the fee did increase a lot, is that possible?
He send me a SS and would never lie to me and he have Trust Wallet if that's mattes, but it does not matter.. a funny experience and thanks to Nc50lc for explaining even tho I didn't do a thing. this forum is fucking the best! 🥇
Just compare the " Transaction ID" ( TXID) of the transaction that he screenshot and the old transaction that's rebroadcasted yesterday. The " 0.00023053 BTC" transaction must be from someone else. Somebody must have followed the instructions that I've provided and rebroadcasted the transaction without informing you. Anyone can do that since it's already a signed raw transaction that's ready to be included to a block, but no one can edit any information from it like the amount ( to change the fee) without having access to your private key to create a new signature based from the edited data. FYI, I didn't broadcast it yesterday in case you want to create a replacement with your own address as the output ( option1) Then I also checked if it's in my node's mempool and other blockexplorers, and it's not existing there aside from Blockchain.com's database/mempool. |
|
|
|
-snip-
I understand that this mining is unprofitable and useless on both a computer and a laptop, but is it possible to run mining on Windows for fun?
It's easy with your laptop's CPU: - Launch your Bitcoin Core node (fully synced)
- Use the command generatetoaddress <number of blocks> <bitcoin address>
The command is designed for " RegTest" but it'll also work in mainnet, it's just your CPU ( as you know) isn't enough to mine a block. It will " mine" with 1000000 iterations by default which is easy to exhaust even with slow CPU. So, add a third argument, e.g: generatetoaddress <number of blocks> <bitcoin address> 2147483647 to mine with the maximim possible number of iterations. There'll be no result if it didn't succeed ( returns the [block hash] if success, otherwise "[]") and there's no visible GUI element while mining; So it's not " Fun" IMO, but it's definitely mining in the background if you check your Windows laptop's Task Manager. Ref: https://github.com/bitcoin/bitcoin/blob/327f08bb0cd91a22249395adeb34549e3c86ca76/src/rpc/mining.cpp#L255-L294 |
|
|
|
What I want to do is to reverse the transaction, but if that not possible just send it (it's to one of my best friends) and I already paid him one more time long time ago of course.*
The second option is very easy, just get the raw transaction hex saved by that blockexplorer. Use their API, type this URL ( containing your TXID): https://blockchain.info/rawtx/1b14560ebb55e692d17138a4996cc0c79624484fcc44a6f3fb4d2f517b5d8618?format=hex And it will output the raw transaction hex that you can broadcast to other blockexplorers ( example) or your wallet. I wont broadcast it myself to give you freedom to choose what to do. I've just tested it on my node to see if there'll be no problem broadcasting the transaction: testmempoolaccept '["0200 -snip- 0000"]'
Result: [
{
"txid": "1b14560ebb55e692d17138a4996cc0c79624484fcc44a6f3fb4d2f517b5d8618",
"wtxid": "13f2925240c3a1b197c8912cd8a7c7af501903d16b5d4d46bb52dc04dd0b2728",
"allowed": true,
"vsize": 178,
"fees": {
"base": 0.00003605,
"effective-feerate": 0.00020252,
"effective-includes": [
"13f2925240c3a1b197c8912cd8a7c7af501903d16b5d4d46bb52dc04dd0b2728"
]
}
}
]
Note: broadcasting that will make the first option harder to pull-off.
For the first option; restoring the seed to other clients that supports " coin control" except those who use Blockchain.info's API should be sufficient since the transaction is already dropped by the majority of the nodes. Use coin control ( e.g.: in Electrum) to choose the same input as that transaction and use that to make a new transaction. |
|
|
|
|
Show Posts
