Bitcoin Forum
May 23, 2024, 10:34:02 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 [80] 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 ... 288 »
1581  Bitcoin / Bitcoin Discussion / Re: Why Peter Rs Fee Market Wont Work on: February 01, 2016, 03:58:39 AM
In regards to your comment about using pre-consensus techniques to completely eliminating block-size dependent orphaning risk, you were wrong about that too, as I demonstrated in the subchain paper.
Your work is not a non-existence proof, it's an analysis of a specific scheme. You made the same error in reasoning in your prior orphaning work, where you erroneously concluded that orphaning was proportional to the size of the block-- this later work implicitly admits the error by saying it is proportional not to size but to the rate of additions, but does not go far enough.

You proposed a needlessly deficient design, one which was inferior to what I'd already described to you, due to having the flaw of increasing orphaning risk to add new transactions.

This flaw can be simply (and compatibility with your design!) corrected by miners: in your scheme miners add transactions by adding them to a block attempt, thus taking orphaning risk.  Instead, miners could add transactions by first adding then to a separate hash tree, committed to by the block whos data is only shared with weak blocks, not full block solutions.  Only when a transaction is well and buried in this second tree, do miners then add it to their blocks.  Avoiding the orphaning risk resulting from doing so.

Not only can miners do this this mitigate the orphaning from the new addition, but you cannot prevent them from doing so.
1582  Bitcoin / Bitcoin Discussion / Re: Finally, Bitcoin Core = REKT on: January 31, 2016, 11:28:48 AM
which got basicaly monopolized by BlockStream and Bitcoin
Can you explain this for me?  Bitcoin Core is a project with dozens of people. One of the main developers of Bitcoin Core is a founder of Blockstream. And this is "monopolized"? Please, help me understand what you're thinking here.

Meanwhile, the developers of other implementations just don't bother to tell you about their business partnerships at all. Makes me sick.
1583  Bitcoin / Bitcoin Discussion / Re: What is a team and is what not a team. on: January 30, 2016, 06:16:41 AM
None of us have to take funding from anywhere in particular. Do you have any idea what experienced people in the domains we are knowledgeable in can get paid-- even entirely outside of the Bitcoin space?  Often more than attorneys.

Where we choose to work is a matter of optimizing our time and interests. We have the incredible fortune that none of us are forced to compromise our principles to put bread on the table.

It's true that the employment situation for many around the world isn't amazing, but right now (and for the last decade at least) any concern for systems programing, cryptography, network programing, security, etc. is misplaced.

I have spent two days unemployed, a weekend, in the last 21 years.
1584  Bitcoin / Bitcoin Discussion / Re: I "Think" that I found Satoshi Nakamoto on: January 30, 2016, 06:10:31 AM
paper submitted to International Association for Cryptography Research (IACR)
This paper is completely unrelated to bitcoin other than using the word's digital cash. It it is typical for contemporary digital cash papers.
1585  Bitcoin / Bitcoin Discussion / Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal! on: January 30, 2016, 01:23:47 AM
So many critics! Hey, Gavin's trying to help!
So were the doctors who performed frontal lobotomies on unruly children.

The Bitcoin market price doesn't seem to think much of his help.
1586  Bitcoin / Bitcoin Discussion / Re: Analysis and list of top big blocks shills (XT #REKT ignorers) on: January 29, 2016, 10:59:29 AM
The Toomininstas are confronting the same problem the Gavinistas did, which is that multiplying a tiny number such as 3tps by another tiny (ie sane) number such as 2 or 4 or even 8 still only produces another tiny number such as 6tps or 12tps or 24tps.

You can't get to Visa tps from here.  Our only realistic path to Visa is orthogonal scaling, where each tx does the maximum economic work possible.
Right, card payments are currently at around 5000 TPS on a _year round_ average basis, with highest day peaks probably at over 100k TPS. And that is now, these figures have been rapidly growing.

These are numbers high enough that just signature processing would completely crush even high end commercially available single systems.  Even if you took some really great drugs and believed plain-old-bitcoin could get anywhere near matching that in the near future while having any decentralization remaining.... so what? it wouldn't be close again after just a couple more years growth.

This sounds like a MBA school failure example: Ignoring your strengths and trying to match one on one with a competitor in an area where you're weakest and the slowest to improve and they're strongest and the fastest to improve.  Especially since considering payment networks as the primary competition for a _currency_ is a bit bizarre. Yet a payment network is all that some have wanted Bitcoin to be... I don't begrudge that, but the weirdness of the goal doesn't relieve it from having to have a logically consistent roadmap, or permit it to take down the whole currency in its failure.

A trip to the moon requires a rocket with multiple stages or otherwise the rocket equation will eat your lunch... packing everyone in clown-car style into a trebuchet and hoping for success is right out.
1587  Bitcoin / Bitcoin Discussion / Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal! on: January 29, 2016, 06:37:49 AM
Just some spit-balling here, I'm sure I have some ordering and details wrong.


Mike and Gavin argue for no limits and ~free transactions forever, regardless of the costs.

Some in core suggest that if we really need to show the flexibility of a blocksize increase, 2MB could probably be sold and made safe enough (with planned future improvements) if we really had to.

Gavin gets some clue and realizes no limit at all makes no sense; Mike grudgingly agrees to go along with a 20MB proposal.

Miners reject that as unrealistically large.

Gavin and Mike retrench with a 8MB that rapidly ramps to gigabytes. Announce intent to adversarial fork the network in Bitcoin XT. A new client which is 99.99% code from Core but with the addition of the new expanded blocksize and Mike hearn declared benevolent dictator of the project.

In spite of announced intentions by some, almost no one adopts Bitcoin XT and XT development sits at a near standstill compared to Core.

Miners' notice the 8MB change isn't really 8MB and some aren't pleased.

Systems testing is finally performed on XT via testnet a month before it was intended to activate. Many performance problems are found with 8MB, person testing it suggests that 4MB or 3MB initially may be more realistic.

Core completes a years long development work which speeds signature validation >5x, invents a clean way to allow new efficiencies and security trade-offs, gets node pruning working, and comes up with a way to get roughly 2MB worth of capacity without a the risky and coordination problematic hardfork, while simultaneously fixing some long time bugs like malleability and misaligned incentives (utxo bloat).

Core posts a capacity roadmap including these solutions, along with a plan for further development to allow more capacity into the future.

Almost the entire development community and many in industry sign on an open letter in support of this plan. On the order of fifty people in all, it includes all of the most active contributors to Bitcoin Core and many other pieces of Bitcoin software.

Gavin, Jeff, and a few other people (including people involved with the recently insolvent Crypsy exchange) announce that they're creating "Bitcoin Classic"; a retry of the XT approach but with added popular voting on a centralized web voting site.

Mike Hearn catches fire, slams Bitcoin with a one-sided attack piece piece in the NYT calling Bitcoin a failure. Some argue that Mike's position is driven by his employment at R3, an adversarial to Bitcoin company working with major banks. Astute followers know this isn't true: Mike's misalignment with Bitcoin has existed forever.

Bitcoin market price crashes significantly.

Core creates a public test network for the new improvements and many people are actively testing on it. Several wallets begin their integration process for the new improvements. Development moves rapidly, several standards documents are written.

Market price substantially recovers.

Gavin finally announces code for the new "Classic", largely duplicating the XT functionality. Instead of the BIP101 rapid growth scheme, it features a 2MB hardfork, and none of the other improvements that are recently in core and in the works.

Bitcoin market price drops significantly again.

I'm hoping we get to the point where the market realizes it's being toyed with here and repeated XT reloaded attempts are pretty meaningless. We're not seemingly there yet.

Have I basically summarized the last year? Anyone want to add any bullets?
1588  Bitcoin / Bitcoin Discussion / Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal! on: January 29, 2016, 01:55:18 AM
not so against any kind of increase in the max block size
The Bitcoin Core capacity roadmap includes several block size increases, including the immediate term segwit proposal that many people are actively working on (and which has a testnet)-- which increases the capacity to fairly close to Gavin's latest proposal (which is not BIP 102).
1589  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: January 28, 2016, 11:38:45 AM
That is why miners should be depending on full nodes for their relaying
needs, so it will be the nodes whose mempools matter.
That isn't how the system works, and it's not possible to make it work that way.

You can implement whatever rules you want; but miners don't care, they'll receive transactions around you. Even if every other node implemented some mempool policy; miners can just set up their own and people would send transactions directly to it.


Quote
Which leads to a question, why isn't Corallo's fast relay protocol in Bitcoin Core?
Because it has been under constant, rapid development. It's also only of limited interest to non-miners. I recommend adding it to contrib a while back, but the pace of development precluded it. Perhaps now that it's pretty mature he'll change his mind.
1590  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: January 28, 2016, 11:21:47 AM
there is a balance (or conflict) of power

Yes, but it does not play out equally in all respects: When it comes to mempool policy, miners have almost absolute power; no one else has almost any influence except via highly inefficient mechanisms like selling our coins and adopting a new cryptocurrency or hardforking the POW to fire the set of miners. The remedies are so costly that non-miners are basically deprived a voice, at least in any strong sense, on things related to mempool policy.  Even a single moderate size miner has huge influence on mempool policy behavior, the action of a majority of miners isn't required.

When it comes to hardforking system rules, this balance is reversed. For those, a miner's opinion has almost no weight. A miner can only impose opinion there by stopping mining (if a miner produces a rule violating block, it's ignored as if it never happened). For that the users matter; and hopefully the users are prudent enough to understand that if they collectively act to harm a minority of users, they undermine the value argument for the system (... after all, why not you next?). (And perhaps developers matter a little there, since you need at least some people who are willing and able to develop to write the rules and maintain the system).

And this is all part of the intentional balance of power in the system. In an ideal world, Bitcoin would have no miners-- no even slight point of trust at all, just a purely flat p2p system. This isn't possible in the real world, so Bitcoin uses miners to determine the ordering of transactions but carefully confines them to control only the ordering; which is already very powerful-- it's what creates that near absolute control over mempool policy. That this point of trust is tightly confined.

Of course, many people wear multiple hats:  I am own Bitcoins, I develop the Bitcoin protocol and applications, I mine Bitcoin, I help run a Bitcoin related business, I advocate Bitcoin to others, and I also use Bitcoin casually.-- and some authority someone lacks under one hat they may have under another.
1591  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: January 28, 2016, 10:53:34 AM
In terms of revenue, you've mentioned private side chains, I assume either by subscription or fee? Some would infer that a somewhat expensive and crowded main chain environment might incubate such services, for transactions generally, not just those seeking confidentiality. Why are they wrong?

Gregory, I'm not trying to diminish the work you've done, which is much more than I will ever do. Some people just have some questions, and I sincerely appreciate your responses.
And by support and development contract.  Private sidechains can offer functionality that a global decentralized system cannot directly for fundamental reasons-- e.g. instantaneous transactions, not just thing they don't offer yet (like CT or smarter smart contracts); they're just a different trade-off.  

Regardless of what you think of crowding-- an increase in the blocksize does not guarantee its avoidance, as miners are free to impose further restrictions; and a single person with a while loop could produce unbounded amounts of 'load'. Even if I don't expect them to do so, or at least not often, they can and that's always a risk at any (plausible) size.

The kinds of block size increase that even people aggressively in factor of block size increases believe might be viable in the Bitcoin network are fairly modest, e.g. classic and "2 MB", which, as mentioned is pretty close to the proposed segwit capacity.  By contrast, a private system used between businesses, could run arbitrarily large assuming all its participants were willing and able to invest in the cluster computers and expensive bandwidth required at _every_ node. Oh the benefits of not being a permission-less decentralized system.  The space of possible systems which don't require the other benefits of a private system, don't require the benefits of a decentralized public system, and would not work in bitcoin now but would with the kind of realistically small blocksize increase, and would choose to do so.. is pretty narrow-- and isn't something that we've ever considered in business discussions.  More philosophically, the bitcoin blockchain is a precious global shared public resource with huge externalized costs that fall to all future users; it's good stewardship to not cram things that don't need to be in it, into it regardless of what the limits are.

For added color: I've never heard a prospective customer say something like "X TPS won't work but 8*x TPS will work"; they do say things like "X TPS works now, but we might need 100000*X TPS on short notice, can we have that with absolute confidence if we're willing to pour money at it?"  And that latter question can never be true when your only mechanism is dumping all your data into a in a worldwide _shared_ decentralized flooding system run by third parties whos costs you don't pay. So if then also we also avoid huge businesses setting themselves up for failure with the expectation of the 100000 fold increase peak loads that the system couldn't possibly take without a decentralization killing blocksize-bailout, I think that is good too.

But also, hold up a minute. I think we're both playing along with Mike Hearn's claim that it's all _me_ saying, or the techies (or blockstream) alone, saying that HF's are dangerous in principle  and/or that block-size matters. It's not (go check out those bitcoinocracy links-- or Jon Matonis, for an example)... and it's also not our choice (except as people who own Bitcoin, and in our individual capacity to decide what efforts we'll volunteer time on). I get targeted because I've stepped up and drawn fire so that other people can get some work done.

I'm sorry for taking things so off-topic here. This is a tangent, and I wouldn't have gone down it. But people from Bitcoin Core who were on a phone call with some Chinese miners last week told me that some of these claims about Blockstream came up multiple times.  Even if it took a "happily biased" poster here to call them out, I think some people were thinking about them and I think it's better to have addressed them head on. I hope we can talk some about actual business needs in later posts.
1592  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: January 28, 2016, 10:29:21 AM
that is equivalent to saying that the user community is just plain stupid
I think that's a naive perspective. Consider, Peter_R was making news some time back circulating an academic style paper arguing that a fee market exists absent any blocksize limit. But his analysis depends deeply on there being continued inflation, and does not work without it.  If we drive the system into a state where the choice is to take a _bit_ of inflation or else suffer a debilitating loss of security the answer will be obvious, and it doesn't require anyone being stupid. Avoiding that kind of trap requires constant vigilance and foresight to avoid creating that trap in the first place.

This is doubly true given that many of the arguments are fully general: People argue that somehow without mechenisms in the system miners will collectively self-regulate and behave in a way that achieves a globally good outcome, absent security assumption breaking collusion or coercive force, even when it's in their individual best interest to defect; because they want Bitcoin to be valuable. This could just as well be applied to them controlling inflation; and people keep making it even though that kind of strongly trusting long term benevolence against short term interests already been disproved by finney attacks, withholding and dos attacks on pools by each other, voluntarily centralization in response to orphaning, and many other effects which the system survives precisely because it doesn't trust miners and is instead built out of rules that limit the amount of harm that mistakes or greed can cause, without requiring an external collusion which could easily be abused (including via violent threat) to censor transactions or perform other harmful acts.

I don't think users are stupid. I think governance is incredibly hard and that the development history of fiat currencies shows that mankind is ill-equip to create a strong and sound system via human governance-- not through lack of trying, but because mankind is fundamentally not cut out for it: there is always some excuse that makes people feel justified in compromising the property rights of some for the benefit of (potentially many) others. Bitcoin was specifically created and promoted to replace that kind of subjectivity with machines, but it can't do it if we go around undermining it.  ... Does that mean I think Bitcoin can never be hardforked? Absolutely not! Some kinds of hardforks would be completely uncontroversial; it's the ones that have earnest opposition from real owners of Bitcoin that such great care needs to be taken with.

[Also-- witness Bitcoin Classic arguing that it's proper to put the 21m cap up to a popular vote. I think that is reprehensible. A simple majority shouldn't just be able to vote to undermine the property rights of a minority, even if there a strongly fair global voting mechanism were possible.

]

Even if you don't buy my argument that the risk is real; the argument that Bitcoin could easily have its rules changed is FUD that our competition would ruthlessly exploit. After all, this is an earnest concern held by many of the longest term and most experienced among us... it would be an easy sell to someone looking for "the catch".

1593  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: January 28, 2016, 09:57:33 AM
How does Blockstream plan on ensuring an ROI for its investors? I understand there is some time-locked bitcoin involved... but this is a business, right?
Sure, discussed at some length in posts here: https://www.reddit.com/r/IAmA/comments/2k3u97/we_are_bitcoin_sidechain_paper_authors_adam_back/clhn1hl

If you look out there, there are major technical problems in using Bitcoin and applying Bitcoin-like technology to broader industry-- for an example that couldn't be included in the above write-up, though it's surprising to many the #1 cited complain is the lack of commercial privacy in Bitcoin: No one wants their competitors tracking their books, or their customers criticizing their margins. So, Adam Back and I went out and created confidential transactions; which specifically solved that (currently for private sidechains, but hopefully someday its successors will be available in Bitcoin proper).  Who else is going to do that kind of original powerful work?  If you don't see the business case for solving the hardest problems in this space, and or enabling the reach of Bitcoin more broadly, then you may be underestimating how powerful and world changing cryptocurrency can be. Fortunately, our investors aren't. And _ensuring_? There are no guarantees in investment.

But even ignoring all that... lets just assume for a moment that Blockstream is really malevolent, and that the protections we built into it (described on that Reddit thread) all failed. What then? We're just a part of Bitcoin Core; and the message I'm giving you is also held by the vast majority of the non-blockstream contributors. I applaud paranoia, but it wouldn't make sense to dismiss the work of the hardest working independent people in the space because of an unsubstantiated maybe about a generous contributor they have collaborated with. If you're going to go down that route, you'll find yourself jumping at every shadow. After all, blockstream could have been kept completely secret-- why would you assume someone really out to serve a private interest wouldn't do so.  It is, sadly, not unheard of for people working on Bitcoin to fail to disclose their affiliations. Ironic that some would attack those who disclose them without asking any questions of the rest.
1594  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: January 28, 2016, 09:09:48 AM
Hi Eric,

You might want to meditate some on this post: https://bitcointalk.org/dec/p1.html

Bitcoin was created to be a system of money that depended on cryptography and mathematical proof instead of strong trust; removing systemic political risk and providing monetary sovereignty to it users. Bitcoin is simple in implementation, but complex in implications-- it carefully balances economic incentives and clever algorithms. As typical for cryptosystems, the details matter greatly: Many people have failed to understand the careful balances in the system, and many an altcoin that twiddled with the parameters in seemingly innocuous ways found their system unworkable or insecure in practice.

Capacity is an important criteria for the Bitcoin system; but is one that is sometimes in competition with security, censorship resistance, and the other properties which are critical to Bitcoin having value compared to traditional financial instruments.  I believe that with care we can navigate these compromises and with intelligent technology we can reduce the conflict-- just as Bitcoin does. We must be humble about the emergent properties of a system which no person understands completely, and be careful to do no harm. There are many ways to achieve capacity, and the fine details of them matter greatly from an engineering perspective; but if implemented well-- are irrelevant to the end user.

Some people, like Mike Hearn and Gavin have pitched a future where Bitcoin runs exclusively out of large datacenters and its users are left depending on the trustworthiness of a small number of organizations scattered around the world. They've suggested a world where security is provided by unspecified mechanism or donations instead of fair market forces, or where proof of work only acted as a bootstrap.  I don't share that view, nor does Bitcoin Core in general: We don't believe the world sees or will see value in recreating a centralized payment processing network like Paypal, except with less efficient technology... I don't think Bitcoin's value as a trust-reduced personally autonomous global currency are just a sales pitch, I believe we can deliver on them now and into the future... and that if we give up on these values, even if we enjoy short term benefits like unlimited capacity, that kind of Bitcoin would fade away because it wasn't providing something the world needed that it didn't already have.

The seeds of achieving truly great capacity without compromising the differentiating values of Bitcoin, our removing our arguments for security without collusion in the long term were sewn in the very first versions of the software-- support for payment channels are just one example. Though this work is still maturing.

Bitcoin Core has adopted a capacity roadmap that increases the direct capacity some, while also applying risk mitigation in the forms of allowing new more secure lite client modes, improved relay performance, and other optimizations-- and does so in a way that is compatible and which doesn't require immediate cooperation from all the participants.  "Classic" (in quotes, because I believe the name is deceptive and insults all of our intelligence) proposes similar capacity but without the safe-guards, by a hard rewrite of the system's rules.

I think incredible care must be made when rewriting the rules like that: The rules _are_ Bitcoin. The stability of Bitcoin's rules _is_ the soundness of the currency. If the rules can be easily rewritten against the will of some users by others according to political whim then what can be trusted? Is the supply fixed? Will coins be confiscated and awarded to others? If that gate is crossed then there is almost always some excuses which is "good enough"-- as was lamented in some of Bitcoin's earliest announcements.  And these changes are controversial -- see, for example, the millions of dollars of Bitcoins backing opposition to things like BIP101 and supporting core over classic. I don't believe that Core has the power to make changes prohibited by the rules of the system while they are opposed by an economically significant portion of Bitcoin's users. If it does, by way of inertia or lazyness, have that power I don't believe it has the moral authority: to rewrite the system out from under people risks walking the thin line of theft.  And if the system could really be so easily rewritten against controversy: it may bring into question Bitcoin's ability to uphold any of its properties. This is a dangerous road that should be avoided whenever possible.

I certainly hope it doesn't come to that, and I believe it won't: With the planned improvements we can gain capacity without the controversy; and preserve harmony as the essay I initially linked to discusses. We should be able to satisfy all users and uses of the Bitcoin currency; and we must if we are to achieve the full potential of the system.

As far as classic itself goes. I must admit having a difficult time taking the question seriously.  The active technical minds in this space, dozens of people, almost unanimously agree with Core's approach.  Similar to XT, perhaps arguably worse off--, classic is not currently supported by a vibrant team of experienced and able parties. In spite of much posturing and language, they've failed to even deliver on the most basic software development work, and once they do I am doubtful that they'll be able to continue maintaining it. If this development is happening now, it doesn't appear to be in the open and subject to extensive peer review. This is no coincidence: most people who understand the technology deeply overwhelmingly agree with Core's approach. Perhaps it will get its act together in a way that XT didn't, but that hasn't happened yet. It's a little alarming to me to hear some reputable parties backing something with so little delivered substance, and I'm somewhat concerned that it's setting up the industry for further embarrassment (beyond the small amounts classic related embarrassment suffered so far), perhaps even worse than caused by XT and Mike Hearn.

I feel I shouldn't need to go into this-- But I know it's being said I feel I should confront it head on: Some of the advocates of Classic claim that Bitcoin Core is somehow controlled by my company, and that we somehow hope to profit from stifling Bitcoin. I believe they do this because it's a cheap attack, easily believed because most do not have the time or energy to follow the details of the activity in core-- similarly they draw an equivalence between the technical people who've signed on and those involved in the core project. To an insider these comparisons are laughable, but I am aware these claims have cause concern. Everyone at Blockstream has a significant financial interest in preserving Bitcoin's value (time locked bitcoins are part of our compensation, and most of us owned personally significant amounts of Bitcoins prior to blockstream). The fact is that my company was created by some of the most active developers of the Bitcoin system as a way to provide sustainable funding for that development-- something few to no companies in the industry were doing so; but even so it's just a rough half dozen voices out of dozens-- and you can happily talk to non-blockstream Bitcoin developers like Cory Fields, Wladimir, Alex Morcos, or Eric Lombrozo-- or outside-of-bitcoin technology experts like Bram Cohen (inventor of Bittorrent) or Nick Szabo-- and get much of the same message you're getting from me. The understanding that there is a fundamental capacity/security trade-off is not a new one though we're constantly learning new implications of all aspects of the system, scaling included. I think that the work we've done inside and outside Bitcoin speaks for itself, but if that's not enough-- talk to the other contributors and compare notes.  I don't know of a better way to answer the conspiracy theories than that.

I hope this has provided some useful food for thought-- but really, what I think is missing is your thoughts. What requirements do you feel aren't being met by Core that would leave you asking such a question? (I could guess, but communication is much better than guessing.)
1595  Bitcoin / Bitcoin Discussion / Re: "Bitcoin classic", brought up by literal crooks on: January 28, 2016, 06:36:11 AM
People who make bad judgements tend to make bad judgements in many areas. It doesn't have to be more diabolical than that.
1596  Bitcoin / Bitcoin Discussion / Re: "Bitcoin classic", brought up by literal crooks on: January 28, 2016, 05:58:06 AM
Classic has been losing reliability and credibility, as to my knowledge, the development has been quite stagnant
There may be more development in secret. Rather than having public activity on github they seem to have mostly done code dumps with their initial patches. It certainly seems more dead than even XT did.
1597  Bitcoin / Development & Technical Discussion / Re: Why soft fork is a very bad idea and should be avoided at all costs on: January 28, 2016, 01:09:26 AM
I'm sorry you disagree with the primary process by which the Bitcoin system evolves which has been used since the very beginning.

Perhaps you should take this to the altcoin subforum. No one is going to buy into the suicide pact Hearn and you seem to wish for-- and even if they did, they can't enforce it: soft forks can't be prevented.
1598  Bitcoin / Bitcoin Discussion / Re: Analysis and list of top big blocks shills (XT #REKT ignorers) on: January 27, 2016, 11:29:28 PM
You don't understand how Lightning works then; the transactions are on-chain, but the settlement is still only per block.

I've found that directing people to the description of transaction cut-through has helped open their eyes to the fact that transactions can use the blockchain without every one of them being stuffed into it.

Could you imagine a country designed by block maximalists? Every trade, agreement, and contract would have to be held before the highest court!

"How can business be possible with only 125 cases per year?  We must scale the court!"
1599  Bitcoin / Bitcoin Discussion / Re: Part 3 – Much more on why clues suggest Peter Todd is probably Satoshi on: January 27, 2016, 12:24:26 PM
Doubt it.His view on block size debate is pretty different than
your own fevered imagination, you mean.

on this subject; the topic is boring. It doesn't matter who Bitcoin's creator is... the design of the system was intended to eliminate third party trust; give it some respect by respecting it's creator's desire for privacy.
1600  Bitcoin / Bitcoin Technical Support / Re: Raspberry Pi 2 Node on: January 27, 2016, 10:55:10 AM
You would need a 128GB SD card now. The performance will be very poor, it's just on the margin of workable.  SD cards usually don't have good write endurance either.
Pages: « 1 ... 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 [80] 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 ... 288 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!