Post your SegWit questions here - open discussion - big week for Bitcoin!

[hudd]

Since the SW is activated, how can a user now send a SW transaction?
E.g., I'm using an Electrum wallet, a BitPie wallet, and have a qt full node, and sometimes I also send from/to an exchange or shapeshift.
That whether a transaction is SW or not, depends on the sending address, receiving address, or both? How can I create a SW transaction to lower the fee?

Ledger has supported Segwit recently.
Bitcoin Core is another option but you can only do so using CLI at the moment.
Electrum dev said on github that next version will be released soon letting you create and send segwit addresses.

IMO, most major wallets are ready for segwit. They just didn't let you do so before Segwit finally activated.

[CyberKuro]

Since the SW is activated, how can a user now send a SW transaction?
E.g., I'm using an Electrum wallet, a BitPie wallet, and have a qt full node, and sometimes I also send from/to an exchange or shapeshift.
That whether a transaction is SW or not, depends on the sending address, receiving address, or both? How can I create a SW transaction to lower the fee?

Ledger has supported Segwit recently.
Bitcoin Core is another option but you can only do so using CLI at the moment.
Electrum dev said on github that next version will be released soon letting you create and send segwit addresses.

IMO, most major wallets are ready for segwit. They just didn't let you do so before Segwit finally activated.

It's good for whoever already used ledger wallet or bitcoin core which can transact through segwit chain.
There are over 24K unconfirmed transactions and BTC7 total fees right now, better than yesterday obviously which reached over 80K unconfirmed transactions. Usually I checked current network regarding unconfirmed transactions to predict how much fees to be paid and how long I should wait for the transaction to be confirmed.
I do not use ledger wallet or bitcoin core, but I can confirm current fees through blockhain.info walet is convenience around BTC0.00022218 for BTC0.0535, but not for electrum, still have to pay high fees for small amount transaction. Electrum devs takes more time to update their codes.

[polyhedron]

It's good for whoever already used ledger wallet or bitcoin core which can transact through segwit chain.
There are over 24K unconfirmed transactions and BTC7 total fees right now, better than yesterday obviously which reached over 80K unconfirmed transactions. Usually I checked current network regarding unconfirmed transactions to predict how much fees to be paid and how long I should wait for the transaction to be confirmed.
I do not use ledger wallet or bitcoin core, but I can confirm current fees through blockhain.info walet is convenience around BTC0.00022218 for BTC0.0535, but not for electrum, still have to pay high fees for small amount transaction. Electrum devs takes more time to update their codes.

True that currently the tx fees are too much more paid.
Since the difficulty of BCC mining tripples ~12 h ago and miners switched back to BTC, most tx with reasonable fee have already been digested.
http://8btc.com/data/attachment/forum/201708/27/203406a132yw8wbm3zdwiw.png
As this shows, actually all tx with >0.0005 BTC/kB can be confirmed soon. But in Electrum, if I choose "Dynamic fee", the lowest suggested fee ("within 25 blocks") is still ~0.004 BTC/kb, 8 times than really needed (as far as the miners don't switch back to BCC).

[reee]

What about the lighting network? When will it be avaible?

[MrBitter]

 How can I know if one transaction is Segwit transaction or not. As far as I know, not all P2SH addresses are segwit addresses.

Thanks

[danielW]

If using bitcoind (command line) on bitcoin core, how do I:

1) create a segwit address

2) will 'bitcoin-cli getnewaddress' give me a segwit or non segwit address.

3) what exactly is the difference between a segwit and non-segwit address,

4) if I use bitcoin-cli sendfrom ...' will the change address generated be a segwit or non segwit address?


Also what about the next version of Bitcoin core, how do I:

5) create a segwit address

6) will 'bitcoin-cli getnewaddress' give me a segwit or non segwit address.

7) if I use bitcoin-cli sendfrom ...' will the change address generated be a segwit or non segwit address?

8 ) When will this segwit capable version of bitcoin core be out?

[Kakmakr]

Once all wallets are SegWit ready, would we see a dramatic change in tx fees or do we still have to depend on miners not shifting large amounts of hashing power between BCC and BTC? This looks like a bigger problem than Block sizes at the moment. The bigger block size or more effective use of blocks, just delay the inevitable outcome <congestion> when miners swap to more profitable chains.

How can we reduce this impact, when miners act in this way, other than adding more hashing power from other sources? Miners will follow the most profitable chain.

[-ck]

Once all wallets are SegWit ready, would we see a dramatic change in tx fees or do we still have to depend on miners not shifting large amounts of hashing power between BCC and BTC? This looks like a bigger problem than Block sizes at the moment. The bigger block size or more effective use of blocks, just delay the inevitable outcome <congestion> when miners swap to more profitable chains.

How can we reduce this impact, when miners act in this way, other than adding more hashing power from other sources? Miners will follow the most profitable chain.

If miners spend 25% of their time mining BCH indefinitely then bitcoin difficulty will drop by 25%. This will go some way towards alleviating delays associated with them switching to it. Yes transactions will be slower while they're on BCH but not as slow as now and then transactions will be faster once they switch back. Of course this will only be while BCH has any perceived value, and this mining rush on it should make people aware what it really should be worth...

As for segwit I expect quite a lot will switch to segwit addresses and transactions in time and we'll see maybe a doubling of transaction throughput long term from segwit activation alone. That's not enough to save us indefinitely.

[genesis.vision]

What about the lighting network? When will it be avaible?

Poon and Buterin have already announced implementation of Lightning for Ether nicknamed Plasma, I doubt that it won't delay Lightning development for Bitcoin...

[BTC-TK]

What about the lighting network? When will it be avaible?

It's way to soon for things like that.
As of now, there is a draft of the specifications (https://github.com/lightningnetwork/lightning-rfc), and three implementations that are doing integrations tests. Meanwhile the spec draft is updated.

Like with bitcoin itself, while you can test it in your test environment using "fake" coins, that really is not the same as real world tests with real value.
Segwit activated a few days ago and this phase has just begun.

In the coming months the protocol should be finalized, and wallets will begin releasing implementations.

This cannot be fucked up. The moment money is lost for a protocol problem ( not for user error ) the whole thing could collapse. So you'll agree that it needs its fair amount of testing.

[noobinscrypt]

Since the SW is activated, how can a user now send a SW transaction?
E.g., I'm using an Electrum wallet, a BitPie wallet, and have a qt full node, and sometimes I also send from/to an exchange or shapeshift.
That whether a transaction is SW or not, depends on the sending address, receiving address, or both? How can I create a SW transaction to lower the fee?

Ledger has supported Segwit recently.
Bitcoin Core is another option but you can only do so using CLI at the moment.
Electrum dev said on github that next version will be released soon letting you create and send segwit addresses.

IMO, most major wallets are ready for segwit. They just didn't let you do so before Segwit finally activated.

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!!

[pebwindkraft]

I can't get the details to understand how old clients work with segwit transactions.
I find phrases like <old clients see segwit tx as "anyone can spend">. 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)

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 

[achow101]

<snip>

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.

[suppersz]

<snip>

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.

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?

[achow101]

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?

Yes, that is correct.

[Kakmakr]

Once all wallets are SegWit ready, would we see a dramatic change in tx fees or do we still have to depend on miners not shifting large amounts of hashing power between BCC and BTC? This looks like a bigger problem than Block sizes at the moment. The bigger block size or more effective use of blocks, just delay the inevitable outcome <congestion> when miners swap to more profitable chains.

How can we reduce this impact, when miners act in this way, other than adding more hashing power from other sources? Miners will follow the most profitable chain.

If miners spend 25% of their time mining BCH indefinitely then bitcoin difficulty will drop by 25%. This will go some way towards alleviating delays associated with them switching to it. Yes transactions will be slower while they're on BCH but not as slow as now and then transactions will be faster once they switch back. Of course this will only be while BCH has any perceived value, and this mining rush on it should make people aware what it really should be worth...

As for segwit I expect quite a lot will switch to segwit addresses and transactions in time and we'll see maybe a doubling of transaction throughput long term from segwit activation alone. That's not enough to save us indefinitely.

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.

[pebwindkraft]

<snip>

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.

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?

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://bitcointalk.org/index.php?topic=1573616.0, looks like I need to dive deeper...

[achow101]

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 ?

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.

[pebwindkraft]

thx, got it. And thanx for your patience, explaining twice to me.
I went through Andreas' book, which says:

Once a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node

...
But it doesn't mention this handshake or protocol. I might send him a note ...

[jackg]

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...