hudd
Newbie
Offline
Activity: 12
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2017, 10:20:46 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2017, 03:28:01 PM |
|
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
Newbie
Offline
Activity: 7
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2017, 03:51:57 PM |
|
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.pngAs 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
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 439
Merit: 252
Get Paid to Play your Media on Current
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2017, 08:48:37 PM |
|
What about the lighting network? When will it be avaible?
|
|
|
|
MrBitter
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 29, 2017, 10:11:25 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2017, 05:17:23 AM Last edit: August 30, 2017, 06:21:50 AM by 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
Legendary
Offline
Activity: 3514
Merit: 1963
Leading Crypto Sports Betting & Casino Platform
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2017, 06:12:53 AM |
|
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.
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 30, 2017, 08:48:39 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
genesis.vision
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 258
Merit: 10
The next step in Financial Markets evolution
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2017, 08:51:05 AM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 154
Merit: 14
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2017, 03:27:00 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2017, 04:34:24 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2017, 06:49:44 PM |
|
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 ![Huh](https://bitcointalk.org/Smileys/default/huh.gif)
|
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3486
Merit: 6822
Just writing some code
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2017, 08:20:28 PM |
|
<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
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 336
Merit: 250
There is a day to be born, and another to die
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2017, 09:09:38 PM |
|
<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
Moderator
Legendary
Offline
Activity: 3486
Merit: 6822
Just writing some code
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 31, 2017, 09:12:26 PM |
|
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
Legendary
Offline
Activity: 3514
Merit: 1963
Leading Crypto Sports Betting & Casino Platform
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 01, 2017, 06:52:25 AM |
|
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.
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
pebwindkraft
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 01, 2017, 09:13:40 AM Last edit: September 01, 2017, 11:02:51 AM by 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
Moderator
Legendary
Offline
Activity: 3486
Merit: 6822
Just writing some code
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 01, 2017, 01:49:25 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 01, 2017, 06:05:15 PM |
|
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
Copper Member
Legendary
Offline
Activity: 2856
Merit: 3071
https://bit.ly/387FXHi lightning theory
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 01, 2017, 06:19:48 PM |
|
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...
|
|
|
|
|