Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 30. (Read 84847 times)

If you've come up with some genuine analysis as to why Segwit is a bad thing, I'm all ears. But what you wrote is seriously thin on explanation, I'm not going to attempt to read between the lines of some vague, incoherent handwaving. Either say exactly what you're getting at or be quiet.

Go reread what I posted ... and reread it ... and reread it ... until you understand that what I posted is how it works, and that your segwit fanboyism is blinding you.

The average user doesn't even need to read the code, they can fire up a 12.1 node and watch as it connects to a bunch of 13.1 nodes that you claim are blacklisting it. But by all means, keep talking

LOL read about how it works.

You're the one talking shit

Look, it's simple.

If 13.1 nodes are blacklisting lower versions, why then are 13.1 nodes connecting to lower versions? Is it because you're talking shit?

Really?

The technical term is de-prioritisation.

Though I wont post the name of the dev who said

There are no segwit blocks.

The result is effectively blacklisting.

To ensure that the network is not partitioned and that segwit blocks are being passed to segwit enabled nodes, a Core 0.13.1 node will use its outgoing connection slots to connect to as many nodes with the NODE_WITNESS service bit as possible (right now only Core 0.13.1 nodes). However a 0.13.1 node will still accept incoming connections from older nodes. There is no blacklisting going on, just preference for the outgoing connections to connect to nodes of the same capabilities.

Kano, your trolling is terrible. You're a disgrace to the technical community for posting this claim.


That's not the idea behind that code, the idea is to make sure that the soft-fork does not cause a network partition. Unless you've got something helpful or insightful to say, shut your mouth

It's not even an absolute connection preference, hence why those running sub 13.1 nodes do connect to 13.1 nodes with free connection slots. You should be ashamed of yourself

So I guess no one noticed the blacklisting in the new 0.13.1 code?

So if you run 0.13.1 you will find that it will connect to other 0.13.1 nodes on the network, but not to 0.13.0 or lower.

i.e. you are disconnecting yourself from the majority of pools, mining transactions on the network.

At the moment that's ~75% of blocks.
Your txns can of course get to the pools via other roundabout ways, but you wont connect to them directly.

Yeah even the main core developers implement blacklists without making it clear they exist

That is possible, but the node still would not accept the transaction because segwit output are considered non standard. Such a transaction would thus be considered non standard and rejected by the node until it is included into a block.

There are in fact no such things as segwit transactions. There are transactions which spend from segwit output types. Because those output types are created by the receiver of a transaction, then it is impossible for a non segwit wallet to receive a segwit output to that wallet because there are no segwit outputs associated with the wallet. A transaction can spend from a segwit output types and spend to a legacy output type and that is perfectly fine and will be considered valid by the receiving non-segwit wallet (of course it has to be confirmed first because said transaction would be non-standard).

There already addresses that start with a '3' and they have been standard for many years already. These addresses are called Pay to Script Hash (p2sh) addresses and are most commonly used for multisig addresses.

Is it true that if Segwit gets activated that Bitcoin addresses will start with "3" than the normal "1"? How are we going to be forced to make the switch with the most hassle free way possible?

If SegWit is implemented into Bitcoin, then anyone who does not use SegWit is going to have to pay a premium in TX fees when compared to users who do use SegWit, so to the extent that SegWit is implemented into Bitcoin, using SegWit is beneficial to the user of Bitcoin (this is not the same as saying that SegWit is what is best for Bitcoin).

You are correct to say that some wallet providers (and other bitcoin services as well) might think that SegWit is what is best for Bitcoin. My question is, has anyone attempted to ask the "official" opinion of major bitcoin services regarding their stance of SegWit? The success of most major bitcoin related services is generally aligned with the success of Bitcoin.

While I do concede that after a soft fork, a node may not know that a particular transaction is invalid, I think that this is not quite the same with SegWit. For example, if a soft fork that invalidated any transaction after block n that is signed with (/contains?) a "high" s-value, then a node that has not upgraded might receive a transaction with a high s-value and not reject said transaction -- however said transaction would be a valid transaction prior to block n, and the soft fork. I would think that much of the time, a sender of these kinds of invalid transactions would have made an honest mistake (although there are some exceptions to this), and the receiver could ask the sender to resend the transaction after sufficient time has passed and has not confirmed. What I believe the difference is that someone could send a SegWit transaction to a non-SegWit node that was never valid, but the node would treat said transaction as if it were valid.

---

I do have another SegWit related question:

If someone who has not upgraded to SegWit receives a SegWit transaction, are they able to spend outputs from said transaction?

No.

Will the blockchain develop to a stage that people who do not use segwit will not be able to transact through any other means i.e legacy transactions become obsolete?

Segwit introduces a lot of other changes as well. It makes the sighashing linear instead of quadratic. Additionally the sighashing includes additional information that helps with cold storage and hardware wallets which are not connected to the internet. This allows those offline wallets to also verify transactions before signing, something that hardware wallet vendors (at least 1 that I know of) have indicated is something that the want.

While that is true, there are also many wallet vendors who do also believe that segwit is the way to go. In fact, those that don't think segwit is best don't need to implement segwit (and probably aren't going to).

No, you are incorrect. Non-upgraded nodes do not suddenly just stop validating transactions and are suddenly unable to validate transactions. They still fully validate all transactions and blocks to the best of their ability. This means that transaction hashes are still checked, the merkle root is still checked, signatures of legacy transactions are checked, inputs and referenced outpoints are checked, etc. Non-upgraded nodes still check and validate nearly everything in a segwit transaction. The only thing that they are unable to do is to check the signatures for segwit transactions. In that case, the wallet relies on miners on having done so and it waits for confirmations for segwit transactions before accepting them. This is no different from other soft forks.

Your understanding is flawed.

Segwit transactions will appear to pre-13.1 nodes as ANYONECANPAY. That's why they will be able to validate Segwit blocks without being able to understand Segwit. This is how any soft forks in the past that alter signature interpretation have handled it, and the mechanism has been in Bitcoin either since the beginning or from very early on.

It is possible for one person or entity to rent several VPSs and run a full node that runs Core 13.1 (or some other version of Bitcoin), so while counts of various types of nodes does mean something, it doesn't necessarily reflect the overall support of the community.

I am really looking for the opinions of major Bitcoin companies such as Coinbase, BipPay, Circle, major exchanges, gambling sites, and others. Do they wish for SegWit to be implemented, do they wish for SegWit to not be implemented, are they neutral?

I agree that SegWit allows for a greater number of transactions in a block, but I don't think it is the most optimal way to achieve this. I am not sure how serious other problems that SegWit "fixes" really are for Bitcoin, especially malleability

Wallet software is being changed to implement SegWit because the creators of such software believe that SegWit will likely be implemented, not necessarily because they believe SegWit is what is best for Bitcoin. If it was apparent that Bitcoin was about to HF to have a maximum block size of 2 MB, then wallet providers would likely also be in the process of upgrading their software to support this.

Even if I know that a particular node is run by coinbase (for example), the fact that this node 'supports' SegWit, does not necessarily mean that coinbase supports SegWit. If SegWit does in fact get implemented into the Bitcoin network, then coinbase (in this example) will want to have prepared for, and tested SegWit sufficiently.

My understanding is that if a node does not upgrade, then it does not have a way to validate that a transaction is valid (due to being unable to validate the transactions signature), and does not have any way to validate that a block that contains one or more SegWit transactions is valid. Am I right about this, or is this not accurate?

If the above is accurate, then I think you are using a very specific definition of "backwards compatible" to make your statement.

No. Transaction malleability is a barrier to a different type of tracking, tracking when a transaction for a deposit confirms. This is for exchanges and services since they usually track when a transaction confirms so that they can credit the account. Usually they look for a specific txid in a block, but if a transaction was malleated and the malleated transaction was included in the block, the Bitcoin was still paid but the service does not know that since they were not looking for the malleated transaction. The service would not know of the malleated transaction because their node would reject it as a double spend.