Re: [bitcoin-dev] Censorship

I am not sure that this is on-topic for the bitcoin-dev mailing list, but it seems politically relevant enough that I'm going to respond. /r/bitcoin and bitcointalk.org are both discussion websites that pertain to a specific topic. All (or nearly all) discussion websites pertaining to a specific

[bitcoin-dev] Proposal - Mandatory Weak Blocks

Prior discussion: http://gnusha.org/bitcoin-wizards/2015-11-09.log Goal: Increase transaction throughput without increasing miner centralization pressure, and without putting undue burden on full validating nodes. 'Weak Block': a block which meets a target with a lower difficulty, typically some

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

> I love seeing data! I was considering 0.10 nodes as 'unmaintained' because it has been a long time since the 0.11 release. https://packages.gentoo.org/packages/net-p2p/bitcoin-qt The Gentoo package manager still has 0.10.2 as the most recent stable version. Getting a later version of the

Re: [bitcoin-dev] Three hardfork-related BIPs

On Jan 29, 2017 2:28 PM, "Tom Harding via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: If that's true, why haven't we already seen AML/KYC required of mining pools? That would be comparatively trivial. Some regulators are already looking into it. Even at this point you'd

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

No, Bitcoin classic only activates if 75% of the _miners_ adopt it. That says nothing about the broader network and indeed is much easier to achieve through politicking, bribery, coercion, and other tomfoolery as 75% of the hashrate is ultimately only a dozen people or so. You have plenty of

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

> What we want is a true fee-market where the miner can decide to make a block > smaller to get people to pay more fees, because if we were to go to 16MB > blocks in one go, the cost of the miner would go up, but his reward based on > fees will go down! > A block so big that 100% of the

Re: [bitcoin-dev] High fees / centralization

On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Raystonn, Your logic is very hard to dispute. An important special case is small miners. Small miners use pools exactly because they want smaller, more frequent payments. Rising fees force

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Perhaps you are fortunate to have a home computer that has more than a single 512GB SSD. Lots of consumer hardware has that little storage. Throw on top of it standard consumer usage, and you're often left with less than 200 GB of free space. Bitcoin consumes more than half of that, which feels

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Mar 29, 2017 12:20 PM, "Andrew Johnson" wrote: What's stopping these users from running a pruned node? Not every node needs to store a complete copy of the blockchain. Pruned nodes are not the default configuration, if it was the default configuration then I

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Mar 29, 2017 9:50 AM, "Martin Lízner via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Im tending to believe, that HF is necessary evil now. I will firmly disagree. We know how to do a soft-fork blocksize increase. If it is decided that a block size increase is justified, we

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Sure, your math is pretty much entirely irrelevant because scaling systems to massive sizes doesn't work that way. At 400B transactions per year we're looking at block sizes of 4.5 GB, and a database size of petabytes. How much RAM do you need to process blocks like that? Can you fit that much

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

I am in support of having multiple PoW forks to choose from, but it is indeed problematic to have one chain running a rotation of algorithms. The reason I support multiple algos is because we don't want an attacker secretly making asics ahead of time in the event of an emergency PoW fork. We want

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

I have a practical concern related to the amount of activation energy required to get something like this through. We are talking about implementing something that would remove tens to hundreds of millions of dollars of mining revenue for miners who have already gambled that this income would be

Re: [bitcoin-dev] A Small Modification to Segwit

On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: I can speak from personal experience regarding another very prominent altcoin that attempted to utilize an asic-resistant proof of work algorithm, it is only a matter of time before the

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

Most people do not want to go out and buy new hardware to run a Bitcoin node. The want to use the hardware that they already own, and usually that hardware is going to have a non-generous amount of disk space. 500GB SSD with no HDD is common in computers today. But really, the best test is to go

[bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

*Rationale:* A node that stores the full blockchain (I will use the term archival node) requires over 100GB of disk space, which I believe is one of the most significant barriers to more people running full nodes. And I believe the ecosystem would benefit substantially if more users were running

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

we can keep the resource requirements of this altruism low, I think we can expect it to continue. This proposal attempts to keep those requirements low. On Tue, Apr 18, 2017 at 6:50 AM, Tom Zander <t...@freedommail.ch> wrote: > On Monday, 17 April 2017 08:54:49 CEST David Vorick vi

Re: [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

What, in your appraisal, is the purpose of the block size limit? I think we will be more able to have a productive discussion around this proposal if we clear that up first. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Flag day activation of segwit

That's simply a 51% attack choosing to censor transactions. We could do that today, ban all transactions that aren't approved by the PBoC. You respond to that with a PoW hardfork, or by finding some way to prop up / subsidize non-censorship miners. On Mar 13, 2017 5:59 AM, "Nick ODell via

Re: [bitcoin-dev] Moving towards user activated soft fork activation

On Mar 5, 2017 6:48 PM, "Eric Voskuil" wrote: Independent of one's opinion on the merits of one fork or another, the state of centralization in Bitcoin is an area of great concern. If "we" can sit down with 75% of the economy and/or 90% of the hash power (which of course has

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Thu, Apr 6, 2017 at 2:24 AM, Jonathan Toomim via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Ethically, this situation has some similarities to the DAO fork. We have > an entity who closely examined the code, found an unintended characteristic > of that code, and made use of

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

> > Another thing that could be done is increase the number of times SHA256 is > performed... but now we are really talking about altering the PoW > algorithm. Correct me if I'm wrong: The more number of times its > performed, the less any patent-able pre or post calculation > skipping/caching

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

No one is suggesting anything like this. The cost of running a node that could handle 300% of the 2015 worldwide nonbitcoin transaction volume today would be a rounding error for most exchanges even if prices didn't rise. Then explain why PayPal has multiple datacenters. And why Visa has

Re: [bitcoin-dev] Miniscript

Glad to see this post. I have been following Miniscript for some time, and the static analysis that is possible with Miniscript is particularly interesting to me. Today, new Bitcoin applications such as JoinMarket, Wasabi wallet, and Arwen all suffer from a problem of having novel bitcoin