You don't need to do this, batch payments are quite a different concept in which you send many to many different addresses at once in one transaction, thus dramatically reducing your fees for the transaction. On Electrum, for example, you can do "send to many" which is quite convenient for the user. I had thought that batch payments would still require effectively (or near enough to) the same number of input and output scripts, resulting in similar amounts of data needed for the transaction. That is to say, instead of a lot of small (data size) transactions, you're sending one giant (data size) transaction, but the total bytes would be roughly the same. I had forgotten to take into account the saving that can be made from the "fixed" 10 bytes in a transaction. Given that a transaction has a size that is "approximately" (and I know this isn't entirely accurate) [181bytes*Inputs + 34bytes*Outputs + 10 bytes], I guess the 10 byte saving per "batched" transaction will add up if you combine 100 transactions in one. That is an effective saving of 990 bytes... which at fees of ~150sats/byte starts to add up pretty quickly... around 0.15 BTC!  It's not just that overhead. With individual payments, each transaction will have create a change output, and that change output is likely to be spent from for the next payment, which both leads to extra outputs and long unconfirmed transaction chains. Doing batched payments completely removes the need for a change output for each actual payment and reduces the risks related to long unconfirmed transaction chains. |
|
|
|
But my questions remain unaswered.
Is there a certain threshold where Core devs will add native UASF support? when is enough support "enough"?
No. Core does not just implement something because some arbitrary and easily faked metric (node count is highly unreliable due to the easiness of making thousands of "nodes") shows that "enough" people support a proposal. Many Core devs think that UASF is unsafe anyways, so unless the proposal significantly changes, it probably won't be implemented into Core. There is currently no indication or talk about implementing UASF into Core. Is uacomment same as running the UASF client?
No. The UASF client will enforce segwit signalling after August 1st. That behavior is not present in Core. |
|
|
|
That's your opinion. Thank you. We all have one. Some of us even have arguments.
It is my opinion, it is a fact stated in the asicboost paper itself: Through gate count reduction on the silicon AsicBoost improves two essential Bitcoin mining
cost metrics simultaneously and by a similar factor: the energy consumption (Joule per Gh) and
the system cost ($ per Gh/s). With the system cost being proportional to the capital expenses of
a Bitcoin mine and the energy consumption being proportional to its operating expenses,
AsicBoost reduces the total cost per bitcoin mined by approximately 20%.
Asicboost does not make existing GH/s somehow mine blocks faster without change the GH/s (in fact, it can't even effect non-asicboost chips because it is partially a hardware optimization). It makes the cost per GH/s lower. Can you explain why the old thread has been locked by moderation?
No, I can't. I was not a moderator at that time. It was probably locked because the topic was beaten to death. |
|
|
|
|
There is no signalling with UASF. You can show your support by setting the uacomment, but it does nothing with regards to actually activating segwit.
|
|
|
|
|
No, Asicboost does not make mining hardware run faster and somehow generate blocks faster. Your original question, assumption, and theory is still invalid; those "fast" blocks are due to variance in block finding. Asicboost does not make miners make blocks faster, just more efficient so they end up consuming less electricity and thus have fewer costs.
|
|
|
|
|
Yes. It has been like that for a long time, and that is actually what is supposed to happen. Many of the Core devs have a Bitcoin Developer badge. Others who are considered experts such as Peter Todd have a Bitcoin Expert badge.
These badges only appear in the Dev and Tech section because that's where knowing the people who know the technical details matters.
|
|
|
|
|
It's a problem with blockchain.info, not anything to do with the Bitcoin network. They are improperly interpreting the output data. The output is a p2sh address, so the 3... address is the right one. For some reason, without showing all scripts, the website interprets the hash160 as a p2pkh address instead of p2sh.
|
|
|
|
|
The Bitcoin Core data files (including your wallet) are not deleted when you uninstall and reinstall Bitcoin Core. Furthermore, you cannot change your password or access your Bitcoin without knowing the previous password. Reinstalling Bitcoin Core is not going to change that. If you have forgotten your password, your Bitcoin is lost. The password is tied to the wallet file, not the install of Bitcoin Core.
|
|
|
|
How to uninstall bitcoin core without losing the data, in Lubntu Linux. I installed by downlowding the tar file, not an installer, and now want to uninstall so I can then insatall the earlier 0.13 version as the current one doesn't let me make payments (broadcast) using armory ?
I read that I just need to overwrite the binaries but it's such a a pain to overwrite or remove/add anything from the usr protected folders in linux...
You uninstall it by deleting the files that you extracted from the original tar file. Or you can extract the 0.13.2 tar file the exact same way you did with the 0.14.0 tar file and just overwrite anything that conflicts. Either way, you won't lose any data or any of the blockchain since that is stored elsewhere. |
|
|
|
|
It depends on who is running the bounty. If it is a thing on this forum, then usually you do whatever the bounty calls for and the person who made it will send you the Bitcoin to your wallet. If it is on some other site which manages bounties, then it depends on what the site does and you should ask them there.
|
|
|
|
|
What exactly do you see? Do you see any error? If you look in task manager, do you see the bitcoin-qt process after you try to open it? Can you please provide the debug.log files?
|
|
|
|
1. Using bitcoin-qt one can enter password with spaces in the window to decrypt the wallet. How to do it with bitcoin-cli? Imagine a password is 120 130 140 (two spaces between the numbers), if I type walletpassphrase 120 130 140 150 will bitcoin-cli interpret 120 130 140 as password (with two spaces) and 150 as timeout?
No, that will not work. You have to surround your passphrase with quotes, so like walletpassphrase "120 130 140" 150 2. What if spaces are at the beginning and the end of password? How to send such phrase using bitcoin-cli (in GUI when typing spaces arrows appear, so I think GUI normally "sees" those spaces). Thanks!
Again, use double quotes around your entire passphrase. |
|
|
|
How to send passphrase to bitcoin core using bitcoin-cli in Linux terminal? I've got my decrypted wallet and would like to check which of the passwords is correct by sending passphrases via bitcoin-cli. What commands should I use? Thanks.
Do you mean the password that you use to unlock an encrypted wallet? If so, you have to use walletpassphrase <passphrase> <timeout> where <passphrase> is your passphrase and <timeout> is an amount of time in seconds to keep the wallet unlocked. |
|
|
|
1) Can "G" get his money settled
on the main blockchain by closing out his channel
with F, even if the other 4 channels remain open
indefinitely?
Yes. 2) What happens to A's money that
she sent to G if she never closes
her channel with B?
G received an amount of money that A owed to him. A's money technically went to be. 3) What are the implications for B,C,D,E,F ?
Nothing. |
|
|
|
|
You should upgrade to Armory 0.94.1 at least. You can also use Armory 0.95.1 but you will have to downgrade Bitcoin Core to 0.13.2.
|
|
|
|
|
What version of Armory are you using? What version of Bitcoin Core are you using?
Try running Bitcoin Core manually if you aren't already. Go to File > Settings and uncheck the box "Let Armory run Bitcoin Core in the background" and then stop Armory. Start Bitcoin Core then start Armory again.
|
|
|
|
I see.
So if you receive a block that has a transaction in it that was not in your mempool but was included in the block, does that transaction get added to your mempool and then shortly removed once you finish validating the block?
No, that would be unnecessary. |
|
|
|
|
Can you post the debug.log (if it exists)? Have you tried setting the rpcport to be a different port? What do you have set in your bitcoin.conf file (if it exists)?
|
|
|
|
1) Is asicboost a hardware or software optimisation?
As I understand it, both, but the effect is more greatly seen in hardware optimization. With hardware optimization for asicboost, you will still need corresponding software to perform the preprocessing. According to my current understanding, asicboost optimizes mining through forming a merkle root of special kind. That sounds like it should be implemented in software? Does hardware need to be designed in special way to take advantage of optimized merkle roots? If so, can such special hardware be used to mine regular, unoptimized blocks?
There are two forms of asicboost, overt and covert. The overt form involves changing the bits in the version number and that is pretty obvious to see once the block is found, hence it is overt. The covert form involves finding multiple merkle roots which collide in the last 32 bits. The way that asicboost works is that it takes advantage of the way that sha256 processes data in order to use the partial hashes of previous block headers when calculating the hashes of multiple block headers so it reduces the number of calculations that need to be made, which in turn makes the mining more efficient. 2) Is asicboost (as the name suggests) applicable only to ASICs (not to GPUs, FPGAs)? If so - why?
The most gains can be found in ASICs because the mining circuitry can be changed to be asicboost circuitry which has less logic gates and is thus more efficient. 3) Does observing of empty blocks from a miner increase our suspicions of asicboost being used?
I guess, that since they need a special merkle root, it may happen, that an empty or almost-empty block provides a necessary merkle root, so they just keep mining such an empty block until it is mined or an optimized merkle root found for a filled block, whichever happens first?
Possibly, but given that empty blocks still happen without asicboost, it isn't really an indicator of much. 4) If it's all about special merkle roots, why couldn't we detect asicboost optimized blocks just by analysing the blocks and their merkle roots?
The covert form of asicboost involves merkle roots. It involves finding and having multiple merkle roots which collide in the last 32 bits. However, because miners only broadcast their final block, outside observers cannot know what the other merkle roots that they have tried and whether those collide. Since we don't know anything about the other merkle roots, we don't know if they are using covert asicboost. If they use overt asicboost, it is very obvious; the block version number will be all messed up. |
|
|
|
|
Show Posts
