Peter Todd discusses here a scheme where miners may be bribed into rejecting txs that don't include identity information:
https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitcoin
Topic: Attached Transactions - Alternative to Replace By Fee (RBF) - Anti Censorship (Read 2706 times)
April 21, 2016, 05:14:21 AM
March 01, 2016, 07:16:02 PM
https://www.reddit.com/r/Bitcoin/comments/48eg6y/alex_petrov_of_bitfury_highfee_spam/d0izum5
Quote
It's probably also possible to just identify this spammer's transactions and block them directly.
February 26, 2016, 07:15:20 PM
> You don't understand. This is a non problem and if it were a problem, your solution doesn't work.
It must be so simple you can't explain it.
It must be so simple you can't explain it.
February 26, 2016, 03:47:43 AM
> What exactly does the 'word' being spread about censorship actually accomplish? Since the majority of hashing power are colluding, they can do whatever they want, and no amount of social engineering will help that.
Without this they can cherry-pick individual transactions to not send, meaning the cost to censor a tx is what you are willing to pay in fees as one person. If you pay 0.1 BTC in fees the miner may have stronger interests than that amount to keep censoring the tx. If you can attach the txs together the cost of censoring one tx becomes amplified by each tx, so instead of losing 0.1 BTC over time miners would be choosing to lose the sum of all attached fees from txs that touch the chain of attachment.
You don't understand. This is a non problem and if it were a problem, your solution doesn't work.
https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
The only thing to quibble with I saw was the lack of ability to use the sequenceid to encode information without enabling RBF as the entire bitspace (other than -2 and -1) activate RBF. But encoding stuff into sequenceid is probably a bad idea anyway.
I have no idea how this got turned into "anybody can cancel payments"
Anybody making such claims, can you explain how somebody can cancel a payment I send with sequenceid of 0xffffffff?
Or how anybody can undo a micropayment with a sequenceid and undo a payment?
James
February 26, 2016, 03:23:07 AM
> What exactly does the 'word' being spread about censorship actually accomplish? Since the majority of hashing power are colluding, they can do whatever they want, and no amount of social engineering will help that.
Without this they can cherry-pick individual transactions to not send, meaning the cost to censor a tx is what you are willing to pay in fees as one person. If you pay 0.1 BTC in fees the miner may have stronger interests than that amount to keep censoring the tx. If you can attach the txs together the cost of censoring one tx becomes amplified by each tx, so instead of losing 0.1 BTC over time miners would be choosing to lose the sum of all attached fees from txs that touch the chain of attachment.
You don't understand. This is a non problem and if it were a problem, your solution doesn't work.
February 25, 2016, 08:11:19 PM
> Op, the problem is that if people's transactions could be made dependent on another person, they are not acting to their own interests. Buy linking their transactions to the censored one, their own transactions will also not confirm and that is detrimental to their own interests.
If the tx is invalid or miners are unable to accept it then over time they will fall out of the mempool willingly.
EDIT: If your talking about a reverse attack of some kind then we are ultimately talking about *valid* transactions miners chose not to process, which is censorship.
If the tx is invalid or miners are unable to accept it then over time they will fall out of the mempool willingly.
EDIT: If your talking about a reverse attack of some kind then we are ultimately talking about *valid* transactions miners chose not to process, which is censorship.
February 25, 2016, 08:09:23 PM
> What exactly does the 'word' being spread about censorship actually accomplish? Since the majority of hashing power are colluding, they can do whatever they want, and no amount of social engineering will help that.
Without this they can cherry-pick individual transactions to not send, meaning the cost to censor a tx is what you are willing to pay in fees as one person. If you pay 0.1 BTC in fees the miner may have stronger interests than that amount to keep censoring the tx. If you can attach the txs together the cost of censoring one tx becomes amplified by each tx, so instead of losing 0.1 BTC over time miners would be choosing to lose the sum of all attached fees from txs that touch the chain of attachment.
February 25, 2016, 10:55:13 AM
The solution is an emergency hard fork to another mining algorithm which renders so all of the miners' equipment useless. This has been discussed before and it is a solution if miners were to be colluding to the detriment of bitcoin.
I view that as a total failure of the currency, IMO.
Selling? I'm buying.
February 25, 2016, 08:33:50 AM
The solution is an emergency hard fork to another mining algorithm which renders so all of the miners' equipment useless. This has been discussed before and it is a solution if miners were to be colluding to the detriment of bitcoin.
I view that as a total failure of the currency, IMO.
February 25, 2016, 08:30:02 AM
I suppose it is more of the threat of a hard fork which cuts out the miner's is what would persuade them to not abuse their power.
I've seen no evidence of miners "abusing their power" - if anything the miners (at least pools) have tried their hardest to not get involved with the politics and just support the future of Bitcoin (which makes sense for them economically).
February 25, 2016, 08:25:16 AM
I suppose it is more of the threat of a hard fork which cuts out the miner's is what would persuade them to not abuse their power.
I've seen no evidence of miners "abusing their power" - if anything the miners (at least pools) have tried their hardest to not get involved with the politics and just support the future of Bitcoin (which makes sense for them economically).
It is the exchanges (and mostly just American ones) and some of the devs (ex-core) that have been the cause of all the troubles so far (and in the case of devs that seems to be mostly about ego rather than anything else).
February 25, 2016, 08:23:47 AM
The solution is an emergency hard fork to another mining algorithm which renders so all of the miners' equipment useless. This has been discussed before and it is a solution if miners were to be colluding to the detriment of bitcoin.
I think that is not really going to be such an easy thing.
Miners need to turn BTC into fiat in order to do their business (i.e. pay for their electricity and other costs) - but exchanges need the miners to have a steady source of people wanting to exchange.
If devs wanted to "cut out the miners" then exchanges would be screwed for income in the short-term at least (as many of them are partnered with mining pools) so I can't see the exchanges actually likely to agree with such a change.
February 25, 2016, 08:19:08 AM
The solution is an emergency hard fork to another mining algorithm which renders so all of the miners' equipment useless. This has been discussed before and it is a solution if miners were to be colluding to the detriment of bitcoin.
I think that is not really going to be such an easy thing.
Miners need to turn BTC into fiat in order to do their business (i.e. pay for their electricity and other costs) - but exchanges need the miners to have a steady source of people wanting to exchange.
If devs wanted to "cut out the miners" then exchanges would be screwed for income in the short-term at least (as many of them are partnered with mining pools) so I can't see the exchanges actually likely to agree with such a change.
Remember it is the mining pools that actually control the consensus (as those who dislike China are finding out much to their chagrin).
February 25, 2016, 08:14:01 AM
Miners en-masse currently can decide to block transactions. With something like an attachment process this would become impossible as the word was spread about a tx being censored.
I'll just keep bumping this thread every week or so.
I'll just keep bumping this thread every week or so.
They can but they don't en-mass, because if they did this means that bitcoin itself has failed, since we then have a collusion of majority hashing power.
For the sake of argument, let's say you're right and that is occurring now. What exactly does the 'word' being spread about censorship actually accomplish? Since the majority of hashing power are colluding, they can do whatever they want, and no amount of social engineering will help that.
Op, the problem is that if people's transactions could be made dependent on another person, they are not acting to their own interests. Buy linking their transactions to the censored one, their own transactions will also not confirm and that is detrimental to their own interests.
February 25, 2016, 08:03:36 AM
Miners en-masse currently can decide to block transactions. With something like an attachment process this would become impossible as the word was spread about a tx being censored.
I'll just keep bumping this thread every week or so.
I'll just keep bumping this thread every week or so.
They can but they don't en-mass, because if they did this means that bitcoin itself has failed, since we then have a collusion of majority hashing power.
For the sake of argument, let's say you're right and that is occurring now. What exactly does the 'word' being spread about censorship actually accomplish? Since the majority of hashing power are colluding, they can do whatever they want, and no amount of social engineering will help that.
February 25, 2016, 05:54:47 AM
> For censorship to be a real concern, such a transaction would never make it into the blockchain
I believe non-miners run mempools, is this correct?
> just because a minority of hashing power decides to censor your transaction doesn't mean the entire network will
Miners en-masse currently can decide to block transactions. With something like an attachment process this would become impossible as the word was spread about a tx being censored.
I'll just keep bumping this thread every week or so.
I believe non-miners run mempools, is this correct?
> just because a minority of hashing power decides to censor your transaction doesn't mean the entire network will
Miners en-masse currently can decide to block transactions. With something like an attachment process this would become impossible as the word was spread about a tx being censored.
I'll just keep bumping this thread every week or so.
February 22, 2016, 04:48:23 AM
> 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.
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.
For censorship to be a real concern, such a transaction would never make it into the blockchain - just because a minority of hashing power decides to censor your transaction doesn't mean the entire network will; like I say, overall this is not rational behaviour for miners.
February 21, 2016, 09:57:11 PM
> This already exists. It's called CPFP (Child Pays For Parent).
This requires coordination before the txs are made.
This requires coordination before the txs are made.
The wallet can also be designed to handle it, so that the coordination is done at least in part by the wallet, based on settings which can be altered by the user. See, for example, the project referred to in my signature for some ideas there.
February 21, 2016, 08:25:33 PM
> This already exists. It's called CPFP (Child Pays For Parent).
This requires coordination before the txs are made.
This requires coordination before the txs are made.
February 21, 2016, 06:48:38 PM
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.
This already exists. It's called CPFP (Child Pays For Parent).
If I've received an output from an unconfirmed transaction, I can use that output as an input in a new transaction. I can then pay a much larger fee in the new transaction. The new transaction cannot be confirmed unless the previous transaction is also confirmed in the same or earlier block. As such, the new transaction can provide a larger incentive for the older transaction to be confirmed.
Then, by using CoinJoin techniques, it would be possible for many people to all get involved in the same new transaction. As such, all the fees from multiple payments could all be combined into a single transaction that depends on the earlier transaction being confirmed.
February 21, 2016, 05:43:13 PM
> 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.
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.
February 21, 2016, 05: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, 05: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, 05: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, 08: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, 05: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, 04: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, 04: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: