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 scripts.
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
I do like that the volume of emails has been reduced substantially. I used
to delete hordes of dev emails because I couldn't keep up. At least now I
feel like I'm able to skim most things that look interesting and I get to
assume that if the subject seems relevant to me the content is worthwhile.
> 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 soft
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 chann
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
either
I like the idea of having some way for developers to show that they've
given an idea legitimate consideration, as I feel some proposals are often
considered much more in depth before rejection than the proposer realizes,
however I don't think any sort of on-chain system really makes sense. It
compl
I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
The s
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 been done) and negot
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
https://lists.
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 bitcoin
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
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 ca
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
ver
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 think you would see far more use
> > When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
> Why is that a given? Is there math that outlines what the risk levels
are for various configurations of node distribution
> 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 transaction
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 th
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 multipl
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 RAM
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 av
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 t
>
> 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 hav
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 "
*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 f
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 o
think the only way to increase full nodes it to design an incentive for
> people to run them
>
The primary incentive is the sovereignty that it gives you. Running a
Bitcoin full node gives you security and protection against political
garbage that you can't get any other way. The net
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 t
28 matches
Mail list logo
