What is XBT and how it relates to Bitcoin? Difference ...

Threat modelling

There is a discussion on the Bitcoin XT mailing list about threat modelling.
A threat model is a way to figure out which attacks you care about, which you don't, and then prioritise the ones that matter. If you aren't familiar with threat modelling and would like more background, please read the linked email.
I figured I'd raise the visibility of this discussion as a way to get more opinions. Feedback welcome.
submitted by mike_hearn to bitcoinxt [link] [comments]

Purportedly Satoshi posts to [bitcoin-dev] mailing list chastising effort to fork Bitcoin with Bitcoin XT.

submitted by DINKDINK to Bitcoin [link] [comments]

Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork) | Jorge Timón | Aug 19 2015

Jorge Timón on Aug 19 2015:
On Wed, Aug 19, 2015 at 10:25 AM, Btc Drak via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
I see no problem with Satoshi returning to participate in peer review.
Bitcoin development has long since migrated from a single authority figure
to a system of technical peer review consensus. What is more of a problem is
this list has degenerated to a generalised discussion forum where any
academic or technical debate is drowned out by noise.
I joined this list so I keep be abreast of bitcoin's technical development
and proposals. I am sure many ecosystem stakeholders and participants also
once used this list to keep abreast of technical developments and academic
research. It would be splendid indeed if we could return to some semblance
of decorum that once existed.
Do you think we could have a "bitcoin-discuss" list where specifically
non-technical discussion can happen leaving this list for more academic and
technical debate together with setting a clear mandate about what is on
topic for this list?
Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
But technical people run away from noise while non-technical people
chase them wherever their voices sounds more loud.
One thing that I would like though, is separating Bitcoin
Core-specific development from general bips and consensus discussions.
I know, the bitcoin-consensus mailing list will probably still be
noisy, but at least we will have a non-noisy one and the ability to
say things like "Bitcoin Core's default policy is off-topic in
bitcoin-consensus" in the noisy one...
Also developers of alternative implementations may not be interested
in Bitcoin Core-specific things, so they may want to subscribe to
bitcoin-consensus and unsubscribe from bitcoin-dev.
I already told this to some people and everybody seemed to be positive
about this change, at most sometimes skeptics about the potential
benefits.
Thoughts?
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010400.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork) | Jorge Timn | Aug 19 2015 /r/bitcoin_devlist

Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork) | Jorge Timn | Aug 19 2015 /bitcoin_devlist submitted by BitcoinAllBot to BitcoinAll [link] [comments]

Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork) | Jorge Timón | Aug 19 2015

Separated bitcoin-consensus mailing list (was Re: Bitcoin XT Fork) | Jorge Timón | Aug 19 2015 submitted by coincrazyy to BitcoinAll [link] [comments]

It's important news.

It's important news.

https://preview.redd.it/k1hqsk17q4x41.jpg?width=1386&format=pjpg&auto=webp&s=1c1cf2c7357ae4f439704c3e516781472e4c722d
It's important news. The largest operator of sports betting stops servicing users in the Russian Federation. Today Betfair betting exchange has made an official mailing list about the lack of possibility to register users in Russia. The world market share in the Russian Federation in the game industry is 5.127%. Si14 Bet is in the process of applying for membership in SRO and obtaining the necessary licenses. Follow our news and stay up to date with the latest events in the world of gambling. https://si14bet.io #si14 #betfair #bet365 #Si14Bet #oods #livebetting #soccerbetting #bettingtip #soccerbetting #bookies #bettingexchange #bookies #bettingexchange #livebetting #oods #rich #bookmaker #sportsgambling #rich #bookmaker #sportsgambling #millionaire #billionaire #makemoney #moneyonline #bettingexchang #bettingexperts #onlinesport #onlinesport #casino #gambling #investment #sportsbetting #million #luxurylife #bet #bettingsports #cash #sport #betting #bet #onlinebetting #bettingonline #bettingfootball #burnmagazine #ieo #investing #money #burnmagazine #luxury #everydayeverywhere #golang #ico #bitcoin #bettingonline #bettingfootball #bettingtip
submitted by Si14Bet to u/Si14Bet [link] [comments]

There should be only one feature added in the November fork: BIP135 - Miner voting for consensus-level changes

It's become clear in the recent weeks that the uncertainty of who supports what creates an unbearable amount of back and forth bickering, unnecessary drama, division in the community and most of all distracts to too high of a degree from the main goal: to make Bitcoin (BCH) the best money it can be - the constant bickering about what features to include or not to include overshadows almost completely all the great dev ideas about how to improve BCH (and reasonable criticism of said ideas on an individual basis).
And as Peter Rizun (BU) pointed out, it results in top-down take-it-or-leave-it "bundles" which is a worrying practice. Specific proposals should be evaluated and eventually implemented on a one-by-one basis based on miner support
This is what BIP135 does, it allows miners to vote for individual proposals, defines a threshold for lock-in and a grace period before the change is actually activated (this could be left predictable every 6mo as is now).
I believe this BIP should be implemented across all clients to facilitate this process of activating features a super-majority of miners support, BU and XT already implemented it:
"Bitcoin XT and Bitcoin Unlimited are aligned in the belief that consensus-level changes should be activated only after ratification by the miners. 'Take-it-or-leave-it' bundles, and hard-fork deadlines, are adding unnecessary stress and politicking." - Peter Rizun
ABC's Amaury is so far against this idea, he provided this reasoning for that:
I can answer that one directly. Because nakamoto consensus is better. Let's say what the whitepaper says:
They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.
As one one can say miner do not vote for proposals. They do vote by extending the chain that contains proposal they like. There must be a chain that exists to do so to begin with.
"Miner voting" as requested doesn't match what satoshi describes as miner voting, and in fact prevents the kind of miner vote described in the whitepaper.
I think this is misguided, expressing miner preference/support in blocks they mine does not detract in any way from Nakamoto Consensus, it still happens just the same way as it always have. With BIP135, it's just more informed decision than the chaos of guessing we have right now so miners and users know what they can expect, severely lowering uncertainty and drama - that is a good thing.
The communication between community/devs/miners before miners make their final decisions with their hash is taking place anyway, it's just scattered over twitter, reddit, mailing-list, slack channels etc. resulting in incomplete and often times faulty information being spread - BIP135 makes this communication that exists anyway more effective and actually representative (and unfakable) of the miner opinion.
I hope deadalnix reconsiders his position, BIP135 is just a communication tool that is solely needed, it does not replace or even affect Nakamoto Consensus in any way.
As a side-note, I believe the Satoshi quote that Amoury referenced does not concern these kinds of disagreements about the future direction of Bitcoin but rather routine operation of the Bitcoin protocol. The WP does not address the event of deliberate forks over disagreements over protocol, otherwise BTC would still be Bitcoin and BCH "just an altcoin" like BTC has claimed - this is clearly not so.
That is why I think we should make the communication of protocol changes more effective and transparent by implementing BIP135 first before anything else as division/chaos/drama or even forking BCH will only hurt the goal we're trying to achieve here
submitted by mushner to btc [link] [comments]

Bitcoin Cash: A Reflection on How Far We’ve Come

On August 1, Bitcoin resumed its original roadmap, scaling on-chain towards global adoption as Peer-to-Peer Electronic Cash.
It’s been just 3 and a half months since Bitcoin Cash broke away from BTC in order avoid a software mutation called Segwit, and to restore progress and growth to the ecosystem.
After a recent price rally that saw us reach 0.5 BTC ($3000), the reality is setting in that an overnight ‘flippening’ scenario that some people hoped for is unlikely, and that we have a longer road ahead.
It’s really important to remember how much has been achieved in such a short time.
Let’s take a moment to reflect on how far we’ve come as a young community.
July:
August:
September:
October:
November:
This rate and scale of industry adoption is unprecedented.
With every BTC holder receiving an equal amount of Bitcoin Cash, and with the price over $1300, the rate and scale of user adoption is unprecedented.
With fast, reliable transactions and fees that are less than 1 cent, and with both BitPay & Coinbase hinting at a full Bitcoin Cash integration, the rate and scale of merchant adoption will be unprecedented.
With unprecedented industry, user and merchant adoption, it’s only a matter of time until Bitcoin Cash becomes the default medium of exchange and store of value cryptocurrency.
The old Bitcoin is back. You can feel it. It’s the resurgence of a grassroots movement not seen for years. People are putting Bitcoin Cash posters in the streets, handing out leaflets, tipping strangers a few dollars online, and asking in forums how they can contribute to the community.
Just in the last couple of days a ‘Bitcoin Cash Fund’ was established, to assist with marketing and projects. The initial goal was $200 to make a short animated advert, but over $17,000 has been donated already. All of this positivity and energy is inspiring.
While businesses are being forced to abandon BTC due to exorbitant and skyrocketing fees (upwards of $10), they’re being cheered on every day as they embrace Bitcoin Cash.
The original vision is still alive. As an early bitcoiner, I’ve never been more optimistic.
Make sure you involve yourself in the community, we’re just getting started :)
Reddit: BTC or BitcoinCash
Twitter: twitter.com/BITCOINCASH
Website: bitcoincash.org
Dev: Mailing List
Also posted on Yours: Bitcoin Cash: A Reflection on How Far We’ve Come
submitted by cryptomic to btc [link] [comments]

Clearing up Some Widespread Confusions about BU

Running Core is like buying a Sony TV that only lets you watch Fox, because the other channels are locked away and you have to know how to solder a circuit board to see them. To change the channel, you as a layman would have to switch to a different TV made by some other manufacturer, who you may not think makes as reliable of TVs. This is because Sony believes people should only ever watch Fox "because there are dangerous channels out there" or "because since everyone needs to watch the same channel, it is our job to decide what that channel is." So the community is stuck with either watching Fox on their nice, reliable Sony TVs, or switching to all watching ABC on some more questionable TVs made by some new maker (like, in 2015 the XT team was the new maker and BIP101 was ABC).
BU (and now Classic and BitcoinEC) shatters that whole bizarre paradigm. BU is a TV that lets you tune to any channel you want, at your own risk. The community is free to converge on any channel it wants to, and since everyone in this analogy wants to watch the same channel they will coordinate to find one.
Yet people who are accustomed to Sony are so confused by the idea that the community could coordinate itself that they assume BU is, like XT, a TV that tunes to a specific channel, and they rail against that channel as dangerous. This is quite silly considering you can use BU to tune to Fox! That is, you can run BU with exactly Core settings. So you know you are being snowed there.
Although the following is hard to understand because of the fact that Satoshi introduced a meant-to-be temporary, non-controversial 1MB blocksize limit into the code, it is actually the Core devs who are tacitly proposing something bran new: By keeping the 1MB limit all these years while it gradually grew to be very controversial (due to increased Bitcoin usage), they have changed the situation from Satoshi's original one where the code didn't come with any controversial stances baked into it, to one where it does. Core has gradually moved to a lock-in model because they imagine the community to be incapable reaching consensus on its own, or at least incapable of reaching a good consensus.
By retaining the 1MB cap well past its time, they have little by little snuck in a new governance model I will call Governance by Centralized Inconvenience Barrier (GCIB). This is identical to Sony's model where they try to govern what everyone watches by making it inconvenient to change the channel (you have to know how to mod your TV or go find another maker who may not make TVs as well).
It is centralized because whatever goes into the Core repository counts as (they say) the "reference implementation," and any client that deviates from that is subject to extreme censorship on the Core mailing list as "off topic" and coincidentally the same applies on all the biggest Bitcoin forums (except this one) and bitcoin.org. Core's hope is that this new governance model will keep people from doing anything stupid and reckless, thanks to Core's paternalistic guidance. You can ironically know it is centralized because they focus on arguing that Core is somehow decentralized, using the flimsiest of reasoning: "anyone can contribute [but the committers must approve]" and "the team is decentralized because the devs live all over the world [so what?]" and "only unanimous votes among the 7 committers can make changes [that's still just an FOMC, and unanimity just means at best no changes at all and at worst total colluded central control]".
The pretzel logic even extends further, as to avoid the accusation of central control they instead say, "Fine, no changes at all." Not realizing that this effectively disallows any kind of temporary measures, including Satoshi's temporary blocksize limit. That would be insane, especially in the face of hot competition from altcoins, so the pretzel logic extends further: only soft forks are allowed, and hard forks are especially not allowed under controversy. Yet this is the ultimate in silliness, because a controversial soft fork will merely incite everyone who is against it to hard fork as a defense.
The whole paradigm where they think they can somehow "disallow" people from changing the channel (coordinating on blocksize settings without a group of devs rigging the consensus-finding) is hopelessly centralized. The whole paradigm where they think they can somehow "disallow" people from hard forking by only issuing soft forks is hopelessly centralized. The whole paradigm where Core = Bitcoin is hopelessly centralized.
BU, Classic, BitcoinEC, and soon btcd are the new bread, the "rooted" clients in the way you root an iPhone. For the purist, BitcoinEC is rooted Core, a minimal patchset. Unlike Core devs, these devs all refuse to pretend they are the determiners of what Bitcoin is. They understand that Bitcoin is not held together by trivial inconvenience barriers erected by dev teams, as that would have a trivially easy attack vector, as you can't really stop people from running a patch or modding their code in the long run even if you could do it for a while by pointing out there are some risks now due to lack of coding talent and such. They understand that the 21M coin limit is not held in place by Core devs locking down the coin issuance settings, but by the fact that the community would never tune to any channel that had a different issuance schedule. So they understand there is no danger in letting users adjust settings, because it is not the inability deviate from the herd that keeps the herd moving together, but instead the incentives involved.
It is time for Bitcoin grow up, to throw off childish things like the illusion that a group of devs are needed to set consensus, as well as the idea that that wouldn't be extremely dangerous as it would centralize control to the very extent to which it was necessary (meaning Bitcoin would barely be a thing at all; no wonder so many Core guys were longtime Bitcoin skeptics and seem to reject the idea of antifragility).
submitted by ForkiusMaximus to btc [link] [comments]

Bitcoin Cash: A Reflection on How Far We’ve Come

On August 1, Bitcoin resumed its original roadmap, scaling on-chain towards global adoption as Peer-to-Peer Electronic Cash.
It’s been just 3 and a half months since Bitcoin Cash broke away from BTC in order avoid a software mutation called Segwit, and to restore progress and growth to the ecosystem.
After a recent price rally that saw us reach 0.5 BTC ($3000), the reality is setting in that an overnight ‘flippening’ scenario that some people hoped for is unlikely, and that we have a longer road ahead.
It’s really important to remember how much has been achieved in such a short time.
Let’s take a moment to reflect on how far we’ve come as a young community.
July:
August:
September:
October:
November:
This rate and scale of industry adoption is unprecedented.
With every BTC holder receiving an equal amount of Bitcoin Cash, and with the price over $1300, the rate and scale of user adoption is unprecedented.
With fast, reliable transactions and fees that are less than 1 cent, and with both BitPay & Coinbase hinting at a full Bitcoin Cash integration, the rate and scale of merchant adoption will be unprecedented.
With unprecedented industry, user and merchant adoption, it’s only a matter of time until Bitcoin Cash becomes the default medium of exchange and store of value cryptocurrency.
The old Bitcoin is back. You can feel it. It’s the resurgence of a grassroots movement not seen for years. People are putting Bitcoin Cash posters in the streets, handing out leaflets, tipping strangers a few dollars online, and asking in forums how they can contribute to the community.
Just in the last couple of days a ‘Bitcoin Cash Fund’ was established, to assist with marketing and projects. The initial goal was $200 to make a short animated advert, but over $17,000 has been donated already. All of this positivity and energy is inspiring.
While businesses are being forced to abandon BTC due to exorbitant and skyrocketing fees (upwards of $10), they’re being cheered on every day as they embrace Bitcoin Cash.
The original vision is still alive. As an early bitcoiner, I’ve never been more optimistic.
Make sure you involve yourself in the community, we’re just getting started :)
Reddit: BTC or BitcoinCash
Twitter: twitter.com/BITCOINCASH
Website: bitcoincash.org
Dev: Mailing List
Also posted on Yours: Bitcoin Cash: A Reflection on How Far We’ve Come
submitted by cryptomic to Bitcoincash [link] [comments]

The Origins of the Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to Bitcoin [link] [comments]

Compact Blocks stole XThin's ID #: "When Bitcoin Core used the same ID # for their Compact Block that was already being used by the XThin block, they made it so that any implementation that wants to accept both cannot depend on the identifier as a way to identify the data type." ~ u/chernobyl169

UPDATE: u/chernobyl169 has now mentioned that, for greater clarity, he would have liked to edit the OP quote to insert the word "solely", as follows:
"When Bitcoin Core used the same ID # for their Compact Block that was already being used by the XThin block, they made it so that any implementation that wants to accept both cannot depend solely on the identifier as a way to identify the data type."
https://np.reddit.com/btc/comments/4xljh5/gregs_stubbornness_to_stay_with_his_lies_amuses/d6gqs2d
When Bitcoin Core used the same ID # for their compact block that was already being used by the XThin block, they made it so that any implementation that wants to accept both cannot depend on the identifier as a way to identify the data type.
(This is bad, because identifiers exist specifically so that a client can correctly identify a data type.)
A hack has to be introduced to reroute data processing dependent on something other than the identifier. This is clumsy, difficult, and unnecessary.
~ u/chernobyl169
More info here about Core "Compact Blocks" stealing the ID # which "XThin" was already using:
https://np.reddit.com/btc/comments/4xl6ta/thomas_zander_and_dagurval_are_not_telling_the/d6getna
More info about XThin here:
https://np.reddit.com/btc+bitcoin/search?q=author%3Apeter__r+xthin
What's going on here?
As many people know, there's been a debate going on for the past few days, regarding Core/Blockstream's decision to steal Xthin's ID # and use it for their own version of XThin, which they call Compact Blocks.
Once again, Core/Blockstream seem to be having a hard time incrementing a number!
As usual, the details are somewhat technical - but actually not very hard to understand.
And, as usual, Blockstream CTO "One Meg" Greg Maxwell u/nullc and the weirdo Luke-Jr u/luke-jr who Greg put in charge of assigning BIP ID #s are confusing the debate (and driving more users and devs away from Bitcoin) by making irrelevant technical arguments which only create more confusion and division in the community.
Meanwhile, the basic facts are simple and clear:
  • Two protocol improvements for compressing blocks were proposed: XThin (from u/Peter__R and other non-Core/non-Blockstream devs), and Compact Blocks (from Core/Blockstream).
  • XThin was using a certain ID # first. Using a ID # for these kinds of optional features is a standard procedure to allow clients to notify each other about which optional features they are using.
  • Core/Blockstream didn't like XThin. So made their own version of it called Compact Blocks - but they gave Compact Blocks the same ID # that XThin was already using - essentially "stealing" XThin's ID #.
  • You don't need a degree in computer science to know that every optional feature should really get its own unique ID # in order for these kinds of optional features to work best.
  • Now u/nullc and u/luke-jr have started to engage in their usual bullshitting technical and semantic parsing, trying to argue that both optional features could actually use the same ID # (if the features would subsequently negotiate the details by sending more data over the wire in a longer, more complicated process called "handshaking").
This is typical disruptive behavior from u/nullc and u/luke-jr.
  • First, they introduce unnecessary complexity and confusion into Bitcoin in order to benefit their repo and features (Core and Compact Blocks) at the expense of other repos and features (Classic, Unlimited, XT and XThin).
  • Then they create more confusion and division in the community by wasting people's time arguing online desperately trying to justify the whole mess which they caused - which would never even have happened in the first place if they would simply use a fucking unique ID # for every proposed Bitcoin improvement like any normal person would have done.
Normal devs don't engage in this kind of petty bullshit.
Normal healthy projects involving normal honest mature cooperative devs would never have this kind of petty malicious bullshit involving stealing an ID number and then disrupting the community by wasting everyone's time arguing for days over the whole thing.
This whole mess is simply further evidence that u/nullc and u/luke-jr are toxic devs who are harmful to Bitcoin development. Their unethical, uncooperative behavior continues to drive away many potential users and devs.
Blockstream CTO and Core architect Greg Maxwell u/nullc (and BIP ID # assigner u/luke-jr) need stop being toxic.
They need to recognize that they are not the dictators of Bitcoin.
They need to act like devs do on all other projects - openly and cooperatively, instead of being underhanded and shady.
They need to stop engaging in sneaky behavior, trying to sabotage other Bitcoin repos by stealing ID #s which were intended to be uniquely assigned to Bitcoin improvement proposals for new features.
Greg and Luke Jr have pulled this kind of bullshit before.
Sadly, this current mess with the stolen ID # is actually part of a long-standing pattern of sabotage and vandalism of other repos committed by u/nullc and u/luke-jr:
Luke-Jr is already trying to sabotage Bitcoin Classic, first lying and saying it "has no economic consensus", "no dev consensus", "was never proposed as a hardfork" (?!?) - and now trying to scare off miners by adding a Trojan pull-request to change the PoW (kicking all miners off the network)
https://np.reddit.com/btc/comments/418r0l/lukejr_is_already_trying_to_sabotage_bitcoin/
Greg Maxwell nullc just drove the final nail into the coffin of his crumbling credibility - by arguing that Bitcoin Classic should adopt Luke-Jr's poison-pill pull-request to change the PoW (and bump all miners off the network). If Luke-Jr's poison pill is so great, then why doesn't Core add it?
https://np.reddit.com/btc/comments/41c1h6/greg_maxwell_unullc_just_drove_the_final_nail/
Greg and Luke Jr don't play fair.
If they wanted to invent their own version of XThin, then fine. They should not only have given it a different name from XThin (Compact Blocks), but they should also have given it a different ID # from the one already being used by XThin.
This is just common sense and common courtesy - and their refusal to follow such simple, standard practice (and then waste days of people's time arguing online trying to defend their indefensible actions) is just further evidence that they are toxic.
Greg and Luke can never admit they were wrong about something and just move on.
Greg's stubborn behavior wasting people's time arguing about this whole thing is also very revealing - suggesting that perhaps he also suffers from a similar toxic pathology that Luke Jr is already famous for.
If Greg had been a mature project leader, he would have settled this thing instantly, saying, "OK, sorry about the mixup, guys! XThin has its own unique ID # now, so please just re-publish the spec for XThin using this ID #, and let's all move on."
Instead, he and Luke-Jr have spent the past couple of days posting trivial arguments all over Reddit desperately looking for minute technical details which they could possibly use to defend their indefensible earlier actions - and creating more toxicness and division in the community as a result - scaring off more users and devs.
Greg u/nullc and Luke Jr u/luke-jr are of course perfectly welcome to continue being toxic.
The result will simply be that more and more users will continue to discover that nobody is required to use "One Meg" Greg's Bitcoin Core client with its artificially tiny 1 MB "max blocksize" (and its conflicting ID #s for optional features like XThin & Compact Blocks).
Users can install (and already have installed) other clients such as Bitcoin Classic or Bitcoin Unlimited - which are already running 100% compatible on the Bitcoin network right now, ready to provide bigger blocks for on-chain scaling (and which by the way don't use conflicting ID #s for different proposed optional features =).
And more and more devs will continue to discover that they are not required to get unreliable ID #s through Luke-Jr, and they are not required to publish proposed Bitcoin improvements on unwelcoming Core-controlled mailing lists, IRC channels, and other discussion forums.
Bitcoin will route around the sabotage committed by unethical, toxic devs like u/nullc and u/luke-jr.
Like most other software on the web (such as browsers), Bitcoin (and improvements to Bitcoin) can and should and probably will evolve to be defined not via a single "reference implementation" - but via a published set of specifications or protocols, which various devs are free to implement, in various codebases, using various (decentralized, open, honest, ethical) repos and discussion forums.
So, Greg and Luke can continue to be in charge of their Bitcoin repo, Core, with its artificially tiny 1 MB "max blocksize" - and its unnecessarily conflicting, confusing ID #s.
Meanwhile, serious, open Bitcoin development will simply continue to decentralize, using simpler, safer on-chain scaling approaches such as bigger blocks - and standard procedures for assigning unique ID #s to proposals.
submitted by ydtm to btc [link] [comments]

Our BlockStream Saviours and XT Infidels!

Dear Bitcoin community, we (your BlockStream Saviours) working hard to improve Bitcoin by getting rid of XT Infidels!
Here is what we have done so far!
  1. Successful DDOS against XT Nodes, you can see nice drop here: http://xtnodes.com/xt_nodes_alldata.php
  2. Successful DDOS against Slush Pool (https://www.reddit.com/bitcoinxt/comments/3j63j2/slush_pool_under_ddos_attack/). Slush, this is what you get for ignoring our memo. For rest of you miner's, pay attention to what happened to Slush. We will let you know which blocks to mine. Keep voting for BIP100. It will soon be ready. https://www.reddit.com/bitcoinxt/comments/3rs3vs/jeff_garzik_bip100_seems_unlikely_to_be_adopted/
  3. Created “authentic” letter from Satoshi http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010238.html Very proud of this :) Got Gregory Maxwell to bless it! http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010327.html Thanks Gregory, we can always count on you (nice note on headers, pure gold).
  4. Kicked Mike Hearn out of #bitcoin-dev, he was talking too much anyway.. Good Job Wladimir J. Van, you should come join us at BlockStream! https://www.reddit.com/btc/comments/3n20nb/wheels_of_censorship_have_been_engaged_at/
  5. Censored Gavin out bitcoin-dev mailing list :) That was awesome! Unfortunately Evil BitcoinXT Infidels noticed. https://www.reddit.com/Bitcoin/comments/3qi3w9/gavins_bitcoindev_post_gets_moderated_out/
  6. Started character assassination against Gavin and Mike Hearn (so far so good).
  7. Started successful censorship campaign at /bitcoin and bitcointalk.org with our Top Lieutenant Theymos. Theymos, you make us all proud.
  8. Had Theymos teach lesson to BIP101 supporters https://github.com/bitcoin-dot-org/bitcoin.org/pull/1028 https://www.reddit.com/Bitcoin/comments/3rejl9/coinbase_ceo_brian_armstrong_bip_101_is_the_best/cwpglh6 Theymos, you have our permission to merge pull request 1028. Coinbase, see section #2 (Slush learned their lesson). To make it more clear - We will erase you from Internet!
  9. Almost removed Gavin from Foundation (he refuses to cooperate)... https://www.reddit.com/Bitcoin/comments/3hksre/blockstream_employee_asking_to_remove_gavin_from/
  10. Halted block-size increase nonsense-madman-talk by starting Scaling Bitcoin Workshop x2. Kudos to our great leader Adam Back for this brilliant idea!
  11. Our Plan is simple! https://www.reddit.com/Bitcoin/comments/3gmkak/the_blockstream_business_plan/
  12. Our Plan is working! https://forum.bitcoin.com/post6452.html#p6452
  13. Please return to /bitcoin and bitcointalk.org where it is safe and peaceful. We will make you feel comfortable!
  14. Please avoid forum.bitcoin.com and /btc at all costs.
Together We Will Succeed!
Your friends at BlockStream. XOXO
submitted by blockstream_fan to btc [link] [comments]

Laffka opensource torshop+bitcoin

Laffka opensource torshop+bitcoin
14.8 For sane instructions, please refer to https://github.com/eruina/laffka, most relevant technical stuff is in README.md - https://github.com/eruina/laffka/blob/masteREADME.md
14.8 RELEASE 2.01
pip3 -r requirements.txt
nano app/configuration.py
nano app/templates/disclaimer.html
python3 laffka.py
https://github.com/eruina/laffka
10.8 Made one test sale, spores for for microscopy in syringe.
Can confirm, payment of mailing expenses made to my wallet rapidly and without problems.
Proof:https://www.blocktrail.com/BTC/address/1FwJdVgMZHK6WWX9t9GJnBnSVrSqfqkARB/transactions
Revamped site, welcome: http://laffka6wwduoexvb.onion/
source code will be availible 12.8
Revamped sitehttp://laffka6wwduoexvb.onion/
9.8 Items can be added, removed and edited from console panel:
Console item
And this is how it looks like listed: http://laffka6wwduoexvb.onion/item/6
Listing
Custom list of amounts to ship is in use now, howver - admin console validates only if session authorized.
What does this mean? Means that putting wrong values into database might bring whole Laffka down. Especially amount lists and orders which include both MainNet and TestNet orders.
Temporary solution would be to implement /rescue page, where admin can delete any offending row from database. Bit lame, but would do for now.
I am also puzzled at in which form package is to make. Well, have 3 days to figure it out.
8.8 At very basic level Laffka works in very basic level without any external stuff. Here:
Second part of admin console
At the risk of being labeled pedlling crap - shop example on laffka should work: http://sporeikzj77hnrxq.onion/ (yes, it is fully working little shop)
8.8 Items can be changed from console now. One can change, but not add or remove items at the moment.
Ugly as hell, but admin console in fact doesnt need to be pretty.
it needs to be functional.
https://preview.redd.it/xqpdx0rn0ue11.png?width=1195&format=png&auto=webp&s=c495e2c89b59c7a0fcc35a2c123a83a8667c35d1
6.8 Orders part of console is finished. Orders shown - ones that are paid, and ones that are marked with note.
Rather nifty, but probably requires additional changes after code is released.
Orders page
Order 98 will be shown even if Wif key is swept. Order 99 will disappear after Wif key is swept. Simple, and probably will require additions, but would do for now.
Time to fiddle with items.
5.8 Something like this. Subject to change!
Console, early version
5.8 Admin console is a bit of a puzzle. At the moment, I think of showing orders that has been paid AND orders which has note left by admin. Should be sufficient for first release version.
I also deem it bit pointless at the moment to validate values of admin console forms, orders and items.
4.8 pip3 module requirements now include flask-login and flask-session.
It would be interesting to run few instances of Laffka with common order table. This way one can make and keep a lot of small darknetshops in hidden onion land, with overall price well under 50€.
Login and session are required for shopowner identification, means it is in progress, after which packaging only left.
It might be interesting to make liveusb with sole purpose of running small Laffka-torshop.
Word Laffka is from finnish Lavka, which means small shop, usually at market place.
2.8 I should mention, that purchase process is very nonintrusive for customer. Gives a bit strain to shop owner, but not much.
1.8 Meanwhile I suffer from heat and overuse of bandwith, here is small presentation, how payments work.
Suppose customer would like 3pcs of Test item 1:
Generic order of Test item 1
So, customer clicks 3pcs, and arrives at second page:
Address part of ordering
Finally customer arrives at personalized payment page
Check out
After which customer is asked to pay for order:
Electrum Testnet
After order being paid, payment reflects on orderpage(http://laffka6wwduoexvb.onion/pay/mryJ3ukrFHoUmdHeSkR4XZcwe3wvG3pRkd)
After payment been through:
Finished payment
Shop owner can claim funds by sweeping own private key from admin console(not finished yet)
Private key cUP4jznEGX8EDMPw813w4B7E6fBo3FDXPqhRLp5sFHq3v3KCgP2z
All right, now lets swipe:
Sweep-sweep.
Voila, New transaction received
Received payment
So, all in all customer paid 4.64526, and shop owner received 4.64108, difference is paid for bitcoin transaction, while private key was swept.
Nifty.
1.8 FFS. Seems I've depleted bandwith for august.
need to tune tor more careful.
UPDATE: temporarily example can be accessed at http://laffka6wwduoexvb.onion/. test22cq47 doesn't work for now.
1.8 Satellite skeleton is done, orders page in progress.
Makes sence to finish satellite with instructions after admin console is done.
Still fucking hot in here, coding advances very slow, yet I believe it is going to be finished before deadline, 12.8
31.7 Satellite is in works, meanwhile testshop can be found at http://test222cq47k6qrn.onion/
http://laffka6wwduoexvb.onion/ is going to point to project site itself, with sources and instructions.
31.7 My bad.Had theoretic items in a shop, and was considered peddling crap by administration.
Exchanged those to Test item 1 and 2, as seen here: http://laffka6wwduoexvb.onion/
Project is now hosted separatedly from development, and should be availible all the time.
Of course, since it is early Alpha, it can fall, but otherwise you are welcome to make test order and pay it with testBitcoins.
It is fucking hot here, literally cannot concentrate myself to do anything useful.There is but two things left before release:
  1. Admin console (for fiddling with items, and sending orders)Have idea how to elegantly handle orders, but not items
  2. Some form of ready to deploy package
Also, I must mention requirements. Installing whole thing on pristine CentOS 7.4 was under 15mins, so here are first requirements:Python3 and python3-pip
And pip requirements for now: flask, requests, Flask-APScheduler, Flask-WTF, bitmerchant
12.8 is still deadline for release.
29.7 Nifty!!!
Too hot to think about admin console, yet it is not harder to run few instances of Laffka on machine than typing:flask run --port=5678andflask run --port=6789
in two different consoles. Actually nifty. No conflicts, two absolutely separate instances having nothing to do with each other.One can already generate sales, yet database from admin perspective is accessible only from some DB Browser.
29.7 I have observed, that visitors are coming to payment page, where it asks address and then most probably close page.
Don't be afraid, type some stupid shit there, it will transfer you to payment page itself. Don't be afraid to pay order neither, since testBitcoins do not cost anything. Neither I receive any information, except routes of visitors.
Answering questions: Design is no priority whatsoever. Since Laffka is developed with Tor in mind, there is no graphical elements at all. May be later CSS will be tweaked and ability to add pictures to items, but I don't see myself developing cushy designs for Laffka.
It should be lightweight, fast and simple. Functionality is of priority here.
Then there is question "How can I participate". At the moment only by testing is a method or participation, ie making order and paying with testBitcoins. After first release, one can branch code and develop own branch. I am not yet ready to release first public version.
Before releasing, there is necessity to create make/setuptools.py
28.7 Hello.
Always wanted my own small shop on darknet, not consolidated markets, which are riddled with such problems as exit scams, DDOS attacks, rules which you couldn't change and whatnot.
Never found anything suitable, heard about torshop, but apparently it was a scam.
Which is quite understandable - never trust your private keys to unknown third party, it is just plain stupid.
I think I came up with solution. Well, I didn't invent idea of opensource, but I think I know how to make this thing work.
Let me present Laffka, in its very much alpha stage.
It is written in Flask+python3, and uses* sqli*te as database engine. Doesn't require blockchain downloading, checks transactions online and generates private keys for bitcoin wallet sweeping, thus getting payments for *a t*x price.
Should work clearnet too, I don't see why not. Works excellent and made specially for hidden service purpose.
No binaries whatsoever, everything is in clean and understandable python+html. No surprises, no hidden stuff. Plain opensource. And plain opensource will be released, without tricks.
There are some pypi dependencies, I will list them in documentation upon release.
And release is coming soon. Not yet, but I've decided to draw a little attention, since Laffka accepts and processes payments, albeit on very basic level (no admin console at the moment, lot of functionality still missing)
Please observe alpha version 0.02 in action - http://laffka6wwduoexvb.onion/
make order, or observe existing order - http://laffka6wwduoexvb.onion/pay/mxprSXCVX7WvvADDDVCrKmEhfsvWvznawu
(observe increasing wallet balance upon sending testBitcoins. No blockchain involved.)
It would be greatly appreciated if you'd make order and pay for it. TestNet, not MainNet, so no money involved whatsoever. I require some feedback about project. You can run Electrum in testnet electrum --testnet, and get testBitcoins at some faucet, https://testnet.coinfaucet.eu/en/ for example (there are others)
If link doesn't work, it is ok - means I've took it off, and it will be coming back online bit later. Resource will run continuously when I finish satellite for Laffka (ToDo list is on index at http://laffka6wwduoexvb.onion/)
Thanks for attention.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
yes, it is me
http://silkkitiehdg5mug.onion/faceless
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJbXh9iAAoJEEuIauo+qFrQPvcP/A+aYZEkFgMNkl8pKj2RtOtv
fZeeMu45vTRNDbShZkkvtSRTLkInhHONQ7+2iYZLYQOMXCpMtgUdmZCXBxsQgf0j
WKyjgMuyP/IFOAZzPYlkDhBc7XlVMmaSR5aezrAcKF1vVUujrFwxuCBNFs7gjF74
1IKK1O3QHmjP/mHakmM31Ml5/VGH0cOaEQAcSJ4j3WUnfm5qCblRu81BFqWgoMh/
wyzJg6YYXcH+Hw2IAgJ4N2yL+Ze1DNehWVnNxxzbeqqkpuNvMVxutTqOjVcvj6or
WVzke9rjEYpP8tpNlIdCnPaKq9IpRmSnJHeh0gN6SknRsT56gyPZ2dS09j4bATCD
vL9yrufAb7KJKgZoQfMH02i1M9+PFL/HPV4l1Do62dAY5EKwdwOFBiAn/1rfKFXA
NuD7N63+zKtUJyO3HKxtdxMmyRE3XcTD0OWnLfjhcrsCcptu+9kPIN+aDu9OnuXt
j94FLiJupwf1k5jeKIcvDXT+fwr3SacrmrsOTv4vcGC2LJj0aEK+/dEE0RDoCl
x3pPWT9v31PvA11HiT8PpLH2aQoE6e0iwhfRHtcsqy8itfwzCeSqhZz56q377BcH
FKYYcyIJulTji7YYGrLU+6aKlYBGTGTCISPonTgZoB2fi5UZaSu6UvhrEA5sAEEH
t81FDBuHqqeHaPH0mi0R
=ZVSC
-----END PGP SIGNATURE-----
submitted by faceless-valhalla to darknet [link] [comments]

Attacking Bitcoin in the UK: Offences under the Computer Misuse Act 1990

The Computer Misuse Act 1990 in the United Kingdom makes it an offence to deliberately cause disruption to computer systems with intent http://www.legislation.gov.uk/ukpga/1990/18/section/3
The recent and planned "stress test" attacks by Coinwallet.eu not only cause disruption, they cause nodes to crash and make services unavailable.
I would caution CoinWallet.EU against their "stress tests" are at risk of breaching UK law and probably cyber crime laws elsewhere. Any individual or business affected may contact the police and the evidence of the attacks is burned into the blockchain forever and various publications who have covered the story with direct contact from coinwallet.eu representatives.
EDIT:
It seems there is a bit of confusion, so I'll cover some of the concept here.
There is a concept in most legal jurisdictions that abuse or unauthorised use of computer systems/networks is an offence. In the case of abuse, if one intends to cause disruption and then attempts to do so, then an offence has been committed. Whether a computer system is vulnerable to attack is not the point and is not a defence.
Penetration testing is illegal without explicit permission from the owner of the computer system in question. Many people have conflated the Bitcoin network with nodes. If an attacker executes a denial of service it affects bitcoin nodes. There are two specific examples: DOS attacks against nodes, as it happening with XT, and the transaction attacks that have been executed by Coinwallet.eu.
In both examples the DOS attacks have a negative impact on the computer running the full node, as well as the functionality of the full node. The XT attacks consume bandwidth and the transaction attacks fill node mempools and cause nodes to crash.
This post is not about political values, it's about the law, as it stands. The attacks on XT nodes and the "stress tests" are illegal actions and those performing them should think twice. Of course getting caught is a different matter, certainly the XT attackers have not come out publicly, so hunting them down may pose a challenge. Coinwallet on the other hand has made no attempt to hide their intentions and I assume there is a trail leading right back to them. As a matter of law, I urge attackers to cease operations.
I'm quite shocked that some of the reddit community would condone these illegal actions or chose to politicise the matter.
I know I am not alone in my feelings and I would like to thank mike_hearn for actually bringing up the matter of the legality of attacks a few days ago on the XT mailing list. Unfortunately for him, the attackers of XT nodes are pretty well hidden. While I do not remotely support XT, or BIP101 (I'm quite vocal against them), I absolutely do not condone the illegal actions, however so motivated. I think there are better ways to let the Bitcoin ecosystem decide it's future. In any case, this post it not about XT or the blocksize debate, but about the illegality of the recent and planned attacks.
Further clarification of the law in the UK can be found here http://www.cps.gov.uk/legal/a_to_c/computer_misuse_act_1990/ under "Section 3 CMA - Unauthorised Acts with Intent to Impair"
submitted by btcdrak to Bitcoin [link] [comments]

On Mike Hearn, Block Size, and Bitcoin’s Future

My new years resolution was to avoid the block size debate. Oh well.

Regardless what you think of block size debate. Mike Hearn and his tactics have done nothing but pollute the well. He has been intransigent in development, his proposals were routinely shut down because they were horrible on a technical level, he had many dangerous ideas which undermined the very concept of Bitcoin. When he made no traction with his idea, he created his own Bitcoin client.
Because that wasn’t enough he began politicking users to switch to his client. When users found no technical benefit or improvement over his client and failed to adopt it, that wasn’t enough. He then found a tool which he could use to drive a wedge into the community, and drive adoption to his client or so he thought, the block size. Rather than offer constructive support to this issue, he recruited Gavin and others to create this imaginary war that did not exist, of a Bitcoin mafia vs the people. Coincidentally, it was during this time that he became concerned with the block size that the spam attacks on the network beginning happening. Heckuva coincidence.
Mike, in his dramatic style, made the proclamation that bitcoin is forking and with that he introduced a new level of politics to Bitcoin beyond what it had ever experienced. In addition, Mike has managed to make the scaling issue, a complex technical issue, into something that is a political litmus test, like abortion, or gun control, something that was sorely missing in a technical community.
As if merely raising the block limit would fix Bitcoin’s problem in his eyes. Mike is smart enough to know that wasn’t the case, but it didn’t matter because by turning something complex into something simple, he was able to sell the story, to people who weren’t interested in the technical nuances, but wanted something to hang their beliefs on. His ideas were perfect fodder to those adopters who were suffering in Bitcoin’s long bear market. Mike had the answer, bitcoin is suffering because the devs refuse to scale it. Mike Hearn had a simple solution, just change a number, it's so easy, any lay person can see that. Clearly if you opposed such a simple change you had ulterior motives, the people in opposition where trying to steal bitcoin.
Mike worked in front and behind the scenes like a dogged politician to create this imaginary timetable that bitcoin was about to explode and collapse, watch the price he said. Creating sensationalist media posts that were technically flawed, and painted bookworm engineers, who have done nothing but work in the best interest of Bitcoin, as scheming backroom politicians who were co-opting bitcoin for their meglo-maniacal ambitions (project much Mike?) When the time table for Bitcoin’s, life or death decision came and went, and bitcoin did not collapse, and no one adopted his client, he cried foul. Ironically, Mike laments that Bitcoin is the hands of 10 developers (not true) yet he had appointed himself the benevolent dictator of his coin Bitcoin-XT.
Why was the Bitcoin community not falling on its sword and adopting his plans? It’s probably because again, the secret cabal was conspiring to suppress his ideas. His ideas which were spammed over social media, which got thousands of page views, which generated hundreds if not thousands of hours of discussion. Despite all this, no-one knew that Mike had this beautiful solution to rescue bitcoin, all because this evil mafia conspired to deny freedom to Bitcoiners around the world and keep his ideas a secret.
Meanwhile actual developers are moving forward with proposals that will scale bitcoin but Mike says that isn’t enough. Despite his incessant nagging, driving XTers to brigade every bitcoin discussion, ruining technical discussions in the development mailing list. That still wasn’t enough. Nope, unless Mike Hearn got his way, Bitcoin is a failed experiment. Mike Hearn’s goal was never about Bitcoin, it was about wrecking Bitcoin. There is no way you can reconcile his tactics with someone who put Bitcoin first.
No one had previously proposed forking Bitcoin to their own client, without calling it an altcoin or alternate implementation. Even Garzik was clear about it in discussion with Satoshi himself. Mike was the first to introduce the idea that creating your own implementation of Bitcoin, which is not compatible with other implementations, and changes a core function of bitcoin with something as low as 75% approval, was not an alt version of bitcoin but was still Bitcoin. Amazing, He has attempted to change what was an accepted and understand aspect of Bitcoin.
Now forking Bitcoin is a grand idea, Bitcoin forks for everyone. Forking Bitcoin is not something new, it has been around since day one, and the community had agreed that a fork of Bitcoin, without unanimous consensus, was an Altcoin.
People who care about bitcoin do not promote Altcoins because it’s clear this would fracture Bitcoin and undermine the very method in which bitcoin secures itself. But in Mike’s world people should undermine their investment in order to get a better investment.
Bitcoin has shown that the economic consensus mechanism works, that the consensus will respect the protocol. That if the time to change the protocol comes, it will be a change that is readily apparent, and will be adopted unanimously (Mike, that means without opposition.) Because from an economic interest it makes no sense to undermine bitcoin by fracturing it. And so surprise, suprise, bitcoin participants are making rational economic decisions. Bitcoin is not a democracy where 51% rules. In fact that is Bitcoin in a state of attack.
Still the very fact that Bitcoin has continued to function, and even begun to rise again precisely when it was supposed to be collapsing, was a slap in the face to Mike Hearn. So the final stroke a front page NYT , “you can’t fire me I quit ” announcement with a dramatic companion post all over social media, as If Bitcoin has lost some key intellectual power.
Sorry Mike, but Bitcoin is not yours to fail.
The best thing that could happen to Bitcoin and Mike Hearn is a final divorce, though messy it has been. But has Mike really left us? Something tells me he hasn’t. Instead Mike’s new job will be to further the new meme that Bitcoin is a failed experiment and he should know because he was a “lead” developer who worked directly with Satoshi.
And for proof, this morning I watched the Brookings Institute Webstream of their conference Beyond the Blockchain. The very first thing thing Charley Cooper of R3 CEV (Mike’s new employer) brought up was how Bitcoin was failed according to Mike Hearn, how Bitcoin was not going anywhere and that the future was private block chains.
So let’s congratulate Mike on his new role, where he will work to undermine bitcoin at every turn in front of regulators, banks, VCs and the public. At least now Mike can stop pretending what his real goal has been all along.
Because this has never been about raising the block limit or about or about a technical issue. This has been about co-opting Bitcoin into either Mike Hearn’s coin, or something more nefarious, on behalf of greater powers.
Mike, Good Luck, Stay Strong; I wish you the best.
source: http://bitledger.info/on-mike-hearn-block-size-and-bitcoins-future/
submitted by bitledger to Bitcoin [link] [comments]

Jeff Garzik is killing it on the mailing list!

I thought that the mailing list is now completely brainwashed by pro fee-market folks. But Jeff is such a refreshing participant that I haven't lost all hope. However, there is a risk that Jeff will be the next person alienated from Bitcoin Core (maybe he would join the XT/BIP 101 efforts then?).
Anyways, some quotes with links:
The core design of bitcoin is that trustless nodes validate the work of miners, not trust them.
Soft forks move in the opposite direction. Each new soft-forked feature leans very heavily on miner trust rather than P2P network validation.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe012009.html
 
For that reason, I've proposed, and am working hard, on an approach that includes Segregated Witness as a first step. It shows the ecosystem that something is being done, it kicks the can down the road, it solves/issues half a dozen other issues at the same time, and it does not require the degree of certainty needed for a hardfork.
Segregated Witness does not kick the can, it solves none of the problems

1, #3 - #8 explicitly defined and listed in email #1.

1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there will be no Fee Event, because the core block size is still heavily contended -- 100% contended at time out SW rollout.
2) We are only 100% certain that bitcoin works in the blocks-not-full-on-avg state, where there is a healthy buffer between the hard limit and the average block size.
There is remains major ECE risk due to the core block size freeze, possibly pushing the system into a new, untried economic state and causing major market and actor disruption. Users of the Service can still drift randomly and unpredictably into a Fee Event.
SW mitigates this - only after several months - only assuming robust adoption rates by up-layer ecosystem software, and - only assuming transaction volume growth is flat or sub-linear
Those conditions must go as planned to fulfill "SW kicked the can" -- a lot of if's.
As stated, SW is orthogonal to the drift-into-uncharted-waters problem outlined in email #1, which a short term bump does address.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe012018.html
 
But what you're arguing for is that - despite being completely expected - blocks grew fuller, and people didn't adapt to block size pressure and a fee market, so the Core committee now needs to kick the can down the road, because we can't accept the risk of economic change. That sounds very much like a bailout to me.
I am arguing for continuing what we know works. We are 100% certain blocks-not-full-on-avg works, where a "buffer" of space exists between avg block size and hard limit.
Any other avenue is by definition speculation and risk. You think you know what a healthy fee market should be. Massive damage occurs to bitcoin if you are wrong - and I listed several
vis expectation, there is clear consensus and expectation that block size would increase, from 2010 onward. It was always a question of when not if.
Sticking with 1M presents clear risk of (a) economic fracture and (b) community fracture. It quite clearly risks massive change to an unknown system at an unknown, unpredictable date in the future.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe012027.html
submitted by BIP-101 to btc [link] [comments]

The Origins of the (Modern) Blocksize Debate

On May 4, 2015, Gavin Andresen wrote on his blog:
I was planning to submit a pull request to the 0.11 release of Bitcoin Core that will allow miners to create blocks bigger than one megabyte, starting a little less than a year from now. But this process of peer review turned up a technical issue that needs to get addressed, and I don’t think it can be fixed in time for the first 0.11 release.
I will be writing a series of blog posts, each addressing one argument against raising the maximum block size, or against scheduling a raise right now... please send me an email ([email protected]) if I am missing any arguments
In other words, Gavin proposed a hard fork via a series of blog posts, bypassing all developer communication channels altogether and asking for personal, private emails from anyone interested in discussing the proposal further.
On May 5 (1 day after Gavin submitted his first blog post), Mike Hearn published The capacity cliff on his Medium page. 2 days later, he posted Crash landing. In these posts, he argued:
A common argument for letting Bitcoin blocks fill up is that the outcome won’t be so bad: just a market for fees... this is wrong. I don’t believe fees will become high and stable if Bitcoin runs out of capacity. Instead, I believe Bitcoin will crash.
...a permanent backlog would start to build up... as the backlog grows, nodes will start running out of memory and dying... as Core will accept any transaction that’s valid without any limit a node crash is eventually inevitable.
He also, in the latter article, explained that he disagreed with Satoshi's vision for how Bitcoin would mature[1][2]:
Neither me nor Gavin believe a fee market will work as a substitute for the inflation subsidy.
Gavin continued to publish the series of blog posts he had announced while Hearn made these predictions. [1][2][3][4][5][6][7]
Matt Corallo brought Gavin's proposal up on the bitcoin-dev mailing list after a few days. He wrote:
Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell...
So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase.
Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler).
This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo
Shortly thereafter, Corallo explained further:
The point of the hard block size limit is exactly because giving miners free rule to do anything they like with their blocks would allow them to do any number of crazy attacks. The incentives for miners to pick block sizes are no where near compatible with what allows the network to continue to run in a decentralized manner.
Tier Nolan considered possible extensions and modifications that might improve Gavin's proposal and argued that soft caps could be used to mitigate against the dangers of a blocksize increase. Tom Harding voiced support for Gavin's proposal
Peter Todd mentioned that a limited blocksize provides the benefit of protecting against the "perverse incentives" behind potential block withholding attacks.
Slush didn't have a strong opinion one way or the other, and neither did Eric Lombrozo, though Eric was interested in developing hard-fork best practices and wanted to:
explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.
Matt Whitlock voiced his opinion:
I'm not so much opposed to a block size increase as I am opposed to a hard fork... I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
Bryan Bishop strongly opposed Gavin's proposal, and offered a philosophical perspective on the matter:
there has been significant public discussion... about why increasing the max block size is kicking the can down the road while possibly compromising blockchain security. There were many excellent objections that were raised that, sadly, I see are not referenced at all in the recent media blitz. Frankly I can't help but feel that if contributions, like those from #bitcoin-wizards, have been ignored in lieu of technical analysis, and the absence of discussion on this mailing list, that I feel perhaps there are other subtle and extremely important technical details that are completely absent from this--and other-- proposals.
Secured decentralization is the most important and most interesting property of bitcoin. Everything else is rather trivial and could be achieved millions of times more efficiently with conventional technology. Our technical work should be informed by the technical nature of the system we have constructed.
There's no doubt in my mind that bitcoin will always see the most extreme campaigns and the most extreme misunderstandings... for development purposes we must hold ourselves to extremely high standards before proposing changes, especially to the public, that have the potential to be unsafe and economically unsafe.
There are many potential technical solutions for aggregating millions (trillions?) of transactions into tiny bundles. As a small proof-of-concept, imagine two parties sending transactions back and forth 100 million times. Instead of recording every transaction, you could record the start state and the end state, and end up with two transactions or less. That's a 100 million fold, without modifying max block size and without potentially compromising secured decentralization.
The MIT group should listen up and get to work figuring out how to measure decentralization and its security.. Getting this measurement right would be really beneficial because we would have a more academic and technical understanding to work with.
Gregory Maxwell echoed and extended that perspective:
When Bitcoin is changed fundamentally, via a hard fork, to have different properties, the change can create winners or losers...
There are non-trivial number of people who hold extremes on any of these general belief patterns; Even among the core developers there is not a consensus on Bitcoin's optimal role in society and the commercial marketplace.
there is a at least a two fold concern on this particular ("Long term Mining incentives") front:
One is that the long-held argument is that security of the Bitcoin system in the long term depends on fee income funding autonomous, anonymous, decentralized miners profitably applying enough hash-power to make reorganizations infeasible.
For fees to achieve this purpose, there seemingly must be an effective scarcity of capacity.
The second is that when subsidy has fallen well below fees, the incentive to move the blockchain forward goes away. An optimal rational miner would be best off forking off the current best block in order to capture its fees, rather than moving the blockchain forward...
tools like the Lightning network proposal could well allow us to hit a greater spectrum of demands at once--including secure zero-confirmation (something that larger blocksizes reduce if anything), which is important for many applications. With the right technology I believe we can have our cake and eat it too, but there needs to be a reason to build it; the security and decentralization level of Bitcoin imposes a hard upper limit on anything that can be based on it.
Another key point here is that the small bumps in blocksize which wouldn't clearly knock the system into a largely centralized mode--small constants--are small enough that they don't quantitatively change the operation of the system; they don't open up new applications that aren't possible today
the procedure I'd prefer would be something like this: if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk. Hardfork changes should only be made if they're almost completely uncontroversial--where virtually everyone can look at the available data and say "yea, that isn't undermining my property rights or future use of Bitcoin; it's no big deal". Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target. This is frustrating
many people--myself included--have been working feverishly hard behind the scenes on Bitcoin Core to increase the scalability. This work isn't small-potatoes boring software engineering stuff; I mean even my personal contributions include things like inventing a wholly new generic algebraic optimization applicable to all EC signature schemes that increases performance by 4%, and that is before getting into the R&D stuff that hasn't really borne fruit yet, like fraud proofs. Today Bitcoin Core is easily >100 times faster to synchronize and relay than when I first got involved on the same hardware, but these improvements have been swallowed by the growth. The ironic thing is that our frantic efforts to keep ahead and not lose decentralization have both not been enough (by the best measures, full node usage is the lowest its been since 2011 even though the user base is huge now) and yet also so much that people could seriously talk about increasing the block size to something gigantic like 20MB. This sounds less reasonable when you realize that even at 1MB we'd likely have a smoking hole in the ground if not for existing enormous efforts to make scaling not come at a loss of decentralization.
Peter Todd also summarized some academic findings on the subject:
In short, without either a fixed blocksize or fixed fee per transaction Bitcoin will will not survive as there is no viable way to pay for PoW security. The latter option - fixed fee per transaction - is non-trivial to implement in a way that's actually meaningful - it's easy to give miners "kickbacks" - leaving us with a fixed blocksize.
Even a relatively small increase to 20MB will greatly reduce the number of people who can participate fully in Bitcoin, creating an environment where the next increase requires the consent of an even smaller portion of the Bitcoin ecosystem. Where does that stop? What's the proposed mechanism that'll create an incentive and social consensus to not just 'kick the can down the road'(3) and further centralize but actually scale up Bitcoin the hard way?
Some developers (e.g. Aaron Voisine) voiced support for Gavin's proposal which repeated Mike Hearn's "crash landing" arguments.
Pieter Wuille said:
I am - in general - in favor of increasing the size blocks...
Controversial hard forks. I hope the mailing list here today already proves it is a controversial issue. Independent of personal opinions pro or against, I don't think we can do a hard fork that is controversial in nature. Either the result is effectively a fork, and pre-existing coins can be spent once on both sides (effectively failing Bitcoin's primary purpose), or the result is one side forced to upgrade to something they dislike - effectively giving a power to developers they should never have. Quoting someone: "I did not sign up to be part of a central banker's committee".
The reason for increasing is "need". If "we need more space in blocks" is the reason to do an upgrade, it won't stop after 20 MB. There is nothing fundamental possible with 20 MB blocks that isn't with 1 MB blocks.
Misrepresentation of the trade-offs. You can argue all you want that none of the effects of larger blocks are particularly damaging, so everything is fine. They will damage something (see below for details), and we should analyze these effects, and be honest about them, and present them as a trade-off made we choose to make to scale the system better. If you just ask people if they want more transactions, of course you'll hear yes. If you ask people if they want to pay less taxes, I'm sure the vast majority will agree as well.
Miner centralization. There is currently, as far as I know, no technology that can relay and validate 20 MB blocks across the planet, in a manner fast enough to avoid very significant costs to mining. There is work in progress on this (including Gavin's IBLT-based relay, or Greg's block network coding), but I don't think we should be basing the future of the economics of the system on undemonstrated ideas. Without those (or even with), the result may be that miners self-limit the size of their blocks to propagate faster, but if this happens, larger, better-connected, and more centrally-located groups of miners gain a competitive advantage by being able to produce larger blocks. I would like to point out that there is nothing evil about this - a simple feedback to determine an optimal block size for an individual miner will result in larger blocks for better connected hash power. If we do not want miners to have this ability, "we" (as in: those using full nodes) should demand limitations that prevent it. One such limitation is a block size limit (whatever it is).
Ability to use a full node.
Skewed incentives for improvements... without actual pressure to work on these, I doubt much will change. Increasing the size of blocks now will simply make it cheap enough to continue business as usual for a while - while forcing a massive cost increase (and not just a monetary one) on the entire ecosystem.
Fees and long-term incentives.
I don't think 1 MB is optimal. Block size is a compromise between scalability of transactions and verifiability of the system. A system with 10 transactions per day that is verifiable by a pocket calculator is not useful, as it would only serve a few large bank's settlements. A system which can deal with every coffee bought on the planet, but requires a Google-scale data center to verify is also not useful, as it would be trivially out-competed by a VISA-like design. The usefulness needs in a balance, and there is no optimal choice for everyone. We can choose where that balance lies, but we must accept that this is done as a trade-off, and that that trade-off will have costs such as hardware costs, decreasing anonymity, less independence, smaller target audience for people able to fully validate, ...
Choose wisely.
Mike Hearn responded:
this list is not a good place for making progress or reaching decisions.
if Bitcoin continues on its current growth trends it will run out of capacity, almost certainly by some time next year. What we need to see right now is leadership and a plan, that fits in the available time window.
I no longer believe this community can reach consensus on anything protocol related.
When the money supply eventually dwindles I doubt it will be fee pressure that funds mining
What I don't see from you yet is a specific and credible plan that fits within the next 12 months and which allows Bitcoin to keep growing.
Peter Todd then pointed out that, contrary to Mike's claims, developer consensus had been achieved within Core plenty of times recently. Btc-drak asked Mike to "explain where the 12 months timeframe comes from?"
Jorge Timón wrote an incredibly prescient reply to Mike:
We've successfully reached consensus for several softfork proposals already. I agree with others that hardfork need to be uncontroversial and there should be consensus about them. If you have other ideas for the criteria for hardfork deployment all I'm ears. I just hope that by "What we need to see right now is leadership" you don't mean something like "when Gaving and Mike agree it's enough to deploy a hardfork" when you go from vague to concrete.
Oh, so your answer to "bitcoin will eventually need to live on fees and we would like to know more about how it will look like then" it's "no bitcoin long term it's broken long term but that's far away in the future so let's just worry about the present". I agree that it's hard to predict that future, but having some competition for block space would actually help us get more data on a similar situation to be able to predict that future better. What you want to avoid at all cost (the block size actually being used), I see as the best opportunity we have to look into the future.
this is my plan: we wait 12 months... and start having full blocks and people having to wait 2 blocks for their transactions to be confirmed some times. That would be the beginning of a true "fee market", something that Gavin used to say was his #1 priority not so long ago (which seems contradictory with his current efforts to avoid that from happening). Having a true fee market seems clearly an advantage. What are supposedly disastrous negative parts of this plan that make an alternative plan (ie: increasing the block size) so necessary and obvious. I think the advocates of the size increase are failing to explain the disadvantages of maintaining the current size. It feels like the explanation are missing because it should be somehow obvious how the sky will burn if we don't increase the block size soon. But, well, it is not obvious to me, so please elaborate on why having a fee market (instead of just an price estimator for a market that doesn't even really exist) would be a disaster.
Some suspected Gavin/Mike were trying to rush the hard fork for personal reasons.
Mike Hearn's response was to demand a "leader" who could unilaterally steer the Bitcoin project and make decisions unchecked:
No. What I meant is that someone (theoretically Wladimir) needs to make a clear decision. If that decision is "Bitcoin Core will wait and watch the fireworks when blocks get full", that would be showing leadership
I will write more on the topic of what will happen if we hit the block size limit... I don't believe we will get any useful data out of such an event. I've seen distributed systems run out of capacity before. What will happen instead is technological failure followed by rapid user abandonment...
we need to hear something like that from Wladimir, or whoever has the final say around here.
Jorge Timón responded:
it is true that "universally uncontroversial" (which is what I think the requirement should be for hard forks) is a vague qualifier that's not formally defined anywhere. I guess we should only consider rational arguments. You cannot just nack something without further explanation. If his explanation was "I will change my mind after we increase block size", I guess the community should say "then we will just ignore your nack because it makes no sense". In the same way, when people use fallacies (purposely or not) we must expose that and say "this fallacy doesn't count as an argument". But yeah, it would probably be good to define better what constitutes a "sensible objection" or something. That doesn't seem simple though.
it seems that some people would like to see that happening before the subsidies are low (not necessarily null), while other people are fine waiting for that but don't want to ever be close to the scale limits anytime soon. I would also like to know for how long we need to prioritize short term adoption in this way. As others have said, if the answer is "forever, adoption is always the most important thing" then we will end up with an improved version of Visa. But yeah, this is progress, I'll wait for your more detailed description of the tragedies that will follow hitting the block limits, assuming for now that it will happen in 12 months. My previous answer to the nervous "we will hit the block limits in 12 months if we don't do anything" was "not sure about 12 months, but whatever, great, I'm waiting for that to observe how fees get affected". But it should have been a question "what's wrong with hitting the block limits in 12 months?"
Mike Hearn again asserted the need for a leader:
There must be a single decision maker for any given codebase.
Bryan Bishop attempted to explain why this did not make sense with git architecture.
Finally, Gavin announced his intent to merge the patch into Bitcoin XT to bypass the peer review he had received on the bitcoin-dev mailing list.
submitted by sound8bits to sound8bits [link] [comments]

You don't need they Core / Blockstream devs - they need you.

http://38.media.tumblr.com/fa44a78d7d6f6a2e0536e611e43093a8/tumblr_inline_mjh5diUr7t1qz4rgp.jpg
This whole blocksize drama over the past year is actually based on a totally false premise: that somehow you have to "beg" the Core / Blockstream devs, or "debate" with them, or get some kind of "consensus" from them.
But they actually have no power of over you at all.
When's the last time Bitcoin users begged the Fed or Ben Bernanke or Janet Yellen or Christine Lagarde to do something?
So why are we wasting our time begging and debating for the past year with Core / Blockstream devs such as Gregory Maxwell and Adam Back and Peter Todd, who are simply ignoring everything we tell them?
You can tell how weak the Core / Blockstream devs actually are by the desperate tactics they engage in:
The Core / Blockstream decision-making process, based on:
  • a small group of Core / Blockstream devs ACKing and NACKing proposals on their mailing list;
  • (and now more recently) payments and incentives behind the scenes at Blockstream
...is totally disconnected from the actual needs and requirements of actual Bitcoin users, and dangerous to Bitcoin at the technical, systemic, and technical level.
Other devs such as JGarzik have recently pointed this out, and businesspeople are listening:
https://np.reddit.com/BitcoinMarkets/comments/3x4iqk/jeff_garzik_i_have_never_seen_this_much/
Jeff Garzik: "I have never seen this much disconnect between user wishes and dev outcomes in 20+ years of open source." ... "The worst possible outcome is letting the ecosystem randomly drift into the first Fee Event without openly stating the new economic policy choices and consequences."
Fortunately, in order to remove the Core / Blockstream devs from power, you don't have to engage in debating or begging at all.
All you have to do is ignore them and un-install the crippled Core / Blockstream code, and install Bitcoin code from other devs that will actually do what you want (eg, BIP 101 / XT).
What are the Core / Blockstream devs going to do then - stamp their feet and throw a temper-tantrum?
Begging them and debating them has merely been feeding into their totally unjustified sense of their own importance - and our totally unjustified sense of our own powerlessness.
You actually have all the power.
The Core / Blockstream devs are nobody if you simply refuse to run their code.
submitted by ydtm to btc [link] [comments]

The harvesting of passive supporters

This is a theory sketch of a feeling I developed as an observer of both Bitcoin attempt to raise the block size limit, and now the Ethereum hard-fork attempt to recover stolen DAO funds. In these cases two groups arise, one pro and other against the change. Lets call people* in these groups active supporters, and we expect that the side that is going to win is the side with most active supporters. What I argue is, in truth, active supporters are not the deciding players, and the real outcome is decided by the passive supporters.
Passive supporters are those people who are either ignorant of the issue, or don't care (and they are frequently ignorant because they don't care). They represent that 90% majority that doesn't vote on the pools' pools. Those who simply upgrade the software when the auto-upgrades pops up. They are those who activates a switch if they read that they must activate a switch, otherwise they will lose money, and don't question why there is a switch in the first place.
And what side gets to win such a dispute? The side with key people in position to herd and harvest most of the passive supporters. The role of active supporters is not to convince the other side, their role manage to reap the passive supporters, by any means they can. For instance, pro-HF active supporters in Ethereum mining pools managed to get the passive supporters in that pool by voting on what side the pool must take.
The "do nothing" side always begin with a distinct advantage, because this side, in principle, already have all the passive supporters. The side that requires all users to update their clients starts losing. If only the miners are required to update their clients, the disadvantage is smaller, but exists. Of course, for pool user, do nothing may be going with the side the pool took. Thus, pools choosing a side provides the greatest opportunity for reaping passive supporters: they don't have to do nothing, the choices was made for them.
Also, very relevant in Ethereum case, is the default setting of the client, in case of auto-update. Updating a software is not an action perceived as actively taking a political stance, although it can be in case of cryptocurrencies. Many users have their software updated automatically, like Ubuntu's PPA users, and for them, the "do nothing" position is just to let the auto-updater do their job (or manually upgrading, ignorant of the political consequences). Such passive supporters will end up following the "official stance".
After the "do nothing", what seems to be the most influential factor in passive supporters is leadership (particularly important to Chinese, it seems), or probably related, the "official stance". That seemed to be the single reason the Chinese reject the 8 MB block increase fork on Bitcoin (according to a biased account), and probably makes a huge difference when Vitalik goes about speaking for a hard fork. An e-mail allegedly from Satoshi Nakamoto criticizing Bitcoin XT fork made a huge attention, ironically undeserved, because using that name to voice a personal opinion stood against all the culture create by Satoshi Nakamoto himself in Bitcoin's mailing list: that is to value the content, not the author.
It is possible that there is nothing wrong with this state of things, but for me it just doesn't seem to be fair. I think that every such contending decision should be engineered to minimize the role of passive supporters.
Here follows some (probably unrealistic) proposals taking this issue into account:
As I said, some of these proposals may be unrealistic, or very hard to get, or wrong and unfair, but my goal here is to solve the problem, but make people aware of it, that the "passive supporters" are the majority, and consider their role in decision making processes. How fair and just that process really is in this perspective?
(*) In our case, "people" is actually hashrate, but the reasoning follows.
submitted by lcvella to ethereum [link] [comments]

How to incentivize miners to switch to XT

The idea is for XT to code in SPV mining as a native behavior during the time between when the next block's header arrives and the rest of the block. This will:
I stumbled on this mailing list thread https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010125.html
Sergio proposes:
SPV mining incentive will stay until there is no subsidy, as many other incentives. SPV mining also must be there to prevent malicious actors from DoS-ing the relay network. If it's there, then the DoS incentive disappears.
Let's code "instant" mining into Bitcoin Core, and do it right.
And Pieter responds:
I thought about this too. Since headers-first it would be trivial to do: if our best header is ahead of our best block, hand out an empty template in createblocktemplate, and we're done.
Unfortunately, Greg Maxwell pointed out that this (even with a time limit) amplifies selfish mining, since I can propagate headers before propagating blocks, in order to make others temporarily work on top of my chain.
Greg's concern is valid. If a selfish miner knew they could withhold their block (which may contain double-spends) but broadcast their headers and have people mine on top of it then that makes the problem much worse.
Is there a solution to this?
submitted by peoplma to bitcoinxt [link] [comments]

This graph shows Bitcoin price and volume (ie, blocksize of transactions on the blockchain) rising hand-in-hand in 2011-2014. In 2015, Core/Blockstream tried to artificially freeze the blocksize - and artificially froze the price. Bitcoin Classic will allow volume - and price - to freely rise again.

The graph below tells you everything you need to know about the way that Bitcoin price and volume normally always move in lockstep, tightly correlated with each other - until Blockstream tragically tried to interfere starting around 2015:
https://imgur.com/jLnrOuK
http://nakamotoinstitute.org/static/img/mempool/how-we-know-bitcoin-is-not-a-bubble/MetcalfeGraph.png
(There is a typo in the legend of the second graph linked above: "Bitcoin market map" should say "Bitcoin market cap[italization]".)
Bitcoin's "Metcalfe's Law" relationship between market cap and the square of the number of transactions
https://np.reddit.com/Bitcoin/comments/3x8ba9/bitcoins_metcalfes_law_relationship_between/
https://np.reddit.com/btc/comments/3x8mmc/bitcoins_metcalfes_law_relationship_between/
How We Know Bitcoin Is Not a Bubble
http://nakamotoinstitute.org/mempool/how-we-know-bitcoin-is-not-a-bubble/#selection-59.4-68.0
(Scroll down to see the graph - also note there is a typo in the legend: "Bitcoin market map" should say "Bitcoin market cap[italization]".)
Without artificial limits, Bitcoin volume and price are naturally and tightly correlated.
This tight, lockstep correlation between those two lines during 2011-2014 has been absolutely amazing - one of the tightest correlations you'll ever observe in any dynamic system anywhere, in economics, sociology, or nature.
Price and volume rose (and fell) hand-in-hand for 4 years straight - one of the most majestic examples of emergent phenomena in the whole history of economics.
Left to run its natural course, this graph would probably have continued in lockstep, and thus would have eventually gone into the history books of future generations, marking the inexorable emergence and dominance of the cryptocurrency known as Bitcoin - the inevitable triumph of humanity's first decentralized and permissionless store of value, medium of exchange, and unit of account - steadily rising through the years in price and volume - and in usefulness.
Then in late 2014, a new company called Blockstream tried to block this natural progression.
The oligarchs behind the ancien régime of debt-backed, violence-enforced infinite fiat thought they had figured out a clever way to attempt to make their last pièce de résistance while making some money too.
They brought out their their usual grab-bag of assorted dirty tricks which they typically use to take down any new social or economic or political movement that promises to liberate people from the stranglehold of private central bankers:
So far, Blockstream thinks they're winning in their battle to control Bitcoin.
  • They succeeded (during 2015) in splitting the community, maybe even creating even a few more useful idiots in the process.
  • They succeeded (during 2015) in suppressing the price: as you can see by observing how the lockstep correlation between price and volume diverged in 2015, with the price now lagging and sagging below the volume for the first time ever.
https://imgur.com/jLnrOuK
But can they keep spreading around their fiat and FUD to continue fooling all the people all the time?
Probably not. Because...
Now you can choose to run a repo without Blockstream's artificial scarcity on blocksize and transactions on the blockchain.
Now, instead of running the Bitcoin Core repo from Blockstream, you can run any one of these another tested and deployed repos, which do not artificially limit the blocksize to 1 MB:
Bitcoin is a natural, market-based and community-based, emergent phenomenon.
At its heart, in the words of Satoshi Nakamoto, Bitcoin is a P2P Electronic Cash System where Alice "A" can send to Bob "B" some amount of Coins "C", secured via a cryptographic signature.
It may come as a shock to certain people's egos, but even if most of the devs were to suddenly stop working now - the current system would probably work fine for the next few years - with investors and businesspeople continuing to gradually increase the price and volume in accordance with the desires of the worldwide market, and miners and full-nodes continuing to gradually increase the "max blocksize" in accordance with the capacity of the worldwide infrastructure - and everyone continuing to innovate and participate in the growth of the system in accordance with the desires of the worldwide community.
Bitcoin doesn't really need a whole lot of interference from devs trying to centrally plan what the "max blocksize" should be - or mods trying to centrally control what the "consensus of opinions" should be. These kinds of things are better left to just naturally emerge on their own.
Central planning and control are not needed.
As we have already seen, when the market is allowed to determine Bitcoin price and volume on its own, they both naturally go up, hand-in-hand - while the value of centrally-planned fiat goes down and and down.
And when the community is allowed to determine upvotes and downvotes on its own, the quality of debate naturally goes up - while the quality of centrally-controlled debate on censored forums goes down and down.
We all know that Bitcoin is supposed to be trustless and permissionless.
Bitcoin development should also be egoless.
As a dev or a mod, it's hard to "step aside" and let the market or the community decide. It's much more tempting to interfere: enforce a limit here, delete a comment there.
But the market and the community are emergent phenomena. They work best when devs and mods learn to put aside their egos and "step back" and let the market and the community do what they will.
This is the raison d'être of Bitcoin Classic, Bitcoin Unlimited, and Bitcoin XT: learning to let the market and the community decide again - learning to step back again, and let the price and volume go up again, with no unnecessary interference from devs or mods.
https://imgur.com/jLnrOuK
submitted by ydtm to btc [link] [comments]

Schnorr BIP, Taproot BIP, Tapscript BIP ~ bitcoin-dev Mailing List Free Crypto Trading Bot – Bitcoin MACD strategy - YouTube The Mailing List where Bitcoin Began, with Perry Metzger Bitcoin What...? - YouTube

Bitcoin XT is an implementation of a Bitcoin full node that embraces Bitcoin's original vision of simple, reliable, low-cost transactions for everyone in the world. Bitcoin XT originated as a series of patches on top of Bitcoin Core and is now a independently maintained software fork. See our ... Bitcoin was born through an online forum. Satoshi Nakamoto, Bitcoin’s founder, first published its white paper in late 2008 on the cypherpunk mailing list, which was used by cryptographers from around the globe beginning in the 1990s. Bitcoin’s initial growth was also largely driven by various online hacker forums. Bitcoin XT was a fork of Bitcoin Core, the reference client for the bitcoin network. Skip to content. Menu. Home; Sample Page; Uncategorized Posted on October 4, 2020 October 4, 2020. Bitcoin Regrets: How Much Would $100 Be Worth Today? Bitcoin Regrets: How Much Would $100 Be Worth Today? Mining gives legitimacy to Satoshi Nakamoto’s imaginative and prescient, enabling a decentralised and ... Bitcoin XT is an implementation of a Bitcoin Cash (BCH) full node that embraces Bitcoin's original vision of simple, reliable, low-cost transactions for everyone in the world. Bitcoin XT originated as a series of patches on top of Bitcoin Core and is now a independently maintained software fork. See some selected features. Bitcoin XT downloads are code signed and are built reproducibly using ... I have been following the recent block size debates through the mailing list. I had hoped the debate would resolve and that a fork proposal would achieve widespread consensus. However with the formal release of Bitcoin XT 0.11A, this looks unlikely to happen, and so I am forced to share my concerns about this very dangerous fork.The developers of this pretender-Bitcoin claim to be following my ...

[index] [41420] [20262] [21651] [17468] [5636] [15483] [46108] [43255] [4237] [34744]

Schnorr BIP, Taproot BIP, Tapscript BIP ~ bitcoin-dev Mailing List

=====(暗号通貨 初心者)===== #bitcoin #仮想通貨 #暗号資産 【初心者必見】ブロックチェーン丸わかり徹底解説 #暗号通貨 アクア #暗号通貨 確定申告 ... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. - What Bitcoin XT is and how it differs from Bitcoin Core - The roadmap ahead and how a transition to BitcoinXT would occur - Update on Lighthouse Links mentioned in this episode: - The Capacity ... Here are two BIP drafts that specify a proposal for a Taproot softfork. A number of ideas are included: * Taproot to make all outputs and cooperative spends indistinguishable from eachother ... We tested the service and it worked very well. 5/5 stars, full grade horseshit as promised. http://motherboard.vice.com

#