text:
How many days has bitcoin reached "all time high" in the first 3 quarters of 2017?
From Jan 1 2017 to Oct 1 2017 makes around 275 days. How many of these days did the BTC price reach an all-time-high?

I'm voting to close this question as off-topic because you can simply check this by looking at BTC price charts which are available on a multitude of bitcoin websites.

There are plenty of interesting question which can be simply answered by looking at readily-available information - if you know where to look. I don't think this is reason for closing, but perhaps an answer should focus on where the find the information rather than just a number.

Agree with @PieterWuille, I don't think this should be closed


text:
How to install specific version of bitcoind
How do I install a specific version of bitcoind?
I want to install bitcoind version 0.12.1 in my system.
How can I do that?
I am trying to use bitcore's Insight Explorer in my project.  It uses version bitcoind v0.12 to query all those things that are shown in the UI... I have tried to run this with v0.14 but Insight UI crashes.

Source code for Bitcoin Core, v0.12.1 can be downloaded directly from GitHub, via https://github.com/bitcoin/bitcoin/releases/tag/v0.12.1
Binaries are available at:  https://bitcoin.org/bin/bitcoin-core-0.12.1/
Be aware, v0.12 has known vulnerabilities, and should not be used in new work.  https://bitcoin.org/en/release/v0.13.0 shows some of the vulnerabilities that were fixed in v0.13.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
How can i mine solo with Bitcoin Core
It's only a question, i don't want to mine solo, knowing that it's not efficient, but since Bitcoin Core 0.13.0 how do we mine solo? (using rpc maybe?)

Possible duplicate of How can I solo mine using Bitcoin Core?

This topic doesn't answer my question

Download cfgminer or gpuminer or...

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How different crypto exchange correlate with prices
I did searched on how the crypto exchange works, However I do not find the exact answer to my questions.
Let's assume we are talking about two exchanges -
Exchange A - USA based, local (i.e. users kyc based on US identity card like SSN).
Exchange B - Indian based, (i.e. users kyc based on indian identity card like Adhaar)
So Exchange A will have only US users and B will have only Indian users.
Now if US people are believing that bitcoin price will rise and purchase a lot of bitcoin and price increases by some %, how it will affect the price in exchange B?
As 90% of Exchange B users will be sleeping and will not know that price on exchange A is increasing, how it will relate?
Will any user on Exchange B ever be able to purchase bitcoin from any user of exchange A??

The above scenario also make me question how will the very first user of exchange B will buy and from whom will it buy the bitcoin
Edit ---
As one of the answer suggested that Binance.com accepts, I know about binance.
My question is not understood properly here.
Let's take example of newly formed exchange, and exchanges here in India, which accepts only Indian ID card.
How price increase at bianance will affect price at some less known new local exchange?

Your base assumption that exchanges only accept local identities is false. Most accept traders from around the world.
Take Binance.com for instance, which is based in China with servers in South Korea\Japan, and they accept international IDs when you verify your account.

in general your statement is correct. no one can really prevent that someone buys btc at exchange A and sells it at exchange B. but i think "... a major exchange that doesn't accept a U.S. ID. ..." this statement is wrong caused by special laws of the usa. so usa-citizen may have a special position for cryptoexchanges (see https://www.bitfinex.com/posts/227 for example. bitfinex is one of the biggest exchanges)

@anion Good call. I didn't realize Bitfinex gave the U.S. the boot. I'm updating my answer accordingly.

You are correct for the big exchanges @KPaul,
But here I am talking about new exchanges like we have amy exchanges in India, which only accept Indian ID cards, I want to know, How these exchanges will work? And even if for example Binance.com have users from around the world, how prices from there will affect prices on less known new exchanges.

@Sanuj, those smaller local exchanges may vary some from the large exchanges, but in the end, people aren't oblivious to what the price is elsewhere. It's not like I would sell my Bitcoin on X small exchange for only $5,000 when I know everyone else is getting $14,000. So the fact that the bigger exchanges are used by people all over the world means that the users on smaller exchanges probably will want to buy or sell within 5% of what's happening on larger exchanges. Give or take. When the price swings a lot in one day, you may see a larger delta temporarily as everyone catches up.


text:
bitcoin-cli could not locate RPC credentials
I'm running a bitcoind 0.16 and it seem working, blockchain in sync etc..
I've used the "new" rpcauth, which is non deprecated so kind of referennce as explained here: https://github.com/bitcoin/bitcoin/blob/v0.16.0/contrib/debian/examples/bitcoin.conf. I've generated the rpcauth line and the password with
./share/rpcauth/rpcauth.py bob
Copied the rpc line in the ~/.bitcoin/bitcoin.conf file and stored the password elsewhere. The conf file have this [rpc] section:
server=1
rest=1
rpcauth=bob:b2dd077cb54591a2f3139e69a897ac$4e71f08d48b4347cf8eff3815c0e25ae2e9a4340474079f55705f40574f4ec99

I run
./src/bitcoin-cli get blockchaininfo -rpcuser={...} -rpcpassword={...}

The answer is:
error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/home/bitcoin/.bitcoin/bitcoin.conf)

It's like the cli can't read the rpc credentials from the command line. It's not saying "credentials are wrong". Also the conf file is the correct one so...
Any clue?

You are using bitcoin-cli incorrectly.
The command line arguments come before the RPC command. Anything that comes after the RPC command will be interpreted as arguments for the RPC, not arguments to bitcoin-cli
So what you should actually be doing is
src/bitcoin-cli -rpcuser={...} -rpcpassword={...} getblockchaininfo

The "accepted answer" is technically correct but it's INCORRECT in its reasoning and doesn't explain that there are actually 2 RPC auth methods for bitcoind (which bitcoin-cli communicates with).
The commandline -rpcuser and -rpcpassword are NOT FOR rpcauth accounts.  That's the first problem that was never mentioned in the accepted answer.
It also failed to mention that you cannot use rpcauth creds from the bitcoin-cli command line app.  Bitcoind has 2 RPC auth methods,  only 1 of them is available via command line and that's the old one that's going to be removed.  After that, you're screwed.  No more command line access to bitcoind via bitcoin-cli (like that makes any sense ...).  You'll have to create your own script and connect to it over the RPC port without the use of bitcoin-cli from what I can tell.
For now you have to use rpcuser and rpcpass either on the command line or in bitcoin.conf file.  Perhaps rpcauth support will be added to the command line in the future for but at the moment, it doesn't appear like that's going to happen.
Anyway if anyone can actually show a real answer to this (that uses rpcauth from the bitcoin-cli command line app), feel free.  I see no way to use rpcauth from command line bitcoin-cli at the moment.  It looks like https://github.com/bitcoin/bitcoin/blob/master/share/rpcauth/rpcauth.py is going to replace it but currently all it does is generate passwords.  That's pretty useless as far as actually using any pre-built command line apps for communicating with bitcoind is concerned.

This is not correct. There are two mechanisms for configuring RPC authentication (rpcuser/rpcpassword, or rpcauth), but the -rpcuser/-rpcpassword arguments to bitcoin-cli is compatible with both. rpcauth is just a means of avoiding the cleartext password in the config file.

Per this answer, itself after this guide, you may get the Could not locate RPC credentials message if bitcoin-cli is not looking in the right place for the datadir. You can explicitly tell it where to look:
bitcoin-cli -datadir=/path/to/your/datadir YOUR_COMMMAND

Try to use the old authentication way which i always been using and has no issue
#rpcuser=USER
#rpcpassword=PASS

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Can I use my Bitcoins to buy household commodities just like ordinary money?
Can I use my Bitcoins to buy household commodities just like ordinary money?  You see, I'm a newbie and have yet to learn the basics including all the facts about Bitcoins.  However,  I want to be ascertained as to whether my time and efforts in learning the trade will be rewarding in such a way that,  I'll be able to use whatever amount of Bitcoins I may earn someday to actually purchase things from the nearby store.

Currently there are relatively few shops that accept Bitcoin. If you want to know whether your local stores accept it, you will have to ask them. (Be prepared to be told "no" or more likely "I have no idea what you are talking about.")
Your title about "legal tender" is actually asking something different. "Legal tender" is a legal term, referring to a method of payment that must be accepted to settle a debt. As far as I know, Bitcoin is not legal tender in  any jurisdiction. However, people are still free to accept it if both parties agree (unless other local laws forbid it). In any case, legal tender is irrelevant to retail purchases, where no goods have already changed hands and no debt exists ahead of time. The seller can decide what forms of payment they do or don't want to accept.

authors: Игорь Демьянко


text:
Is blockchain.info storing paper wallet (offline) private keys?
Does anyone know if it is safe to use blockchain.info "Watch Only" addresses?
The real question is what happens after I perform a transaction - sending BTCs out of such a wallet. Will blockchain.info record the "offline" private key used for such transaction somewhere on the server?

Why would it store the private while you only gave the public key?

When a "watch only" wallet is used to send the BTCs a user must provide a private key, hence the private cryptographic key is exposed during the transaction. My question is: will this private key be stored/cashed by the website.

What? Never ever a private key is compromised during a transaction NEVER. You sign the transaction with the private but the STAYS private. You miss understanding public key cryptography.

If you use "watch only" it is only to see the balance nothing is compromised EVER.

My Wallet's warning for watch-only addresses ("You will not be able to send bitcoins from this address without later providing the private key") can be a bit confusing.
It's possible to specify an address and watch it. And it's possible to import a private key to be able to use the associated address as if it was generated with the My Wallet client.
But these two features are really unrelated. You don't "send out of a watch-only address", rather you import a private key thus making it no longer a watch-only address.
So the question is really whether My Wallet's "Import Private key" feature is safe. I don't have the official answer, but I see no reason why it shouldn't follow the same policy as other keys - the private key is encrypted in your browser (and as needed, decrypted and used to sign) and never leaves your computer in plaintext. If that's true, it is safe as the server never sees your plaintext key.

Thank you Meni. You were the only person who actually made a real effort to answer my question. My concern is that even though the private key reaches blockinfo's server in encrypted form, it probably is stored. And whatever is stored on a server, becomes much less secure, for example could be decrypted using a brute-force attack with a comprehensive dictionary. So I think the way to go with this would be to use a watch only address while I do not use it at all to transfer the funds out. As soon as any amount is transferred out, I consider such a wallet compromised and I will have to create a

@Vitro: You choose which password to use for the encryption. If you use a strong password (random and long enough that you have to write it down) brute-forcing is impossible. Cracking the encryption algorithm is conceivable, but you'd know in advance when weaknesses are found. The main vulnerability would be a virus on your machine that steals the key/password. I'd say it's pretty safe - but I agree it's a bit less safe than when the key exists only in a properly made paper wallet.

@Vitro: It looks like your comment was cut off, you can write the rest in a new comment.

Oops, my bad, I didn't notice that the message was cut off when I converted it from an answer to a comment. The complete last sentence was: "As soon as any amount is transferred out, I consider such a wallet compromised and I will have to create a new watch only address, and move all remaining funds to it."

blockchain doesn't record on their server any private key, or any key at all; or, they do, but they are encrypted and they can't access them, only you can
"watch only" addresses are public keys only anyway

Lohoris. Thanks for the reply,but I am looking for a real answer. Also please do not assume that I'm a noob if I'm asking a question. I am well aware that the "watch only" wallets are based on public keys, but if you would have read my question more closely you would notice that the question is about the usage of such a wallet to send BTCs , i.e. private key is used for the transaction of the BTCs out of the "watch only" wallet.
Would anyone else please, answer my question?

He actually answered your question, if anyone would not tell his public asymmetric cryptography would have been broken a long time ago. The whole point of a public key is to be guess what public, hence your address is safe when you give it to anybody.

When a "watch only" wallet is used to send the BTCs a user must provide a private key, hence the private cryptographic key is exposed during the transaction. My question was and remains: will this private key be stored/cashed by the website.

No you NEVER provide the private key when doing a transaction, you provide the public key and then SIGN with the private key.

@Vitro I do not assume anything: you asked a noob question, so you got a noob answer. Please don't assume you know something if you don't, sorry.

@Lohoris: You and Gopoi have completely missed Vitro's point.

@Gopoi: The OP was talking about "upgrading" a watch-only address to a managed address by importing the private key. The interface warns that such importing will be needed if one ever wants to send from the watched address. He wanted to be sure that the key he imported never leaves the browser unencrypted.

Blockchain.info wallet is opensource https://github.com/blockchain
So you can verify it yourself, that it is indeed not storing your private key.

It's better to verify in the JS that the private key never leaves his computer.


text:
Can I mine with CGMiner or BfgMiner with both an AMD and NVidia GPU on the same MOBO?
I cannot find any good articles or webpages on this, is it possible to run CGMiner with both an AMD and a NVidia graphics card installed? I think I can remember reading something way back that said you shouldn't but can. Does anyone know any concrete information on it?

What's up with all these people recently wanting to start mining on GPU or even CPU? It's absolutely totally pointless.

You don't think I know that, there's no need to flame. I would like to mine because I find it enjoyable, its not all about the profit. It is also not pointless.

Yes, it´s possible.
But, there are some things that you shound know:
1) Minning Bitcoin with GPU is almost dead, you should have read about other crypto coins. Specifically "scrypt" based ones.
2) Nvidia are not power efficient for mining... would be better if you just sell the nvidia and buy a amd with the same price. Unless you want to use your nvidia for gamming, video editing... dunno... just not for mining.
3) CGMiner = AMD ; CUDAminer = Nvidia ... diferentes programs. don´t no if they work well together... if it does, them you are good to go :-)
hope i had help you.

The algorithm is scrypt. And yes I know btc gpu mining is dead, I was trying to determine if I could use them for ltc mining. I've got it setup now no worries.

Mining with normal hardware CPU/GPU is pointless you get less than GHs and are not power efficient. Most of the mining pool will not even give you work to do.
You have two alternative, buy hardware: Butterfly labs, Kncminer are the most famous company selling it. In alternative you can use cloud mining with cex.io where you can buy and sell GH/s any time. You will get access to the biggest private mining pool, GHash.io and you can potentialy gain on trading

I am mining ltc, I was just asking in general. Its even more pointless to buy hardware than it is to mine with a gpu.

Ok I got your point. Although it is not pointless to buy hardware, it is fun and can be economically rewarding.


text:
Is it possible to make PoW ASIC-resistant through dynamically generated hash chains?
Bitcoin's static proof-of-work function SHA256(SHA256(data)) was apparently easy enough to be implement as ASIC which lead to the re-centralization we see today.
But what if the PoW function changes for every new block based on the hash of the last block mined? One could generate a new hash chain by seeding a commonly known PRNG with the hash of the last block and use it to generate a chain of hash functions from a (large) pool of commonly known hash functions.
Steps:

RIPEMD(SHA2(SHA3(MD5(RIPEMD(SHA2(data)))))) => digest (i.e. old block header hash)
PRNG(digest) => SHA2(MD5(SHA3(SHA3(RIPEMD(RIPEMD(data))))))
digest (i.e. new block header hash)

This way every miner would know how to generate the new chain of hash functions which has to be used to generate a digest with certain criteria (leading zeros) for the next block but nobody could calculate the subsequently hash chains and nobody could implement static hash chain circuits but has to use FPGAs which have to be reprogrammed every block and have to be able to host every possible hash chain constellation. If the hash chains are complex enough it might even lead to a decrease in FPGA efficiency which would favour general computing hardware and reinstate the "one-CPU-one-vote" principle.
What do you think of this approach? Why might it be flawed?

Isn't this essentially the premise of X11?

I believe X11 is just a chain of hashes. I think flyMaster is proposing having a battery of hash functions and using a different one depending on some characteristic of the previous block solved.

I have looked up the DarkCoin PDF and as far as I read they just use a static chain of 11 different algorithms. Do you have a link to an more in depth X11 description or a good readable implementation?
My approach is to generate a new hash chain for each block based on the prev block.

How would you handle difficulty readjusting when the algorithm changes?

The hash chain needs a predefined runtime which we call then 1 round. The chain generation algorithm has to stop adding new rounds of hash functions after the limit is reached. For this to work we have to measure the mean runtime of every algorithm used and assign runtime factors to them.
Assumed SHA3 is two times slower than SHA2 on an average general computing device in store today the chain SHA2(SHA2(SHA2(SHA2(data)))) and SHA3(SHA3(data)) and SHA3(SHA2(SHA2(data))) are equal in terms of runtime.
Based on this measure we can speak about difficulty adjustments of multiples of that.

There cannot be such a thing as an “ASIC-resistant” algorithm. ASICs are designed specifically to implement an algorithm and will always be faster than any CPU.
On the other hand, it might not even be a good idea to have ASIC resistance, because ironically, the ASICs would be the ones optimized for this and the general-purpose computers would be left behind, while also being way worse for energy consumption (something which seems to bother many people).
Source: https://download.wpsoftware.net/bitcoin/asic-faq.pdf

You are right regarding static algorithms. My question is if this applies to a dynamically changing algorithm as well. My assumption is that the most efficient ASIC for a constantly changing algorithm is a general purpose CPU.

@flyMASTER, why would it be any different? Unless this “changing algorithm” includes every possible algorithm, there must be a finite number of algorithms that can individually be optimized, as well as being able to optimize the decision of which one to use.

Sorry for answering so late, I was quiet busy over the last days. You are right in respect of that all partial algorithms can be implemented as ASICs except for the sequence in which they get called. For a runtime of 1ms on a general computing device I got chain lengths of random concatenated hash functions of around 1000. The questions is: If every part algorithm is implemented is it still "expensive" to redo the rewiring for every round of hashing?

The point of the article I linked is that yes, it's expensive to do the wiring, but that there will be people willing to pay for that, and once they got it, they will outweigh the common people anyway, and with a much greater advantage (because they won't be able to pay for the expensive ASIC).

So you think the rewiring algorithm is possible to implement as ASIC in a way that is more efficient (computing time/energy efficiency) compared to a software implementation running on a CPU?

Of course, because it would still be doing only one thing. A CPU has to handle a whole other bunch of processes (including, most of the time, a web browser).

I believe that Arturo's answer is correct in a strict sense.  You asked if it is possible, and the goal is "ASIC-resistant" by which you mean that it cannot be optimized through the development of an ASIC.  Any algorithm is, by its nature, suitable to be encoded into an ASIC.  Well, any programmable algorithm that is, and that includes all possible hash-chains.
However, there are competitions for the creation of new hash algorithms.  The results of these competitions, once known, can be incorporated into ASICs, but that takes time.  During the time it takes, the competitions will continue.  If the results of such competitions were regularly added to the list of possible hash functions, then the ASIC development would probably no longer be suitable because the algorithm would not be known in advance for a long enough period to develop the ASIC.
I very much like the idea you presented, but it needs some refining to be effective at decentralizing mining.  This is assuming that the static nature of the PoW is a significant factor contributing to the centralization of mining.  I believe it is.
In fact, we don't even need a hash chain.  If hash competitions were frequent enough, the PoW could simply used the latest winner.  How fast can an ASIC be developed?  That is how often the competition for creating a new hash would have to run.  I'm guessing at least several difficulty changes.

There's more to mining than hashing as I explain in this article:
http://cryptorials.io/beyond-hashcash-proof-work-theres-mining-hashing
which suggests that memory chips could be the ASIC there's no need to resist.

If I understood the question well, you are using PRNG to select which chain of hashes will be used, so you can have any combination of RIPEMD, SHA2, SHA3, MD5, ...
If that is the case, then expect a chip to be developed to implement all those hash functions. So, to calculate one arbitrary hash is super fast (compared to general CPU). Then all you need is some control unit that will just send those subtasks to those chips. So at the end you have ASIC that by itself is unable to calculate the whole hash, but with the help of control unit, the whole thing is able to produce a much faster result than CPU. Depending on how many different hash functions you have there, it might be even beneficial for the chip to have pairs or those hash functions hardwired.
At the end this does not prevent building ASICs at all. This does not even raise the cost that much - as many "anti-ASIC" algorithms attempt by depending on big amounts of expensive memory.


text:
Why don't we have a help for Bitcoin Core CLI options in the same way as we do for CLI commands?
There is detailed help for bitcoin-cli commands using for example:
./src/bitcoin-cli getconnectioncount help.
However, there isn't generally detailed help for bitcoin-cli options such as
./src/bitcoin-cli -netinfo help.
(Note the dash in front of netinfo with no such dash before getconnectioncount)
Is there a reason why there isn't the same help for bitcoin-cli options?
Jon Atack added on IRC:

If not is there an already planned way to add to the help doc and
would this be a good idea? For more detailed help than in
./src/bitcoin-cli -h
I was thinking it might be good to have a detailed help doc for
-netinfo either with help -netinfo or expand the existing one at
./src/bitcoin-cli -h | grep -A3 netinfo or add a doc/netinfo.md
file

I don't understand why you dump random conversations between developers on this site. Without context this question makes no sense - most CLI options do have help.

This simply is a shortcoming that should be fixed.
David Harding added on IRC:

help <command> is for RPCs; -h is for a quick summary of CLI
parameters.  Extended CLI parameter help should probably be in a
manual page.

That's pretty much the opposite of the truth. The bitcoin-cli options in question (-netinfo), (-getinfo), (-generate) are as much end user features as the RPC commands, they've just been moved from bitcoind to bitcoin-cli. The fact that they aren't listed in -help or through other means is a shortcoming that should just be fixed.

Cool, thanks. Will update.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Should block height or MTP or a mixture of both be used in a soft fork activation mechanism?
Should block height or MTP (median time past defined in BIP 113) or a mixture of both be used in an activation mechanism like BIP 8 or BIP 9 for defining the timings of the state transitions?
What are the advantages and disadvantages of both and how do they compare?

Should block height or MTP (median time past [...]) or a mixture of both be used in an activation mechanism like BIP 8 or BIP 9 for defining the timings of the state transitions?  What are the advantages and disadvantages of both and how do they compare?

The main advantage of MTP is that it usually roughly corresponds to wall time, so it's easy to communicate what a number means to humans.  For example, BIP141 says: "the BIP9 starttime will be midnight 15 november 2016 UTC [...] and BIP9 timeout will be midnight 15 november 2017 UTC".  When both of those MTP values were reached on the actual network, they were within three hours of actual UTC.
The main disadvantage of MTP is that it can be manipulated by miners.  MTP is the median of the value recorded in the nTime field of the current block header and the previous 10 blocks.  Miners can set their nTime values to any value greater than the current MTP and less than two hours in the future.  This makes it possible for a majority of miners working for an extended amount of time to hold MTP to an old value (say 3 months ago) and then, in the space of a single block, move to a much later time (say 1 month ago).  This can allow them to jump over MTP-based mandatory signaling periods such as specified in BIP148.
The main advantage of block heights is that there's no way to skip over a height-based threshold, so they make sense for flag day activations, mandatory signaling requirements, and other transitions we want to ensure happen (such as from BIP9 LOCKED_IN to ACTIVE, which happens using a relative height-based threshold of 2,016 blocks).
The main disadvantage of block heights is that they're not particularly consistent.  In an average year, we expect there to be 52,596 blocks, but it would not be extraordinary for there to be 58,440 blocks---reducing an intended 12-month deployment to 10.8 months.
There's no harm in mixing MTP times and heights, and there can be significant advantages if you can take advantage of both strengths at the same time without losing too much to their weaknesses.

Using block heights for the start and timeout parameters has the advantage of giving miners a known number of signaling periods. Loss of hashpower doesn't reduce the number of retarget periods available for activation.  Especially for an activation mechanism over a shorter time horizon (e.g. the Speedy Trial proposal) it may be important to ensure miners have the maximum number of signaling periods. Block heights are also arguably easier to communicate and easier to reason about as blockchain developers are used to working with them.
Using MTP (median time past) has the advantage of being able to schedule an activation at a specific time in the day to avoid activation occurring in the middle of the night for some region in the world. Concerns around hashrate decreases or increases affecting the number of signaling periods can be mitigated with selecting mid signaling period MTPs. The short duration of proposals like Speedy Trial are less sensitive to hashrate drifts changing the number of periods (a large hashrate decrease would be required to decrease the number of signalling periods).
A concern with MTP is that a coalition of miners could scale down their mined blocks at nTime to MTP + 1 to prevent reaching a MTP start time at the expected real world time. This concern seems minor as it could impact difficulty adjustments and would require broad participation from miners to limit MTP.
It is also subject to debate whether using block height consistently or using a mixture of both block heights and MTP is preferable for making the implementation and release of an alternative competing (compatible or incompatible) activation mechanism (e.g. a UASF release) more difficult or for avoiding a scalp for marketing purposes.
AJ Towns explains a disadvantage with using MTP for the minactivation point here. If activation time falls near a difficulty retarget block activation could happen the next day or in two weeks. This presents some communication challenges.
In addition:

The height at which you transition from LOCKED_IN to ACTIVE must be fully determined as soon as you transition from STARTED to LOCKED_IN. That way the entire LOCKED_IN period has to be re-orged if you want to steal funds protected by both nLocktime and the new rules.

In summary, there appears to be consensus that block heights should be used exclusively in activation mechanisms for future soft forks but it is less clear whether there is consensus to use them exclusively for the proposed Taproot activation mechanism, Speedy Trial.
For more details on the timewarp attack on MTP see this from Mark Friedenbach and this from Andrew Chow.
This answer was taken from comments on GitHub and the mailing list from Andrew Chow, AJ Towns, Jeremy Rubin, Sjors Provoost, Antoine Riard and David Harding.


text:
What is a compressed Bitcoin key?
The standard Bitcoin client in version 0.6 apparently introduces compressed keys.
What are they? Are there any drawbacks to using them? Any incompatibilities with older software? Reductions in cryptographic strength?

A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There are no compatibility or security issues because they are precisely the same keys, just stored in a different way. The original Bitcoin software didn't use compressed keys only because their use was poorly documented in OpenSSL. They have no disadvantages other than that a little bit of additional computation is needed before they can be used to validate a signature.
If you think of a public key as a point somewhere along a giant letter U, an uncompressed key is the x and y coordinates of the point. A compressed key is how high up on the U the point is along with a single bit indicating whether it's on the left or right side. As you can visualize, they both encode precisely the same thing, but the compressed form requires half as much space plus one bit. (Of course, they're really points on elliptic curve secp256k1, but the concept is the same.)

So if the older software encounters a compressed key (how would that happen? in wallet.dat? in the block chain? in a transaction broadcast?) can it handle it?

No, it can't. But it is always disallowed to try to read a wallet.dat file with an earlier version of the software. That's a permitted break. (You could still manually extract the case, uncompress them, and put them into the earlier form if you had to. But that kind of compatibility is not supported. You can't go back with a newer wallet file unless you translate the data.)

To answer your other question, only in the wallet.dat. Compressed keys aren't yet supported anywhere else because that would be a protocol-breaking change.

If this is only for wallet.dat, why bother about a few bytes? 31 bytes saved add up to a megabyte only if you have 33.825 keys.

Old clients can validate transactions with compressed public keys because Bitcoin sends public keys to OpenSSL without checking their format and OpenSSL automatically processes the public key according to the leading byte (0x04 for uncompressed, 0x02/0x03 for compressed).

The advantage is mainly for the blockchain and the network, as transactions will be a bit smaller now. It's 33 bytes instead of 65, by the way.

So, if I understand correctly, a single private key is always connected to a single public key representable in two different formats, which is connected to two addresses (from whether the compressed and uncompressed form of the key is hashed)? So somebody can send coins to either address, but to use those coins I need to use the right version of the public key (which the newer software will automatically handle and the older software won't?)

I have a problem understanding it :  I have an uncompressed private key, I enter it in bitaddress.org, and I get two public addresses : one compressed and one uncompressed.
On one I have one million dollar, on the other 0. And they both come from the same private key. How does that make sense?

@Advanced A single private key has a single corresponding public key. But that public key can be expressed in two forms, compressed and uncompressed. Each public key form has a corresponding Bitcoin address. Bitcoins can be sent to addresses without regard for how that address was formed.

@DavidSchwartz The link to Secp256k1 in your post has become broken. But: What an excellent explanation of how this compression is archieved!

@Qqwy Thanks. I fixed the link to point to something that is at least a little relevant.

Format (private keys):

uncompressed: 0x80 + [32-byte secret] + [4 bytes of Hash() of
previous 33 bytes], base58 encoded
compressed: 0x80 + [32-byte secret] + 0x01 + [4 bytes of Hash()
previous 34 bytes], base58 encoded

case 1:

secret (hex):
1111111111111111111111111111111111111111111111111111111111111111
uncompressed:

secret (base58): 5HwoXVkHoRM8sL2KmNRS217n1g8mPPBomrY7yehCuXC1115WWsh

pubkey (hex):
044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1

address (base58): 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a

compressed:

secret (base58): KwntMbt59tTsj8xqpqYqRRWufyjGunvhSyeMo3NTYpFYzZbXJ5Hp

pubkey (hex):
034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa

address (base58): 1Q1pE5vPGEEMqRcVRMbtBK842Y6Pzo6nK9

Obtained from the Bitcoin developer mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development

This answer is different from above where the first byte of compressed/uncompressed is (0x04 for uncompressed, 0x02/0x03 for compressed)

It appears that this answer refers to the bitcoin specific import/export format of keys, vs the usage of compressed keys itself namely in OpenSSL.  I hope this helps future readers contrast the two answers here.

The quote is quite misleading. Since it is a quote, it probably should not be edited but “4 bytes of Hash() of previous […] bytes” should have been “4 bytes of Hash(Hash()) of previous […] bytes”. Hash function is applied twice.

@Akater hash applied twice is still a hash. Since it doesn't say which function Hash() corresponds to, the quote is correct. I don't know which function is used, so maybe e.g. Hash(x) = SHA256(SHA256(x))

It may help to break the fields apart.

04
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
385b6b1b8ead809ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1

03 [could be 02]
4f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa
[discarded value can be computed from above value]

There is more detail omitted above. The 03 can be 02 because the
discarded value has to be derived from the preserved value and
one extra bit of info is needed. That is because there are two
roots [plus and minus] when taking a square root.

a good explanation is available in How can I test if a bitcoin address is compressed or not?

More specifically, a public key in Bitcoin is a pair integers (x,y).
  For uncompressed public keys, these integers are encoded as 256-bit
  unsigned big-endian ints, concatenated together, and then prepended
  with a single 0x04 byte. The result is 65 bytes long.
For compressed public keys, only the x coordinate is encoded (like
  above, as 256-bit unsigned big-endian int). It turns out that the y
  coordinate can only be one of two values, one even and one odd.
  Instead of prepending a single 0x04 byte, a single 0x02 or 0x03 byte
  is prepended depending on y's value (0x02 for even, 0x03 for odd). The
  result is 33 bytes long.

is it 0x02 for y > 0 and 0x03 for y < 0

@CiscoMmu how to know if y > 0 or < 0?

In EC graph, you have 2 points in y coordinate (+ve and -ve) for every one point in x coordinate.


text:
Can bitcoins be bought wholesale?
What options are available to purchase bitcoins in bulk (e.g. a buy in the range of ten thousand dollars or more) without having to mess around with a market exchange?
How can it be determined if the price is fair?
What payment methods are accepted?

What benefits are you trying to gain over using an exchange? What do you mean by "mess around with" exactly?

Basically so that a person can basically hand over to somebody X dollars (or send a wire for an amount), provide bitcoin address and then know that in a day or so bitcoins will arrive and that the overall price paid for them was at a fair rate.

I guess what this would be called is a broker.  Are there any bitcoin brokers, and how would you be able to tell if the broker is fair?

@DavidSchwartz - e.g. volume discounts.

@ripper234: But if you're buying wholesale, the other party is selling wholesale. They would be equally entitled to a discount, and you can't both get a discount. Perhaps you might be able to transact without paying a commission to an exchange, but you're unlikely to get a break on the rate.

@DavidSchwartz - the other part might need to dump a ton of Bitcoins after a few huge deals they've made (Bitpay and BFL).

@ripper234: And you need to buy a ton of Bitcoins. It's symmetric, any argument why they should give you a break is also an argument why you should give them a break. At best, you can save commission.

@DavidSchwartz - this does not fit some information I have received.

DavidSchwartz is spot on. An exchange is the mechanism for determining the appropriate price. If the seller is offering this as a service (has no interest in selling other than the fee he will collect), he will need to buy the coins at the exchange anyway to hedge the rate, so you still have all the slippage and exchange fee, plus the mediator's fee (maybe he can reduce slippage a bit by using multiple exchanges). (continued...)

If you manage to find someone who wants to sell a big amount, you effectively cut the middleman and can spare yourselves the exchange fees, and the appropriate rate will be whatever is going on in the exchanges. But in general finding a seller at the exact time you want to buy isn't easy. There's no free lunch - by the time the market is big enough to find OTC sellers easily, exchanges will be competitive enough that their fees will be too low to make it worth the trouble.

In the end it reduces to market forces and bargaining power. If someone really has lots of coins to dump and not enough people to buy them, he can offer a better rate to attract buyers in a way that is still better for him than to suffer the exchange's fee and short-term slippage.

BitWage gets "wholesale" / "bulk" rates.

The following offer sales of bitcoins in larger quantities:

Tangible Cryptography sells coins received for its bitcoin cash-out service FastCash4Bitcoins.com
Bit-Pay Merchant Services, a merchant processor (minimum $10K transaction)

Very important answer.

You can buy them by trading directly with someone who wants to sell a bunch of coins. One good place to find willing counterparties bitcoin-otc (#bitcoin-otc on freenode irc, and bitcoin-otc.com).

It isn't too hard to find someone willing to sell large amounts of BTC at around the MtGox market price with no fee. You can try #bitcoin-otc or the Bitcoin Forum's "Currency exchange" section. Wire transfers and Western Union are the most commonly-accepted transfer methods for large amounts.
It's also very easy to buy MtGox USD coupons. A lot of sellers will trade 1 MtGox USD for 1 transferred USD -- no fee at all (besides the transfer fee).

I think that in common sense, as there is no central authority to be emiting bitcoins you can not simply be buing wholesale. The only way to get more stable and equal price is:
Firstly - Go to the exchange which handles big volume of BTC, e.g. Mtgox.com
Secondly - You can just be buying the smaller rate of bitcoins.
The payments metods include mainly wire transfers, in Europe SEPA (which is cheaper for earopean), and many other things like Ucash. You can also buy Linden Dollars and trasfer to bitcoin. Or https://www.bitcoinary.com/ seems to be good way when paying with paypal.


text:
Zcash T-address address wise UTXO transaction list both testnet and mainnet API
I need API for address wise UTXO transaction list for Zcash t-address for both testnet and mainnet.


text:
Bitcoind running on external HDD trying to resolve cookie from default datadir
On Elementary OS Loki 0.4.1 I've downloaded and installed bitcoind as per the official guide from bitcoin.org .
However, I in my case I don't have enough space on my internal SSD to store the whole blockchain, so I want to download it and maintain it on an external hooked up HDD.
When I run the bitcoind -daemon -datadir=path_to_external_hdd_folder the Bitcoin server starts up successfully and starts downloading the blockchain to that specified folder (In the logs I can see the height is growing and so is the size of the selected datadir which I passed in as an argument)
My problem is - when I try to run commands by running bitcoin-cli getblockchaininfo for example, I get the error:
error: Could not locate RPC credentials. No authentication cookie could be found, and no rpcpassword is set in the configuration file (/home/martin/.bitcoin/bitcoin.conf)

What's weird is that when I move the .cookie file from my external drive to /home/martin/.bitcoin/bitcoin.conf the commands start working.
This is a temporary solution though, I wouldn't like to move that file everytime I startup the bitcoin server.
Do I maybe need to pass in an extra argument to bitcoind -daemon?
I've tried passing -rpccookiefile=path_to_cookie_file_on_External_hdd to it but that didn't work.
Note: My bitcoin.conf file is empty.
UPDATE 1
I tried setting -conf when starting bitcoind but that didn't work either.

I have added an answer. Note that some of the parameters you have tried only accept a file input and will not accept a path.

Previous user with same issue found a workaround for their scenario: https://bitcoin.stackexchange.com/questions/53194/bitcoind-not-using-correct-directory-inspite-of-datadir-argument

You need to pass the same -datadir option to bitcoin-cli as to bitcoind. This will enable it to find the cookie file, but also potential other relevant changes you could have made to bitcoin.conf like rpcport. (I know you haven't, but this approach is compatible with those).

If this is a bug (it sounds like it is!) please open an issue for Bitcoin Core on the official Bitcoin Core repository issue page.
Please specifically identify as much information in the issue you log as you have here in your question including:
Version and Source
v0.xx.x downloaded from/compiled from
Expected Operation
bitcoind should look in the -datadir= location for the RPC cookie.
What Happens
bitcoind looks in the default location for the RPC cookie and RPC expects bitcoin.conf will be in the default location when checking for credentials.
Everything should be expected in the -datadir= location.
Setting -rpccookiefile= to the correct path matching the specified -datadir= location does not work.
Steps to reproduce
Most of your question and any other details.

Previous user with same issue found a workaround for their scenario: https://bitcoin.stackexchange.com/questions/53194/bitcoind-not-using-correct-directory-inspite-of-datadir-argument

Bitcoind is searching for the .cookie file in the configuration directory.
If you'd like to specify a path for the configuration that's not the default (i.e. In your hard drive), you can do so with the -conf=/path/to/bitcoin.conf

I still get the same result. I'm updating the question to note that my bitcoin.conf file is completely empty.


text:
How to create a blockchain snapshot for a hardfork?
I've done source forks (altcoins) and I understand how those work. But I'm a little stuck on how forks are activated? I need to know how blockchain snapshots are created and how the wallets know to distribute the initial fork offerings? If anyone could point me to a particular commit and/or PR of Bitcoin Cash or Gold where this logic is, I'd be very grateful.

Hard forks are simply extensions of a blockchain where the new blocks follow different consensus rules that are not compatible with the original blockchain. There is no actual snapshotting in a true hard fork. The hard fork software simply syncs up to a certain point with the original blockchain, and after that point, a new consensus rule is enforced which conflicts with the original chain and thus causes a blockchain fork. This is simply governed by an if statement in the block validation code.
The fork is simply activated by a miner who mines a block after a certain block or point in time that follows different consensus rules from the original chain.
For example, with Bitcoin Cash, their software enforced that the first block created after August 1st at 12:00 UTC must be larger than 1 MB and also follows the Bitcoin Cash consensus rules (larger block size, new signature hashing algorithm, etc.). This is encoded as an if statement in the block validation logic which checked the time of a block before executing different consensus rule checks. There is no actual snapshot that is taken; their blockchain up until that forking block is exactly identical to Bitcoin's and can be synced off a Bitcoin node.

There is no actual snapshot that is taken; their blockchain up until that forking block is exactly identical to Bitcoin's and can be synced off a Bitcoin node. - I get that, so you mean this syncing doesn't have to be a part of the code for the fork, per se. They can just have it synced upto their forked height using bitcoind and then run their own modified daemon?

Yes. But in their modified daemon, they also have code that handles the pre-fork rules so that too can sync.


text:
Bitcoin core syncing at 60% since December 13 and barely moving
I am using a macOS Sierra version 10.12.6. my wallet has been syncing since December 13, 2017 and is still at 60% and hardly advancing. Is this normal? Is there anything I can do to speed it up?

You've been syncing since 1917?  Via telegraph???

I don't understand it, when did u sync it, what message did u get (e.g. connecting to peer)

@abelenky bitcoIN started around 2009 so that can't be possible

Duh! 2017! It just started syncing, showing progress rate and time left. I have a fairly new computer that has little stored on it .

I've downloaded the blockchain many times (don't ask why).  Maybe a week or so, just depends, I didn't keep track of the time frame at that point.  If your network is slow, or your computer is slow (when verifying blocks), or if you're going through a VPN that slows you down, all those things could impact your download.

It is likely to be because your computer is slow validating the blockchain but not necessarily. This answer may help you.

Hi @Willtech: When you find a question who is completely answered on another question, please flag it as a duplicate of that corresponding question.


text:
What is the strMessageMagic good for?
The bitcoin message magic, "Bitcoin Signed Message:\n", is defined: https://github.com/bitcoin/bitcoin/blob/203632d20b3107009f45fae56cc3f7d828b16660/src/main.cpp#L80
I know it is used as a part of signing messages to prove they were sent from owners of specific private keys, as detailed here: What are the safety guidelines for using the Sign Message feature?.
What I don't know, though, is what good is this message magic? Does it make sure the same key can't be used in two coins? Is there some cryptographic reason?

Imagine if that weren't there. What if someone tricked you into signing a Bitcoin transaction with your key? They could put the signature they got from you along with your public key into the input script for the transaction, and broadcast that transaction to the network. (Unless something else I'm not aware of would prevent that.)
Granted, it would be somewhat difficult to trick someone into doing that (Bitcoin transactions include null chars, and I don't think you can copy-paste those) but why take the risk at all?

The "magic string" is prefixed to a message before hashing. You could think of it as setting the hashing function to a particular initial state before hashing the message. It serves only to give some distinction to hashes of Bitcoin-specific messages, by resulting in a hash value that is different from hashing just the bare message. There is no cryptographic reason or consequence for this.


text:
Can I retrieve missing Bitcoins that failed to process as Wallet is corrupt?
I have been using an old wallet until last year - Bitcoin Version v0.8.5-beta. QT Version 4.8.3.
I stopped using it as it has become corrupt. I had made several transactions that were not successful before I realized it was corrupt. They are showing in my transactions list as a question mark with 0 confirmations, however the transaction amount has been deducted from my wallet total.
I backed up the wallet.dat file after each transaction and overwrote the previous backup when I did this.
Can I retrieve the missing bitcoins?

Have you used https://blockchain.info to check the status of those transactions?  You'll need the transaction ID.

I checked blockchain.info at the time. It showed for an hour or so as pending ( or holding ) then disappeared. It never got into that system. I'm going from memory so cant remember the actual term it used for pending transaction

If you check blockchain.info now with one of the "missing" transaction IDs, what shows up?

Thanks for getting back. Sorry for the delay in answering - I have been away. I made 4 failed transactions - Three transactions show as zero transactions on Blockchain. The other one shows as 2 transactions and that it was received by the address that I sent it to. But it shows as having 0 confirmations in my wallet. The company that I sent it to said that they didn't receive it.

Hi Max. Further to my earlier comment. The one transaction that shows as being received by the address I sent it to - I sent the payment to them on 14 June 2016. Blockchain shows it being processed much later. The red debit transaction was dated 2016-12-09 and the green part of the transaction was dated 2016-10-17

If you know the password to your wallet.dat, you should try to retrieve the private key adresses and import them in a wallet such as Electrum, and see if that fixes your issue.
This is a bit of a hassle when you have lots of changeadresses though, but it is better then not being able to access your funds.
When you unlocked your wallet.dat in bitcoin core, simply go to the console and
Use

listreceivedbyaddress 0 true

OR, if you have generated new change adresses

bitcoind listaddressgroupings

To get a list of all the adresses that you are currently using / have balance.
Then,

walletpassphrase "your walletpassphrase here" 600
  dumpprivkey [your Bitcoin address here]

OR, you could dump all the private keys at once, if you were using alot of different adresses using the following command:

dumpwallet

And import these keys in a wallet such as electrum.
See if this resolves your issue.

Thanks I'll try that. Once I have entered dumpprivkey [my bitcoin address] where does the key show for me to import from? Thanks

dumpprivkey shows the key on-screen.  dumpwallet creates a text file (you specify the name) containing all the private keys.


text:
Does the creator of Bitcoin hold a 'master' private key?
If the creator of Bitcoin was the one that started the blockchain and with every cryptographic operation deriving from that initial key, would the network be under the complete control of the creator?
The only way I could see this not being the case if the key was disseminated into the network, but I am unsure if that is the case.
If the key is control over the block-chain and if the key generator still holds the key, then regardless of the fact that it is decentralized in operation, it is still centralized in control, like a bank.
I guess I'm really asking whether the creator had/has any advantage in the network (i.e reversing transactions, creating new coins, etc). Unless he specifically programmed the network not to be under his control, it would be right? I mean he IS the creator of the network and unless we have proof (source code inspection?) that the network has been 'turned over' so to speak to the users, we cannot guarantee safety can we?

Are you aware that bitcoin is an open source project? You speak as if it's a black box that the users can't see inside. Anyone can see exactly how everything works by looking at the source code: https://github.com/bitcoin/bitcoin

Related: http://bitcoin.stackexchange.com/q/4335/153 and http://bitcoin.stackexchange.com/q/8236/153

No one holds a key that gives them special control of the blockchain.
The closest thing to a "master key" was the alerts system, which allowed signed messages to be sent to every client, for example, to tell users to update their client in response to a security issue.  This feature was for alerts only and can in no way affect the blockchain, transactions, or user balances.  This key was possessed by Satoshi, Gavin Andresen, and theymos.
Update: The alerts system was retired in the summer of 2018, due to risk of DOS attack vectors (full nodes could be DOS attacked by carefully crafted alert messages), and increasingly widespread knowledge of the alert keys.

Remember, the bitcoin protocol and the code for most clients is open source. You can check it yourself.
If there was a "master key", then we would know. It's very hard to hide such things in code when it will be reviewed by tons of others. (Yes, hiding malicious code can be done, but not at this level).
However, note that Satoshi and a few others have access to update your client. What would happen if they pushed a malicious update? Simple: the community would notice. They would spread the news, and a new blockchain would be branched from the last block created before the malicious update.

Satoshi likely has the key corresponding to the address the coinbase of the genesis block was sent to. This is no different then any subsidy (mining income) produced by any later block. It does not grant any special privileges beyond that.
Actually, not even that, as because of either a bug or a conscious choice, the output of the genesis block cannot be spent.

So you say that the bitcoin system is not vulnerable to a master key attack? I belive that any system should be unless there is responsibility sharing, does bitcoin guarantee this type of democratic self regulation as a network?

I don't think you understand how Bitcoin works. There is no such thing as a 'master key'.

Similar to how terrible laws get passed during a crisis (e.g., the Federal Reserve's passage on Christmas eve, or after journalists call it a night on Friday), there is the potential risk that developers would release software during a crisis in which proper vetting hasn't occurred.
But most of the major players build the Bitcoin-Qt/bitcoind from source and can evaluate changes themselves.  For instance, Slush pool used an emergency fix shared by a member of the Bitcoin-Qt/bitcoind core development team to cause the v0.8 client to ignore the offending block following the March 11th, 2013 hard fork emergency.  The patch involved a few lines of source code changes that could be shared via any method, including a direct personal message.
If instead that change happened to be quite large, the risk of not recognizing code that is malicious increases.  For this reason, if either the complexity or urgency of an informal fix grows, the resistance to implement it until a formal release arrives should increase.  Formal releases are signed by the Bitcoin Foundation and are distributed through normal channels (and not passed as patches directly from developers to miners.)


text:
What are the advantages to attackers of different styles of replacement cycle attacks?
In Antoine Riard's
original description of replacement cycle attacks against HTLCs, a replacement cycle looks like this:

Bob broadcasts an HTLC-timeout  (input A, input B for fees, output X)
Mallory replaces the HTLC-timeout with an HTLC-preimage (input A,
input C for fees, output Y)
Mallory replaces the transaction that created input C, removing the
HTLC-preimage from the mempool

However, an alternative approach is:

(Same) Bob broadcasts an HTLC-timeout (input A, input B for fees,
output X)
(Same) Mallory replaces the HTLC-timeout with an HTLC-preimage (input
A, input C for fees, output Y)
(Different) Mallory uses input C to replace the HTLC-preimage with a
transaction that does not include input A, removing the preimage from
the mempool

The alternative approach has three clear advantages:

It's simpler.  The original approach works by replacing input C's parent, removing from the mempool the data necessary to confirm the HTLC-preimage; the alternative approach simply replaces the HTLC-preimage, removing it from the mempool directly.
It requires less setup.  The original approach requires input C's parent to be an unconfirmed transaction already in the mempool of targeted nodes; the alternative approach can use any of those outputs or any confirmed output.
It's more robust.  If the original approach's unconfirmed output gets confirmed, the attacker needs to create another unconfirmed output.

Are there additional advantages to the alternative approach?  Are there advantages to the original approach?


text:
How are past transactions validated (when there have been softforks)?
Let's say I run a bitcoin client for the first time. It downloads a copy of the blockchain from the very beginning and starts validating all the transactions included in all the blocks.
Since there have been some softforks during Bitcoin's timelife, how does the client know which validation rules needs to apply to validate each transaction?
Even if there are some checkpoints so that there is no need to validate the whole blockchain, how does the client handle different rules for different transactions?
Are there different sets of rules included in the source code, together with block heights indicating when they should be used?

Four methods have been used to decide whether a softfork should apply:

The softfork applies to all blocks, past and future.
Example: The softfork to remove the integer overflow bug.
The softfork applies to all blocks with a timestamp after a flag day.
Example: The initial form of BIP30 was applied to all blocks with a timestamp later than 1331769600. (March 15, 2012, 00:00 UTC)
The softfork applies to all blocks except some grandfathered-in blocks.
Example: The current form of BIP30 is applied to all blocks, except two that violate it.
The softfork applies to all blocks created after a successful miner vote. A Bitcoin client can determine if a softfork applies purely by looking at the blockchain.
Example: BIP34, which required block height to be placed in the coinbase in all new blocks.

Or in short: every recent softfork has included a trigger condition that only depends on the chain itself. Thus, during historical validation, you know which rules to apply where.


text:
How many addresses are sent in response to a getaddr message?
I've been trying to determine the number of addresses a node sends when it receives a getaddr message but I'm a little confused.
On one hand, on addrman.h/.cpp I can see that:
// the maximum percentage of nodes to return in a getaddr call
#define ADDRMAN_GETADDR_MAX_PCT 23

// the maximum number of nodes to return in a getaddr call
#define ADDRMAN_GETADDR_MAX 2500

[...]
int nNodes = ADDRMAN_GETADDR_MAX_PCT*vRandom.size()/100;
if (nNodes > ADDRMAN_GETADDR_MAX)
    nNodes = ADDRMAN_GETADDR_MAX;

So it seems that the number of addresses sent is the smaller of the two conditions, namely, 23% of the (active known) nodes or 2500 nodes.
But on the other hand, from the bitcoin wiki:

The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers.

...and...

[About addr messages] If the sender sent over 1000 addresses, they are all ignored.

So, why does a node try to send 2500 addresses if the receiver is going to discard them? Why not sending at most 1000 addresses?

The result from CAddrMan::GetAddr() is fed to CNode::PushAddress, which filters out addresses the peer already has, and inserts them in a temporary buffer of up to 1000 addresses.
Later, in SendMessages(), the contents of that buffer is sent out periodically.

According to the wiki, it seems like these are "Ongoing "addr" advertisements" thus unsolicited.

authors: αԋɱҽԃ αмєяιcαη


text:
How would one turn a Miniscript tree into a Taproot tree with Taproot'd Miniscript?
How would one turn a Miniscript "tree" into a Taproot tree with Taproot'd Miniscript?
(To be clear unlike a Taproot tree a Miniscript tree likely would't be surfaced to the user. Breaking down a Miniscript into a tree like structure is done in the code and was discussed in the Bitcoin Core PR review club on May 18th 2022.)

Uh. Do Miniscript trees and Taproot trees have anything to do with each other except that they're both trees? Why would we want to compare them?

Data structure question. We often think in terms of Merkle trees in Bitcoin, had to remind myself of the definitions for (non Merkle) trees, DAGs etc.

Trees are everywhere in programming. Every set in C++ is represented as a tree. The directory structure of your filesystem is a tree. The blockchain with its branches is a tree. The transactions in Bitcoin blocks are hashed following a tree. The mempool in Bitcoin Core is stored as a tree. The hierarchy of elements on this website's DOM is a tree. This question I think adds more confusion than clarification; yes, both the scripts in taproot are a tree, and miniscript expressions are organized in a tree. There is nothing remarkable or interesting about those facts.

Fair enough. Edited the question. Hopefully you're both happy with edit.

How would one turn a Miniscript "tree" into a Taproot tree with Taproot'd Miniscript?

You wouldn't - they're incomparable things that don't get translated from one to another.
Miniscript is a way to represent a Bitcoin Script, to help reason about it.
Taproot trees are commitment structures that help construct taproot outputs which can be spent by satisfying one of possibly multiple scripts.
Both the taproot script configuration and miniscript expressions can be thought of as trees, but these exist independently, at different levels. At best you can say that a taproot output is a tree whose leaves are scripts, and these scripts may on their turn be representable as miniscript expression trees - but those are trees of a very different nature.
Perhaps a more useful question is:

How can spending policies be translated to a tree of scripts, now that taproot permits outputs to be spendable using a disjunction of multiple scripts rather than a single script?

The simplest case is something like a policy "sign with key K1 OR sign with key K2". It could be implemented as:

A single script <K1> OP_CHECKSIG OP_SWAP <K2> OP_CHECKSIG OP_BOOLOR (miniscript or_b(pk(K1),s:pk(K2))).
A disjunction of two scripts:

<K1> OP_CHECKSIG (pk(K1))
<K2> OP_CHECKSIG (pk(K2))

It gets more complicated when we're talking about more involved policies:

"K1 must sign and either K2 or K3 must sign" can be implemented using:

A single script <K1> OP_CHECKSIGVERIFY <K2> OP_CHECKSIG OP_SWAP <K3> OP_CHECKSIG OP_BOOLOR (and_v(v:pk(K1),or_b(pk(K2),s:pk(K3)))).
A disjunction of two scripts:

<K1> OP_CHECKSIGVERIFY <K2> OP_CHECKSIG (and_v(v:pk(K1),pk(K2)))
<K1> OP_CHECKSIGVERIFY <K3> OP_CHECKSIG (and_v(v:pk(K1),pk(K3)))

"Two out of these three conditions must be fulfilled: (1) K1 must sign (2) K2 must sign (3) both K3 and K4 must sign" can be implemented using:

A single script <K3> OP_CHECKSIG OP_SWAP <K4> OP_CHECKSIG OP_BOOLAND OP_SWAP <K1> OP_CHECKSIG OP_ADD OP_SWAP <K2> OP_CHECKSIG OP_ADD 2 OP_EQUAL (thresh(2,and_b(pk(K3),s:pk(K4)),s:pk(K1),s:pk(K2)))
A disjunction of 3 scripts:

<K1> OP_CHECKSIGVERIFY <K2> OP_CHECKSIG (and_v(v:pk(K1),pk(K2)))
<K1> OP_CHECKSIGVERIFY <K3> OP_CHECKSIGVERIFY <K4> OP_CHECKSIG (and_v(v:pk(K1),and_v(v:pk(K3),pk(K4))))
<K2> OP_CHECKSIGVERIFY <K3> OP_CHECKSIGVERIFY <K4> OP_CHECKSIG (and_v(v:pk(K2),and_v(v:pk(K3),pk(K4))))

Which of these options is optimal may depend on the situation:

Using more script leaves is generally more private, as the unused leaves (and the spending conditions they correspond with) aren't revealed to the blockchain at spending time.
Using more script leaves may or may not be cheaper to spend. In simple disjunction cases (where the policy is "A or B or C or ...") splitting in separate scripts is generally cheaper. When there is a huge combinatorial explosion that a policy needs to be turned into to make use of separate script, a single script may be cheaper to spend.
Coordination in case multiple signing parties need to cooperate may be easier in case of a single script, because they need to decide ahead of time which script they'll be signing for (due to BIP341 sighash rules committing to the actual script used).

A Taproot tree is a Merkle (binary) tree of (Tap)scripts. Every node (an intermediate state in the process of hashing the leaves up to the root) has at most 2 child nodes and every leaf script (at the bottom of the tree) is hashed before being hashed again with the concatenation of its hash and its sibling's hash.
A Miniscript tree doesn't do any hashing as it is just restructuring a single (possibly very large) script into fragments. The root of the Miniscript tree is the whole expression. Every subexpression is a node in the tree. The leaves are the expressions which don't have subexpressions, like pk() or older(). A node on the tree can have more than 2 children. For example, a node of the Miniscript tree could contain a thresh() which contains more than 2 subexpressions (e.g. a 2-of-3 threshold would contain three subexpressions). A node could also only have 1 child (e.g. if it contains one of the Miniscript wrappers a:, d: or l:).
The Taproot tree would be constructed at the Policy level rather than the Miniscript level as each (Tap)script on the leaves of the Taproot tree may be represented as an individual Miniscript (Miniscript only encodes a subset of Script in its entirety). But if we think about how a Taproot tree of policies might be constructed, if the "root" (highest level) of the Policy tree contained a or(A,B,C) this is easily deconstructed into a Taproot tree with leaves A, B and C. If the Policy root contained an and the whole Policy may need to go into a single leaf but there are possible exceptions (if there are disjunctions below it e.g. and(or(A,B),C) is equivalent to or(and(A,C),and(B,C)). If the Policy root contained a thresh (e.g. 2-of-3) it could be reconstructed as an or() of 3 2-of-2s as explained in this blog post for 2-of-3 threshold signature.
Thanks to individual(s) for answering my questions on IRC. Any mistakes are my own.


text:
In future will multiple widely used implementations around libbitcoinkernel be an overall net positive or net negative for the ecosystem?
Assuming the libbitcoinkernel subproject of Bitcoin Core is completed and successfully/safely extracts the consensus engine out of Bitcoin Core will having multiple widely used alternative implementations built around libbitcoinkernel be an overall net positive or net negative for the ecosystem?

There are some clear upsides to having multiple implementations based on libbitcoinkernel that Carl Dong highlights in this short presentation on libbitcoinkernel.
There are multiple approaches that can be experimented with (including rewriting a subsystem in a different language like Rust) when an alternative implementation doesn't have to worry about falling out of consensus with Bitcoin Core. Currently there can only be one approach widely used on the network because of Bitcoin Core's dominance and general perception that it is the reference implementation.
The stringent review culture required not to introduce bugs into the consensus engine often leaks into other subsystems that aren't as security critical (e.g. GUI, tests). It is very difficult to define contrasting review processes depending on the subsystem when they are all part of the same project. Hence reviewers and maintainers have needed to push back against scope creep because the project is already too large to sustain a monoculture that generally runs on well reasoned NACKs preventing a change from being merged.
James O'Beirne highlighted some of the potential downsides though on Twitter.

I have a few arrows pointing in opposite directions on this one. On
one hand, I think having multiple "shell" implementations (shared
libbitcoinkernel used by different networking + mempool + ui designs)
is very important because multiple teams doing parallel
construction/cross-validation is good/resilient and forward progress
on mempool and other important problems is stuck in the mud because
it's hard to gather technical consensus to the point of merge.
These important problems become harder and harder to reason about in
the abstract, and need to be actually tried to gauge efficacy in the
real world. Hard to do experimentation in the wild given the sacred
nature of Core.
But, on the other hand, there are some issues with multiple
implementations beyond the classic "but consensus bug can come from
non-obvious implementation details:"
Policy, not just consensus has a very real impact on e.g. network
splits, or unupgraded miners not mining bad blocks after a soft fork
due to no standardness.  Having many implementations running around
significantly complicates this especially if they exist to experiment
with policy.
Part of the benefit of Core as the sole implementation is that it's
easier in practical terms to consolidate eyeballs and do review over a
single process/codebase. Review maximalism: if you have Core and some
other project that's double the overhead to stay on top of changes.
There are probably more arrows pointing in either direction, and this
is tough to reason about. In any case I'll keep reviewing and
advocating for libbitcoinkernel because it's the clear way forward in
either case.

Carl Dong added on Twitter that even if alternative implementations don't end up getting built around libbitcoinkernel it still brings many benefits:

In the unfortunate event that there doesn’t end up being alternative
implementations built on top of libbitcoinkernel, the modularization
of the codebase as a result of the effort will have been well-worth
the trouble.
It will have achieved what orionwl pointed out here: “What kind of
frustrates me, personally, is that we didn't manage to clearly
separate out the consensus parts. Not to a library (which would be
useful for rust-bitcoin et al), but also not even to a separate
directory.”
libbitcoinkernel can actually do one better than having a separate
directory: after phase 1, any unintentional re-entaglement of
consensus and non-consensus code will make themselves obvious to devs
and reviewers by triggering linker errors.


text:
c-lightning is working on Rust language bindings. How does this compare to the language bindings work LDK has been doing?
I know LDK (rust-lightning) has been doing a lot of language bindings work to support various languages (C, Go, Java, Swift etc).
c-lightning is now working on language bindings itself so you can build say c-lightning plugins in Rust.
How does this language bindings work compare to the approach LDK has been taking?

This was answered during a c-lightning developer call on January 10th 2022. The transcript is anonymized by default.

There we are talking about different bindings. These are the bindings that we use for our RPC interface. I think when rust-lightning is talking about bindings they are talking much more about having a C API that they can compile into their own apps. Whereas this is inter daemon communication or daemon with plugin or daemon with front end. The C API that rust-lightning is building is most likely to be consumed by a binary directly. For example if you are building a Java application or an Android application you will most likely be using GNI to talk to rust-lightning instead of some other Java code. I think they are referring to that. Whereas this is mostly inter daemon and inter process communication. We have a connection or a file descriptor where we write stuff out.


text:
How do ANYPREVOUT and CTV compare when considering how useful they are for vault designs?
What is the latest state of vault research on how useful SIGHASH_ANYPREVOUT and OP_CTV are with regards to existing vault designs? Are new alternatives e.g. TapleafUpdateVerify (TLUV) currently considered more or less useful for existing vault designs?

At the time of writing (January 2022) there seems to be very little research with direct comparisons on the utility and safety of different ways to enable the construction of various vault designs. Indeed the covenant opcode TAPLEAF_UPDATE_VERIFY was only proposed to the bitcoin-dev mailing list in September 2021 and there are no implementations of it as yet let alone detailed analyses of how it compares to constructing vaults using SIGHASH_ANYPREVOUT or OP_CHECKTEMPLATEVERIFY. The mailing list post did suggest that it enables a vault design that matches a previous vault design of Bryan Bishop with additional benefits:

It's fully recursive, allows withdrawals to vary rather than be the
fixed amount L (due to not relying on pre-signed transactions), and
generally seems a bit simpler to work with.

Jeremy Rubin initially described OP_CHECKOUTPUTSHASHVERIFY (which became OP_CHECKTEMPLATEVERIFY) as a "rudimentary, limited form of covenant which does not bear the same technical and social risks of prior covenant designs". This suggests that for vaults specifically the design space may be more limited using OP_CHECKTEMPLATEVERIFY.
Andrew Poelstra has blogged on how to use OP_CAT and OP_CHECKSIGFROMSTACK to construct covenants and vaults (1, 2). These would enable more generalized covenants than OP_CHECKTEMPLATEVERIFY potentially increasing the design space for vaults but with the downsides of being less efficient and arguably riskier. There does seem to be a direct risk/reward trade-off here when attempting to broaden the design space for vaults and it is difficult to assess where on the spectrum is the potential optimum given how few vault prototypes there are let alone fully built out implementations of those prototypes.
The solitary paper that has compared building vaults using OP_CHECKTEMPLATEVERIFY and SIGHASH_ANYPREVOUT at the time of writing is Bitcoin Covenants: Three Ways to Control the Future.
This paper discussed three categories of vault design: deleted key (no consensus changes required but inferior security model), recovered key (requires BIP 118 consensus change, superior security model) and script based (requires BIP 119 consensus change, superior security model).

It stated:

Recovered-key and script-based covenants are mostly functionally equivalent and
so the advantages that recovered-key covenants have over deleted-key covenants also applies to Script-based covenants. If
either were enabled by their required soft-fork upgrade then a new domain of practical covenant-based protocols could emerge.
Understanding precisely what utility is gained from such upgrades is key to their progress.

The paper concluded by stating:

Bitcoin is a complex adaptive system with many interacting parts and
there are systemic risks with every modification of bitcoin’s
code-base and protocol. It is difficult to analyse those risks and it
would be hubris to claim that there are no unknown risks being
introduced.

I know some will disagree including most likely BIP 119's author (Jeremy Rubin) but it appears that on both the utility axis and the safety axis there appears to be a lot more exploration and analysis to do to converge on a tool or set of tools to enable the construction of vaults on Bitcoin mainnet which wouldn't soon afterwards be assessed to be suboptimal. We then get into a high level discussion of whether we should see Bitcoin mainnet as a testbed for new use cases that may or may not work out or whether we should see Bitcoin mainnet as a place where consensus changes are made when there is strong confidence that those changes will stand the test of time on both the utility and safety axes. Personally I lean towards the latter but that is an entire other discussion in itself.
April 2023 update
There is now an additional paper authored by James O'Beirne on "Vaults and Covenants" and a draft BIP (BIP 345) which introduces new opcodes including OP_VAULT. James has a demo vault using OP_CTV and darosior has built that same vault using ANYPREVOUT instead at the expense of additional virtual bytes.

@Prayank: What particular part of it is opinion based? It is summarizing the existing research other than the last paragraph which states there isn't much research (this is a fact) and hence outlines there are opposing views on whether this limited amount of research is enough to consider consensus changes. If you find any other research feel free to link to it or write your own answer.

Now you could say that it includes opinions from arguably qualified people like Jeremy Rubin, Andrew Poelstra, AJ Towns, authors of the covenant paper. Ideally there would be a lot more evidence to justify those opinions (I wish there was personally) but that is the state of the research (which was the original question)

Maybe the research is mainly opinion based from (arguably) qualified people currently. On that I would probably agree with you. But that is the state of the research. I can't do much about that. On the last paragraph I am happy to edit. The last line is my personal view but I outline there is disagreement with me on this. You or anyone else is free to post an alternative answer summarizing the current state of the research.

I'm not sure what you are asking. The resources I summarize or quote from are all public. You are free to send an email to the mailing list discussing any of these resources though obviously I'd recommend you link to their work and attribute them if you do.


text:
Could CHECKSIGADD be used on new ECDSA multisignatures instead of CHECKMULTISIG?
The proposed Taproot soft fork (BIP 342) defines the new opcode OP_CHECKSIGADD to verify Schnorr multisignatures whilst OP_CHECKMULTISIG (and OP_CHECKMULTISIGVERIFY) are disabled for Taproot spends (SegWit version 1). Could we use the OP_CHECKSIGADD opcode for verifying new SegWit version 0 ECDSA multisignatures? Obviously you don't get the same batch verification benefits if the individual signatures are ECDSA but it would still be more efficient to use the counter system of CHECKSIGADD?
For an explanation of how the opcode CHECKSIGADD works see this presentation from James Chiang. Or see Tapscript BIP 342.
"The opcode 186 (0xba) is named as OP_CHECKSIGADD"
"OP_CHECKSIGADD is functionally equivalent to OP_ROT OP_SWAP OP_CHECKSIG OP_ADD"

No because the opcode 186 (0xba) is undefined for SegWit version 0 spends. You can only take advantage of this opcode in SegWit version 1 spends. If you included this opcode in your SegWit version 0 transaction script any attempt to spend it would encounter this script error.
In addition Pieter Wuille added in the comments:

In fact, enabling the same semantics for existing script versions would be a hardfork. It pops elements off the stack, so a script consisting of just "OP_CHECKSIGADD OP_SIZE 1 OP_EQUAL", and fed 3 elements as input would be invalid currently, but valid if such an opcode was added

Indeed, the opcode only exists in tapscript spends.

In fact, enabling the same semantics for existing script versions would be a hardfork. It pops elements off the stack, so a script consisting of just "OP_CHECKSIGADD OP_SIZE 1 OP_EQUAL", and fed 3 elements as input would be invalid currently, but valid if such an opcode was added.


text:
Why is there a OP_NUMEQUAL opcode? Does OP_NUMEQUAL offer a subset of the functionality of OP_EQUAL?
There is a OP_EQUAL opcode that returns (from the Bitcoin wiki):

1 if the inputs are exactly equal, 0 otherwise

And a OP_NUMEQUAL opcode that returns:

1 if the numbers are equal, 0 otherwise

In the case where you want to use OP_NOTEQUAL it is suggested to use OP_NUMNOTEQUAL so it seems like OP_EQUAL and OP_NUMEQUAL can be used interchangeably when dealing with integers:
//case OP_NOTEQUAL: // use OP_NUMNOTEQUAL
What is the point of the OP_NUMEQUAL opcode? Can't you just always use OP_EQUAL instead? Is OP_NUMEQUAL more efficient than OP_EQUAL when dealing with integers?

OP_NUMEQUAL doesn't provide a subset of the functionality of OP_EQUAL as they evaluate differently when comparing 0x01 with 0x0001. OP_NUMEQUAL evaluates 0x01 and 0x0001 as equal as it compares 1 with 1 whilst OP_EQUAL does not deem them equal as it compares a different number of bytes. Hence which one you use in your script will be determined by whether you want such a comparison to evaluate to equal or not.
Edit (August 2023):
Note the Taproot descriptor multi_a uses the OP_NUMEQUAL opcode. multi_a(k,A,B,C,...Z) translates to:
[A] CHECKSIG [B] CHECKSIGADD [C] CHECKSIGADD ... [Z] CHECKSIGADD <k> OP_NUMEQUAL

There is no strong reason for it doing so as multi_a will always have the number encoded minimally. It arguably makes it easier to parse as OP_EQUAL is used in multiple other Miniscript constructions.
Thanks to individuals on IRC for clarifying the latter.


text:
Solving a Block with more than one miner connected to same daemon
Well excuse me in advance if my question sounds funny. But I'm just curious perhaps someone can shed a light.
When in a pool of miners, let's say there are 100 miners connected to a single daemon node, do they solve every block together, concurrently computing, work is divided among miners? Or each miner solves the block individually, parallel?
To further elaborate, for example I got 100 machines, should I connect them all to a single daemon node to mine or it's better to let them mine with their own daemon node each?

Miners connect to a mining pool, which in turn connect to one or more bitcoin nodes. The miners get separate work from the pool and work in parallel.
Working in serial is not possible. There is no progress in mining. Your hash (lottery ticket) is either a winning ticket or not. Then you go on to the next hash. Mining is brute force. You go through billions of lottery tickets per second.
So two miners cannot find the winning ticket "together". They could both do the same work and find the same block, but that would be an awful waste. It is very important that the mining pool does not give out the same work twice. Two miners should never be checking the same lottery tickets (hashes).
Connecting miners directly to a bitcoin node is not possible. It used to work in the olden days when the ancient getwork protocol was used. bitcoind didn't have long polling in those days, though, so it really only worked in theory. These days miners speak stratum and bitcoin nodes speak getblocktemplate. The two protocols are not compatible, so there must be something in between, usually a mining pool.


text:
How to get bitcoin wallet name from bitcoin address
In http://bitcoinwhoswho.com/ , we can find wallet name from bitcoin address, how do they do so? Is there any signature of wallet name in bitcoin address or in transaction id?

There's no concept of a "Wallet" on the blockchain. The "Wallet" you are using with your Bitcoin software is just a group of keys.

yep, thats why that website puzzled me. :P

Welcome to Bitcoin.SE!
I have had a quick look at the website you referenced specifically, however, it suggests most of the information that they have is because people have 'claimed' their address and provided the details.
If you have a look at this example, that represents just about all that is publicly obtainable when someone makes a transaction + the public keys. And, website information, names and, labels is not sourced from the blockchain.


text:
Is Sharding a Good Alternative to MultiSig?
For security purposes, we require that each withdrawal be "approved" by multiple servers so that in the event a single server is compromised the attacker won't be able to siphon funds from the entire wallet. The typical approach to execute this concept is a MultiSig address where a transaction is only approved after it is signed by multiple entities.
However, the fees for a 2/3 MultiSig transaction are nearly twice as high as fees for a regular transaction. If we wanted 3/4 (or higher) MultiSig the fees would be even costlier. This got me thinking of a way to take advantage of the security benefits offered by MultiSig transactions without suffering from excessive fee consumption in the process.
The immediate solution that comes to mind is sharding. In short, instead of using MultiSig we can safely break up the PK using Shamir's Secret Sharing Scheme with unlimited schemes (such as 4-of-7 or 3-of-4 etc) and store the shards on separate servers thereby requiring multiple servers to "sign" a withdrawal request.
Does MultiSig provide any (security) benefit over sharding? Is sharding a viable alternative to MultiSig?
Update:
Perhaps the only problem with this proposal is that each server cannot independently "authorize" the transaction using its "shard". At some point, all shards would need to be known to "reassemble" the PK so the attacker could still use this as the "weakest link" to steal the PK? Is this correct?
Thanks

Advantages of OP_CHECKMULTISIG over Shamir Secret Sharing for k-of-n:

There is no need to reconstruct the actual secret key on one specific machine. With SSS, you're inherently relying on that one machine being able to verify that what it's going to sign is what is intended - otherwise you may e.g. be sending your entire balance instead of just the payment you wanted to make. Also, if that key or (in case BIP32 public derivation is used) any related key is ever reused, that machine being compromised would in fact expose your entire wallet, including future funds. Given that the end goal is reducing the need to rely on the security of a single device, this is not ideal.
Accountability: with an SSS-based signature, the on-chain signature cannot tell you which signer(s) actually signed for spending, while OP_CHECKMULTISIG does. If you want the ability to go after rogue signers.

Advantages of SSS over OP_CHECKMULTISIG:

Cheaper on-chain.
Better policy privacy (you're not revealing on-chain that you were in fact using a multisig policy).

Now, with the hopefully upcoming activation of BIP 341-342 (Taproot) which includes support for BIP 340 Schnorr signatures, there will be more options (disclaimed: I'm a co-author of these proposals):

Native threshold signatures: with Schnorr signatures it is possible to perform something that's effectively equivalent to performing SSS on the public keys, and at signing time on the signatures, and end up with a valid combined signature for the combined public key. This gets you some of the advantages of both, and some additional disadvantages:

No single machine where the private key needs to be combined on (only signatures ever get combined, which are only valid for the specific message the individual signers signed).
Lack of accountability like SSS.
Same on-chain cost as SSS.
Same on-chain policy privacy as SSS.
More complicated protocol that needs multiple interaction rounds between the signers. Also lots of edge cases to take into account to make this secure in practice. For recent work, see FROST. If all you need is n-of-n (rather than k-of-n), it is simpler and less involved; see e.g. MuSig2.

That's not the only option, though. More alternatives are listed in BIP 342, note 5. In a way, SSS and OP_CHECKMULTISIG are two extremes of a spectrum. For example, you can construct an output that contains a Merkle root of a tree for which every leaf is one k-of-k aggregated key. It can be spent by revealing the Merkle branch plus the aggregated signature. This is usually cheaper than OP_CHECKMULTISIG-like constructions that publish all keys and signatures, but not as good as the SSS-like approaches give you. On the other hand, it's simpler too.