Re: [bitcoin-dev] Miniscript

[David Vorick via bitcoin-dev]

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. Bitcoin script is
not easy to
analyze, and historically it has been difficult for me to get comfortable
using these
applications because I have been unable to convince myself to have complete
confidence in the integrity of the transactions these applications want me
to sign.

Well established applications can eventually overcome this issue for users
by
getting sufficient expert review and commentary, however this proves as a
substantial barrier to entry in an ecosystem that is ideally as open as
possible.

Miniscript can make a huge difference here. With Miniscript, it possible to
create
hardware wallets that can perform static analysis on novel miniscripts and
provide
the user with assurances about the nature of the transactions. A hardware
wallet
with a Miniscript analyzer may not be able to tell you that a transaction
is a
CoinJoin transaction, but it will be able to tell you that under all
possible scenarios,
you end up with just as many coins in your addresses that you started with,
modulo
some transaction fee.

This is a big deal for novel application writers, as it significantly
reduces the barrier
for them to convince both themselves and others that the code they wrote
does not
risk user funds being lost, especially if all transactions are being
externally analyzed
and signed.

Miniscript is not of course a complete solution, for example it cannot
solve all of the
high-risk edge cases that are present in the lightning network, but it is a
big step
forward and I believe that widespread use of Miniscript would be a huge
boon to the
Bitcoin ecosystem.

On Mon, Aug 19, 2019 at 7:18 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Miniscript is a project we've been working on for the past year or so,
> and is now at a stage where I'd like to get it some more attention. It is
> joint
> work with Andrew Poelstra and Sanket Sanjalkar.
>
> It's a language for writing (a subset of) Bitcoin Scripts in a structured
> way,
> enabling analysis, composition, generic signing and more.
>
> For example the script
>
>OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 
>   OP_EQUALVERIFY OP_CHECKSIGVERIFY <144> OP_CSV OP_ENDIF
>
> in Miniscript notation would be
>
>   or_d(c:pk(A),and_v(vc:pk_h(B),older(144)))
>
> making it human (engineer?) readable that this is a script that permits A
> to
> take the coins at any time, and B after 1 day. A full description of the
> language can be found on the project website
> http://bitcoin.sipa.be/miniscript
>
> Using Miniscript it's possible to:
> * Write descriptors for addresses for scripts that implement things more
>   complicated than multisig.
> * Make software that can deal with composition of policies (e.g. have funds
>   in a 2-of-3 setup where one of the 3 "keys" is itself a policy that
> involves
>   perhaps multiple devices and timeouts).
> * Compile complex spending policies to efficient scripts.
> * Figure out under what necessary and/or sufficient conditions a script
> can be
>   satisfied.
> * Given signatures for a sufficient set of keys (and hash preimages, if
> needed),
>   generically construct a witness for arbitrary scripts, without metadata
>   apart from the script itself and public keys appearing in it. This means
>   generic PSBT signers are possible for this class of scripts.
> * Compute the bounds on the size of a witness for arbitrary scripts.
> * Perform static analysis to see if any of Script's resource limitations
>   (ops limit, stack size, ...) might interfere with the ability to spend.
> * Who knows what else...
>
> We have two implementations:
> * a C++ one (https://github.com/sipa/miniscript)
> * a Rust library (https://github.com/apoelstra/rust-miniscript).
>
> The implementations are a work in progress, but through large scale
> randomized
> tests we have confidence that the language design and associated witnesses
> are
> compatible with the existing consensus and standardness rules.
>
> To be clear: Miniscript is designed for Bitcoin as it exists today
> (primarily
> P2WSH), and does not need any consensus changes. That said, we plan to
> extend
> the design to support future script changes Bitcoin may include.
>
> Cheers,
>
> --
> Pieter
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

ill need some way to find all of their historical
transactions. The problem is not fetching blocks, it's figuring out which
blocks are worth fetching. It may be sufficient to have nodes store a bloom
filter for each block indicating which addresses had activity. The bloom
filter would probably only need to be about 1% of the size of the full
block. That's not too much overhead (now you are storing 21% of the block
instead of just 20%), and would retain SPV compatibility.

On Mon, Apr 17, 2017 at 12:17 PM, praxeology_guy <
praxeology_...@protonmail.com> wrote:

>
> FYI With unspent coin snapshots, needing archive data becomes less
> important.  People can synchronize from a later snapshot instead of the
> genesis block.  See https://petertodd.org/2016/delayed-txo-commitments
> for my current favorite idea.
>
>
This is something that I think could help a lot too. If the build processes
included verifying the chain and then creating a utxo snapshot at say,
block 400,000, then nodes would no longer need to download, store, upload,
or share blocks prior to that height. It means that a reorg deeper than
that point would hardfork the network. But a reorg 60k blocks deep is going
to cause problems worse than a network split. Then, the only people who
would ever need to care about the early blocks are developers, and it's
more reasonable to expect developers to go through a longer process and
have more resources than everyday users.

On Mon, Apr 17, 2017 at 6:14 AM, Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While I fully agree with the intent (increasing full nodes so a big miner
> waking up in a bad mood can't threaten the world any longer every day as it
> is now) I am not sure to get the interest of this proposal, because:
>
> - it's probably not a good idea to encourage the home users to run full
> nodes, there are many people running servers far from their capacity that
> could easily run efficient full nodes
>
Running a full node is the only way to avoid needing to trust others. It's
also how you make your opinion worthwhile for events like hard forks and
UASFs. If decentralization is the primary motivation, it absolutely makes
sense to encourage people to run their own full nodes. Without a full node,
you are at the mercy of the governance decisions by those who do have full
nodes. But if you have a full node, you can chose to opt-out of any upgrade
(example: ethereum classic nodes).


> - if someone can't allocate 100 GB today to run a full node, then we can't
> expect him to allocate more in the future
>
That's why I'm proposing something to decrease the storage requirements.


> - this proposal is a kind of reinventing torrents, while limiting the
> number of connections to something not efficient at all, I don't see why
> something that is proven to be super efficient (torrents) would be needed
> to be reinvented, I am not saying that it should be used as the bittorrent
> network is doing but the concepts can be reused
>
It's different from torrents in that it uses specialized erasure coding to
make sure that every block is always available, even if an adversary is
running around targeting all the nodes with a particular piece.


> - I don't get at all the concept of "archival" nodes since it's another
> useless step toward centralization
>
"archival" nodes are simply nodes with the full blockchain. Nobody can
bootstrap on the network without them. Today, every bitcoin-core node is an
archival node by default.

> I 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 network does currently depend
on altruism to allow people to download the blockchain, but as long as 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  wrote:

> On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote:
> > The best alternative today to storing the full blockchain is to run a
> > pruned node
>
> The idea looks a little overly complex to me.
>
> I suggested something similar which is a much simpler version;
> https://zander.github.io/scaling/Pruning/
>
> > # Random pruning mode
> >
> > There is a large gap between the two current modes of everything
> > (currently 75GB) and only what we need (2GB or so).
> >
> > This mode would have two areas, it would keep a days worth of blocks to
> > make sure that any reorgs etc would not cause a re-d

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

[David Vorick via bitcoin-dev]

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 out and talk to people. Ask them if they
run a full node, and if they say no, ask them why not. In my experience,
the most common answer by a significant margin is that they don't want to
lose the disk space. That psychology is far more important than any example
of cheap hard drives. People don't want to go out and buy a hard drive so
that they can run Bitcoin. It's a non-starter.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

*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 full nodes.

The best alternative today to storing the full blockchain is to run a
pruned node, which keeps only the UTXO set and throws away already verified
blocks. The operator of the pruned node is able to enjoy the full security
benefits of a full node, but is essentially leeching the network, as they
performed a large download likely without contributing anything back.

This puts more pressure on the archival nodes, as the archival nodes need
to pick up the slack and help new nodes bootstrap to the network. As the
pressure on archival nodes grows, fewer people will be able to actually run
archival nodes, and the situation will degrade. The situation would likely
become problematic quickly if bitcoin-core were to ship with the defaults
set to a pruned node.

Even further, the people most likely to care about saving 100GB of disk
space are also the people least likely to care about some extra bandwidth
usage. For datacenter nodes, and for nodes doing lots of bandwidth, the
bandwidth is usually the biggest cost of running the node. For home users
however, as long as they stay under their bandwidth cap, the bandwidth is
actually free. Ideally, new nodes would be able to bootstrap from nodes
that do not have to pay for their bandwidth, instead of needing to rely on
a decreasing percentage of heavy-duty archival nodes.

I have (perhaps incorrectly) identified disk space consumption as the most
significant factor in your average user choosing to run a pruned node or a
lite client instead of a full node. The average user is not typically too
worried about bandwidth, and is also not typically too worried about
initial blockchain download time. But the 100GB hit to your disk space can
be a huge psychological factor, especially if your hard drive only has
500GB available in the first place, and 250+ GB is already consumed by
other files you have.

I believe that improving the disk usage situation would greatly benefit
decentralization, especially if it could be done without putting pressure
on archival nodes.

*Small Nodes Proposal:*

I propose an alternative to the pruned node that does not put undue
pressure on archival nodes, and would be acceptable and non-risky to ship
as a default in bitcoin-core. For lack of a better name, I'll call this new
type of node a 'small node'. The intention is that bitcoin-core would
eventually ship 'small nodes' by default, such that the expected amount of
disk consumption drops from today's 100+ GB to less than 30 GB.

My alternative proposal has the following properties:

+ Full nodes only need to store ~20% of the blockchain
+ With very high probability, a new node will be able to recover the entire
blockchain by connecting to 6 random small node peers.
+ An attacker that can eliminate a chosen+ 95% of the full nodes running
today will be unable to prevent new nodes from downloading the full
blockchain, even if the attacker is also able to eliminate all archival
nodes. (assuming all nodes today were small nodes instead of archival nodes)

Method:

A small node will pick an index [5, 256). This index is that node's
permanent index. When storing a block, instead of storing the full block,
the node will use Reed-Solomon coding to erasure code the block using a
5-of-256 scheme. The result will be 256 pieces that are 20% of the size of
the block each. The node picks the piece that corresponds to its index, and
stores that instead. (Indexes 0-4 are reserved for archival nodes -
explained later)

The node is now storing a fragment of every block. Alone, this fragment
cannot be used to recover any piece of the blockchain. However, when paired
with any 5 unique fragments (fragments of the same index will not be
unique), the full block can be recovered.

Nodes can optionally store more than 1 fragment each. At 5 fragments, the
node becomes a full archival node, and the chosen indexes should be 0-4.
This is advantageous for the archival node as the encoded data for the
first 5 indexes will actually be identical to the block itself - there is
no computational overhead for selecting the first indexes. There is also no
need to choose random indexes, because the full block can be recovered no
matter which indexes are chosen.

When connecting to new peers, the indexes of each peer needs to be known.
Once peers totaling 5 unique indexes are discovered, blockchain download
can begin. Connecting to just 5 small node peers provides a >95% chance of
getting 5 uniques, with exponentially improving odds of success as you
connect to more peers. Connecting to a single archive node guarantees that
any gaps can be filled.

A good encoder should be able to turn a block into a 5-of-256 piece set in
under 10 mi

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

[David Vorick via bitcoin-dev]

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 "asic resistant"
algorithm gets its own Asics.  The more complicated the algorithm, the more
secretive the asic technology is developed.  Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs.  I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.

On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev"  wrote:

> Curious: I'm not sure why a serious discussion of POW change is not on the
> table as a part of a longer-term roadmap.
>
> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
> the proven, np-complete graph-theoretic or polygon manipulation POW would
> keep Bitcoin in commodity hardware and out of the hands of centralized
> manufacturing for many years.
>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term.   I've heard the
> term "level playing field" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a
> part of good maintenance of cryptocurrency in general.   Killing the
> existing POW, and using an as-yet undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date.   This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


The real bottleneck today is the amount of capex required to achieve
optimal mining. I am strongly in favor of PoW research that investigates
better PoW, but I do not think that any obvious strategies are known yet to
improve substantially on computation heavy hashcash.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

>
> 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 have an effect on efficiency.
>

The more complex that the PoW algorithm is, the more likely it is that
someone finds a unique and special method for optimizing it that they are
able to patent. And the more difficult it is to create specialized hardware
to run that algorithm, meaning that there will be fewer players who are
able to do so profitably (higher fixed costs).

If you want to talk about changing the PoW algorithm, you really want to be
looking to simplify it so that it's more obvious (not that you can ever be
completely sure) that there are no hidden or unexpected optimizations that
someone could patent.

We can even do a lot better than SHA. Cryptographic hash functions need to
be collision resistant, and collision resistance is the property that
usually breaks. Preimage resistance and partial preimage resistance (and
second preimage resistance) is generally easier to protect - to the best of
our knowledge, md5 would actually still be a secure PoW function today.

It's bitterly ironic to me that so much research and effort has been put
into making asic-resistant PoW algorithms when in the long run
asic-resistance only leads to problems like these - single parties who have
found significant optimizations and not shared them, completely destroying
any chance of a level playing field and giving themselves a centralized
monopoly - a result that is supremely unhealthy for the rest of the
community.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 that characteristic in order to gain tens of
> millions of dollars. Now that developers are aware of it, they want to
> modify the code in order to negate as much of the gains as possible.
>
> There are differences, too, of course: the DAO attacker was explicitly
> malicious and stole Ether from others, whereas Bitmain is just optimizing
> their hardware better than anyone else and better than some of us think
> they should be allowed to.
>
> In both cases, developers are proposing that the developers and a majority
> of users collude to reduce the wealth of a single entity by altering the
> blockchain rules.
>
> In the case of the DAO fork, users were stealing back stolen funds, but
> that justification doesn't apply in this case. On the other hand, in this
> case we're talking about causing someone a loss by reducing the value of
> hardware investments rather than forcibly taking back their coins, which is
> less direct and maybe more justifiable.
>
> While I don't like patented mining algorithms, I also don't like the idea
> of playing Calvin Ball on the blockchain. Rule changes should not be
> employed as a means of disempowering and empoverishing particular entities
> without very good reason. Whether patenting a mining optimization qualifies
> as good reason is questionable.
>

Bitmain is blocking protocol upgrades to preserve their mining advantage.
This is quite distinct from someone taking advantage of a visibly broken
and highly toxic smart contract to net themselves tens of millions of
dollars. Further, Bitmain is performing a patented hardware optimization.
The patents mean that other miners are unable to capitalize on these
optimizations. These optimizations are to the tune of 30%. If you give one
player in the mining industry a permanent 30% cost advantage they will
eventually own everything. It's an industry where margins tend towards zero.

The asicboost patent is a direct threat to the health of the Bitcoin
ecosystem, and now we have visible proof. The war against segwit and the
strife with Bitcoin Unlimited was very damaging to the ecosystem, damaging
to the price, and holding back significant improvements and upgrades to the
Bitcoin protocol. I interpret this as a direct attack on the Bitcoin
ecosystem.

I don't know if changing the rules to nullify asicboost is the right move.
I'm sure this won't be the last patent that causes damage to the ecosystem.
But you need to recognize that the issue is not that Bitmain ran a hardware
optimization. It's that hardware optimizations exist which directly inhibit
upgrading the protocol. And it's that hardware optimizations exist
encumbered by patents enough to give one party a decisive advantage in
mining, decisive enough for them to build a single, centralized monopoly.

Each problem is separate, and each problem is significant, and each problem
is fundamental. The DAO attack was a one-time bout of stupidity that
threatened a fixed amount of money. asicboost is an ongoing status that
directly damages Bitcoin's ability to upgrade, and directly damage
Bitcoin's ability to retain any modicum of decentralization in the
hashrate. The DAO issue did neither of these things for ethereum.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 available to them.

That's not something they are going to let go of without a fight, and we've
already seen this with the segwit resistance. Further, my understanding is
that this makes a UASF a lot more difficult. Mining hardware that has
unique optimizations on one chain only can resist a UASF beyond a simple
economic majority, because they can do more hashes on the same amount of
revenue. Threshold for success is no longer 51%, especially if you are
expecting the miners to struggle (and this is a case where they have a very
good reason to struggle). Any resistance from the hashrate during the early
days of a UASF will inevitably cause large reorgs for older nodes, and is
not much better than a hardfork.

I don't know what the right answer is. But I know that we are not going to
get segwit without a fight. We are not going to invalidate covert asicboost
without a fight. And we are working with a system that actively (and is
demonstrably very effective at doing it) resists changes which are
contentious. This is definitely a contentious change, because an important
part of the community (the miners) is going to be actively resisting it.

I urge everybody to realize how difficult something like this is going to
be to pull off. We are literally talking about invalidating hardware (or at
least the optimized bits). It's only going to succeed if everybody is
conclusively on board. As you consider proposals, realize that anything
which is not the simplest and least contentious is already dead.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 into a single machine? Okay, you can't fit
that much RAM into a single machine. So you have to rework the code to
operate on a computer cluster.

Already we've hit a significant problem. You aren't going to rewrite
Bitcoin to do block validation on a computer cluster overnight. Further,
are storage costs consistent when we're talking about setting up clusters?
Are bandwidth costs consistent when we're talking about setting up
clusters? Are RAM and CPU costs consistent when we're talking about setting
up clusters? No, they aren't. Clusters are a lot more expensive to set up
per-resource because they need to talk to eachother and synchronize with
eachother and you have a LOT more parts, so you have to build in
redundancies that aren't necessary in non-clusters.

Also worth pointing out that peak transaction volumes are typically 20-50x
the size of typical transaction volumes. So your cluster isn't going to
need to plan to handle 15k transactions per second, you're really looking
at more like 200k or even 500k transactions per second to handle
peak-volumes. And if it can't, you're still going to see full blocks.

You'd need a handful of experts just to maintain such a thing. Disks are
going to be failing every day when you are storing multiple PB, so you
can't just count a flat cost of $20/TB and expect that to work. You're
going to need redundancy and tolerance so that you don't lose the system
when a few of your hard drives all fail within minutes of eachother. And
you need a way to rebuild everything without taking the system offline.

This isn't even my area of expertise. I'm sure there are a dozen other
significant issues that one of the Visa architects could tell you about
when dealing with mission-critical data at this scale.



Massive systems operate very differently and are much more costly per-unit
than tiny systems. Once we grow the blocksize large enough that a single
computer can't do all the processing all by itself we get into a world of
much harder, much more expensive scaling problems. Especially because we're
talking about a distributed system where the nodes don't even trust each
other. And transaction processing is largely non-parallel. You have to
check each transaction against each other transaction to make sure that
they aren't double spending eachother. This takes synchronization and
prevents 500 CPUs from all crunching the data concurrently. You have to be
a lot more clever than that to get things working and consistent.

When talking about scalability problems, you should ask yourself what other
systems in the world operate at the scales you are talking about. None of
them have cost structures in the 6 digit range, and I'd bet (without
actually knowing) that none of them have cost structures in the 7 digit
range either. In fact I know from working in a related industry that the
cost structures for the datacenters (plus the support engineers, plus the
software management, etc.) that do airline ticket processing are above $5
million per year for the larger airlines. Visa is probably even more
expensive than that (though I can only speculate).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 multiple
datacenters. And why the banking systems have multiple datacenters each.

I'm guessing it's because you need that much juice to run a global payment
system at the transaction volumes that they run at.

Unless you have professional experience working directly with transaction
processors handling tens of millions of financial transactions per day, I
think we can fully discount your assessment that it would be a rounding
error in the budget of a major exchange or Bitcoin processor to handle that
much load. And even if it was, it wouldn't matter because it's extremely
important to Bitcoin's security that it's everyday users are able to and
are actively running full nodes.

I'm not going to take the time to refute everything you've been saying but
I will say that most of your comments have demonstrated a similar level of
ignorance as the one above.

This whole thread has been absurdly low quality.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] High fees / centralization

[David Vorick via bitcoin-dev]

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 them to take payments less frequently, and will only tend
to make more of them give up.

With fees rising superlinearly, this centralizing effect is much stronger
than the oft-cited worry of small miners joining large pools to decrease
orphan rates.


Miners get paid on average once every ten minutes. The size of fees and the
number of fee transactions does not change the payout rate.

Further, we are very far from the point (in my appraisal) where fees are
high enough to block home users from using the network.

Bitcoin has many high-value use cases such as savings. We should not throw
away the core innovation of monetary sovereignty in pursuit of supporting
0.1% of the world's daily transactions.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

> 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 transactions will always be mined in the
> next block will just cause a large section of people to no longer feel the
> need to pay fees.

> As such I don’t fear the situation where the block size limit goes up a
lot
> in one go, because it is not in anyone’s interest to make the actual block
> size follow.

There have been attacks demonstrated where a malicious miner with
sufficient hashrate can leverage large blocks to exacerbate selfish mining.
Adversarial behaviors from miners need to be considered, it's not safe to
simply assume that a miner won't have reasons to attack the network. We
already know that large empty blocks (rather, blocks with fake
transactions) can be leveraged in ways that both damages the network and
increases miner profits.

In general, fear of other currencies passing Bitcoin is unsubstantiated.
Bitcoin has by far the strongest development team, and also is by far the
most decentralized. To the best of my knowledge, Bitcoin is the only
cryptocurrency out there that is both not-dead and also lacks a strong
central leadership.

A coin like ethereum may even be able to pass Bitcoin in market cap. But
that's okay. Ethereum has very different properties and it's not something
I would trust as a tool to provide me with political sovereignty. Ethereum
passing Bitcoin in market cap does not mean that it has proved superior to
Bitcoin. It could just mean that enterprises are really excited about
permissioned blockchains. That's not interesting to me at any market cap.

Bitcoin's core value add is and should continue to be decentralization and
trustlessness. Nobody is remotely close to competing with Bitcoin on those
fronts, and in my mind that's far more important than any of the other
mania anyway.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

> > 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 distributions, vulnerabilities,
etc?  How does one even evaluate the costs versus the benefits of node
costs versus transaction fees?

It's a political assessment. Full nodes are the ultimate arbiters of
consensus. When a contentious change is suggested, only the full nodes have
the power to either accept or reject this contentious change. If home users
are not running their own full nodes, then home users have to trust and
rely on other, more powerful nodes to represent them. Of course, the more
powerful nodes, simply by nature of having more power, are going to have
different opinions and objectives from the users. And it's impossible for
5000 nodes to properly represent the views of 5,000,000 users. Users
running full nodes is important to prevent political hijacking of the
Bitcoin protocol. Running a full node yourself is the only way to guarantee
(in the absence of trust - which Bitcoin is all about eliminating trust)
that changes you are opposed to are not introduced into the network.

> Disk space is not the largest cost, either today or in the future.
Without historical checkpointing in some fashion, bandwidth costs are more
than 2 orders of magnitude higher cost than every other cost for full
listening nodes.

This statement is not true for home users, it is true for datacenter nodes.
For home users, 200 GB of bandwidth and 500 GB of bandwidth largely have
the exact same cost. I pay a fixed amount of money for my internet, and if
I use 500 GB the cost is identical to if I use 200 GB. So long as bandwidth
is kept under my home bandwidth cap, bandwidth for home nodes is _free_.

Similarly, disk space may only be $2/TB in bulk, but as a home user I have
a $1000 computer with 500 GB of total storage, 100 GB seems
(psychologically) to cost a lot closer to $200 than to $2. And if I go out
and buy an extra drive to support Bitcoin, it's going to cost about $50 no
matter what drive I pick, because that's just how much you have to spend to
get a drive. The fact that I get an extra 900 GB that I'm not using is
irrelevant - I spent $50 explicitly so I could run a bitcoin node.

The financials of home nodes follow a completely different math than the
costs you are citing by quoting datacenter prices.

> I don't know how to evaluate the impacts of RAM or CPU usage, or
consequently electricity usage for a node yet.  I'm open to quantifying any
of those if there's a method, but it seems absurd that ram could even
become a signficant factor given the abundance of cheap ram nowadays with
few programs needing it.

Many home machines only have 4GB of RAM. (I am acutely aware of this
because my own software consumes about 3.5GB of RAM, which means all of our
users stuck at 4 GB cannot use my software and Chrome at the same time).
0.14 uses more than 1 GB of RAM. This I think is not really a problem for
most people, but it becomes a problem if the amount of RAM required grows
enough that they can't have all of their programs open at the same time.
1GB I think is really the limit you'd want to have before you'd start
seeing users choose not to run nodes simply because they'd rather have 300
tabs open instead.

CPU usage I think is pretty minimal. Your node is pretty busy during IBD
which is annoying but tolerable. And during normal usage a user isn't even
going to notice. Same for electricity. They aren't going to notice at the
end of the month if their electricity bill is a dollar higher because of
Bitcoin.

> The consequence of your logic that holds node operational costs down is
that transaction fees for users go up, adoption slows as various use cases
become impractical, price growth suffers, and alt coins that choose lower
fees over node cost concerns will exhibit competitive growth against
Bitcoin's crypto-currency market share.  Even if you are right, that's
hardly a tradeoff not worth thoroughly investigating from every angle, the
consequences could be just as dire for Bitcoin in 10 years as it would be
if we made ourselves vulnerable.

This is very much worth considering. If transaction fees are so high that
there is no use case at all for people unwilling to buy extra hardware for
Bitcoin (a dedicated node or whatever), then there is no longer a reason to
worry about these people as users. However, I think the fees would have to
get in the $50 range for that to start to be the case. When talking about
emergency funds - that is, $10k+ that you keep in case your government
defaults, hyperinflates, seizes citizen assets, etc. etc. (situations that
many Bitcoin users today have to legitimately worry about), then you are
going to be making a few transactions per year at most, and the cost of
fees on a home node may be $150 / yr, whi

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

[David Vorick via bitcoin-dev]

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 users running a pruned
node.

But that would also substantially increase the burden on archive nodes.


Further discussion about disk space requirements should be taken to another
thread.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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
very expensive, especially if it motivates you to buy another drive.

I have talked to several people who cite this as the primary reason that
they are reluctant to join the full node club.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 can do it with
extension blocks in a way that achieves full backwards compatibility for
all nodes.

Barring a significant security motivation, there is no need to hardfork.

I am also solidly unconvinced that increasing the blocksize today is a good
move, even as little as SegWit does. It's too expensive for a home user to
run a full node, and user-run full nodes are what provide the strongest
defence against political manuveuring.

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.

Disk space I believe is the most significant problem today, with RAM being
the second most significant problem, and finally bandwidth consumption as
the third most important consideration. I believe that v0.14 is already too
expensive on all three fronts, and that block size increases shouldn't be
considered at all until the requirements are reduced (or until consumer
hardware is better, but I believe we are talking 3-7 years of waiting if we
pick that option).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 them to be uncertain which of a large selection of algorithms are
going to be used, making pre-emptive asic manufacturing more difficult.

But once an algorithm is chosen that should be the end of the story, just
one algo without rotation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The problem with modifying Bitcoin to work around community norms is that
> it's a two-way street. Other people can do it too.
>
> Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
> fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
> 1506812400. It enforces every rule that UASF enforces, plus one additional
> rule. If 60% of blocks in any retargeting period signal for Double UASF,
> any descendant block that creates or spends a segregated witness output is
> invalid.
>
> Double UASF signaling never coincides with UASF signaling, because the
> signaling periods don't overlap. Full nodes happily validate the chain,
> because Double UASF doesn't break any rules; it just adds new ones. Miners
> who adopt Double UASF don't need to understand segwit, because all segwit
> transactions are banned. Miners don't need to commit to a wtxid structure,
> either. Per BIP 141, "If all transactions in a block do not have witness
> data, the commitment is optional." Segwit is activated, but useless. Miners
> who *do* adopt segwit will lose money, as their blocks are orphaned.
>
> Thanks,
> --Nick
>
> On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I recently posted about so called "user activated soft forks" and
>> received a lot of feedback. Much of this was how such methodologies could
>> be applied to segwit which appears to have fallen under the miner veto
>> category I explained in my original proposal, where there is apparently a
>> lot of support for the proposal from the economy, but a few mining pools
>> are vetoing the activation.
>>
>> It turns out Bitcoin already used flag day activation for P2SH[1
>> ],
>> a soft fork which is remarkably similar to segwit. The disadvantage of a
>> UASF for segwit is there is an existing deployment. A UASF would require
>> another wide upgrade cycle (from what I can see, around 80% of existing
>> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
>> ][3
>> ].
>> While absolute node count is meaningless, the uprgrade trend from version
>> to version seems significant.
>>
>> Also it is quite clear a substantial portion of the ecosystem industry
>> has put in time and resources into segwit adoption, in the form of
>> upgrading wallet code, updating libraries and various other integration
>> work that requires significant time and money. Further more, others have
>> built systems that rely on segwit, having put significant engineering
>> resources into developing systems that require segwit - such as several
>> lightning network system. This is much more significant social proof than
>> running a node.
>>
>> The delayed activation of segwit is also holding back a raft protocol of
>> innovations such as MAST, Covenants, Schnorr signature schemes and
>> signature aggregation and other script innovations of which, much of the
>> development work is already done.
>>
>> A better option would be to release code that causes the existing segwit
>> deployment to activate without requiring a completely new deployment nor
>> subject to hash power veto. This could be achieved if the economic majority
>> agree to run code that rejects non-signalling segwit blocks. Then from the
>> perspective of all existing witness nodes, miners trigger the BIP9
>> activation. Such a rule could come into effect 4-6 weeks before the BIP9
>> timeout. If a large part of the economic majority publicly say that they
>> will adopt this new client, miners will have to signal bip9 segwit
>> activation in order for their blocks to be valid.
>>
>> I have drafted a BIP proposal so the community may discuss
>> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
>> text below).
>>
>> References:
>> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/
>> main.cpp#L1281-L1283
>> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
>> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/eviden
>> ce_of_widespread_segwit_support_near50_of/
>>
>> Proposal text:
>>
>> 
>>   BIP: bip-segwit-flagday
>>   Title: Flag day activation for segwit deployment
>>   Author: Shaolin Fry 
>>   Comments-Summary: No comments yet.
>>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
>>   Status: Draft
>>   Type: Informational
>>   Created: 2017-03-12
>>   License: BS

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

[David Vorick via bitcoin-dev]

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.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 negotiate a change to any rule, Bitcoin is a
purely political money.

If "we" can do this, so can "they".

e


There is no doubt that politics play a big role in all of this. Also no
doubt that broader decentralization would be superior. But miner activated
soft forks and user activated soft forks do not need discussions with
centralized parties to move forward. It is merely two different methods for
pushing a soft fork through the network.

The key is that it's a soft fork. Old nodes continue to work as always,
whether the soft fork deploys or not.

User activated soft forks, or perhaps more accurately called 'economically
forced soft forks' are a tool to use if the miners are in clear opposition
to the broader economy. They only work if the broader economy actually
fully supports the soft fork, which is much more difficult to measure than
miner support. And miners with deeper pockets may be able to resist for
some time, effectively performing a rewardless 51% attack and maintaining a
split network for some time. The miners would lose lots of money, but old
nodes would feel all the burn of a hard fork, followed by a sudden deep
reorg when the network finally 'heals'.

I guess in some sense you'd be playing chicken with the miners. If the
split is not instantly successful there would be a lot of damage to old
nodes, even if the majority of new nodes had upgraded. (but there would
also be a lot of damage to the miners).

On Mar 5, 2017 9:31 PM, "Nick ODell"  wrote:

>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).

I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.


This is not relevant to a UASF. The existing nodes on the network have a
single formal definition for longest chain. If the UASF is successful, the
old nodes will follow the new soft fork and there will be only one chain.
Spirit of Bitcoin or not, the UASF is successful and there is no coin split
or network fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 success of the UASF depends entirely on the price. And actually, the
price is easy to manipulate. If you, as an economically active full node,
refuse to acknowledge the old chain and demand that incoming coins arrive
over the UASF chain. In doing so, you drive down the utility of the old
chain and drive up the utility of the new chain. This ultimately impacts
the price.

I think it would be pretty easy to get high confidence of the success of a
UASF. Basically you need all the major economic hubs to agree to upgrade
and then exclusively accept UASF coins. I don't have a comprehensive list,
but if we could sign on 75% of the major exchanges and payment processors,
and get 75% of the wallets to upgrade, then the UASF would be very likely
to successfully obliterate the old rules, as miners would be unable to sell
their coins or pay their bills by stubbornly sticking to the old chain.
It's less risky than a hard fork by far, because there is zero risk of coin
split if the UASF has majority hashrate, which will follow majority
economic value.

A serious proposal I think would get all the code ready and merged, but
without setting a flag day. Then we would get signatures from the major
institutions promising to use the software and saying that they are ready
for a flag day. After that, you release a patch with a flag day 12 months
in the future. People can upgrade immediately, and have a full year to
transition.

That gives tons of time for people to upgrade, and tons of confidence that
the UASF will end up as the majority chain.

If we cannot get enough major exchanges, payment processors, and other
economic hubs to upgrade,  the flag day should remain upset, as the risk of
coin split will be non-zero.

I would suggest that a carefully executed UASF is much riskier than a soft
fork, but far, far less risky than a hard fork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Pre-BIP] Community Consensus Voting System

[David Vorick via bitcoin-dev]

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
complicates things a lot, adds code, incentives, etc. when really all you
care about is some sort of indication of consideration, support, or
rejection.

I also prefer to think of Bitcoin as a system of vetos rather than a system
of approvals. A lot of times changes will be small, highly technical, and
have no visible impact to your every day user. These types of changes don't
really need support outside the devs. Furthermore, I frankly don't give a
crap if we proposal has support from 85% of the participants if there is a
legitimate technical, social, or political reason that it is a bad idea.

And finally, I don't think it should cost money or political power to raise
an objection. A 13yo who has never been seen before should be able to raise
an objection if they indeed have a legitimate objection. Involving money is
almost certainly going to shut down important valid opinions.

And again, I mostly agree with the motivation. It would be good if it were
easier to figure out who had considered a proposal and what their
objections or praises were. But I would like to see that without any
systemization around what is required to pass or fail a proposal, and with
no barrier to entry (such as voting or sending coins or having a recognized
name like 'Bitfury') to provide an opinion.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

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 need multinational cooperation or you'd need China to decide that
51% attacking a budding technology is a good thing to do, something that
would be sure to increase tensions across the world.

But there are two bigger reasons. The first is that regulators are used to
doing regulation at exchange points, regulating mining is new and
unfamiliar and requires a decent understanding of blockchains. And the
second is that Bitcoin is tiny potatoes at this point. To the best of my
knowledge, organized crime outside of DNMs doesn't use Bitcoin. There's
minimal reason to target it while it's so small.

Regulated mining I believe is going to be a genuine risk as Bitcoin grows.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

[David Vorick via bitcoin-dev]

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 channels through which you can make your announcements,
this particular one is not okay.

On Jan 7, 2017 3:12 PM, "Chris Priest via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Bitcoin Classic only activates if 75% of the network adopts it. That
> is not irresponsible or dangerous. It would only be dangerous if it
> activates at 50%, because that would create a situation where its not
> clear which side of the fork has the most proof of work.
>
> On 1/7/17, Eric Lombrozo via bitcoin-dev
>  wrote:
> > Your release announcement does not make it clear that Bitcoin Classic is
> > incompatible with the current Bitcoin network and its consensus rules. It
> > is a hard fork on mainnet with no safe activation as well as including
> > other unsafe changes. There is also no BIP for the hard fork. There is
> also
> > no evidence of community wide consensus for such a hard fork. This is
> > dangerous and irresponsible.
> >
> >
> > It's wrong to announce software without correctly informing people about
> > the contents or risks. Furthermore, there are no release notes in
> > https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
> > changelog. Without those, it is almost impossible for average users to
> know
> > what is under the hood or what has changed and time consuming for
> > developers to assess.
> >
> > On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> Bitcoin Classic version 1.2.0 is now available from;
> >>
> >>  
> >>
> >> This is a new major version release, including new features, various
> >> bugfixes and performance improvements.
> >>
> >> This release marks a change in strategy for Bitcoin Classic, moving from
> >> the
> >> very conservative block size proposal based on compromise to one where
> >> Classic truly innovates and provides a long term solution for the market
> >> to
> >> choose and leave behind the restrictions of the old.
> >>
> >> The most visible change in this version is the decentralised block size
> >> solution where node operators decide on the maximum size.
> >>
> >> Bitcoin Classic is focused on providing users a way to get onto the
> >> Bitcoin
> >> network using a high quality validating node for a large set of use
> >> cases.
> >> Classic presents top notch quality processes in this release, to help
> >> anyone
> >> running Bitcoin.
> >>
> >> We include in this release various projects with the beta label. People
> >> who
> >> want to use the Classic node as an on-ramp to Bitcoin will find them
> >> interesting. These projects will need to be enabled in the config by
> >> those
> >> that want to test them.
> >>
> >> More background information on this release and Classic can be seen in
> >> this
> >> video: https://vimeo.com/192789752
> >> The full release notes are on github at
> >> https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
> >>
> >> --
> >> Tom Zander
> >> Blog: https://zander.github.io
> >> Vlog: https://vimeo.com/channels/tomscryptochannel
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[David Vorick via bitcoin-dev]

>  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 software on a gentoo setup requires
explicitly telling the package manger to grab a later version. I don't know
what percent of nodes are Gentoo 0.10.2, but I think it's evidence that
0.10 should not be considered 'unmaintained'. People who update their
software regularly will be running 0.10 on Gentoo.

> many of whom have privately told me they are willing and able to run an
extra node or three (or a hundred-and-eleven) once there is a final release.

I'm not clear on the utility of more nodes. Perhaps there is significant
concern about SPV nodes getting enough bandwidth or the network struggling
from the load? Generally though, I believe that when people talk about the
deteriorating full node count they are talking about a reduction in
decentralization. Full nodes are a weak indicator of how likely something
like a change in consensus rules is to get caught, or how many people you
would need to open communication with / extort in order to be able to force
rules upon the network. Having a person spin up multiple nodes doesn't
address either of those concerns, which in my understanding is what most
people care about. My personal concern is with the percentage of the
economy that is dependent on trusting the full nodes they are connected to,
and the overall integrity of that trust. (IE how likely is it that my SPV
node is going to lie to me about whether or not I've received a payment).

I will also point out that lots of people will promise things when they are
seeking political change. I don't know what percentage of promised nodes
would actually be spun up, but I'm guessing that it's going to be
significantly less than 100%. I have similar fears for companies that claim
they have tested their infrastructure for supporting 2MB blocks. Talk is
cheap.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Three Month bitcoin-dev Moderation Review

[David Vorick via bitcoin-dev]

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.

My life has improved because of the changes.
On Jan 23, 2016 8:08 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> +1
> The distinction we are making importantly requires that contributors
> provide readers with another thing to say in favor of something - another
> thing which is different than "X people support this instead of only X-1
> people."  Evidence trumps votes.
>
> On Sat, Jan 23, 2016 at 1:38 PM, Gavin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> > On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > I would extend this to say that the technical explanation also should
>> > contribute uniquely to the conversation; a +1 with an explanation
>> > the last +1 gave isn't useful.
>>
>> Yes, comments should contribute to the discussion, with either technical
>> discussion or additional relevant data. I think a +1 like the following
>> should be encouraged:
>>
>> "+1: we had eleven customer support tickets in just the last week that
>> would have been prevented if XYZ.
>>
>> Jane Doe, CTO CoinBitChainBasely.com"
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy  and Meme Racing
>  (in alpha).
> I'm the webmaster for The Voluntaryist 
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante .
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposal - Mandatory Weak Blocks

[David Vorick via bitcoin-dev]

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 fraction such as 5%.

'Strong Block': a block that meets the full target. Also called a block.

---

Introduction:

One of the key sources of miner centralization is the orphan rate. Miners
with 33% hash power are guaranteed to instantly validate 33% of the blocks,
while miners with only 1% hashrate only get this advantage for 1% of the
blocks. If the average orphan rate on the network is high, miners with
significantly more hashpower will have a substantial advantage over smaller
miners.

One of the strongest reasons to keep the block size small is to keep the
orphan rate low. This is to protect smaller miners. Numerous pre-consensus
schemes have been discussed which attempt to drive the orphan rate down.
When considering these schemes, the adversarial case must be considered as
well as the average case.

The circulation of weak blocks has been discussed as a form of
preconsensus. Upon finding a weak block, miners circulate the block to the
other miners, and then when a full block is found, a diff between the weak
block and full block can be circulated instead of just the full block. This
diff is both quicker to validate and quicker to circulate, resulting in
substantially improved block propagation times and a reduced orphan rate,
thus reduced miner centralization pressure.

The adversarial case is not addressed by this scheme. It is still possible
to find and circulate a large, difficult-to-verify block that slowly
propagates through the network and drives up the orphan rate for smaller
miners. A new construction (below) introduces a set of new consensus rules
which protect small miners even from the adversarial case.

---

Construction:

After a block is found, pre-consensus for the next block begins.
Pre-consensus consists of building a chain of weak blocks which meet a
target that has 5% the difficulty of a full block. Each weak block can
introduce at most 200kb of new transactions to the weak-block chain. On
average, a new weak block will appear every 30 seconds. When the next
strong block is found, it must be at the head of a weak block chain and it
must itself introduce a maximum of 200kb in transactions new to the
weak-block chain. The maximum size of a strong block is 16mb, but can be
composed of any number of weak blocks.

Example:

[strong block] -> [weak block - 200kb] -> [weak block - 400kb] -> [strong
block - 600kb] -> [weak block - 200kb]...

---

Analysis:

On average, weak blocks will be found every 30 seconds and each block will
build on top of 20 weak blocks. The average block size will be 4mb. 80 weak
blocks are required to construct a block of the maximum size of 16mb, which
will probably happen 3 out of every 1000 blocks. The race-size for blocks
is kept low, and as explained later, adversarial mining is inherently
decentivized.

This construction establishes a 'pre-consensus' that allows miners to do
faster validation when a new block is found. Assuming that the miner has
seen most of the precursor weak blocks, only a few hundred kilobytes of
validation must be performed even when the blocks are multiple megabytes in
size. In the usual case, only 100kb of validation needs to be performed.

More consistent transaction throughput is achieved. Strong blocks that are
found in rapid succession are likely to each be small, due to having a
small number of weak blocks that they build on top of. Strong blocks that
are found a long time after the previous strong block are likely to have
many weak blocks that they build on top of.

Better censorship resistance is achieved. Creating large blocks requires
building on top of weak blocks. A miner actively trying to censor certain
transactions will have to ignore all weak-block chains that contain the
offensive transaction, and thus will be at a disadvantage due to
consistently producing smaller (and less fee-rich) blocks.

An attacker that is trying to flood the network with intentionally
slow-validating blocks can no longer easily construct blocks at the maximum
size, and instead must create and hide weak blocks which build up to a
strong block that has many unseen transactions. Hiding weak blocks has an
opportunity cost, because in building a chain of weak block is exclusive to
the attacker, the attacker is missing out on the opportunity of building on
top of the other weak blocks being produced.

Compared to Bitcoin-NG, this construction lacks the vulnerability where a
single, more easily-targeted leader is elected and placed in charge of the
next round of consensus.

Everyone has incentive to build on top of the most recent weak block. In
the event that the next weak block discovered is also a strong block, the
fees reaped by the miner will be maxim

Re: [bitcoin-dev] Censorship

[David Vorick via bitcoin-dev]

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 topic have a set of rules that get enforced to facilitate relevant
and interesting discussion. These rules help to block spam, and help to
make sure that discussions happen in their appropriate places. The rules in
place on the two primary bitcoin discussion sites have helped facilitate a
large userbase frequented by many relevant experts. I do believe that we
can thank the strict moderation policies for much of the activity that
happens which is technically interesting.

/r/bitcoin and bitcointalk.org are both centralized forums. As such, the
rules are going to be set by a centralized authority. The rules set have
been set to keep the discussion as interesting and relevant as possible.
When a certain theme becomes a massive echo chamber or little more than
beating a dead horse, it makes sense to implement moderation. Calling it
'censorship' is misleading, because a government authority is not
threatening punishment for the discussion of a certain topic. People are
not banned from visiting forums or websites where off-topic (or
against-the-rules) discussion is happening. People's /r/bitcoin rights are
not being revoked because they are subscribed to a controvertial subreddit.
That would be censorship.

Many people are clearly unhappy with the moderation happening on /r/bitcoin
and bitcointalk.org. Luckily, the switching cost for online discussion
forums is very low. I'm now going to invite people to post links to bitcoin
discussion forums where the moderation authority is different.

I know that a recently popular subreddit is /r/bitcoin_uncensored

I am interested to see what other forums people think are worth mentioning.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev