That change has nothing to do with what your original statement was:
The ripemd160 to sha256 for p2wsh outputs has nothing to do with keypairs.

No 0.12.x release contains any segwit implementation. 0.13.0 and 0.13.1 contain nearly the same segwit implementation (the consensus implementation is not changed). So yes, perhaps you could call it two implementations, but that would be a stretch. Furthermore, you can't even use 0.13.0 with segwit on mainnet, so there is really only one segwit implementation in Core if you want to use segwit on mainnet after deployment.

Polished and ready IS NOT THE SAME AS compatible.

Maybe you don't understand what I am writing, I'll try to break it down for you.

With the segnets, you could do all of the things that you can do NOW with Bitcoin. You couldn't do all of the things with segwit that you can do now on testnet, and some of those things that you tried to do could fail in a horrible way. But it was still compatible with Bitcoin, it did not break anything that you can do with Bitcoin NOW. Segwit was not polished and ready meaning that doing certain segwit related things with the implementation at the time could fail horribly or not work as expected.

The first segnet was not the elements design. It was based on Bitcoin Core. At that point in time, segwit was not ready or polished enough to be tested on testnet, so they created segnet.

During that time, it was already bitcoin compatible, just not polished or ready for testnet, which is why the segnets were created. It was most certainly Bitcoin compatible by segnet3 since I was doing testing on segnet3 with normal Bitcoin transactions and it all went perfectly fine. I'm pretty sure that it was bitcoin compatible in the previous segnets, but I personally did not try them out.

The public version of segwit that is up for activation began as a fork and modification of Bitcoin Core. The concept started on elements, but it was not the elements code made compatible with Bitcoin. The reason it was not deployed on testnet when they began implementation was because it is a consensus change and the developers wanted to test their changes without fucking up anything used publicly (i.e. testnet). The segnets were for "private" testing of segnet so that they could break things without causing major problems with other developers who were using testnet. Breaking testnet would mean that testnet would need to be reset, a much larger and harder task than resetting the segnets.

Tests were being done on the segnets long before it was deployed on testnet. Why do you think they would not test it beforehand before deploying it on a semi-important network? They had to be confident that it would not break the testnet so they did testing on the segnets.

There is a change to the wallets, but not in the way that you are describing. The change is related to output and script creation, not to the ECDSA keypairs.

Also, the wallet part of Bitcoin Core does support segwit. You can have it create the segwit address for an address in your wallet and it will know to track it and how to spend from it. What it doesn't do now is default to using segwit addresses by default (i.e. it just doesn't give you a segwit address when you ask for a new address).

There are 4 BIPs that are being deployed that are related to segwit (peer services, consensus, transactions, GBT). However that does not mean that there are 4 different implementations. There is one implementation specified in 4 documents so that the changes to those things are clearly defined.

I assumed that you were talking about tracking as in de-anonymizing who is sending the transaction. Instead you are talking about tracking as in checking the confirmation status of a transaction. In the latter case (watching a transaction) it is easier to track because malleability is fixed.

I don't think that it is necessary for lightning to be a full node. It can still work without being a full node but with some additional complexity. Where in the lightning paper does it say that a full node is required?


The Lightning Network conducts transactions by creating Bitcoin transactions that can be broadcast onto the Bitcoin network at any time. There are no IOUs being traded, what is happening is that transactions are being created but not broadcast. Again, there is no separate thing where Bitcoin is being converted into some sort of IOU on lightning.

That risk is based on miner collusion. The reverse would also require miner collusion, not some technical aspect of LN that makes it possible for only specific miners to mine those transactions. This is not just something related to LN but rather an issue that can already happen with Bitcoin as it is because it is just miner collusion and requiring human intervention in order for that to be possible.

In what way? The way that inputs and outputs work are still exactly the same.

How so? An LN Node doesn't need to be a full Bitcoin node already. They can work fine as SPV wallets now and after Segwit. Segwit does not change that at all.

What requires a Lightning client to be a full node? As I understand it, it doesn't matter, and segwit does not change that.

I don't think you understand how LN works. LN does not issue IOUs. It creates very real, valid, and broadcastable Bitcoin transactions. There are no IOUs involved.

Not necessarily. LN is not for every type of transaction. It is really only good for small, repeated transactions like faucet payments.

Now that is just FUD. How would LN only allow certain miners to confirm those transactions? That is just completely false.

Blockstream does not own the Lightning Network. LN is an open source spec that is being implemented by multiple teams, it has not owner nor controller.

Regardless, discussing LN in this thread is off topic.

---

You are demonstrating and extreme lack of knowledge on subjects you are arguing against. I highly suggest that you actually do some research before posting.

Please stop spreading FUD.

The segnet was announced right on the new year on December 31st. IIRC it was running before the post to the mailing list.

That is simply not true. Segwit was built on top of Bitcoin Core. It was not an altcoin that was modified to do what Bitcoin does, it was Bitcoin modified to do segwit stuff. However, the elements sidechain was probably completely incompatible, but that codebase was not modified to become Bitcoin but rather the other way around.

Segwit actually activated on testnet block 834624 which was in May.

Not entirely true. Segwit fully works with Core 0.13.1 and you can do segwit transactions from the RPC. It does not have segwit wallet support unfortunately, but other wallets will. (If you couldn't tell, the Core devs tend to focus more on the node aspect of Core instead of the wallet.)

That is just completely and absolutely false. There is no such thing as HD seeded keypairs. Segwit works only with the normal ECDSA keypairs, regardless of whether those keys were derived deterministically.

What 4 different implementations? Users have only needed to download one implementation, the one that was released.

---

---

Please stop with the FUD and trolling. Actually fact check your statements before you make them.

Download and install the latest Bitcoin Core from https://bitcoin.org/en/download. That "Download Bitcoin" button probably doesn't work because it is related to ATI phone home code which was mostly removed.

Please stop with the FUD. Lightning is not just being developed by Blockstream. There are already multiple implementations of Lightning made by multiple different teams, only one of which is Blockstream.

Furthermore segwit is more than just a fix for Lightning. It provides much more uses and fixes which have already been discussed in this thread and elsewhere.

The genesis block is hard coded into the client. If you want a different genesis block, you will have to make it yourself.

If you just want to test and experiment with Bitcoin, you can use regtest mode. This will create a private blockchain which you an mine yourself and test various things.

Yes, that post should work for me.

For now it will be an indicator. Maybe later it will effect the price.

Link to source?

Actually the original code had the entire block subsidy cycle repeat every 64 halvings due to some undefined behavior with c++. BIP 42 (which is full of jokes): https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki fixes this by stopping the halving logic after 64 halvings have passed so that there is actually a finite supply. The change has been merged for a few years already.

Who is proposing this? I have not seen any serious proposal which proposes any sort of change to the monetary supply (except for BIP 42). Do you have a link to a source?

Yes.

Are the lists on the first two posts the definitive SMAS blacklists? Is there a place where I can just retrieve a text file with just the names of all of the people on the SMAS blacklist? I am planning on including an SMAS blacklist indicator for my account pricer.

The transaction was probably unconfirmed for a long time and it was eventually dropped from the network. You likely did not include a high enough fee. Since it has dropped, you should be able to resend the transaction but include a fee so that it can be confirmed.

Yes

Not quite. Uncompressed keys are still technically allowed and valid, just that local node policy for Bitcoin Core is that transactions spending segwit outputs that use uncompressed keys will not be relayed.

I think you are running out of RAM. Look at your CPU, RAM, and disk usage stats while you are running Bitcoin Core. I think that you will see your RAM usage go to 100% and then the computer freezes.

Try closing as many other open applications to free up as much RAM as possible

Bitcoin Core just froze Ubuntu again, it had been running for about an hour, more often it happens after 15-20 minutes. I was able to download blockchain until 1 year 40 weeks were left, then this problem started.

I can't find bitcoin.conf, it should be in /home/username/.bitcoin/bitcoin.conf , but it is not there.

UPDATE:
This is Bitcoin-Qt.conf file from /home/username/.config/Bitcoin :
[/quote]
Bitcoin-Qt.conf is not related to this. That is an internal Qt thing. The bitcoin.conf file in ~/.bitcoin does not exist unless you create it. Make a new text file and save it as ~/.bitcoin/bitcoin.conf. Then add the following line:
This should lower ram usage. The sync will go slowly, but it hopefully won't freeze your computer.

There is no problem here. If the hashes match and you properly verify the download by following: https://bitcointalk.org/index.php?topic=1588906.0 then there will be absolutely no problems.

The AV warnings are all false positives. They usually flag Bitcoin Core as a coin stealer (because it looks for a wallet.dat since it creates the file) or a bitcoin miner (because it contains a miner in the software if you want to mine on regtest or testnet).

ICO means Initial Coin Offering. It means that a new altcoin has been created (and probably premined) and the coins are being sold.