I think you hit the nail on the head here. Peter, Greg and others have been parroting for years that bitcoin is broken by design, despite the functioning network staring them in the face. Peter in particular has been aggressively trying to patch bitcoin in ways that weaken it, all the while making claims that he is "fixing" something that was never really broken to begin with. Ironically (or not, when you really understand their motives), when it comes to the block size, their approach is one of, we'll fix it when it breaks for real. It is so transparent that it would be laughable, if their efforts were not also successful.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
I tend to agree with @awemany that making Replace-By-Fee optional means people will just likely not use it (or use it for some unforeseen purpose). The non-opt-in version would be a downgrade of Bitcoin, which is why the market won't accept it (if Core tries to push it, they instantly ramp up motivation for XT and BU), like I think was @Mengerian's point about my thought experiment of user-configurable block reward: Devs can have fun feeling like they're doing something as long as it isn't allowed to downgrade Bitcoin because it doesn't force user behavior.
Unless Core has more influence than I think, I doubt any norms will arise just because of new options, provided those options are pointless, so in theory anything can be made user-configurable without danger (or perhaps with only temporary danger, quickly remedied in antifragile fashion). Users will simply realize in short order that you don't mess with settings you don't understand, and that you trust no one - certainly not the Core devs. Relying on paternalism to shepherd users away from harmful norms seems untenable; we need there to be multiple versions from which to choose and node operators to understand what they are doing (otherwise what exactly is the point of having more nodes? The only nodes a government would need to compromise if they wanted to attack Bitcoin would be those with operators who had the requisite understanding.).
EDIT: The endgame is to rely on an educated base of infrastructure operators (nodes, miners, etc.), else the ecosystem is at the mercy of devs. Probably in the future a lot of node operators will be engineers themselves, understanding the nature of Bitcoin just as well or better than the devs do.
Unless Core has more influence than I think, I doubt any norms will arise just because of new options, provided those options are pointless, so in theory anything can be made user-configurable without danger (or perhaps with only temporary danger, quickly remedied in antifragile fashion). Users will simply realize in short order that you don't mess with settings you don't understand, and that you trust no one - certainly not the Core devs. Relying on paternalism to shepherd users away from harmful norms seems untenable; we need there to be multiple versions from which to choose and node operators to understand what they are doing (otherwise what exactly is the point of having more nodes? The only nodes a government would need to compromise if they wanted to attack Bitcoin would be those with operators who had the requisite understanding.).
EDIT: The endgame is to rely on an educated base of infrastructure operators (nodes, miners, etc.), else the ecosystem is at the mercy of devs. Probably in the future a lot of node operators will be engineers themselves, understanding the nature of Bitcoin just as well or better than the devs do.
Last edited:
- Aug 29, 2015
- 536
- 2,597
Yeah, Peter Todd sure does seem to like to break stuff... I would be skeptical they have a "grand plan" to destroy Bitcoin though. I think it's likely their motivation stems from a desire to tinker with things, show off how clever they are, and play the role of badass cypherpunks.
Peter Todd sees his role as stirring the pot as much as possible to see if anything's broken. He's testing the antifragility, even if out of an unhealthy desire to stand out. Sometimes I imagine him going, "Let's turn on the juice and see what shakes loose!"
Last edited:
I'd forgotten about this song until reminded of it today.
It's almost as old as Bitcoin, having been written a few months after the genesis block was mined.
It's almost as old as Bitcoin, having been written a few months after the genesis block was mined.
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
I think with this opt-in RBF scheme, payment processors will just reject tx's flagged for RBF with no if, ands, or buts, exactly akin to rejecting a tx with insufficient fees attached.
One thing I can maybe sort of imagine being useful with opt-in RBF is trying to consolidate outputs for zero fee not being in a rush, but still wanting to be able to cancel it in a pinch. Like say you did some pooled mining and decided to take payouts in something like 0.1 or 0.01 increments, and you have potentially dozens of these outputs going to the same address. There's so many reasons why it's bad for privacy to keep a lot of small outputs around like that to taint every single imaginable transaction, so being able to put a large tx out there for free and just hope it gets picked up, but retaining the ability to cancel it if you really need to produce a spend could maybe be useful.
If everybody pretty universally rejects tx's flagged for RBF, then maybe this could just be great for managing addresses/outputs to and from yourself.
On the other hand, the comments of folks like GreenAddress and Gmax/Todd trivializing the ramifications on wallets as "just a line of code" or a few lines of code I wonder maybe could be the straw that broke Core's back, because they're ignorantly dismissing all the ramifications for workflow in wallets and accepting payments due to the implications of procedure outside of the very basics of how the software works. They're creating insecurity from the top-down in how the ecosystem needs to function, and picking winners and losers after-the-fact. They're literally creating an artificial use-case for GreenAddress.
Last edited:
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
Green Address's use-case WRT zero conf is that you send bitcoins to a timelocked 2-of-2, where you hold one of the keys locally and Green Address holds the other.
After that, the principle behind green addresses is that the recipient can now trust the zero conf tx because of having confidence that Green Address themselves will not collude with you to produce a double spend.
This is the grossest, clumsiest, most centralizing way to secure zero conf imaginable. The whole thing will never work unless one provider gets massive network effects, and there are secure protocols for informing all merchants of what secure keys to trust the signatures from. I would submit that it would take a radical attack on zero conf in general to even dream of their business ever getting off the ground.
If anything, this is something that I could imagine the payment processor doing themselves. Coinbase achieves this effect off-chain anyway, simply because they have merchants and if you pay them with a Coinbase wallet, they achieve the same result without attacking the protocol.
[doublepost=1448679118,1448678420][/doublepost]Putting my Machiavellian business scheme hat on, I suspect the play here is to get Peter Todd to break zero conf to score them an exit by selling the company to a payment processor and/or staying on for the consulting job.
After that, the principle behind green addresses is that the recipient can now trust the zero conf tx because of having confidence that Green Address themselves will not collude with you to produce a double spend.
This is the grossest, clumsiest, most centralizing way to secure zero conf imaginable. The whole thing will never work unless one provider gets massive network effects, and there are secure protocols for informing all merchants of what secure keys to trust the signatures from. I would submit that it would take a radical attack on zero conf in general to even dream of their business ever getting off the ground.
If anything, this is something that I could imagine the payment processor doing themselves. Coinbase achieves this effect off-chain anyway, simply because they have merchants and if you pay them with a Coinbase wallet, they achieve the same result without attacking the protocol.
[doublepost=1448679118,1448678420][/doublepost]Putting my Machiavellian business scheme hat on, I suspect the play here is to get Peter Todd to break zero conf to score them an exit by selling the company to a payment processor and/or staying on for the consulting job.
FYI: One of the first applications of OT voting pools is going to be to allow individual users to create their own self-insurance smart contracts.
Almost certainly, one of the first things these self-insurance contracts will be used for is insuring zero conf (on-chain) Bitcoin payments.
In that sense, it will be similar to the Green Address solution except not limited to single company. There will be a large number of entities who could operate reliable insurance oracles.
Also, the oracle will only see the transactions in the event there's a claim on the contract so there's nobody continually monitoring a user's spending habits and (potentially) selling their behavioural data to advertisers.
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
I think this is a great question:
https://www.reddit.com/r/btc/comments/3ujj1s/serious_gametheory_question_if_youre_a_miner_and/
https://www.reddit.com/r/btc/comments/3ujj1s/serious_gametheory_question_if_youre_a_miner_and/
- Aug 28, 2015
- 517
- 1,679
I have had the night to ruminate over this latest merge into Core.
What this RBF class of transaction means is that 0-conf accepting payment processors will simply ignore them by default as they may be double spent later in a block by a miner accepting the same coins moving with a higher transaction fee.
Why bother to go to the trouble of introducing this when if you don't trust 0-conf you can simply wait until the 1st confirmation? Well in the context of full blocks this starts to sound useful - if transactions are getting stuck regularly then this allows you to spend your btc where previously the initial transaction was waiting in the mempool for hours upon end. Wallets could be upgraded to allow resending of transactions when they have failed to confirm quickly.
But this is a Peter Todd release and there is a clear motivation. What he wants to do is break 0-conf functionality by releasing this change incrementally. First opt-in. Next when Core finally relent and are forced to upgrade the max_blocksize (in all likelihood as little as possible to avoid complete mutiny amongst miners) it will be hard forked as simply 'in'. Bang there goes all 0-conf safety.
In his own words about future 'instant' transactions:
TheZerg: it is getting extremely urgent that a 'clean' fork of Core with scaling code changes only (bitcoin unlimited) is released to extremely loud fanfare as soon as possible. I am beginning to view the bitcoin Core open source project as maliciously captured. We need to promote the ideals of keeping core (little c) functionality of bitcoin and the economic incentives therein preserved as much as possible, whilst allowing the base protocol to scale as far as it can until limited by technology - not people.
What this RBF class of transaction means is that 0-conf accepting payment processors will simply ignore them by default as they may be double spent later in a block by a miner accepting the same coins moving with a higher transaction fee.
Why bother to go to the trouble of introducing this when if you don't trust 0-conf you can simply wait until the 1st confirmation? Well in the context of full blocks this starts to sound useful - if transactions are getting stuck regularly then this allows you to spend your btc where previously the initial transaction was waiting in the mempool for hours upon end. Wallets could be upgraded to allow resending of transactions when they have failed to confirm quickly.
But this is a Peter Todd release and there is a clear motivation. What he wants to do is break 0-conf functionality by releasing this change incrementally. First opt-in. Next when Core finally relent and are forced to upgrade the max_blocksize (in all likelihood as little as possible to avoid complete mutiny amongst miners) it will be hard forked as simply 'in'. Bang there goes all 0-conf safety.
In his own words about future 'instant' transactions:
So there we have it - attempt to break 0-conf functionality by trojan horsing an opt-in change into Core, followed by a permanent change during the contentious upcoming hard fork, but don't worry because LN (private for profit off chain solution owned and run by blockstream) can provide safe instant transactions!
TheZerg: it is getting extremely urgent that a 'clean' fork of Core with scaling code changes only (bitcoin unlimited) is released to extremely loud fanfare as soon as possible. I am beginning to view the bitcoin Core open source project as maliciously captured. We need to promote the ideals of keeping core (little c) functionality of bitcoin and the economic incentives therein preserved as much as possible, whilst allowing the base protocol to scale as far as it can until limited by technology - not people.
Last edited:
Note the TOR change... whether u are for it or not its pretty clear that Core is throwing every feature in that can create problems subsequently to be solved by lightning...
Prudence, indeed, will dictate that Governments long established should not be changed for light and transient causes; and accordingly all experience hath shewn, that mankind are more disposed to suffer, while evils are sufferable, than to right themselves by abolishing the forms to which they are accustomed. But when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them under absolute Despotism, it is their right, it is their duty, to throw off such Government, and to provide new Guards for their future security.
it's really a so
it's really a solution to the problem they've created with 1MB. double spending 0 confs is only a problem for face to face purchases, not online ones. Todd, gmax, et al are destructive forces.
Unfortunately, it isn't even a solution for the 1mb problem. When blocks are full, if you "opt-into" RBF, your transaction will only get included if the fee you pay is higher than any other non-RBF TX, otherwise your TX will get de-prioritized so that hopefully you will eventually up your fee for inclusion. Opting into RBF increases the likelihood that your transaction will be delayed.
@Impulse
agreed. yes, we're back to the central planning model where idiot savants like Todd, gmax, Luke, & btcdrak are either unaware of their own shortcomings or are purposely screwing up Bitcoin to advantage their offchain solutions. it's probably a bit of both.
agreed. yes, we're back to the central planning model where idiot savants like Todd, gmax, Luke, & btcdrak are either unaware of their own shortcomings or are purposely screwing up Bitcoin to advantage their offchain solutions. it's probably a bit of both.
They are going to be shocked by the degree to which Ricardian contracts can put the functionality they're trying to break back into Bitcoin without pushing transactions off-chain and into proprietary services.
Everybody thinks OT is an off-chain transactions system because that's the first thing Chris implemented on top of his smart contract platform, but the primitives its built on are just as useful for purely P2P contracts that don't involved off-chain servers at all.
The original goal was to make smart contracts that would handle parts of a business transactions that didn't involve the payment itself - warranty, return policies, service dispute resolution, etc.
However, if Bitcoin developers are going to break the payment layer in an attempt to force transactions off chain, then we'll just extend those insurance contracts to cover the payment in addition to the higher-level functionality so the payments can stay on the blockchain where they belong.
Last edited:
My Thoughts On Opt-In Replace-by-Fee
When I read about Todd's "opt-in" replace-by-fee, my initial thought was that it was harmless because it was optional. This morning, I think it will do damage to Bitcoin's reputation as a payment system. Here's how...
Firstly, it's important to understand what the "opt-in" means. The "opt-in" isn't on a node-by-node basic; it's on a transaction-by-transaction basis. What this means is that if an attacker "opts-in" on a payment to a vendor, and later tries to double spend that payment, that all the nodes and miners running Blockstream's implementation of the protocol will work to facilitate the double spend attack.
So why will this cause problems? There are several ways:
1. Local Bitcoins
Core has just made it very easy for scammers to operate on Local Bitcoins: the scammer will simply trade bitcoins for cash and then double spend it a bit later. The newbie buying the coins won't understand that "since this TX was flagged for double-spending, he should have waited for a confirmation." Instead of double-spending being a low-probabiliy attack that required a knowledgable person to even attempt, Core is making it easy and reliable for your average run-of-the-mill scammer.
The idea that Bitcoin now has a payment type to make double-spending easier will not make sense to newbies. In fact, it makes no sense to me! We can unstick stuck transactions with child-pays-for-parent, after all.
2. Merchants Running Custom Payment Systems
The same problem will happen at merchants running their own payment systems: many won't get around to upgrading to detect these transactions (they might not even realize they need to). After they get scammed a few times, they will be more reluctant to accept Bitcoin at all. Explaining to them that "well you should have noted that the transaction was double-spendable" would just seem ridiculous: "you're telling me that Bitcoin now facilitates double spending!?"
3. Extra Work for Payment Processors
Payment processors like Bitpay will get around to making sure they can detect the double-spendable transactions. However, this means they'll need to put engineers on the job and take them off of other projects. In other words, Core has effectively forced these payment processors to spend more money to support a "feature" that there was no demand for anyways.
The Good News
There is a silver lining to this! Once industry wraps their heads around how silly this "opt-in RBF" is, then I think we'll see more backlash. Perhaps this will be the proverbial straw that broke Core's back, pushing people into XT, btcd, Unlimited and other clients that don't support any form of RBF.
Why Did Core Add "Opt-in" Replace By Fee?
My hunch is that Blockstream already realized that this would cause damage to Bitcoin's reputation as a payment system, and that by selling it as "optional" they could allow the damage to occur without taking the blame ("it was the free market at work!"). When the problems I described above start to happen, it will give them more ammunition to say "We told you we need Lightning Network because Bitcoin isn't reliable as a payment network!"
Posted as comment:
When I read about Todd's "opt-in" replace-by-fee, my initial thought was that it was harmless because it was optional. This morning, I think it will do damage to Bitcoin's reputation as a payment system. Here's how...
Firstly, it's important to understand what the "opt-in" means. The "opt-in" isn't on a node-by-node basic; it's on a transaction-by-transaction basis. What this means is that if an attacker "opts-in" on a payment to a vendor, and later tries to double spend that payment, that all the nodes and miners running Blockstream's implementation of the protocol will work to facilitate the double spend attack.
So why will this cause problems? There are several ways:
1. Local Bitcoins
Core has just made it very easy for scammers to operate on Local Bitcoins: the scammer will simply trade bitcoins for cash and then double spend it a bit later. The newbie buying the coins won't understand that "since this TX was flagged for double-spending, he should have waited for a confirmation." Instead of double-spending being a low-probabiliy attack that required a knowledgable person to even attempt, Core is making it easy and reliable for your average run-of-the-mill scammer.
The idea that Bitcoin now has a payment type to make double-spending easier will not make sense to newbies. In fact, it makes no sense to me! We can unstick stuck transactions with child-pays-for-parent, after all.
2. Merchants Running Custom Payment Systems
The same problem will happen at merchants running their own payment systems: many won't get around to upgrading to detect these transactions (they might not even realize they need to). After they get scammed a few times, they will be more reluctant to accept Bitcoin at all. Explaining to them that "well you should have noted that the transaction was double-spendable" would just seem ridiculous: "you're telling me that Bitcoin now facilitates double spending!?"
3. Extra Work for Payment Processors
Payment processors like Bitpay will get around to making sure they can detect the double-spendable transactions. However, this means they'll need to put engineers on the job and take them off of other projects. In other words, Core has effectively forced these payment processors to spend more money to support a "feature" that there was no demand for anyways.
The Good News
There is a silver lining to this! Once industry wraps their heads around how silly this "opt-in RBF" is, then I think we'll see more backlash. Perhaps this will be the proverbial straw that broke Core's back, pushing people into XT, btcd, Unlimited and other clients that don't support any form of RBF.
Why Did Core Add "Opt-in" Replace By Fee?
My hunch is that Blockstream already realized that this would cause damage to Bitcoin's reputation as a payment system, and that by selling it as "optional" they could allow the damage to occur without taking the blame ("it was the free market at work!"). When the problems I described above start to happen, it will give them more ammunition to say "We told you we need Lightning Network because Bitcoin isn't reliable as a payment network!"
Posted as comment:
Last edited:
Peter is no dummy, my bet is that he will try to use this as a justification for removing the "opt-in" part at some point in the future. The argument will go something like: people should have the right to pay more to have their transactions "unstuck" and having RBF TX's treated as second-class is "unfair", so in order to level the playing field, every TX should be RBF mandatory.
[doublepost=1448734908,1448734241][/doublepost]@Peter R
Indeed, almost any way that you play this out, functionality and UX is hampered, and Blockstream gets an upper hand in pushing the network their way. ALL forms of RBF should be summarily rejected.
