And would adding more miners (supply) increase or decrease the transaction time?  Yes. If you have more miners, or rather hashrate, then the rate of the blocks being mined increases, until the difficulty readjusts. The network attempts to keep the block intervals at 10 minutes. It would have the most impact if the hashrate is suddenly increased right after the difficulty adjustment. The main crux of the issue lies with the capacity of Bitcoin. Each block is limited in size and a block is usually mined at an average of 10 minutes. This means that for every block, there can only be so many transactions being included and confirmed. Having a long wait before a confirmation is usually a result of the lower fees being paid. |
|
|
|
But that doesn't make any sense, the seed phrase are shown on their application so they should be able to see my seed phrase and use it to recover and access to my funds right? How come these wallet providers don't know my seed phrase when they are the one giving it to me?
The randomness required from the seed phrase is generated on the computer itself. Although the seed phrase is shown in the app, the seed phrase should, at no point in time, be transmitted out of your computer. Wallet providers DO NOT generate your seeds, the seed is generated on the computer and in the application itself. |
|
|
|
I see some "ThreadRPCServer method=getblocktemplate user=myusername" and "ThreadRPCServer method=getwork user=myusername"... I believe this behavior should be correct to probe to decide which mining protocol should be chosen....getblocktemplate should be selected because that is the latest protocol...according to a doc I read, cgminer is the one that support GBT as well....
Well...I am kinda lost...."No GBT coinbase + append support found, pool unusable if it has no stratum " ..this message I guess it doesn't kinda make sense why cgminer is showing...
I'll revisit the issue in a bit and see if I can get a fix for it. Can miners select which transactions they want to include to mine in order to create a block?
They can. Most pools uses their own software which has specific parameters to choose the specific transactions to mine. 1. When the request is made, the bitcoin-qt server sends all unconfirmed transactions from mempool to the miner client? or there is some behind logic that the server choose some transactions based on the blocksize(which is 1mb)..then send only up to that size?...if so..how the bitcoin server determines which transactions should be included to send out?..based on time?? based on fees?.....
See getblocktemplate RPC. Bitcoin Core assembles the transaction to send to the miner. By default, Bitcoin Core selects the highest fee rates first, if the user does not specify transactions to be prioritized over the rest. 2. So basically, what the miner tool does is that they take all these transactions that they received to try to create a block?
To assemble the block header and start hashing it while changing the nonce or other parameters during each try. I looked at the couple of miner tools, but I don't see some way to select some transactions based on maybe some fees?
3. So...If they can select some transactions, does that mean there are some other GUI tool out there that shows those transactions received from the server...so they can check checkbox to include only some they want..maybe?..then start mining for those selection only?
The assembly of block for Bitcoin Core is defined here: https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp. I don't think any of the mining software will intentionally exclude any transactions. Any transaction exclusion should be done from the server, not on the mining client itself. |
|
|
|
Ok.. Thanks for the info..then is there any alternative tool I could use like cgminer that works with 0.21 Bitcoin core then?
I tried bfgminer(I guess this is sort of like brother with cgminer), but it doesn't still work...
Any other tools I could possibly try?
I'm not exactly sure. I downgraded by Bitcoin Core and stopped trying to mine after that. CGminer hasn't been maintained for quite awhile as well. BTW, I was jut curious about some detailed error message of 500 ...Is there any place where I can possibly look at more detailed error message why the bitcoin-qt returns 500 ?
I noticed that under testnet3 folder, there is a debug.log... Is this something I can look at here? but it looks like this file wasn't updated when i made a request from cgminer then...
Any help would be appreciated someone could point out that if there are some logs file I could look at?
Thanks,
Add debug=rpc into bitcoin.conf in that testnet folder and try to connect again. The logs from RPC interaction should be logged into the debug.log in that folder. |
|
|
|
I tried doing this and got this error from Electrum 3.0.6 when attempting to sign the transaction I created in 3.3.8:
Electrum was unable to deserialize the transaction: unpack_from requires a buffer of at least 4 bytes
I read through the release notes between that and I found that the format was actually changed slightly in 3.2.0 which results in the raw TXes being incompatible. If you don't mind, you can manually script the raw transaction using Coinb.in. Just key in the addresses which contains the funds and structure it exactly like the raw transaction that you were trying to sign (ie. the same output amount and the same transaction fees). Afterwards, just press Submit for the raw transaction and use your Electrum 3.0.6 to sign. That should work fine. |
|
|
|
I have already known the difference very well now, but what if I transfer from legacy to legacy addreses which is a raw transaction, the sat/byte will be equal to sat/vbyte? Which will be the indication that no fee is reduced.
Yes, when you're spending from inputs associated with legacy address. There will not be any segwit discount as there's no witness in the transaction. The virtual bytes of the transaction will be equal to the raw bytes of the transaction in that case. |
|
|
|
I mean, if miners want to include it to a block, will they use /vbyte or /byte?
The correct answer is that no one knows. Miners can choose to include certain transactions first for their own reasons and completely ignore the ordering of the transactions that they see. The way that they select the transactions might not even be strictly considering fees/size at all. The logical answer is that if they want to maximize their transaction fees collected in a block, they would choose to include transactions based on fees/vbyte instead of strictly fees/size. Mempool sites like these represents the fees in terms of fees/vbyte. |
|
|
|
|
Blockchain.com uses raw size for the satoshis/byte and is thus inaccurate. You should be looking at the size/WU(Weight unit) for a better representation of the fees. Miners will usually consider fee rates in terms of vbyte and not it's size. Your transaction will stand a chance to get included once the 1vMB from tip of mempool falls to 5sat/vbyte and below.
|
|
|
|
bitcoin has 0 carbon footprint because it is a network and bitcoin nodes, wallets, and bitcoin miners don't produce anything at all.
the electric companies on the other hand that are producing electricity have a terrible carbon footprint. so maybe you are asking the question in a wrong place!
Electric companies produces electricity to satisfy the demand created by Bitcoin miners. The existence of Bitcoin incurs carbon footprint; nodes, wallets and miners all uses electricity. It's like blaming the airline companies for their horrendous carbon footprint but not the travelers who creates the demand for air travel. I really don't think this is an issue with Bitcoin in the first place nor would limiting the miners help. It would just make Bitcoin less secure. |
|
|
|
it is not a recommendation to change the letter cases when turning them into QR code, it is an option that exists to server very special cases like if you wanted to print the address on a very small surface like a physical bitcoin otherwise it is best to stick to lower case because the other wallet that reads it may not be as sophisticated to recognize upper case!
For presentation, lowercase is usually preferable, but inside QR codes uppercase SHOULD be used, as those permit the use of alphanumeric mode, which is 45% more compact than the normal byte mode.
It's specified in the BIP though. I don't think it's difficult for wallets to change it back into lowercase. Definitely not necessary and wouldn't affect normal use, just wanted to align with the BIP. Bitcoin Core is one of the many wallets that represents both their URI and QR codes in caps. |
|
|
|
It's possible, but even using small interval (last month), the lowest value on Y-axis is 170000, not 0.
Yes. It's only 0 on the day itself. They only update the transaction count the following day. |
|
|
|
No more further explanation that bech32 addresses can either be in capital or small letter, but according to all the wallets I have used before, the bech32 addresses are in small letters and numbers, which should be the recommended way. Some people may want to change it to capital, this might lead to typo error, even if bech32 address can still point out few typo errors, it should not be recommended if the wallet someone is using uses small letter which I believe is the standard wallets are using which makes the QR code have smaller field.
The way bech32 is designed is to make the address standard unambiguous. Those lookalike letters have already been eliminated and standardizing all of the characters to either be in uppercase or lowercase will reduce the chances of typos. It's fine for them to be represented in uppercase. There is absolutely nothing wrong with representing them in uppercase. Wallets like Electrum will automatically convert it back into a lowercase string if you enter an address in uppercase. AFAICT, some wallets like Electrum represents bech32 addresses in lowercase when using the QR codes; nothing wrong just that not all follows the recommendation. |
|
|
|
|
Not possible. Miners are not regulated on a protocol level and anyone can relay a block if they can find a hash of the block header that satisfies the target.
Block interval is regulated by the difficulty, a higher network hashrate would result in a faster block interval given that the increase is after the difficulty retarget. High transaction fee is a result of the fee market consisting of the transactions that are sent by the user.
You cannot restrict the number of miners with the way Bitcoin protocol is designed.
|
|
|
|
but as for node of blockchair.com, i speculate many transaction was dropped (one possible reason is the transaction is on mempool more than 2 weeks) because the transaction count isn't dropped to 0. Isn't that due to them not updating the chart in real time? By using a smaller interval, the transaction count on the day itself is always zero and if you check it the next day, it'll be as per normal. The reason why it looks like there's a huge drop only happens if you select a larger interval and the (0) transaction count on the day itself affects the chart towards that day. https://blockchair.com/bitcoin/charts/transaction-count?granularity=date&interval=3m |
|
|
|
1) Maybe when I tried to recover from my seed , I mistyped or misentered the phrase, causing myself to recover to a new but empty wallet?
But this is not possible because there is a checksum on the pass phrase. If any word is wrong, or even the sequence of the word is wrong, the checksum fails and cannot go through.
The checksum rule is not always obeyed with all of the wallets. There is also still a chance that your mistyped or mis-copied phrases still matches the checksum even with the error. 2) I might have accidentally created a new wallet instead of restoring? I installed the old version of MyCelium on a simulator, after creating a new wallet the screen will not prompt me to back up my seed. However, under "Accounts" there'll be a red-font warning that no backup was created, and if I had tried to create a PIN Lock (which I usually do), it would require me to backup my seed first before allowing a PIN lock to be created. So, it is almost impossible for me to have created a new wallet plus having a set of new seed without myself remembering anything about it.
So the mystery remains - where are my coins lying in now if it cannot be in a new wallet yet not in my usual wallet?
It's more likely that you are actually restoring the wrong seeds. I can't think of anything if you have tried loads of deviation path and increased the gap limit. |
|
|
|
|
CGminer was broken with Bitcoin Core's RPC when I upgraded from 0.19 to 0.20.0. The problem likely persisted till 0.21.0. Downgrading it back to 0.19.0 helped me to solve the issue.
I didn't try to fix the problem with 0.20.0 but that could probably be fixed by running a stratum proxy in between.
|
|
|
|
|
Can you get the master public key of the Trezor?
You can download a Electrum 3.3.8 to import the master public key and create a transaction from there, transfer it to an offline instance of Electrum 3.0.6 and then sign it from there before transferring it back to Electrum 3.3.8 to broadcast. Electrum 4.0.1 and above has incompatible raw transaction formats with older versions.
|
|
|
|
1) Is that a guaranteed way to recover all coin from a seed phrase, regardless of where the coin is hiding (e.g. derivation paths, gap limit etc)
You don't have to try any other derivation path, just importing it back into MyCelium should suffice. You have to know both of them in order to recover the funds. Gap limits should be unchanged on MyCelium, derivation path should follow BIP44. Is there a problem with just importing it in MyCelium? If it isn't there, then you might have the wrong seeds. |
|
|
|
|
They shouldn't. Wallets are not supposed to transmit the seeds to any external servers. The entropy for the seeds should be generated on the computer, then no one else should be able to access your seeds.
|
|
|
|
Zero transaction fees are no longer feasible. It was calculated with the coin age as a factor a long time ago before it was removed. The inputs amount was also taken into consideration [1]. There is really no point to try to allow for free transactions to be relayed. The mempool is frequently being pushed to it's limits and it's fairly pointless to reserve any of it for free transactions; miners would rather choose the paid transactions. [1] https://en.bitcoin.it/wiki/Miner_fees#Historic_rules_for_free_transactions |
|
|
|
|
Show Posts
