USERBOOST : Userspace Weaponry ..

[spartacusrex]

I was thinking about HOW it is that we are in the situation we currently find ourselves in.

The miners seem to have taken ALL the power, and we let them.. Or have we..

When I try to digest the UASF and what it means, I picture someone standing in font of a row of tanks, holding a pea shooter.

I'm rooting for him (the Users), but I think trying to beat the miners (the Tanks) at this game, is almost impossible.

We need to remember that Bitcoin has a LOT of moving parts. And the BIGGEST piece.. is that we.. the Users.. PAY.

What I mean is, WE PAY the miners FEES, for mining our transactions, and that amount is now comparable to the amount that is mined for finding a block. ie.. It's a LOT.

Well..

We need to be able to construct a txn that can ONLY be mined by a miner that is signalling SegWit.. hehe.

Now currently - this is not possible, as there is no way of accessing the 'versionBits' in the Block Header (where SegWit Signalling happens) from a script. (Unless please please some one tell me I am wrong ?)

BUT - if we had a very simple 'OP_CHECKVERSIONBIT' function (Same as OP_CLTV bascially - but for versionBits instead of nLocktime), then we could create TXN's that could only be mined by a miner that is signalling for something we want.. like SegWit.

THIS. IS. POWER..

I would like to see how many miners hold out, when all the juicy fat txn fees are being gobbled up by the segwit signalling miners.. And only the scraps are left for those not signalling..

As I said - I don't think this is possible right now - but in future - I think it is something we should set up, so that when (not if) this situation arises again.. we can make our wishes known, in the strongest possible way. With our money BTC..

[spartacusrex]

Hmm.. hate to bump my own topic.. But.. really thought this idea would get more traction !? ^^

It basically levels the playing field ?

So that the users and the miners can balance each other out.. since currently the users have ZERO recourse..

It would mean we don't need a messy UASF.

IMHO - it fixes the current problem.

Am I missing something ?

[franky1]

1. Core (LukeJR) GAVE pools the electoral powers. pools did not take or ask for it
2. Core (gmax and a couple others) removed many fee control mechanisms.. again pools didnt ask for it nor demand it


now to address the questions
to have the functionality of new keypairs can only occur after an activation. and once majority of nodes is there to validate such new keypairs which would be weeks after activation
EG segwit keypair function wont be available for weeks AFTER segwit activation. and then its too late to let users vote on segwit tier network anyway because its already there.

in the future we could have an update where a spare byte is used to allow users a poll. but from a protocol stance it would be meaningless.
the BS cartel will just plow alot of tx fee's into any agenda they like and get their funds back through the pools they control.

EG blockstream/barrysilbert cartel have control/partnership with BTCC
so could bait the opposition by including 50btc fee that BTCC accepts into BTCC block(but doesnt relay the unconfirms to other pools)to make oppositions think they are losing out. when infact its just BTCC building blocks filled with tx's paying themselves and returning fee's to themself and respending that fee again and again to themselves(meaning no actual cost/loss).

much like the 3card/shell street hustle game
hustler sets up 3 cards. a stranger puts a $1 note down with a promise he will get $10 choosing the right card/shell... he wins. and walks away with $10, to gain spectator interest.
what people dont realise is the stranger that wins is the hustlers friend and hands the $10 back to the hustler before doing the same again an hour later

either way this topics proposal and UASF would just still remain as faking the election and avoiding real consensus to push in features that would normally get forgotten.

whats needed is core and the BS cartel to take no/abstain as an answer and go back to the drawing board. not fake the election to push it through.

[cellard]

Wether we like it or not, UASF is happening for sure. We must get ready for it. Get your coins on full validating nodes, and demand your exchanges and services to list UASF.

Again, wether you are pro or anti UASF, you MUST have the choice to to get both UASF and Legacy coins. This means that any exchange or service that does not list UASF coins is a SCAM.

They must list UASF, period.

[DannyHamilton]

- snip -
We need to be able to construct a txn that can ONLY be mined by a miner that is signalling SegWit.. hehe.
- snip -

It really surprises me that pools don't offer exclusive mining services yet.

I'd think that, by now, every pool would have a website and API where you could push a transaction to them to be confirmed exclusively by them.  In other words, any transaction they receive via this mechanism would be included in the pool's mempool for inclusion into their blocks but would NOT be broadcast to the rest of the network until it was broadcast within one of their blocks.

In this way, I could support a small pool, or a SegWit signalling pool, or a Bitcoin Unlimited pool, or whatever.  I'd just exclusively send my fee paying transactions to them and not to the pools that I oppose.

I understand that this would open an attack vector whereby someone could provide a high fee transaction to multiple pools and then broadcast a low fee transaction to the network, so it makes confirmations more important.  If a pool didn't want to risk being used for such an attack there are certainly some precautions they could take.  For example:

They might choose to only accept such exclusive transactions if they are RBF transactions.  That way they could immediately broadcast the higher fee transaction to the network if they see a competing lower fee transaction from a peer.

They might choose to immediately give up the higher fee exclusive transaction and accept the lower fee transaction from a peer.

They might require that they see the lower fee transaction on the network before accepting the higher fee exclusive transaction, and might require that both transactions have the exact same outputs.

There are many things a pool could do to reduce the risks to Bitcoin users while still providing a method for users to reward them for making decisions that favor the users.

For that matter, multiple pools with the same ideology could form a coalition and agree to only relay the higher fee transaction between pools belonging to the coalition.  Then the user could be presented with a single location to push the transaction, and be confident that the high fee transaction will confirm as soon as ANY coalition member solves a block.

[25hashcoin]

https://mobile.twitter.com/officialmcafee/status/869272724040015875