> Choosing to publish zero transactions is not rational behaviour
Currently happens multiple times per day. Check the blockchain an empty block is published every once in a while (Although they do this because they have poor internet)
> because a miner doing so loses out on collected fees to the next miner, the same is true of cherry picking individual transactions; even if one miner does this, the next guy has no reason to do so.
Except the cost is low. My $0.04 tx fee as a single user cannot compete with various interests of censorship. However, if my $0.04 was pooled together with other users who didnt want me to be censored it would balloon into a larger amount that would be very hard to convince all miners not to process.
Topic: Attached Transactions - Alternative to Replace By Fee (RBF) - Anti Censorship - page 2. (Read 2659 times)
February 21, 2016, 06:43:13 PM
February 21, 2016, 06:34:08 PM
Quote
Full censorship isn't possible unless a miner has a majority of hashing power; up until this point, miners will include valid transactions into blocks which get 'censored' by the minority of hashing power.
That's not true. Miners right now can choose to publish zero transactions in a block or they can cherry pick some transactions and not others. My goal is to ensure that nobody can ever have a tx censored that others do not want censored.
Choosing to publish zero transactions is not rational behaviour because a miner doing so loses out on collected fees to the next miner, the same is true of cherry picking individual transactions; even if one miner does this, the next guy has no reason to do so.
February 21, 2016, 06:33:03 PM
Well it was a good idea not sure what else to do and I'm not interested in checking these forums often. Hope something like this eventually makes it's way into Bitcoin but I don't think I have the stomach to push it though layers of BS.
February 21, 2016, 06:28:02 PM
Quote
Full censorship isn't possible unless a miner has a majority of hashing power; up until this point, miners will include valid transactions into blocks which get 'censored' by the minority of hashing power.
That's not true. Miners right now can choose to publish zero transactions in a block or they can cherry pick some transactions and not others. My goal is to ensure that nobody can ever have a tx censored that others do not want censored.
February 21, 2016, 09:31:37 AM
If each transaction could be "attached" to another in this way it could become very hard to censor a transaction that "the people" do not want censored. This could stop miners from censoring specific wallets or specific transactions unless they are willing to let that censorship balloon into more lost mining fees. Currently, we don't have any kind of censorship like this, but we do have lazy miners that produce small blocks about 6 times a day (I wrote a small tool here: https://fullblocks.github.io )
Please let me know if there is any way to do this currently or any BIPs that would allow for this.
Please let me know if there is any way to do this currently or any BIPs that would allow for this.
Full censorship isn't possible unless a miner has a majority of hashing power; up until this point, miners will include valid transactions into blocks which get 'censored' by the minority of hashing power.
February 21, 2016, 06:11:26 AM
I spoke in IRC more about this.
In particular I was wrong to drag RBF into this, because it's a mempool thing, which I knew but simply forgot when making this post. I thought the best way to bring the topic up was to mention RBF since people are familiar with that concept and "bumping" a transaction.
Another user created this SE question: http://bitcoin.stackexchange.com/questions/43003/is-there-a-way-to-create-a-transaction-that-it-can-only-be-confirmed-after-anoth
It more clearly summarizes the question as:
To elaborate on this I think if Bitcoin had something that could do this we could make it very difficult to censor transactions individually. If someone had a tx being censored they could go onto social media and share that tx and others could begin "attaching" to the censored tx to promote it's processing as miners wouldn't get the fee of any txs attached to the censored one.
In particular I was wrong to drag RBF into this, because it's a mempool thing, which I knew but simply forgot when making this post. I thought the best way to bring the topic up was to mention RBF since people are familiar with that concept and "bumping" a transaction.
Another user created this SE question: http://bitcoin.stackexchange.com/questions/43003/is-there-a-way-to-create-a-transaction-that-it-can-only-be-confirmed-after-anoth
It more clearly summarizes the question as:
Quote
Is there a way to create a transaction A that cannot be confirmed until B has been included in a block, although A does not build on any UTXO B creates?
To elaborate on this I think if Bitcoin had something that could do this we could make it very difficult to censor transactions individually. If someone had a tx being censored they could go onto social media and share that tx and others could begin "attaching" to the censored tx to promote it's processing as miners wouldn't get the fee of any txs attached to the censored one.
February 21, 2016, 05:48:08 AM
RBF is an optional feature, and it can be extremely poweful imho. This is especially true when combined with the programmable signature structure and time locking. Trying to chain transactions would be complex, as there is already a chain in place, and you would have to ensure that the attachment didn't get confirmed before the master transaction. I suspect you would also have to record block numbers, as they may not be in the same block.
February 21, 2016, 05:19:09 AM
Hi everyone. With RBF recently getting some exposure I was thinking more about ways to solve the problems that RBF solves without it. In particular, I see the blockchain more as a data structure made up of immutable pieces, and I don't like that RBF violates this to some degree. I would prefer a Bitcoin where people submit things to the network and any attempt to "undo" is a separate transaction.
It's possible my understanding of RBF or Bitcoin has caused me to miss something, but from what I know right now there is no way to submit a transaction that will only be valid if another transaction has already been placed into a block. Currently two parties would have to setup multisig or agree on a private token of some kind or in general cooperate together before the transaction is made.
If there was a system in place where you could "attach" a transaction to another in this way it could solve the problems RBF originally was supposed to solve, which is allowing you to send more to "bump" a transaction. This would be done by making another transaction with a miner fee to incentivize it to be placed into a block.
Likewise this could help solve the problem of miners publishing blocks with zero transactions in them. If each transaction could be "attached" to another in this way it could become very hard to censor a transaction that "the people" do not want censored. This could stop miners from censoring specific wallets or specific transactions unless they are willing to let that censorship balloon into more lost mining fees. Currently, we don't have any kind of censorship like this, but we do have lazy miners that produce small blocks about 6 times a day (I wrote a small tool here: https://fullblocks.github.io )
Please let me know if there is any way to do this currently or any BIPs that would allow for this.
It's possible my understanding of RBF or Bitcoin has caused me to miss something, but from what I know right now there is no way to submit a transaction that will only be valid if another transaction has already been placed into a block. Currently two parties would have to setup multisig or agree on a private token of some kind or in general cooperate together before the transaction is made.
If there was a system in place where you could "attach" a transaction to another in this way it could solve the problems RBF originally was supposed to solve, which is allowing you to send more to "bump" a transaction. This would be done by making another transaction with a miner fee to incentivize it to be placed into a block.
Likewise this could help solve the problem of miners publishing blocks with zero transactions in them. If each transaction could be "attached" to another in this way it could become very hard to censor a transaction that "the people" do not want censored. This could stop miners from censoring specific wallets or specific transactions unless they are willing to let that censorship balloon into more lost mining fees. Currently, we don't have any kind of censorship like this, but we do have lazy miners that produce small blocks about 6 times a day (I wrote a small tool here: https://fullblocks.github.io )
Please let me know if there is any way to do this currently or any BIPs that would allow for this.
Jump to: