network still clogged.
crimony.
Topic: Gold collapsing. Bitcoin UP. - page 165. (Read 2032248 times)
I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
Right. I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions. Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?
...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.
I don't follow. It sounds like you think it would be a good thing to make zero-confirm transactions less secure. Is this true?
Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.
Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.
Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.
full-RBF breaks this.
we agree on the need for a fee mkt. where we apparently disagree is where it is to be enforced. i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users. yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time. only they can do this.
I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.
only users can determine how much they are willing to pay.
Assuming you mean as part of a market process where users and miners meet at price points, I agree.
yes, this is what i mean. thanks.
Yes, the more mining costs the more miners will mine.
we agree on the need for a fee mkt. where we apparently disagree is where it is to be enforced. i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users. yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time. only they can do this.
I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.
only users can determine how much they are willing to pay.
Assuming you mean as part of a market process where users and miners meet at price points, I agree.
yes, this is what i mean. thanks.
we agree on the need for a fee mkt. where we apparently disagree is where it is to be enforced. i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users. yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time. only they can do this.
I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.
only users can determine how much they are willing to pay.
Assuming you mean as part of a market process where users and miners meet at price points, I agree.
...
fritzed out? where do you even get that? the pt is, that MANY ppl already agree on, is that RBF is not safe b/c it allows reversal of tx's in an already established industry where it has been proven not to be a problem. it tries to fix something that is not there.
fritzed out? where do you even get that? the pt is, that MANY ppl already agree on, is that RBF is not safe b/c it allows reversal of tx's in an already established industry where it has been proven not to be a problem. it tries to fix something that is not there.
Smart people have warned for a long time that zero-conf transactions are brittle. If an 'industry' has built up around them, tough shit.
and your's is exactly the kind of attitude we should be rejecting here:
"so what if we decide to change the rules in midstream on a bunch of ppl, it's what i think is best, so tough shit".
Quote from: imaginary_username
Gosh, I know you guys are good guys and care about the system being ironclad from all sides. But you gotta get out, take a walk in the real world sometimes
Also applies to the "bigger blocks will mean fewer nodes" argument.
Quote
Because it can be economically expected that most transactions now are low priority, since fees are cheap. This means the actual transaction volume that likely would be taking place given only somewhat more expensive fees is much, much less. It's should be obvious enough that if transactions were completely free people would spam like crazy. That's not a judgment on the validity of those transactions; it's just economic reality. People start to economize dramatically when there is even a marginally-above-zero cost versus when there isn't.
This is in no way suggesting 1MB is sufficient, but it's not helpful to pretend that transaction volume when fees are negligible will remain the same if fees go to merely tiny. In no other market would we expect such a thing, and for all we know we could easily be talking about order-of-magnitude differences in volume from a fee increase that still presents no real pain for any major use case.
This is in no way suggesting 1MB is sufficient, but it's not helpful to pretend that transaction volume when fees are negligible will remain the same if fees go to merely tiny. In no other market would we expect such a thing, and for all we know we could easily be talking about order-of-magnitude differences in volume from a fee increase that still presents no real pain for any major use case.
but cheap to who, you? i remember an Indian standing up at the San Jose conf during Q&A and complaining about high tx fees for ppl in his country. and they are, given their relative income levels.
we should be promoting Bitcoin to these 3rd world countries where a .0001 minimum fee is arguably expensive. that's why we have the economic fee choice of .00001 which oftentimes still results in rejection. to take it further, do you believe that Bitcoin should offer even these Indians the ability to buy a cup of coffee for cheap fees? i think so but probably you think different. i know tvbcof and iCE would flat out say no way. but then that goes back to my argument that for maximum decentralization and to become digital gold Bitcoin needs to service these ppl.
when you say ppl will spam like crazy, don't you trust that the miners can react to filter that spam, if they so choose? the problem with the 1MB choke approach is that yes, new users will be forced to economize on their tx's. OR just leave.
This isn't relevant to the question of whether having a fee market would help. I'm not saying 1MB is adequate, and I'm not saying that fees shouldn't be cheap enough for any particular group. I'm saying that no matter what blocksize cap we have, or even if we have no cap, we will still need a fee market for maximum scalability on chain. And we could easily be talking about order-of-magnitude differences in scalability contingent on the presence or absence of a proper fee market. As for miners blocking spam, sure, but as you say: who's to tell what is really spam?
we agree on the need for a fee mkt. where we apparently disagree is where it is to be enforced. i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users. yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time. only they can do this. only users can determine how much they are willing to pay.
I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
Right. I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions. Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?
...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.
I don't follow. It sounds like you think it would be a good thing to make zero-confirm transactions less secure. Is this true?
Jumping in. Not good to destroy zero conf, but we need to be antifragile, so the protocol should not guarantee zero conf, which it doesn't and never did. The receivers of coins must take full responsibility if they rely on zero conf, using heuristics like the current card companies does. I think I lean to the side of just not care about zero conf, from the basic bitcoin side.
I just noticed this humorous analogy of full-RBF on Reddit in response to Maaku's comment that zero-confirm transactions were "already dead":
Quote from: imaginary_username
Analogy: Sure, locking your front door is good policy no matter where you're at. Not locking your door at all times is already dead, in your words. But some days, when I move furniture or out there to chase down my escaped cat, I feel okay leaving the door unlocked for a few minutes. It's possible, but highly unlikely, that people are gonna just break in during that time.
Implementing full RBF today will be akin to actively sending a marauding gang of thugs, and they'll break in every house that has an unlocked door for however short amounts of time. And then the Devs will point and laugh "I told you not to do 0-confs!"
A sane person can accept the risk of highly infrequent break-ins; if that becomes more often, maybe that person then invests in locking the door more often and more carefully. Great. But a sane person will not tolerate the mayor sending roving gangs of thugs to break into his house at the first sight of unlocked doors. Instead of investing in bigger locks, he's more likely to conclude that "this town sucks" and move on.
Gosh, I know you guys are good guys and care about the system being ironclad from all sides. But you gotta get out, take a walk in the real world sometimes, see how this is actually being used sometimes, before killing a usecase.
Implementing full RBF today will be akin to actively sending a marauding gang of thugs, and they'll break in every house that has an unlocked door for however short amounts of time. And then the Devs will point and laugh "I told you not to do 0-confs!"
A sane person can accept the risk of highly infrequent break-ins; if that becomes more often, maybe that person then invests in locking the door more often and more carefully. Great. But a sane person will not tolerate the mayor sending roving gangs of thugs to break into his house at the first sight of unlocked doors. Instead of investing in bigger locks, he's more likely to conclude that "this town sucks" and move on.
Gosh, I know you guys are good guys and care about the system being ironclad from all sides. But you gotta get out, take a walk in the real world sometimes, see how this is actually being used sometimes, before killing a usecase.
...
fritzed out? where do you even get that? the pt is, that MANY ppl already agree on, is that RBF is not safe b/c it allows reversal of tx's in an already established industry where it has been proven not to be a problem. it tries to fix something that is not there.
fritzed out? where do you even get that? the pt is, that MANY ppl already agree on, is that RBF is not safe b/c it allows reversal of tx's in an already established industry where it has been proven not to be a problem. it tries to fix something that is not there.
Smart people have warned for a long time that zero-conf transactions are brittle. If an 'industry' has built up around them, tough shit.
i know the probability is random. so why has every_single_one i've seen always been within a minute or two?
And is it just me, or does it seem like people keep remarking on the coincidental "pathological inability to find blocks" during each of the stress tests? (this is from memory, could be wrong)
Might it have something to do with how mining pools work, perhaps a bug or inefficiency that causes them to throw away or waste hashing power if they are busy collecting too many transactions, lowering the overall effective hashrate significantly? (And conversely the 0 tx blocks are using their real full hashrate??)
/no-idea-about-this-technical-aspect
no, you're not imagining it. i remember smooth making several comments about delayed blocks related to spam attacks. i even expected some sort of delay in the face of it. it's new info to me.
As far as I can tell, the only "benefit" is that it breaks zero-confirm transactions and, like sticking with the 1 MB limit, provides impetus to use off-chain solutions.
Yes.tvbcof doesn't get it.
I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
Right. I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions. Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?
...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.
I don't follow. It sounds like you think it would be a good thing to make zero-confirm transactions less secure. Is this true?
Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.
I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
Right. I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions. Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?
...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.
I don't follow. It sounds like you think it would be a good thing to make zero-confirm transactions less secure. Is this true?
Totally true. In my opinion they are simply incompatible with the design of Bitcoin when Bitcoin is being used as a reliable system as I would like it to be. ('reliable' has some technical meanings in computer science BTW. e.g., 'reliable signals' in OS design.) Efforts to make it otherwise are effectively pounding a square peg into a round hole and result in wasted energy, splinters and breakage. Also completely unnecessary and counterproductive when 2-way-peg and some of the other technology that Blockstream is working on result in sidechains being a nearly perfect proxy for native Bitcoin.
So, to counter justusravenier's answer in the new post I noticed before posting this: 'No.'
i know the probability is random. so why has every_single_one i've seen always been within a minute or two?
And is it just me, or does it seem like people keep remarking on the coincidental "pathological inability to find blocks" during each of the stress tests? (this is from memory, could be wrong)
Might it have something to do with how mining pools work, perhaps a bug or inefficiency that causes them to throw away or waste hashing power if they are busy collecting too many transactions, lowering the overall effective hashrate significantly? (And conversely the 0 tx blocks are using their real full hashrate??)
/no-idea-about-this-technical-aspect
with RBF, does the sender have the ability to completely change the destination address back to himself?
What's your problem with that? It's his money until it's not.
Oh, Bitcoin is not a real-time system in spite of years of propaganda trying to make it so? How sad. I think I'm going to cry.
Except that Bitcoin does function as a real-time system for most use cases today perfectly fine. There is an entire Bitcoin ecommerce industry that proves you wrong.
precisely.
Then why are you all fritzed out about the RBF 'attack'. Real-time Bitcoin not so robust as you've been led to believe?
lol, why do you even Bitcoin? you're such a pessimist. your father must have beat you.
fritzed out? where do you even get that? the pt is, that MANY ppl already agree on, is that RBF is not safe b/c it allows reversal of tx's in an already established industry where it has been proven not to be a problem. it tries to fix something that is not there.
As far as I can tell, the only "benefit" is that it breaks zero-confirm transactions and, like sticking with the 1 MB limit, provides impetus to use off-chain solutions.
Yes. blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal. pools taking defensive action. when will Blockstream devs do something?:
Why do you call this "defensive" action?
when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block. this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing the next block with only the "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.
How about: When they see a new block, they immediately start mining based on that, with an empty transaction list. When they have removed the transactions in the last block from their own list of transactions to include, they mine with the new list. If a block is found quickly, it will be the empty block, else it will be a block with the new list.
You can see that the zero transaction blocks always come a short time after the previous. But they should not need minutes to establish a new list, so I am not sure.
Maybe some miner can chime in and say what really is going on.
your first paragraph was correct.
i'm not sure why the 0 tx blocks come so fast after the previous block. i keep asking this.
it's the sigop checking of a large block, i believe, that takes the extra time.
Well my first paragraph suggested a reason. They need time to construct a new transaction list.
Edit: The block finding is completely random. It is just as probable to find a block the first second, as after several minutes.
i know the probability is random. so why has every_single_one i've seen always been within a minute or two?
Jump to: