Sending transactions only to SegWit miners

[LonelyPrince]

What do you think of sending transactions only to segwit miners and avoid non-segwit miners, thus we can create incentive for miners with our fees.

[1714743131]

1714743131

[1714743131]

1714743131

[1714743131]

1714743131

[1714743131]

1714743131

[1714743131]

1714743131

[jonald_fyookball]

What do you think of sending transactions only to segwit miners and avoid non-segwit miners, thus we can create incentive for miners with our fees.

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that. 
Whoever mines the block decides what transactions to include.

[franky1]

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that.  
Whoever mines the block decides what transactions to include.

technically it can be done if you set your node to only connect to a pools IP adress of the ones you prefer
or you know the pools API to manually 'PushTX' the transaction to only the pools you prefer

[SONG GEET]

What do you think of sending transactions only to segwit miners and avoid non-segwit miners, thus we can create incentive for miners with our fees.

Rather than this i think segwit supported pools should start tx accelerator service like viabtc have. to attract more support for segwit. Also this is not possible currently, users don't have power to choose from which miner they want to get their transaction confirmed.

[jonald_fyookball]

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that.  
Whoever mines the block decides what transactions to include.

technically it can be done if you set your node to only connect to a pools IP adress of the ones you prefer
or you know the pools API to manually 'PushTX' the transaction to only the pools you prefer

why wouldnt the tx get relayed onward?

[franky1]

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that.  
Whoever mines the block decides what transactions to include.

technically it can be done if you set your node to only connect to a pools IP adress of the ones you prefer
or you know the pools API to manually 'PushTX' the transaction to only the pools you prefer

why wouldnt the tx get relayed onward?

some pools dont relay unconfirms to other pools. especially high fee tx's so that if the pool misses that block they can still include the still unconfirmed tx in next block.

also the network game theory is that the normal non-mining fullnode relay should have got the tx's to all the pools so no need for the pools to retransmit unconfirms between each other, allowing the bandwidth between pools to be utilised better to broadcast to each other mainly solved blocks and not much else

[Quickseller]

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that. 
Whoever mines the block decides what transactions to include.

technically it can be done if you set your node to only connect to a pools IP adress of the ones you prefer
or you know the pools API to manually 'PushTX' the transaction to only the pools you prefer

why wouldnt the tx get relayed onward?

It most likely would get relayed. Pools do not want to harm their reputation by confirming a double spend transaction, so they will broadcast any transaction they receive to the rest of the network, and will not accept any transaction that conflicts with other transactions in their mempool.

[Killerpotleaf]

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that.  
Whoever mines the block decides what transactions to include.

technically it can be done if you set your node to only connect to a pools IP adress of the ones you prefer
or you know the pools API to manually 'PushTX' the transaction to only the pools you prefer

why wouldnt the tx get relayed onward?

some pools dont relay unconfirms to other pools. especially high fee tx's so that if the pool misses that block they can still include the still unconfirmed tx in next block.

also the network game theory is that the normal non-mining fullnode relay should have got the tx's to all the pools so no need for the pools to retransmit unconfirms between each other, allowing the bandwidth between pools to be utilised better to broadcast to each other mainly solved blocks and not much else

interesting...

this could be a strong incentive for miners to signal upgrades.

but this idea might deteriorate into a way to pay miners to signal what you want them to signal tho  

[Killerpotleaf]

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that. 
Whoever mines the block decides what transactions to include.

technically it can be done if you set your node to only connect to a pools IP adress of the ones you prefer
or you know the pools API to manually 'PushTX' the transaction to only the pools you prefer

why wouldnt the tx get relayed onward?

It most likely would get relayed. Pools do not want to harm their reputation by confirming a double spend transaction, so they will broadcast any transaction they receive to the rest of the network, and will not accept any transaction that conflicts with other transactions in their mempool.

i dont see how they are at risk of minning a double spend.
if the TX they are withholding from the rest of the network, at one point becomes a double spend, they simply drop it.

[Quickseller]

Since segwit requires 95% signaling to activate, most or all miners will be segwit anyway.

If you're asking if today, would it be possible to send your transactions to a pool signaling segwit, the answer is no.  You don't have the power to do that. 
Whoever mines the block decides what transactions to include.

technically it can be done if you set your node to only connect to a pools IP adress of the ones you prefer
or you know the pools API to manually 'PushTX' the transaction to only the pools you prefer

why wouldnt the tx get relayed onward?

It most likely would get relayed. Pools do not want to harm their reputation by confirming a double spend transaction, so they will broadcast any transaction they receive to the rest of the network, and will not accept any transaction that conflicts with other transactions in their mempool.

i dont see how they are at risk of minning a double spend.
if the TX they are withholding from the rest of the network, at one point becomes a double spend, they simply drop it.

This would entail a lot of extra processing all for a few extra measly cents in a transaction. Normally a node will receive a transaction, and if said transaction is valid per the blockchain and does not conflict with another transaction in it's mempool they will accept said transaction, regardless of the attached fee. You are proposing that a (mining) node accept a never before seen transaction, not relay said transaction, and if a conflicting transaction is later received, to drop the original.

This has the potential to result in lower overall transaction fees because the public transaction may have a lower tx fee attached, and if the private higher tx fee transaction was broadcast, then other nodes would have rejected the conflicting public transaction.