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

When you think we will see faster transactions and lower fees? I thought that should be a consequence of SegWit?

Thank you again.

"Core" is a group of developers. We aren't exactly social people nor are we affiliated with "crypto media". They tend to not write things about what we are doing even though virtually all discussion happens in the open. It is not that "Core" is secretive but rather we produce little content that the media can capitalize on to make stories (i.e. not much interesting stuff comes out that journalists can understand and write stories about; we don't have press releases or anything of the like) as nearly all discussions are technical in nature. Furthermore, "Core" is not an entity; it is not one cohesive thing with an opinion. It is made up of several individual developers who happen to work on the same thing. Very rarely does "Core" produce something unless nearly all of those individuals agree on the same thing and agree that it should be published. However "Core" has made their position very clear on 2x and this blog post: https://bitcoincore.org/en/2017/08/18/btc1-misleading-statements/ details what everyone in "Core" generally agrees with.

The quadratic sighashing issue, although limited by a 1 MB tx limit, can still cause large blocks to take even longer to validate (on the order of several seconds, which to computers is ages). The memory blowup attack which, although is an implementation problem, AFAIK the fix is not present in btc1 (the segwit2x implementation). It is also not known whether the network can handle 8 MB blocks (that is what the effective maximum block size would be) and how that would effect block orphan rates and full node count.

Jeff Garzik.

If 2x does somehow succeed, then most Bitcoin Core developers will quit Bitcoin entirely as 2x's success would mean that miners and companies can have absolute control over what Bitcoin does. Bitcoin would no longer be decentralized and be something that miners can change on a whim.

Thank you. You're right, I'm not a developer/miner/etc. and I don't understand all the code and everything all that well, which is why I'm here trying to learn more before the chain splits again. I do realize that forks are things that need to be thoroughly tested, both soft and hard. Also, I realize that hard forks are much more difficult to plan.

It looks like you're part of Core. This does give me a better idea of why you're opposed to it, though Core probably should voice their reasoning more publicly. To me, Core seems to be rather secretive and little is published about them in the crypto media, which is what most in the crypto community follow and all we hear is that Core is opposed. This fork is much more divisive than BCH, I really hope you're able get more miners/exchanges on your chain.

Could you elaborate on this some:

Who can we expect to be the developers for the Segwit2x chain if Core stays on the old chain?

Segwit2x was produced from essentially a backroom deal of only a bunch of companies. The "New York Agreement" was written beforehand and the signers were invited to just sign it. Some Bitcoin Core developers were invited, but only to sign the agreement. They weren't invited to discuss the proposal at all as it was already written, they were invited to stamp their approval on it. Those Bitcoin Core developers who were invited declined to go and sign the agreement. The agreement was written by companies and completely without any input from the technical community.

The block size has already been increased with segwit. We don't know how that exactly is going to effect things and increasing the block size again so soon will probably be detrimental to Bitcoin (note that there are a lot more things to consider than just the capacity of blocks). Changing things now may cause Bitcoin to be worse off in the future.

Clearly you don't understand the code and how forks have been deployed in Bitcoin. Even for "simple" change, a lot still has to be done for it (deployment code, tests, etc). The 2x hard fork is very rushed and done without much or any review (of both code and technical merits). Furthermore, it is well known to the developers that there are many issues with larger block sizes which 2x does not address. Lastly the Bitcoin Core developers consider hard forks something that should rarely happen. Thus if a hard fork does happen, it should be planned out to happen well into the future and include a lot of things that need fixing via hard fork (e.g the things on the hard fork wishlist).

I'm having a really hard time understanding why there is so much disagreement over Segwit2x and Core. I've tried to find answers but everyone seems to have a different one. So far I've heard the following:

Segwit2x is supported by a corporate backed development team and only about money, not bitcoin. They are supporting the fork to divide us and kill Bitcoin. I don't know if this is true or not, but would like more info if someone has a reference.

Segwit2x is a hardfork and Core does not like to hardfork. Fair enough, but blocksize can't stay at 1 MB forever. Why would we split the community if we're going to need it down the road anyway.

Segwit2x is simply unnecessary. Read above.

Segwit2x code is unreliable and opens up new attack vectors. I didn't think this was anything other than a basic change of block size parameters and nothing else.

Segwit2x was for the big blockers who got their BCH.

According to this: https://en.bitcoin.it/wiki/Segwit_support#Developers Core is unanimously opposed to Segwit2x. But why? What is so bad about it?

I don't know who's side I am suppose to be on. I'm inclined to side with the most talented of the group, which would be Core, but again why do they hate Segwit2x so much?

Correct me if I'm wrong, but IIRC, a transaction is considered a "Segwit transaction" and have all its benefits if the funds have been sent from a Segwit address, regardless of the type of address the receiver has.

non-segwit to segwit = legacy transaction
segwit to non-segwit = segwit transaction

I'm a bit confused here. If I ever send funds from a non-segwit address to a SegWit address (I will clearly not have the benefits of SegWit here) then what happens (whether its considered as a SegWit transaction or not) If spend that to another non-SegWit address?

Would someone please write up a BIP for the SegWit signature algorithm implemented in Trezor and discussed here:

https://github.com/trezor/trezor-mcu/issues/169

So that we can kick start the process of having this become the industry standard algorithm for signatures based on SegWit addresses.

I am sorry but I do not have the time to write it up right now.

Thanks!

I would think that it is that. If its not synced it does not know segwit is activated yet.

I tried using the [addwitnessaddress address] in bitcoin core and go an error code 4 (segwit not activated on the network yet). Is there a reason for this does anyone know? The only thing I can think of is that my bitcoin core version is not fully synced yet with the network/blockchain and that might be causing the problem but other than that...

thx, got it. And thanx for your patience, explaining twice to me.
I went through Andreas' book, which says:
...
But it doesn't mention this handshake or protocol. I might send him a note ...

No, I just explained this to you, but I will do it again with more detail.

When you broadcast a transaction to the network, what you are doing is telling all of your nodes "I have a piece of data that is of type transaction". This is done with an inv message. When legacy nodes receive that inv message, the tell you "Give me this piece of data that is of type transaction". That is a getdata message, and the type is specified by an integer interpreted as MSG_TX. However when a segwit node reeives the inv, they say "Give me this piece of data that is of type witness transaction." That is a getdata message and the type is specified by an integer interpreted as MSG_WITNESS_TX. When you node receives the getdata message, it looks at the type that the requesting node asked for. If it asked for a MSG_TX, then a transaction will be sent in the legacy transaction format. If it asked for a MSG_WITNESS_TX, then the transaction will be sent in the witness format (note that the witness format for non-segwit transactions is the legacy transaction format). So non-segwit nodes will receive a segwit transaction in legacy format, i.e. all witness data stripped out and segwit nodes will receive the whole thing.

ok, I got that, with the MSG_TX and Segwit tx will only be sent in response to getdata. I still have to get the full picture...
Assume I have a segwit capable client, created a segwit tx, and push it into the network. Potentially an "old" full client can fetch the tx. If so, what is he doing: rejecting the transaction, cause he receives "zero" TX_IN_Count ?

p.s.: looked up communication between nodes (here it is getheaders): https://bitcointalksearch.org/topic/how-does-getheaders-to-work-1573616, looks like I need to dive deeper...

The problem is that they are not shifting 25% but rather 60% and more at a time and this effectively cripple the mining on the least profitable chain. We should find a solution to keep them on a specific chain and preventing them to switch. They have a choice to mine what they want, but they should not be able to cripple a specific coin, by jumping between chains.

It might sound unethical to do this, but in doing this we are securing our network and also retaining our hashing power and increasing our effectiveness. This will also introduce specialization into mining and giving other Alt coins a foot in the door.

Just play with the idea. Miners have too much power and influence at the moment.

Yes, that is correct.

So legacy bitcoin nodes will receive the same data, except without the witness data at the end, correct? I think I finally understand why it's called a soft fork now, these legacy nodes are virtually untouched through segwit.  Am I correct on this, or did I still get it wrong?

Because old clients will not receive transactions in the segwit transaction format. Segwit transactions will only be sent in response to a getdata for inv type MSG_WITNESS_TX. However old nodes will not have that inv type in their getdata messages, only MSG_TX, which indicates to segwit capable nodes to send the transaction in the legacy format.

I can't get the details to understand how old clients work with segwit transactions.
I find phrases like . And then phrases like "old clients don't forward segwit tx" (cause they are invalid?).
So as usual I take a look into the description: (https://bitcoin.org/en/developer-reference#raw-transaction-format)

Quote

Name           Data Type           Description
version         uint32_t              Transaction version number
tx_in count   compactSize uint  Number of inputs in this transaction.
tx_in            txIn                    Transaction inputs as outpoint data structure
 ->prev_out  outpoint              Previous outpoint, beginning with tx ID hash
...

Signed SegWit tx are serialized in this way (https://bitcoincore.org/en/segwit_wallet_dev/):
 nVersion|marker|flag|txins|txouts|witness|nLockTime
    Format of nVersion, txins, txouts, and nLockTime are same as the original format
    The marker MUST be 0x00
    The flag MUST be 0x01
    ...

Looking at the way an old client would receive data, he would get serialized data:

 nVersion   | Marker | flag | txins ...
 01000000      00        01    ...

So the old client would interprete the nVersion code correctly, but then would get a "00" (the marker field) as the "tx_in count", trying to get the following "01" as the tx_in structure. This tx_in structure begins with an outpoint, that has a tx ID hash as first element. So the "01" and subsequent hex characters would build the TX ID Hash (32Bytes).

I would think, that already the marker field ("00") would make the tx invalid for an old client (zero input not allowed?), and then the tx_in structure (and the tx ID hash field) is filled with "garbled" data.

How can this segwit tx then be seen as transparent to the old client?  Wouldn't the old client simply mark it as invalid?

thx 

wow! when i just saw andre antonopolos tweet about paying a contractor with segwit i decided to take a look at this forum, didnt now ledger starting supporting a segwit txs, that is awesome!!