It's not possible to do extremely small micropayments on bitcoin directly as people use it today. Bitcoin's made a lot of promises around micropayments, but doing it in an economical way has tradeoffs, especially if you're talking about millions to billions of transactions per second. In fact it's not possible to extremely small micropayments on ANY platform. Try sending $0.001 to someone once. It's not possible. The closest you're probably going to get is sending someone an item on Steam (and there's no easy way to price the items). The reason for this is underwriting costs, it's too expensive for Visa to process it since they're assuming some liability. Even Paypal, who ostensibly should be doing this, charges $0.30 for payments for goods and services.
Lightning allows for micropayments to actually happen because custody is still pushed to the edges, so you don't have the same kinds of underwriting risk.
This means that something as simple as paying someone $0.001 over the internet one time will become viable this year. The amount of possible business models and use cases could dramatically shift. Users may not know they're using Bitcoin (your application could hide it and abstract it away), but people are getting paid in a way they could not before (even centralized systems did not exist, let alone decentralized ones). Pay-per-click webpages, massive decentralized CDNs, creating API services without a username/password to make onboarding seamless (you paid? you're done!).
We're working on code here: http://github.com/lightningnetwork/lnd
It's MIT licenced and will soon have some pretty simple APIs to use. Of course, since this stuff will be in testing for a little while, make sure you only use small amounts/micropayments initially when it's released.
This has been possible for many years.
I think the big difference here is that obviously decentralization is nice, but the real issue is that Linden could do it because they simply didn't become big enough to be a target. There were some attacks at the edges, but if you wanted to do what Linden did at Visa-scale, they would quickly put a stop to it with chargebacks.
Adversarial problems are far easier at smaller scale, but it is a good point, thanks for the correction! It may be more accurate to say nobody's done it where it could be conceptually feasible at high-scale/volume with dedicated adversaries (many of the Linden exchanges solved this with high exchange rates to buy in, e.g. Virwox).
If you mean Linden would have issues with chargebacks for people exchanging real money -- why wouldn't any BTC exchange have the same problem? It seems unlikely you'll be able to buy $0.01 of BTC.
In fact, any centralize system that throws out chargebacks should have zero problems scaling. A few years ago VISA said their target was around 50K tx/sec peak (though their daily peak is only a few thousand). It'd be slightly odd for a centralized system to not be able to easily scale to that volume.
Forgive me if I'm misunderstanding the thread.
The only utility in LN is hopefully retaining decentralized properties of bitcoin. PokerStars, Linden & WoW have supported micropayments for a long time?
Im not sure why any of these services could not grow 10x and still function internally? They are already servicing tens of millions.
Say I want to pay Bob $0.001. That's too small for a bitcoin transaction since the fee is higher than that. So from what I understand I would "load" say $10 into the lightning network then create a transaction over the network to Bob for $0.001. Say tons of other people do this and now Bob is sitting on $10. How does he turn that into actual Bitcoin? Like get it out of the lightning network. Doesn't he have to close off all those thousands of channels?
At any time either party can close out the channel unilaterally by broadcasting the most recent state. The person that broadcasted it gets refunded after a delay (assuming the uncooperative case where the other party in the channel goes off the Antarctica or something -- in a cooperative case, both parties close out immediately with the current balance).
Leaving coins in LN is fully backed on-chain, of course, since these are real bitcoin transactions passed around. The added benefit is you can transact instantly in high volume, so coins in LN will probably have more use than coins off LN when it comes to payments.
Say Bob says I want my $10 to stick on OKCoin now. He broadcasts that he wants to close the channels for all those thousands of people now? Doesn't that mean the transactions go through on the actual network costing him ~$0.05 for each $0.01? Or am I understanding settlement completely wrong?
You update your channel to tell Bob, I will pay you conditional upon a proof that you paid Carol. Bob pays Carol and provides proof. If Bob didn't provide proof after an agreed timeframe, this gets cancelled. There can be an arbitrary number of people between you and Bob (7-degrees of Kevin Bacon, but probably don't go too high!).
This is done completely off-blockchain. At any time this can be moved on-blockchain, but since the blockchain will enforce the payment as part of its transaction scripting language, you both elect to do it off-blockchain. Think of this with the system intent/design where it represents an enforcible caching layer where invalid cache can be corrected on-blockchain.
You can do thousands, even millions of these transactions off-blockchain. Only the final balance is net-settled on the blockchain. So you finalize your balance between Alice and Bob if you want to close out the channel. Note that the channel between Bob and Carol could still be left open and everything still works fine!
Since it's scalable in a routed graph (think switches instead of hubs), you could potentially do millions to billions of transaactions which route value, much like routing packets on the internet.
If you have any questions, do send me an email. I'm working on making the explanation better so feedback is always appreciated.
I'm also suspicious of pay-per-whatever extending to end-users. People hate that kind of billing, even when it's cheaper (I learned this the hard way). And between companies, again, what's the benefit of having thousands of transactions when a couple would do?
Pay per website you visit, you visit a lot of different websites.
The notion is that you make each payment to be the smallest atomic component, so you need high-volume for that (since one large purchase gets split into many small purchases).
End-users don't like being scammed. If it's sufficiently low value with sufficiently high service level, you will get adoption. Appstore payments of $0.99 don't even register for a lot of people (with the exception of egregious Pay-to-Win games), if the payment was $0.001 and you only end up spending $0.10 in a day nobody would care. If you're getting billed per-hour on AWS, people prefer that to per-month.
The benefit between companies isn't for persistent relationships. It's the notion that you're reducing information cost (instead of paying a large payment with signon, you don't care who your counteparty is -- if they don't deliver who cares you're only out $0.001). In the longer-term, this is about reframing how you discover business relationships in the first place due to information/transaction costs.
PayPal is doing this. At least, via their subsidiary Venmo. The first thing I thought of when you said "try sending $.001 to someone once" was "huh, I do that all the time on Venmo. Couldn't be simpler."
Venmo also explicitly discourages you from sending money to people whom you don't have a social relationship with due to chargeback risks. They're a long ways away from being a general payment platform for goods and services online with people whom you don't have a prior relationship with, and as part of that will likely drop it from their business model. There's a reason why Paypal has been talking about doing it for 15 years but haven't actually done it (paypal doesn't charge any fees for payments to your friends but charges fees if you're paying for goods and services).
Plus it won't work (in the sense of saving blockchain space) for people who have few peers and tend to move money in one direction, e.g. a consumer connected to a "paypal"-like lightning service who makes purchases but doesn't sell online, this could be a significant portion of users.
It's a great extension to Bitcoin, but it shouldn't be confused with what Bitcoin does.
Unless I missed something, outsourcing watching the blockchain cannot be called trustless; they need to know what to watch. If your watcher collaborates with your LN-hub, you are doomed.
Here is my get-rich-quick-scheme:
* Setup a big LN hub.
* Setup a LN-watching service
Then for each peer connected to both, I filter those that:
* have a balance with <10% on my side
* have an earlier balance with >90% on my side
* haven't been seen for a week.
For those, I submit the tx of the earlier balance. Sometimes I'll lose a bit but mostly I will gain more.
(e.g. the large parked capital requirements acting as a barrier to entry, fees - if bitcoin is to be a low-volume settlement layer - plus people wanting to keep spending money consolidated (i.e. opening as few channels as possible) while still getting the benefit of complete payment connectivity)
What are the "inherent flaws"? Seems like the bitcoin blockchain has done its job better than any other blockchain for longer. Also, it's open source.. You can submit a proposal yourself if you want to fix it..
Not really. The vast majority of the bitcoin community has been trying to do just that. But a few devs have unilaterally been able to block the changes. The Devs have a lot of "soft power" to do stuff like that.
Thats a common claim made on easily sockpuppeted forums, but when put to cryptographic votes, we find pretty much the opposite response: http://bitcoinocracy.com/arguments/if-non-core-hard-fork-win...
Similarly, I've found in person meetings to also yield similar results.
> But a few devs
Really, almost the _entire_ technical community; with the exception of a few high profile companies and their consultants.
> have unilaterally been able to block the changes
That isn't how Bitcoin works.
Bitcoin development has been hijacked by Blockstream since 2014.
They want these changes to happen, they just want the Core Development team to say that they are going to stay out of the way, and not attempt to burn the whole thing down if they don't get their way.
Basically, they can scare people into thinking that there is going to be two separate, competing chains. This would cause prices to crash , and crash hard.
Because of this threat to burn the whole thing to the ground, they prevent the community from acting in the first place, even though it has the support to do so.
Doesn't matter the majority of users have moved to the new fork. That becomes the new core.
>They can say that they have 10% of the mining power and threaten to not move over to the hard fork.
Why would this matter? That 10% of miners will move over quickly or lose money by mining on a fork with no value.
>Basically, they can scare people into thinking that there is going to be two separate, competing chains.
There would be but since the majority of users and miners and companies want the one you want theirs would be losing right?
>This would cause prices to crash , and crash hard.
Why? If the vast majority want the change then they will just continue on as normal. It's only the people still using the old fork that will have problems.
None of these problems exist if the majority truely wants the change.
And if they do that, then there is a chance that there will be two competing forks, instead of one, and each competing fork will dump their coins on the other fork, and basically cause the whole thing to crash.
Core can't "win" by doing this, but they can certainly make the rest of us lose. This threat, along with their constant insistence that improvements are Just Around The Corner, has allowed them to delay efforts to coordinate and make the changes that the community wants.
Eventually people will wizen up to the fact that their improvements are never coming, but until then, they are playing the delaying game to buy themselves as much time as possible until they are able to get their competing, lighting network out of the door.
If there is one fork with 5-10% of the hashing power why do you think anyone would care about it?
What do you mean by dump their coins on the other fork? You mean like try to sell them on an exchange? But the majority of users would be on the new fork right so they would have the majority of coins so why does it matter if the core developers dump their coins? Do you believe it to really be so fragile that a dozen users could crash the whole thing just by selling their coins?
Have you considered that the real reason there hasn't been a change is that because the people that want it aren't actually in the majority?
Are you actually for real?
This is the current mining pool distribution:
Antpool, which represents 17% is in favor of 2MB, and has threatened to NOT include any Core changes until it happens.
f2Pool, which is 23%, supports 2mb.
BTCC, which is 13%, supports 2MB
BW, which is 12%, supports 8MB!
Huobi, (HaoBTC), is 7%, and also supports 8MB.
Proof for both:
KNCMiner, which is 2%, supports bitcoin classic (2MB hardfork)
Half of slush pool (5% total, so 2.5%) supports classic.
The only major miner that hasn't explicitly supported some sort of block size increase, is I believe Bitfury, which is ~10%.
Now, please add up all of these numbers, and see if it adds up to a majority.
My other points that you skipped over all still stand. If the majority truely wanted change they could do it painlessly. But they don't so the minority that does has to find something to blame besides lack of support so you come up with a ridiculous dream in which a handful of developers are holding everything up.
It's a flaw because users did nothing wrong yet their transaction could take hours if not days to confirm if it confirms at all.
The most simple and straightforward fix is to increase the maximum blocksize from 1MB to something larger, which many users in the space have demanded. The max-blocksize was always meant to deter spam and attacks.
New users should use Bitcoin Classic, which fixes the problem and subverts Blockstream's obstruction.
What are you referring to?
Step 1: Buy off all of the top developers of open-source project. Check.
Step 2: Refuse to support/fix basic network operations so that transactions stop confirming just as the network needs to grow. Check.
Step 3: Create a 2nd-layer solution for growth that allows the company to siphon Billions of dollars over many years. Check.
Step 4: Censor any forum where people alert others about secret get-rich playbook. Check.
We founded the company.
> all of the top developers
A couple people out of a community of around 50-200 depending on the phase of the moon.
> Step 2: Refuse to support/fix basic network operations
Uh. You know that Bitcoin is a decenteralized system that no one controls; right? We do a lot of fixes, but we're not your personal code monkies. There is a LOT going on in Bitcoin, and it's working pretty darn well at the moment.
> Step 4: Censor any forum
Via our magical mind control rays, I suppose? Blockstream doesn't control or influence any forums.
Wheres your playbook? Which step does "Create throwaway accounts on hacker news to slander people" fit? Is it before "profit" or "suppression of inconvenient technology"?
Please provide details on funding. Specifically, how much AXA paid?
"A couple people out of a community of around 50-200 depending on the phase of the moon."
Again a lie. The top Core devs are Blockstream employees.
Blockstream has created a toxic environment and a huge ivory tower.
"Uh. You know that Bitcoin is a decenteralized system that no one controls; right? We do a lot of fixes, but we're not your personal code monkies. There is a LOT going on in Bitcoin, and it's working pretty darn well at the moment."
Meanwhile 80%+ of the hasrate is concentrated in a single country and in the hands of a handful of entities.
Ironically, Blockstream goes graet lengths to exploit this (HK roundtable farce).
"Via our magical mind control rays, I suppose? Blockstream doesn't control or influence any forums."
People associated with BlockstreamCore support censored and manipulated forums, interestingly owned by a single individual (theymos)
Gregory, you are the most pathetic individual in the Bitcoin space.
Dunno, not enough to be broken out on the reports I have. They're not an investor that I've ever met with-- we have a lot of investors. Though it's a cute technique that y'all have been using where you try asking something that would be confidential, to try to inhibit a response on the long list of leading questions that follows.
>> "A couple people out of a community of around 50-200 depending on the phase of the moon."
> Again a lie. The top Core devs are Blockstream employees.
I gave a breakout in another post; if you want to go by top you end up with three out of the top 10, all of whom were founders of the company. wooo.
> Blockstream has created a toxic environment and a huge ivory tower.
What does that even mean? or another way, how could someone falsify that claim?
> Meanwhile 80%+ of the hasrate is concentrated in a single country and in the hands of a handful of entities
Unfortunately, the block size limit was set too large and this created outsized returns for large consolidations. More recent improvements have caught things up a bit but it will take a while for the damage to equalize out.
> People associated with BlockstreamCore support censored and manipulated forums,
What the @#$@ are you talking about? Citations? Or are you just saying that anyone of the vast majority of people who are supportive of our work is "associated"?
Can you clarify this statement?
This isn't a throw-away account. I've lurked for years without needing to become involved. The larger public needs to know that:
> We founded the company.
Obviously you're the CTO but not all of the other 'employees' paid by your company founded it with you.
> You know that Bitcoin is a decentralized system that no one controls; right?
Actually you've locked down the codebase. Any one developer can make a common sense change contentious and prevent it from being merged. That's kinda centralized don't you think? Getting a few people to disagree is a pretty low barrier if a government was bent on destroying Bitcoin. We need decentralized development to match Bitcoin's decentralized nature.
> Bitcoin, and it's working pretty darn well at the moment.
Does that include transactions that don't go through even with correct fees? What do you say to the new user that did nothing wrong and has to wait 3 days for his coins to reappear in his wallet because he tried to send a transaction during a high-volume time? Does that also include overly expensive fees approaching 50cents and could reach several dollars within the year?
Limiting transaction velocity and making transactions artificially expensive is a bad idea at this point in Bitcoin's existence.
You need to stop ignoring that network operations are failing.
> Via our magical mind control rays, I suppose..
No, by calling alternate code bases altcoins - even though they operate on the same blockchain - you have setup an environment where they are not allowed to be honestly discussed at length on /r/bitcoin. Further, even though positive posts are banned, negative posts about other Bitcoin wallet/mining software are allowed. Any outside person can clearly see that is censorship. Moderators point to CoreDevelopers as the reason for that censorship. I also know you know Theymos so you can't say you're not buddies with him. I'm sure if you wanted you could ask for it and have posts removed/deleted.
The "top developers of Bitcoin" you were referring to did.
> Actually you've locked down the codebase.
So, there is a concrete claim of an action. But you're not specific. Locked down how? What are you referring to? Please provide hyperlinks for clarity.
> We need decentralized development
Every developer has their own codebase, the community tends to cooperate because its efficient and makes sense. But participating at all requires making your own fork, and anyone can at any time promote their fork for public use. Some have, but the ones created to rewrite Bitcoin's rules with a hardfork so far have not been supported by engineers and languish largely stillborn.
> Does that include transactions that don't go through even with correct fees?
I'm not aware of any issues like that, can you point me to a trouble ticket?
> Limiting transaction velocity
How have we done that? The design of Bitcoin and physical reality create limits and select trade-offs.
> No, by calling alternate code bases altcoins
> even though they operate on the same blockchain
The people who are calling things like the deceptively named Bitcoin "classic" altcoins do so specifically because when they activate they will not operate on the same blockchain.
> you have setup an environment where they are not allowed to be honestly discussed at length on /r/bitcoin. [...] I'm sure if you wanted you could ask for it
I, nor anyone at my company, have any control over /r/bitcoin's policies, and-- in fact-- I argued vigorously against them (before I saw what the unmoderated feed looked like-- a non-stop stream of brand new sockpuppet accounts promoting rule rewrites, often with dishonest claims, outnumbering all other posts 20:1)...
> I also know you know Theymos
What does that mean? I've had a few conversations with him, yes-- and in the ones where I tried to convince him to not use a fairly restrictive moderation policy in /r/bitcoin I failed.
By the expression "locked down" I mean that no reasonable change can happen if any one of the main core devs don't want it to. Some of the core devs think the max-blocksize is too large. I won't name names, but a modest larger blocksize is reasonable.
Additionally hard-forks are the safest way to make large important changes. They are safer than soft-forks (limbo) and for the blocksize one would be required. I'm sure you know all of this, but the reason for a hard fork was because it's an important and critical change. At one point it was on the core scaling roadmap I believe (or promised by your CEO to Chinese miners in Hong Kong).
> when they activate they will not operate on the same blockchain
Hard-forks have happened twice before and people aren't calling the current version an altcoin of the original Bitcoin. Bitcoin Classic's change has safety mechanisms like a 30 day grace period before activation, it wouldn't disrupt time-locked coins, and it has other checks that prevent attacks on hard to process transactions. It also only changes if there is overwhelming miner consensus well above the regular 51% 'Nakamoto' consensus. Unanimous consensus works for trivial matters but the big stuff, the important stuff should go with a large majority and not be held back by a stubborn minority. Classic also removes the hard-fork if it doesn't happen by a certain date.
> I tried to convince him to not use a fairly restrictive moderation policy in /r/bitcoin I failed.
I'm glad your being vocal about the censorship and expressed your opinion to Theymos. An entire sub of 19,000+ users arose out of those policies. On /r/bitcoin most of the posts are positive white-washed pump the price news rather than genuine discussions. A big genuine thanks for talking to him about it, and I hope you can keep that process moving towards non-censorship.
> stream of brand new sockpuppet accounts
People created new accounts because their main accounts were being banned for talking about the benefits of on-chain scaling. Sure some of those were FUD, but a lot of them were also genuine.
Blockstream will run a Lightning hub and make money off of facilitating transactions before settling them on-chain. Since blockspace is limited they will make (or have made) agreements with miners like BTCC in China - that way they will always be able to settle, but on-chain transactions might get kicked off and be forced to use their centralized system. It's really rather insidious.
Lightning is also not the peer-to-peer solution that the Bitcoin Whitepaper promotes in its abstract. The first few sentences describing the reason for Bitcoin to exist in the first place make peer-to-peer the number one priority.
Bitcoin can't scale in a peer to peer way to handle any real kind of volume. It's kind of the downside of distributed systems is that they suck at scaling and throughput.
I'm guessing you want them to increase the block size to 2mb but what does that get you? 6tps? So we go to 20mb and you're up to 60tps? You can't scale it on chain and get anywhere near the tps needed for it to be globally successful.
So your options are offchain scaling or limiting its uses with fees.
You can find it at https://github.com/lightningnetwork/lnd
Blockstream has no intention of ever monetizing lightning on Bitcoin in any way (nor do I have any idea how we could do so); our interests for it in the case of Bitcoin are only to promote and expand the use of Bitcoin. (We also hope to use it to enable other kinds of asset systems).
I thought it was obvious that the parent poster was being ridiculous, but should've ended the post with :^)
I'll take your word for it that Blockstream will never run a Lightning network hub.
We understand how the Lightning network works and you also have to admit that it has the potential to centralize into a few large hubs -- even if they aren't by Blockstream -- that will be able to provide the lowest transaction costs in order to keep track of user transaction data.
The problem with Lightning is that it's really far off, and it might not even work.
Meanwhile the network is breaking at the edges while we wait for this pie-in-the-sky solution. Increasing the blocksize is the best approach and it's safe to do as a hard-fork. The delay and push back from CoreDevs is what makes people not trust you. We've had enough "my transaction didn't confirm" posts.
(I work for Blockstream, and I am also trying to implement and standardize lightning. But we certainly didn't invent it, and this isn't our page)
Maybe you're just really funny and they are paying you for your incredible sense of humor.
Rusty Russell has done a lot of great work on Linux (the TCP stack in particular) and you've probably used some of his work. For all I know, Russell might be deluded and Blockstream might be an evil brain-washing machine, but if Russell was in it for the money he could or would just as easily have done that 10 years ago rather than today.
I'm sure he is a nice guy and maybe he's even funny.
Blockstream does need to recoup the 70 million in funding they've received though and it's a fact that they have most of BitcoinCore's top contributing developers on their payroll, with exception to Wladimir.
Clearly I'm not the only one concerned about a conflict of interest and I'm sure it's hard to see conflicts of interest if you're the one at the center of it.
One last edit, aside from a grammar correction: authority deserves scrutiny.
Blockstream does support Bitcoin infrastructure development-- something much of the Bitcoin industry has failed to do, perhaps a company you work for and are concealing through your anonymous posts?-- but that is a far cry from a "majority" by any definition. E.g. in the last 3 months 58 people have made contributions to Bitcoin Core, 7 work for Blockstream. Sorted by commits in the last year, among the top ten, 3 work for blockstream (all founders of the company). -- just as we've done for the last 5+ years (the same group has been in the top 10 contributors pretty much the whole time).
Whats your actual allegation beyond pointing out that we spend some resources supporting the public infrastructure we all depend on?
I'm a software consultant for my own developing firm. I don't have a conflict of interest. As I've said before, this is a new account and my only account here. I've read HN for some 5-7 years now as a morning news source and have not gotten involved in the conversation until this point.
To the issue:
MIT would probably be happy to support more Core developers and that would definitely lessen the current conflict of interest.
Is it hard to see that one company paying most of the top developers in the accepted codebase is something that makes people uneasy? It does and the considerable pushback from modest on-chain scaling (which needs to happen eventually anyway) has people worried that you're (Blockstream) is trying to control or limit Bitcoin due to your funding from AXA.
MIT doesn't support _any_ developers. MIT DCI pays MIT and is funded by undisclosed parties, but you never even care to ask about that. (And not that MIT is magically benevolent, in any case...)
We've tried for _years_ to get sustainable funding for development; but the Bitcoin 'industry' is just not interested.
> paying most of the top developers
Why do you keep repeating this misinformation? As I pointed out, e.g. three of the top ten by commit activity work for blockstream (and all of us were founders of the company). This is not most.
> has people worried
Has pseudonomyous sock accounts on the Internet who appear to own not much (to zero) Bitcoins; worried, at least.
> modest on-chain scaling (which needs to happen eventually anyway)
I think all the engineers at blockstream that work on Bitcoin supported segwit which roughly doubles block transaction capacity. (in a backwards compatible while improving scalability, to keep the operating costs low).
> due to your funding from AXA
Pretty perplexing, AXA isn't even to be broken out in the reports I have (we have many investors). I've never even had a conversation with anyone from AXA myself.
> you never even care to ask about that
Honestly, I don't know where that would be public information to know to ask about it.
> to own not much (to zero) Bitcoins;
That is not the case. Most people who have been very vocal pushing for larger blocks have significant Bitcoin investments.
> segwit which roughly doubles block transaction capacity
This only happens if all wallets adopt it, which makes them write/fix their wallet software upstream. That takes time. It's not a quick enough solution for an urgent problem.
Last, if you're taking money from someone there is a conflict of interest there.
"It's hard to get a man to understand something if his job depends on him not understanding it" - Upton Sinclair
Large investors usually want something back for their investments. Maybe you don't know what that is right now, but it's legitimate for regular users to be weary of it.
They aren't. The Digital Currency Inititive (DCI) != MIT. Rather, it's a separate entity that's effectively paying MIT for use of the MIT name and administrative infrastructure; we do not know who is actually funding DCI.
"Together, we’ve raised $900,000. Donors include companies (BitFury, Bitmain, Chain, Circle and Nasdaq) and individuals (Jim Breyer, Jim Pallotta, Jeff Tarrant, Reid Hoffman and Fred Wilson)...while the funds will be limited to support Bitcoin protocol development, the donors do not have any influence over the developers."
That said, I believe that list is incomplete.
It's clearly part of MIT's infrastructure. What you're saying is that the money is not coming directly from MIT.
Some claim it, but like that guy pretending to be Bitcoin's creator. They fail to prove it. People opposing politically adjusting Bitcoin rules have proved that they own Bitcoin. http://bitcoinocracy.com/arguments/if-non-core-hard-fork-win...
> That takes time. It's not a quick enough solution for an urgent problem.
Wallets have already had half a year to catch up already, and you say it's urgent. You think a completely incompatible, forced, and highly controversial change that virtually all the engineers working on the system say is very risky would be faster? Besides, a few large producers of transactions upgrading would make room for others.
If we could vote in some other way to prove our funds outside of this site I will be glad to take part.
Here he is advocating for increasing the blocksize limit to 8MB as soon as possible: https://bitcointalk.org/index.php?topic=1238605.msg12897706#...
And here's his post announcing the launch of the service: https://bitcointalk.org/index.php?topic=1133634
The site allows anyone to propose statements which all Bitcoin holders can then support or oppose by signing messages with their coins. The anti-small-block question wasn't written by the site owner, but is currently the most supported statement on the site.
BlockstreamCore shills can do nothing else.
Its over engineered and over complex. Which is demonstrated by the comments here trying to explain how it works.
No one has yet been able to explain how they will prevent one central hub from developing which by economies of scale will offer the lowest cost path through the network as it will have channels setup with everyone.
Ask yourself who will operate this hub and you'll understand why people want to implement this.
Blockstream is a corrupt company which does not refrain from spreading lies and propaganda to further their agenda.
Everyone is free to look up what entities own them.
Free transactions right now have essentially zero chance of going through, so it makes sense that they're removing it, since it would prevent users from creating transactions that will never confirm. I'm not disputing satoshi's point, but given the current network conditions, the change makes sense.
(Or do they only do that when they personally lose out?)
In addition to what I described above, there are more open questions, ranging from the best network topology to the different patterns of interactions and how they can be optimized. I'm becoming convinced that the best approach would not only allow for one paradigm, but for a range of protocols with different properties (e.g. that work in offline environments) - logical decentralisation. Any kind of maximalism for a single currency and network instance isn't applicable to this.