Version 2 transactions are the new standard. Bitcoin Core by default makes v2 transactions. A transaction must have a version number of 2 or greater to support OP_CSV.
|
|
|
It returns null if successful.
|
|
|
Suggest a BIP that renders Asicboost impractical?
Such a BIP was already proposed. The best thing Bitmain could do to convince people that they don't use covert asicboost is to support said BIP and not go and attack the author of said BIP (which they have unfortunately done).
|
|
|
after segwit is activated, is it possible to revert the change and soft fork back to without segwit? or will the technical debt be too high to do that too?
Reverting a soft fork requires a hard fork. It has nothing to do with technical debt.
|
|
|
You get the block reward when you find the block. The block reward goes to whatever address you have it set to go to. This is either set in your mining software or in whatever node you are using behind the mining software. You won't be able to spend the block reward until 100 blocks have been mined on top of your block.
so i still have to mine the 100 blocks for me to be able to spend this block? No. You don't have to mine 100 blocks, the network does. The network must extend the blockchain by 100 blocks on top of your block.
|
|
|
You get the block reward when you find the block. The block reward goes to whatever address you have it set to go to. This is either set in your mining software or in whatever node you are using behind the mining software. You won't be able to spend the block reward until 100 blocks have been mined on top of your block.
|
|
|
I remembered that once you removed account "price" from btctalk estimator and why do you add it again? To my mind previous action was better because buying/selling of btctalk account don't seems good action and trusted members hate that.
I never removed that part of the site. What I removed was displaying the "post quality" data. Also you said that price isn't depened on exchange rate but than isn't there any fixed rate?
The estimation is in BTC. It is a fixed rate per activity point plus a different rate per extra potential activity.
|
|
|
Interestingly the price of my account has gone up in the past couple of months by around 10 dollars. This is despite the price of Bitcoin going up. I agree its not a lot of cash, but I still dont understand the baseline for the estimate. Where is the baseline price coming from?
The estimations the site makes are not in any way related to the exchange rate of Bitcoin. Read the OP for how the prices are calculated. It's based upon your account's activity number.
|
|
|
The entire point of covert asicboost is that it is covert,
I don't think that is true. It's one of the problems with calling it "covert AsicBoost". It gives the false impression that it is "wrong" or "bad" or "secretive". The entire point of AsicBoost is to generate SHA256 hashes as efficiently as possible. The point of "covert" instead of "overt" is that with "covert" you don't need to make a mess of the block version number (which is better used for actually keeping track of the block version). The fact that it is not easy to tell that a block was mined using the "covert" method is a side effect, and not the point. Well covert asicboost requires more computing power than overt asicboost. You need to find several merkle roots which collide in the last 32 bits and this requires more computing power and more memory than overt asicboost. That additional requirement makes covert asicboost less efficient than overt asicboost. I would think that a miner would want to use the more efficient overt asicboost method to get the most performance gains as possible rather than using the less efficient and more taxing covert asicboost unless they are trying to hide the fact that they are using asicboost.
|
|
|
So batch payments seem to be the way to go. However, this creates some questions to which some may already have found an answer:
A business plan is - of course - always very optimistic... so I have started with some few clients. They will get some Satoshi on your wallet address every week. There will be a minimum amount before you can withdraw this.
If there are only 5000 clients, this shouldn't be a problem. But what if there would be a million clients - in this case, I assume, it would make sense to use multiple wallets - not only for security reasons, but also for not cloaking the network with one huge transaction. Or do I get this wrong?
Large transactions take a long time to verify and propagate, so there is a point where you should use multiple batch payments instead of one gigantic one. Another question is: Has anybody experience how many clients would be ideal to include in one batch payment? Is it more depending on the amount of the payments or the number of payments in the batch?
It is entirely dependent on the number of payments you make in a transaction, not the amount. The only time the amount matters is if you have an output that is below the dust threshold.
|
|
|
Is it even a possibility for UASF to force segwit activation without devs or miners, and then we can all switch back to core code after activation?
Yes, you can do that. UASF only requires that all blocks support segwit after August 1st and that will cause segwit to activate in Core so long as UASF does not cause a chain split. The UASF client does not change how segwit is activated in regards to BIP 9 signalling.
|
|
|
You should watch your language and be respectful...at least when you use your moderator account.
Obviously anyone opinion is welcome, but better to keep one user account for moderation and another for your own opinions.
No. I only use one account for everything, both for my opinions and when I moderate. It is very clear when I speak as a moderator because the only time I do is when I moderate, and right now, I have not done any moderation action on this thread. Staff members using alt accounts is frowned upon. I think you have been the only one to mention "asicboost". Do you have any statistical evidence for the possibility you claim?
Reverse engineering has found that the mining chips used in Bitmain's Antminer S9's and R4's (and perhaps more, I don't know off of the top of my head) contain the circuitry necessary for asicboost to work. It was also found that antpool and the publicly available firmware for the antminers contains the codepaths and api calls necessary for overt asicboost to work, and in fact people have managed to get their miners to use overt asicboost. See https://www.reddit.com/r/Bitcoin/comments/63yo27/some_circumstantial_evidence_supporting_the_claim/dfy5o65/That's not statistical evidence of blocks mined by that procedure. The entire point of covert asicboost is that it is covert, you cannot detect it and there is no statistical evidence that it is being used. The only evidence you can have for it is to examine the software and hardware being used by the suspected party. So far, the hardware and publicly available firmware has been examined and confirmed to be capable of using covert asicboost. Greg has examined a private software and firmware and confirmed that those software came from Bitmain and that they had covert asicboost implemented. Regardless, there is proof that asicboost (covert and overt use the same hardware) is implemented in production hardware and the overt version can be made to work with production hardware and software. Whether Bitmain is using covert asicboost privately is unknown, but likely given the available evidence.
|
|
|
You answer for me? That's part of your moderation duties?
A healthy moderation should stay neutral and not participate in the discussions, nor lock threads.
Now that is a load of bullshit. You mean to say that moderators are not allowed to participate in discussion in which they are interested and have expertise in? Moderators are participants in this forum too, and were posters before they became moderators. I am posting as myself, not as a moderator, nor am I posting on behalf of the forum. I think you have been the only one to mention "asicboost". Do you have any statistical evidence for the possibility you claim?
Reverse engineering has found that the mining chips used in Bitmain's Antminer S9's and R4's (and perhaps more, I don't know off of the top of my head) contain the circuitry necessary for asicboost to work. It was also found that antpool and the publicly available firmware for the antminers contains the codepaths and api calls necessary for overt asicboost to work, and in fact people have managed to get their miners to use overt asicboost. See https://www.reddit.com/r/Bitcoin/comments/63yo27/some_circumstantial_evidence_supporting_the_claim/dfy5o65/
|
|
|
You got me curious. When you say recent events, what are you referring to? Have these patterns been observed again lately?
The recent events he is referring to is the fact that it was recently discovered that Bitmain has implemented and possibly used the covert version of asicboost in their own mining operations.
|
|
|
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.
|
|
|
|