Topic: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 58. (Read 378992 times)

lel old nyooz, still irrelevant.


edit: pfahah theymos, always keeping a stiff upper lip:

https://archive.is/4rvPe

dat gate keeper

ftfy.

what a waste of time arguing with this irrelevant wacko.

The beacon of hypocrisy resides in the person championing freedom of choice & liberty of Bitcoin implementations yet expressing ignorant contempt & outrage any time Core merges code he doesn't agree with.


This. Thank you.

Mike and Gavin have not commented on Opt-in RBF as far as I am aware; you are confusing his comments on full RBF. But on what basis do you believe their expertise is greater than a dozen other parties?

Opt-in RBF is explained in some detail in the FAQ on Reddit, linked previously to you in this thread; you say that you are open to other views, but you seem to have made no effort to familiarize yourself with them.

I just checked his twitter feed and can find no comment on it in the last several months. As far as insight, Gavin is not very active in Bitcoin development and hasn't been for a significant time, before the recent blocksize drama. That he didn't comment on the PR was unsurprising on that basis, but he certainly was aware of it-- since he asked when the merge was being discussed in the weekly meeting if we'd talked to any other wallet vendors about it (though this also indicated he hadn't recently read the PR).

So now Bitstamp is officially on the BIP101 train.

https://www.reddit.com/r/btc/comments/3utza9/bitstamp_supports_bip_101_and_will_switch_systems/

It's tempting to modify the sometimes Bitcoin motto of 'be your own bank' to 'be your own bankster.'  This does not work however.  Banksters ply their trade through opacity, through flexibility in the fiat system, and through protection of their racket using state legal systems.  Bitcoin is distinctly bad on all of these fronts.

At the end of the day, an ecosystem of subordinate chains makes it possible to 'be your own bank' at any scale one wishes or needs, but racketeering will not be as easy as with traditional monetary systems (provided Bitcoin is not bloated into the waiting hands of centralization.)

There actually are some theoretical problems with the system.  It is kind of the way the world works that as the games progress, the winner accumulates all of the chips.  A rock solid Bitcoin (or whatever non-inflationary backing store) only makes this outcome more likely.  This was something I considered before buying my first Bitcoin.  Then, as now, my hope to overcome this problem should it occur is to just replace the backing store.  Hopefully the threat of this and the economic damage it would do to the 'winners' would make it a very risky and undesirable to accumulate such a position in the first place.

We are actually having a reasonable discussion here, well done Trent Russel.

I also agree with you that the underlying volunteerism of Bitcoin is indeed one of its most appealing aspects.

I personally would prefer it if either Core or XT compromised their position on the blocksize so that we can have a higher degree of consensus, while at the same time buying us more time to further distribute development over the long run. A third alternative representing a middle ground between these two extreme positions would also be a positive development if both Core and XT are still unwilling to compromise by that time.

When there are technical experts stating opposing things it is hard for people like me to know what is true, Mike and Gavin certainly do think that it does reduce the functionality of zero confirmation transactions.

If the economic majority where to make these type of decisions for Bitcoin through proxy then it is important for the developers to explain well what they are doing so that the economic majority do not become misinformed, having technical experts make contradictory statements is confusing for the layman. However considering that this is a science unlike politics and economics there should be a singular correct answer for this question regarding RBF and zero confirmation at least. I suppose in this situation it might be appropriate to believe the developers that I respect the most and that best represent my own personal ideology. I did read Mike Hearns criticism of RBF, the logic contained within that paper did make sense to me. If Core has written a paper countering Mike's argument please link that here, I am always open to opposing points of view which is part of the reason why I post here more often.

We have a high volume of low value transactions at this brick and mortar store, the type of place it is it would not be suitable for people to wait for confirmation. Accepting zero confirmation transactions has so far not been a problem, even if some double spends did occur it would be within acceptable loss. Of course if zero confirmation did become less reliable then it is now I would have to either use a payment proccessor or only use cryptocurrencies that have the same functionality that Bitcoin has now, that is if in the future zero confirmation did become less reliable in Bitcoin, which as far as I understand would be the case if the blocks became full, RBF does also not help this situation at least according to what some developers are saying about it.

That is peculiar considering that he has spoken out against it on twitter, I was not aware that he had not told the Core team about his concerns, I find that a bit strange, maybe you have a better insight on why this is the case. I am going to ask Gavin myself why he did not speak out against RBF when it was being implemented into Core, since I do find that rather strange.

No it doesn't.

You should wait for confirmation if your risk model says you should. This is already the case, and many properties of a transaction (like low fee or spending unconfirmed inputs) will make most zero conf accepters wait (and still they frequently get ripped off; because the Bitcoin system itself does not provide security for unconfirmed transactions). Fortunately, Opt-In RBF at least means that there is no risk that the confirmation needs to take an excruciatingly long time.

If he is, he failed to speak up. Of the 19 people that commented on the PR in the nearly two months that it was open, none said anything negative.

The moronero shills shouldn't laugh to early. The chance, that the community will be unable to respond to the blockstream attack (change a 'Peer-to-Peer Electronic Cash System' into a settlement layer for the banksters) is miniscule.

https://www.reddit.com/r/btc/comments/3ush79/then_they_fight_you/

Fair enough. And you're probably right that I shouldn't have used the word "force." If at some point in the future 101 starts getting significant miner support (which seems unlikely), it also wouldn't "force" me or others to go along with the change. I could switch to another cryptocurrency or simply leave the space. This ultimate ability to opt-in or opt-out is one of the most appealing aspects of cryptocurrency.

I can acknowledge that RBF is not a fork. I was indeed mistaken about how this change is properly defined.

I do not consider the seventy five percent miner consensus that is required in order for BIP101 to be triggered to be an attempt to "force" a contentious change, quite the opposite actually it is a way to resolve a contentious decision through the proof of work mechanism.

@VS: Can you at least acknowledge that RBF is not a fork? I'm convinced you understand that RBF doesn't change the consensus rules (the definition of which blocks are valid). At this point it seems like you're trying to avoid acknowledging this.

The resistance to XT was mostly due to XTs attempt to force a contentious change to the consensus rules. I think XT already had relay policy changes before BIP 101 was added. There was no real resistance to XT at that point.

Just to let you know, it's clear to me that you support bigger blocks and alternative implementations.

Not when the blocks fill up rendering transactions unreliable and to expensive for the purchases made at that store, RBF certainly also does not help the situation.

There seems to be mixed responses about how damaging RBF will be to zero confirmation transactions, I suppose this will also depend on the extend of adoption of RBF. As far as I understand it however it will make double spends easier and therefore zero confirmation less secure and also therefore less reliable. While at the same time making Bitcoin less user friendly and more complex.

You will not have to take down your Bitcoin sign, you can operate as before

I would like to preserve and strengthen zero confirmation transactions, like XT and Bitcoin unlimited have stated. There is a fundamental disagreement of believe here.
This proves another one of my points, the solution according to you as a merchant is to transfer my Bitcoins to a third party wallet service or stop using Bitcoin completely. I would not consider this to be an "improvement".

I operate a brick and mortar store which accepts zero confirmation transactions directly, I would not like it if I would have to stop accepting Bitcoin or use a third party, which would mean I would then need to take down the Bitcoin sign I have in my store, I would still accept other cryptocurrencies of course. The blocksize would also be a factor in this, I do not agree with the path Core is taking Bitcoin into, fortunately we now do have alternative implementations to choose from and more are also now starting to appear.

These alternative implementations are critical for the freedom of the Bitcoin protocol. Alternative implementations represent alternative choices for us to choose from as a community, this is a good thing, without alternative implementations it would be an election with only one option, that would not be a choice at all.

Good!  zero-conf was the definition of stupid when I got interested in Bitcoin, and with good reason.  It's not Bitcoin's fault if later arrivals ignorantly tried to hammer a square peg into a round hole.  (Gavin can take a lot of credit for this mis-hap due to his chronic mis-management which, as best I can tell,  was at first out of ignorance and later out of malice.)


Transfer your Bitcoin (in the unlikely event that you have any) to a wallet service which guarantees not to do RBF then and let them interact with vendors.  Or just use ACH/PayPal if you like it so much.  Many of the rest of use have use for something different.


You are welcome to move onward and upward to redditcoin at your earliest convenience.  Don't let the door hit you on the way out.

Nothing in the protocol changed. There is absolutely 0 change to Bitcoin protocol. They did not implement any changes to the protocol.  This is not a change! Since they did 0 change to the protocol, they did 0 contentious change to protocol. Since they did not do a contentious change they have stuck to their work so there is no hypocrisy.

Clearly the comments were said in the context of changes to the consensus rules. Not to absolutely any changes to the client or wallet. You dont need consensus to change for example the colour of the buttons on core. That is not what they meant.

This is simply a change to the non-consensus working of one client, bitcoin core. Like you yourself said it is not special. Bitcoin is decentralised and there are many clients.

Thats not a problem as long as they follow the same protocol.

Most people on reddit haven't got a clue what they are talking about. Most of the noise is done by XTards such as yourself trying to make an issue out of everything that comes out of Core's shop nowadays because you are so butthurt your little fork remains marginal no matter how hard you shout while consensus clearly sits with Core.

What an oblivious little whiner you are... the partisan act really is getting tired. It's time you fall into irrelevance and quit the stage, or, you know, just fork off.

It reduces the functionality of zero confirmation transactions. If I am a merchant should I reject RBF? Since if I did do this it could cause other problems as well. Since it is the person that sends the transaction that chooses to opt in not the receiver.

You claiming that this is not a contentious issue is obviously not true considering the noise that is presently being made on reddit even with all of the censorship.

Even Gavin Andresen is against RBF and last time I checked he was still a Core developer, so now you do not even have your all important "developer consensus".

This "developer consensus" seems to be the proposed governance model of Core, which I wholeheartedly disagree with, as opposed to rule by the economic majority through proof of work consensus.