You are arguing on semantics. The word "transaction" in the title doesn't refer to bits and bytes transactions found in the blockchain but to the more common definition "an instance of buying or selling something". I agree that a better title would have been: "Stop saying that Bitcoin transactions have to be irreversible".
Every domain has domain terms: specialized knowledge and vocabulary.
Within payments, "transactions," "reversibility," "revocability," and "escrow" have definitions. Since BitCoin is in this space, I'd expect an article to use the domain terms from this space.
Yes, if you re-define these terms to mean something more colloquial, it may look like that. If you squint. But that doesn't make it not look amateurish.
Not to be pedantic, but that's not necessarily true; we've had 1 major chain split before that killed ##'s of blocks containing thousands of transactions.
And also transactions that don't make it into a block will just die if the original node doesn't rebroadcast it. So after 1 confirm it's mostly irreversible.
To be truely pedantic, at the time they were on the Bitcoin blockchain, it wasn't until well after the incident started that the developers and pool owners decided to reject that blockchain (which was just as compliant with the stated Bitcoin rules and had a mining majority) and switch to the other side of the form.
To be pedantic, those aren't really 'reversed transactions' so much as 'data loss'. It's not like specific transactions were targeted. If a bank incorrectly recorded a credit card purchase of yours, you wouldn't classify it as 'a reversed transaction'.
If the goods you purchased are already in your hands, and your bitcoin payment has been lost in a blockchain accident, what is your incentive to rebroadcast your bitcoin payment?
I believe you can use nLockTime[0] to construct and broadcast a transaction that cannot be accepted into a block at least until a particular time. Before that time is reached, you should be able to broadcast a conflicting transaction if so desired that is included in a block sooner, thus invalidating the previously broadcast transaction.
i am with you, i actually think the author coming from economics background who knows nothing about cryptography systems should just shut up before saying anything stupid in public...
I'm building something on top of Hangouts, and I had an exchange that this reminded me of.
I was finally connected with a developer evangelist, and I sent an email saying something like "would love to know more about Google's strategic goals with Hangouts".
Her response was "I'm sure you're aware that Google doesn't discuss its strategies outside the company".
What a striking cultural difference from startups, where we're constantly discussing our strategies together.
I've also successfully implemented Zakas' [1] approach after watching his presentation "Scalable Javascript Application Architecture" [2] and abandoning Backbone.Aura [3]. Aura theoretically implements this, but in practice we found that it made some assumptions that were incompatible with our needs. Consequently, we rolled our own implementation.
(which was also posted by politician) was very useful in explaining the theory. I also made some changes to it, but offhand I can't remember what they were. I think it was to do with the separation of starting vs initialising modules (parts of a page).
Even if there aren't enough ratings to be meaningful, seeing movies higher up or lower down than fans think they should be will encourage them to jump in and 'fix' things. :)
If you're just at the "idea stage", then no one is going to steal your idea.
If you've progressed further and have some traction, some lessons learned in customer acquisition channels, etc., then you should be cautious about what you share because your information has real value.
At good metric for an indirect peg on number of people using something is the "star" count on Github. It's not an ideal metric but it is a reasonable proxy. The other thing I'd look at which requires more effort is to look at the number of subscribers to the mailing list (if you can get it.)
I think the negative comments here are missing the fine points of the article.
* Stage of growth is important. In the beginning, success is more about individual effort. When you get bigger, it's more about overall team culture.
* It's not just "being a jerk" that's the problem. It's being a naysayer, working against the culture.
At a certain size, the negative effects of someone's behavior on the culture can outweigh the positives of their brilliance. And when that happens, you have to let them go.
What this post describes is a 2-of-3 multisig, which adds further encumbrances in constructing a valid transaction.
But any transaction, once broadcast, is irreversible.