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.

Well I think those changes could be soft forked in because it changes the script version number, which I think would only affect the address type. I could be wrong though.

I am fairly certain that this isn't possible since it would require the private keys that can spend the inputs of all of the transactions to sign it. However, I could be wrong as I am not well versed in many parts of cryptography. There maybe is an algorithm which could combine all of the signatures, I don't know. You'll have to ask gmaxwell, he is the "chief cryptographer".

Where did luke-jr tell you this? Did he explain why? I don't understand the 1 byte per vin part and would like to see the explanation for it.

What gmaxwell is saying is that segwit allows for future upgrades. One of those future upgrades could be an upgrade to a different signature scheme which does have the 30% reduction.

I think it might actually be 33 bytes per vin because of the implementation being used which does not introduce the new address type. This is so that the p2sh script will still verify true to old nodes. It is a 0 byte followed by 32 byte hash of the witness.

And I don't think that anybody has ever said that it would reduce the space needed to store it. If you are believing everything you read on the internet, you need a reality check. When you read these things, make sure that they are actually backed up by reputable sources e.g. the technical papers.

Could you cite the article(s) which did that? If it was something on bitcoin.org or bitcoincore.org then that could be fixed.

Sure. Any other questions about implementation?

Does it portray segwit that extremely positive? I read it and it didn't seem that way to me.

I believe I have forgotten to address this. Can you please explain how you are getting this?

AFAIK the txids aren't in any structure used by Bitcoin except in the inventories. Those might be stored, depends on the implementation. However, when it comes to the wtxids, there is absolutely no reason to store them. Their sole purpose is to simply have a hash of all of the data in a segwit transaction and have that be applied to the witness root hash in the coinbase transaction. There is no need to store the wtxids since nothing ever references them.

Where are you getting numvins from?

Anyways, your formula is wrong if you assume that the regular txid is currently being stored. Rather it should be

N + wtxid + numvins > N

and that is only if you are going to store wtxids which are not necessary to store anyways.

Yes. If you are following the standardness and validation rules that Bitcoin Core uses, then it should be a non-issue.

What do you mean "verifying process"? Do you mean at start up when it says "verifying blocks" or during syncing and reindexing?

I personally have not have issues with that though. Startup takes a minute or two and reindexing takes a few hours, but it isn't that bad.

How powerful is your CPU? A lot of it depends on the CPU speed.

Also, keep in mind that the blockchain has grown significantly since 0.9 was released.

As long as it fully validates all of the NEW blocks and transactions that it receives. HISTORICAL blocks and the transactions within them are not validated because they are HISTORICAL and are tens of thousands of blocks deep.

And how are you checking the txids if they are not provided? A tx message can be sent unsolicited with a new transaction and it does not contain the txid. In fact, there is no network message that I could find that sends a transaction with its txid. Of course, I think it is safe to assume that if a node requested a specific transaction that it would check the hash of the data it received so that it knows whether that data is correct. But for unsolicited transactions, then the only way to verify them is to check the signature.

No, when bootstrapping historical blocks the witness data is not required because it doesn't need to validate historical blocks. See above.

If you are going to run your node from now until the end of time continuously and save all of the data relevant to the blocks and transactions that it receives and call of that data "permanent blockchain data", then yes, I think it does require more storage than a simple 2 Mb fork.

Since when has anyone ever claimed that segwit is "a way to save permanent blockchain space"?

Since you keep saying stuff about sending transactions between nodes, I don't think you understand how Bitcoin transactions work. It isn't sending between things but creating outputs from inputs after proving that the transaction creator can spend from those inputs. The inputs of a transaction don't affect the outputs of a transaction except for the amounts.

A transaction that spends a segwit input can still create a p2pkh and p2pk output which current nodes and wallets understand. p2pkh and p2pk are two output types that wallets currently understand. Those p2pkh and p2pk outputs can be spent from just like every other p2pkh and p2pk output is now. That will not change. The inputs and the scriptsigs of spending from those outputs will be the exact same as they are today. Segwit doesn't change that.

Rather segwit spends to a special script called a witness program. This script becomes a p2sh address, another output type which current wallets know about and can spend to.

Segwit wallets would instead always create p2sh addresses because that is the only way that segwit can implement witness programs to be backwards compatible. Those p2sh addresses are distributed normally but can only be spent from with a witness program.

Then the attacker is just sending the owner of an address a bunch of Bitcoin. If it is a bunch of spam outputs, then it can be annoying, but that is something that people can already do today.

Well firstly, full nodes don't mine blocks.

The data that composes the block is the data that currently comprises of a block. The header is the same. The Coinbase transaction just has the OP_RETURN output to add the witness root to the blockchain. The transactions are the transactions with the current format. If a block is requested by another node that wants the witness data, then the block is sent with the transactions serialized in the witness serialization format.

And in the future, what is to say that simpletons will be able to understand segwit? In the future, someone would still be saying that segwit is too complicated and that we should not use it. In the future it will still be large changes and it will still be prone to misunderstandings. Nothing will change in the future except instead of increasing the block size limit from 1 Mb to 2 Mb, they will be clamoring to increase the block size limit from 2 Mb to 4 Mb. The situation would literally be the same.

---

Yeah, I asked on #bitcoin-core-dev as achow101 (I go by achow101 pretty much everywhere else except here, although I am also achow101 here). I logged off of IRC because I went to sleep, probably should have asked it earlier.

I will look at the BIP pulls and see if there is anything there.

---

It was originally proposed as a hard fork, but someone (luke-jr I think) pointed out that it could be done as a soft fork. Soft forks are preferred because they are backwards compatible. In this case, the backwards compatibility is that if you run non-upgraded software, you can continue as you were and have no ill effect. You just won't be able to take advantage of the new functionality provided by segwit.

Alternatively, if this were done as a hard fork, then everyone would be required to upgrade in order to deploy segwit and then that would essentially force everyone to use segwit.

I am pretty sure that the idea of segwit grew from this idea to ignore signatures in the txid calculation. This was proposed in BIP 140: https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki. It basically proposed a normalized txid which was the txid but ignoring the signatures. The other stuff in that BIP was because the author wanted it deployed as a soft fork rather than a hard fork. Otherwise a hard fork would be needed.

I agree with that, after all, there are 6 separate BIPs for it of which 4 (or 5?) are being implemented in one go.

Again, no. Full nodes don't have to validate the signatures of transactions in super old blocks. This is something that Bitcoin Core currently does and will continue to do. Since it doesn't check the signatures of transactions in historical blocks those witnesses don't need to be downloaded, although I suppose they could. There will of course be people who run nodes that store all of that data (I will probably be one of those people) in case someone wants it.

From the view point of a new node some years in the future, that data isn't needed and it most certainly won't be downloaded or needed. But for now, yes, you will be storing that data but it can be pruned away like the majority of the blockchain can be now. Keep in mind that a pruned node is still a full node. It still validates and relays every transaction and block it receives. Full Nodes do not have to store the entire blockchain, they just need to download it. That extra data is also not counted as what is officially defined as the blockchain.

Anymore? It was never done in the first place. Verifying the transaction has always been checking the signatures because the creating and verifying signatures involve the hash of the transaction.

It won't increase the CPU load because that is what is currently being done and has always been done. In fact, signature validation in Bitcoin Core 0.12+ is significantly faster than in previous versions due to the use of libsecp256k1 which dramatically increased the performance of the validation.

Well first of all, after you run salvagwallet once, it should fix the wallet and save it so you shouldn't need to do it again or have it run every single time.

Secondly, you should post the debug.log so that we can examine it and see what the error is. Based upon your screenshot though, I think we are going to find this message: