What would your BTC bid be? Serious question; I have a handful.I would personally pay more for a 2011 series 2 coin than for a series 1, but that's partly because I own one of the latter ones and none of the former.
Gregiocy, Gregness, Gregidity ...I was just reading another /u/nullc reinventing-the-wheel-on-production-quotas-and-price-fixing redux on the North Korea subreddit, and this observation occurred to me.
Doesn't perma-full blocks impose a pretty massive negative externality on the recipient of a payment?
With normal goods or services, a straightforward production quota will typically bid-up price in such a way that actually sends pretty actionable signals to the consumer. By that I mean that while total utility is undermined by deadweight loss, it doesn't necessarily directly create friction between buyers and sellers within the market that's unique vs the market equilibrium condition (This is a similar criticism to the fact that tx fee market can't have trading or market makers).
In the case of a Bitcoin tx, you make these business arrangements, for example communicating with another party that you intend to pay them. Now you submit the transaction praying that there isn't some surge of tx demand right after you submit but before you can get into a block, and that if there is, it doesn't extend past a time horizon that the recipient of your payment would find acceptable.
So here's where things get crazy: depending on how unpredictable confirmations become, recipients of Bitcoin payments might become inclined to demand a premium to reflect absorbing the economic dis-utility of getting paid in this unreliable and unpredictable way. A good common-sense example of this phenomenon is something many have experienced if you've been able to talk a car salesman down further by being willing to pay in cash right there.
This is not a road that I think anyone remotely sane is going to want to walk down. Even if you assume that layer 1 is supposed to be only bulk settlement, these issues are exactly the same as the simple payer-payee scenario, if not worse because failure to perform creates systemic risk and cascading failures, far beyond the guy on Craigslist being pissed that your payment for the furniture you're buying for example isn't clearing.
LOL the stick figure was black and represented the keep the limit proponents, is that now insulting towards black people or small block proponents, I'm confused?@Peter R what's this guy dts railing on about racism? I assume the accusation has to do with your simple squish man gif?
I asked at the agreement meeting what "released" meant and I was told it meant SegWit would be published and ready for review. After all, it cannot mean go live on the network or be merged into Core, since the signatories to the agreement had no power to do that. Therefore I do not think its fair to accuse me of lying in this respect.Jeez @jonny1000 , I didn't figure you would resort to outright lying and claim SegWit was released in April:
Since SegWit was "released" in April, this means the developers are committed to have an implementation of the HF ready by July. Although perhaps Luke thinks the meaning of the word "release" in the "agreement itself" is different to meaning in the "estimated timeline based on the agreement's terms".HK Agreement said:The Bitcoin Core contributors present at the Bitcoin Roundtable will have an implementation of such a hard-fork available as a recommendation to Bitcoin Core within three months after the release of SegWit.
Thanks for clarifying your perspective.I asked at the agreement what "released" meant and I was told it meant SegWit would be published and ready for review. After all, it cannot mean go live on the network or be merged into Core, since the signatories to the agreement had no power to do that. Therefore I do not think its fair to accuse me of lying in this respect.
I've heard Greg Maxwell state that SegWit was up and running in 2015.SegWit would be published and ready for review
So I'm afraid whether or not you consider it unfair for me or others to consider your statement a lie is irrelevant. Everyone can tell that there has not been a release which includes SegWit.This document describes the life-cycle of the Bitcoin Core software package released by the Bitcoin Core project. It is in line with standard maintenance policy across commercial software.
I do. Luke-jr is also a notorious twister of the truth.I am afraid I have no explanation for this apparent discrepancy.
Now you're just making Core look even more ridiculous. SegWit had been on their roadmap since way before the meeting. What you're saying is that Core has no power to release any of the items on their roadmap.After all, it cannot mean go live on the network or be merged into Core, since the signatories to the agreement had no power to do that.
Sure.There does seem to be some misunderstanding here
I can give you statistics:since much of the meeting focused on the idea that we would need data on SegWit usage on the network before deciding the parameters for the HF.
Bwahaha.Please bare in mind the time-line in the agreement is only an estimate, so d not hold people strictly to it.
No reason to censor of course, but the author did not understand:why would those douchheads take down/censor an article like this?:
If EU Collapses, May Bitcoin Become Europe’s Common Currency?
http://cointelegraph.com/news/if-eu-collapses-may-bitcoin-become-europes-common-currency
[doublepost=1467299740][/doublepost]maybe it shows just how anti-Bitcoin the small blockists have become. they desperately want offchain solns so their native fiat currencies don't get killed?
I do not know what was meant by released. I am sorry if my comment sounded like a lie. all the information is available. I guess Luke agrees it has not been released yet, therefore he still has over three months to implement the HF code.Or perhaps not - @Jihan , can you confirm that @jonny1000 's description of the agreed SegWit "release" definition is accurate?
What have I tried to redefine?But when they try to redefine history, I call them liars.
This is a ";likley timeline" not deadline."Ready by July" also technically means by 1st July, not 31st July. The miners are being extremely lenient if they extend that deadline.
Nope, Greg doesnt have much to do with the agreement as far as I can tell.Certainly a suspicious amount of misunderstandings around Gregs group, don't you think?
He is right, 75% is more than enough with cherry and sugar. But if someone can be appeased, I am ok with it. I think the avalanche comes before that, maybe at 20%.You're so full of it.
Could you point me to the event that marked the start of the code review?
Thought for the day: Lies have expiry dates.I asked at the agreement what "released" meant and I was told it meant SegWit would be published and ready for review.
I thought it was this (on 19 April 2016):Could you point me to the event that marked the start of the code review?
Source: https://github.com/bitcoin/bitcoin/pull/7910Sipa said:This is the complete code for segregated witness on top of master (implementing BIP141, BIP143, BIP144, BIP145)
The OnChain Scaling Conference is now on youtube:
https://www.youtube.com/channel/UCgw99sImtN_oAnF856-KUEA
Great post @freetrader!@jonny1000 :
Thanks for clarifying your perspective.
Of course, whether you asked that question at the meeting and got the answer is unverifiable by independent parties. Or perhaps not - @Jihan , can you confirm that @jonny1000 's description of the agreed SegWit "release" definition is accurate?
I've heard Greg Maxwell state that SegWit was up and running in 2015.
There's a contradiction here somewhere.
If we're talking about a software development process, there should be a quality gate that marks kick-off of a formal code review. I have not seen any evidence that such a gate was passed in April. Could you point me to the event that marked the start of the code review?
About the word "released":
There is a (global) consensus about what "released" means, and if not defined clearly in the wording of an agreement, that consensus applies, and not some ad-hoc redefinition.
What it means is to have completed the process of validation and undergone the ensuing formal release process that issues project deliverables (source code, executables if those are customary).
In the context of the Bitcoin Core project, "releases" are described by the lifecycle description here:
https://bitcoincore.org/en/lifecycle/
It states right at the top:
So I'm afraid whether or not you consider it unfair for me or others to consider your statement a lie is irrelevant. Everyone can tell that there has not been a release which includes SegWit.
By now, we are all used to the constant redefinitions and excuses emanating from Core.
Personally, I am used to attributing a truth value of 0 to any of their statements about future events.
But when they try to redefine history, I call them liars.
"Ready by July" also technically means by 1st July, not 31st July. The miners are being extremely lenient if they extend that deadline.
I do. Luke-jr is also a notorious twister of the truth.
Now you're just making Core look even more ridiculous. SegWit had been on their roadmap since way before the meeting. What you're saying is that Core has no power to release any of the items on their roadmap.
I would give you some general advice at this point: stop trying to make excuses for Core.
They have already dug themselves a deep hole, and keep on digging. Their strategy is to pile lies upon lies to cover up lies. We all know that ends up spinning out of control, and leads to bad outcomes. Public lies (and our discussions with Core are public) reflect badly on future careers.
I'll grant you that sipa's PR meets your definition of release.I thought it was this (on 19 April 2016):
Source: https://github.com/bitcoin/bitcoin/pull/7910
This is what I thought the release of SegWit was. But it doesn't solve the linear scaling of sighash operations problem, one of the main benefits of SegWit. Is that your concern?
Care to share who told you that, and why you believed them?I was told it meant [...]
I believe the paper (Satoshis white paper) was always designed to be a high level overview of the current reference implementation, and that we should update it now that the paper is outdated and the reference implementation has changed significantly from 2009.
If you honestly believe that anything will happen in Core without Gregs or Adams approval, you are even more misled than I thought..Nope, Greg doesnt have much to do with the agreement as far as I can tell.