Voting / signaling on TXs

HostFat

Member
Sep 13, 2015
39
48
I think that now miners aren't able to hear the voice of the market.

The value of the money is given mainly by its users, from who uses it.

Because of this, miners tend to follow/see what the full nodes are saying, it's the mostly true number that they are able to see. But they still can be a result of a "Sybil attack"

But nodes aren't the majority of the users and who uses the network, they are a minority, and there is an high friction on changing the software for another one.

So my idea is to find the cheapest way (in bytes) to add a flag on the TXs, to indicate a preference for a modification/BIP/HF/other.

Then the miners, after a month (or more, it's an example), they will be able to see what the majority of the TXs are requesting.
They can even count only TXs with a fee bigger than x (ex: 0.0001 BTC)

Even this can receive a "Sybil attack", but it will costs a lot. More over, miners can take stats for more than a month, maybe a year.

So there must be a standard, and it should be added on every light client:
- Electrum
- Bitcoin Wallet
- Copay
- Braidwallet
- Multibit
- Others ...

The user will choose on the interface for what he/she wants to give the signal/vote, and then every next TX that he/she will made will also have the chosen flag.

What do you think? :)
 
Last edited:

HostFat

Member
Sep 13, 2015
39
48
There is a good reply from and drwasho and ThomasZander (and my reply)




I though also about using this way:

While I think that it can work, I also think that the majority of the wallets will not agree to connect to a new server outside of their domain.

Maybe another solution is simpler, it is choosing a code for the fees:

The common fee can be 0.0001 BTC (example), so if someone want the BIPx, he will use instead the 0.00010004 BTC as fee.

For the BIPy, 0.00010002

So the last satoshi will be the "bit" to signal his/her vote for something.

This doesn't need any change on the protocol and neither any more bytes.

There must be a common chosen code for every bip/proposal.
 
  • Like
Reactions: freetrader

HostFat

Member
Sep 13, 2015
39
48
Another idea from Gavin to avoid using bits on fees - from Slack:
transaction signatures can safely contain a few bits of information-- wallets could sign with different ECDSA nonces until they get a signature with the bits set the way they want to vote. That's a little messy (you can't tell if somebody is voting or not, you can just see if there is a bias in the bits to tell if LOTS of people voted one way over another) and subject to all the usual use-transactions-to-vote problems (miners can censor, relaying nodes might drop, etc).
I wouldn't suggest pushing any transaction voting idea, because the end result is very likely to be just another year or three of endless goal-post-moving discussion.
 
  • Like
Reactions: freetrader

Members online