Even so, a 1 Mb transaction can still take a while to validate. A hypothetical scenario described here: https://bitcointalk.org/?topic=140078 states that a transaction of 1 Mb could take up to 3 minutes to verify. In reality, there was a roughly 1 Mb transaction that took about 25 seconds to verify described here: http://rusty.ozlabs.org/?p=522. Anything that is over a few seconds is quite a long time in computer standards. Now, both of those scenarios are less likely to happen now since libsecp256k1 introduced significantly faster signature validation, but it is still vulnerable to such attacks. A maliciously crafted 1 Mb transaction could, in theory, still take 25 seconds or longer to verify.

When you install, change the install directory to your flash drive. When you want to run bitcoin core, you will need to start it with the
Option where <path to data folder> is the path to the folder on your flash drive where you want the data to be stored. The data is the blockchain, databases, and the wallet file.

No. What he was responding to was th original idea of changing  txid calculation entirely too something new. This idea (the second option) is instead introducing a new txid calculation method which will work alongside the original txid calculation algorithm.

Additionally, on further thought, it will still require twice the lookup tables. There needs to be one for the transactions that version 1 txs can spend from and one for the version 2 txs. Version 2 txs still need to be able to reference the txid of a version 1 tx to spend from it or that ntxid for the version 1 tx also needs to be stored somewhere so it will increase the lookup table sizes.

Unconfirmed transactions are the issue. What do we do about transactions that were created just before the fork block? How do you distinguish between an unconfirmed transaction created prior to the fork and an unconfirmed transaction created after the fork block?

The first is possible but it is not optimal because it requires twice the lookup table size.

The second is also possible but the issue is the hard fork. The problem is that hard forks shouldn't be done often and for small things like this. It would be better if it was packaged with other stuff that is desired that also requires a hard fork. If also has less functionality than segwit.

I think they are since the transaction is hashed differently if the transaction uses witnesses. The different hashing method allows for faster hashes by using midstates which can be reused for every signature verification.

If you could put up a doc with notes on armory, that would be great! I am trying to write some changes but when I get to the C++ part, I find it hard to figure out which file has what I want to change. The Python part is relatively self-explanatory.

I noticed that droark created a breakdown of the Bitcoin Core source at https://github.com/droark/bitcoin-dev-notes/blob/master/Bitcoin_Core_source_breakdown.md. Does such a thing also exist for armory?

Although I don't think Bitcoin Core has stats on reorgs, it does keep all of the valid blocks it receives. You could scan through the blk*.dat files and see if there were any chain reorgs.

Edit: I stand corrected:

Nope. You only know it if the service running the API announces that something will change or if it suddenly changes and now nothing works.

Satoshi doesn't have a github account. I'm pretty sure that the original sourceforge repository was setup by Sirius. It was migrated to github later by someone else.

A post of poor quality adds nothing to the discussion. They can be irrelevant to the discussion or repeats of what was already said.

If you are posting for the sake of posting, then don't post. If what you are going to say has already been said, don't post. If what you post just isn't going to help advance the discussion, don't post.

This also applies to the long threads with stupid questions where people only post to boost their post count.

It depends on whether blockcypher changes their API but it shouldn't matter unless you are getting raw transactions and verifying then.

I've been told that it is been consistently high but it has been a while since I checked the prices and accuracy so I don't really know.

So, some history. Satoshi wrote the bitcoin whitepaper in late 2008. The whitepaper laid out the design of the bitcoin system. This paper was posted on sourceforge and posted to the cypherpunks mailing list. A few months later, satoshi released the first bitcoin client, bitcoin 0.1.0. Bitcoin core is based upon this client.

Now satoshi probably did create several test Genesis blocks and blockchains while writing this software but the current Genesis block and blockchain is the original production one and the only production mainnet blockchain. Satoshi mined this block and created the Genesis transaction. He probably also mined the first several hundred blocks himself as well.

One of the first bitcoiners was Hal Finney and he and satoshi made some of the first transactions and code changes to bitcoin. Also present was Sirius also did many of the early code changes for bitcoin. Later Gavin also began developing bitcoin in 2010. Some of the other people who develop bitcoin such as Pieter and Gaezik also began working on bitcoin in 2011.

Wladimir came into the scene also in 2011. He is the current release maintainer meaning he decides release schedules and tags released. He took over after Gavin who took over after satoshi. The current oldest source on github comes from the original sourceforge repository. The oldest version is 0.1.5. Prior to that, sources and binaries were probably distributed by zip files from satoshi.

The github repository is not maintained by Wladimir but by all of the core devs collectively.

The address that you mention does get the Genesis block block reward, but due to something in the code that I don't remember, it is actually unspendable. The Genesis block and its coinbase transaction are hard coded into the software.

No. LTC and BTC use two different mining algorithms. ASICs are application specific and this application is the sha256d hash only, which is not the one the litecoin uses.

jl777, this link: https://bitcoincore.org/en/segwit_wallet_dev/ might be useful to you for help with implementing segwit.

Using the same two public keys the same p2sh address will always be generated.

If you can get the redeemscript, then yes.

Maybe you should read gmaxwell's posts about doing a hard fork to change that calculation. They are a few posts above this in this thread.

You can use  gettransaction or getrawtransaction to get the details of a transaction and see how many confirmations it has.

No, they were against hard forking for changing the way that a txid was calculated.