Re: [bitcoin-dev] BIP CPRKV: Check private key verify

[Tier Nolan via bitcoin-dev]

On Fri, Feb 12, 2016 at 5:02 AM,  wrote:

> Seems it could be done without any new opcode:
>

The assumption was that the altcoin would only accept standard output
scripts.  Alice's payment in step 2 pays to a non-standard script.

This is an improvement over the cut and choose, but it will only work for
coins which allow non-standard scripts (type 2 in the BIP).

I guess I was to focused on maintaining standard scripts on the altcoin.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Clearing up some misconceptions about full nodes

[Patrick Shirkey via bitcoin-dev]

On Thu, February 11, 2016 8:15 am, Chris Belcher via bitcoin-dev wrote:
> I've been asked to post this to this mailing list too. It's time to
> clear up some misconceptions floating around about full nodes.
>
> === Myth: There are only about 5500 full nodes worldwide ===
>
> This number comes from this and similar sites: https://bitnodes.21.co/
> and it measured by trying to probe every nodes on their open ports.
>
> Problem is, not all nodes actually have open ports that can be probed.
> Either because they are behind firewalls or because their users have
> configured them to not listen for connections.
>
> Nobody knows how many full nodes there are, since many people don't know
> how to forward ports behind a firewall, and bandwidth can be costly, its
> quite likely that the number of nodes with closed ports is at least
> another several thousand.
>
> Nodes with open ports are able to upload blocks to new full nodes. In
> all other ways they are the same as nodes with closed ports. But because
> open-port-nodes can be measured and closed-port-nodes cannot, some
> members of the bitcoin community have been mistaken into believing that
> open-port-nodes are that matters.
>
> === Myth: This number of nodes matters and/or is too low. ===
>
> Nodes with open ports are useful to the bitcoin network because they
> help bootstrap new nodes by uploading historical blocks, they are a
> measure of bandwidth capacity. Right now there is no shortage of
> bandwidth capacity, and if there was it could be easily added by renting
> cloud servers.
>
> The problem is not bandwidth or connections, but trust, security and
> privacy. Let me explain.
>
> Full nodes are able to check that all of bitcoin's rules are being
> followed. Rules like following the inflation schedule, no double
> spending, no spending of coins that don't belong to the holder of the
> private key and all the other rules required to make bitcoin work (e.g.
> difficulty)
>
> Full nodes are what make bitcoin trustless. No longer do you have to
> trust a financial institution like a bank or paypal, you can simply run
> software on your own computer. To put simply, the only node that matters
> is the one you use.
>
> === Myth: There is no incentive to run nodes, the network relies on
> altruism ===
>
> It is very much in the individual bitcoin's users rational self interest
> to run a full node and use it as their wallet.
>
> Using a full node as your wallet is the only way to know for sure that
> none of bitcoin's rules have been broken. Rules like no coins were spent
> not belonging to the owner, that no coins were spent twice, that no
> inflation happens outside of the schedule and that all the rules needed
> to make the system work are followed  (e.g. difficulty.) All other kinds
> of wallet involve trusting a third party server.
>
> All these checks done by full nodes also increase the security. There
> are many attacks possible against lightweight wallets that do not affect
> full node wallets.
>
> This is not just mindless paranoia, there have been real world examples
> where full node users were unaffected by turmoil in the rest of the
> bitcoin ecosystem. The 4th July 2015 accidental chain fork effected many
> kinds of wallets. Here is the wiki page on this event
> https://en.bitcoin.it/wiki/July_2015_chain_forks#Wallet_Advice
>
> Notice how updated node software was completely unaffected by the fork.
> All other wallets required either extra confirmations or checking that
> the third-party institution was running the correct version.
>
> Full nodes wallets are also currently the most private way to use
> Bitcoin, with nobody else learning which bitcoin addresses belong to
> you. All other lightweight wallets leak information about which
> addresses are yours because they must query third-party servers. The
> Electrum servers will know which addresses belong to you and can link
> them together. Despite bloom filtering, lightweight wallets based on
> BitcoinJ do not provide much privacy against nodes who connected
> directly to the wallet or wiretappers.
>
> For many use cases, such privacy may not be required. But an important
> reason to run a full node and use it as a wallet is to get the full
> privacy benefits.
>
> === Myth: I can just set up a node on a cloud server instance and leave
> it ===
>
> To get the benefits of running a full node, you must use it as your
> wallet, preferably on hardware you control.
>
> Most people who do this do not use a full node as their wallet.
> Unfortunately because Bitcoin has a similar name to Bittorrent, some
> people believe that upload capacity is the most important thing for a
> healthy network. As I've explained above: bandwidth and connections are
> not a problem today, trust, security and privacy are.
>
> === Myth: Running a full node is not recommended, most people should use
> a lightweight client ===
>
> This was common advice in 2012, but since then the full node software
> has vastly improved in 

Re: [bitcoin-dev] Soft fork fix for block withholding attacks

[Tier Nolan via bitcoin-dev]

If clients were designed to warn their users when a soft fork happens, then
it could be done reasonably safely.  The reference client does this (or is
it just for high POW softforks?), but many SPV clients don't.

If there was a delay between version number changing and the rule
activation, at least nodes would get a warning recommending that they
update.

* At each difficulty interval, if 950 of the last 1000 blocks have the new
version number, reject the old version blocks from then on.

* Start new target at 255, the least significant byte must be less than or
equal to the target

* Update target at each difficulty re-targetting

T = ((T << 3) - T) >> 3

This increases the difficulty by around 12.5% per fortnight.   After 64
weeks, the target would reach 0 and stay there meaning that the difficulty
would be 256 times higher than what is given in the header.

An attacker with 2% of the network power could create 5 blocks for every
block produced by the rest of the network.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Clearing up some misconceptions about full nodes

[Danny Thorpe via bitcoin-dev]

"With a very powerful "Desktop" machine bitcoin-qt dominates CPU/GPU
resources."

That doesn't match my experience.

System responsiveness / user experience can suffer when running bitcoin-qt
on a spinning hard disk. Disk I/O load will cause the whole system to grind
and severely disrupt the user experience.

Move the Bitcoin data to an SSD, though, and it's an entirely different
story.

The initial blockchain synchronization / "catch up" is CPU and disk
intensive, but after initial sync I find bitcoin-qt uses only a trivial
amount of CPU to keep up with verifying new blocks and new transactions.

Running bitcoin-qt occasionally is a much more painful user experience than
running bitcoin-qt continuously.

I'm running Bitcoin Core v0.12.rc2 on an old dual core Pentium E2160 at
1.8GHz, 6GB RAM, 64 bit Windows 10, with the Bitcoin data on SSD. This
system is about 6 years old and was an economy model even when new. Not
what I would call a powerful system. I've only added RAM and the SSD.

On that machine I run two instances of Bitcoin-qt - one for mainnet, and
another for testnet, and an instance of bfgminer to manage a handful of USB
Block Eruptors for testnet mining. Both bitcoin-qt instances are typically
at their max of 25 connections (each). Total CPU load floats around 11%,
with only occasional spikes to 40% for a few seconds.  The mainnet
bitcoin-qt process uses about 700MB of RAM, testnet about 300MB.

This machine did fall into disk grinding paralysis during initial sync /
catchup with the v0.10 and v0.11 builds of bitcoin-qt, when the Bitcoin
data was on a spinning disk. Moving the Bitcoin data to an SSD drive had
the greatest impact on breaking the disk-bound whole-system paralysis.
Increasing the system RAM, upgrading to v0.12, and upgrading the OS to Win
10 all contributed smaller improvements.

It is possible to run a full node on a small desktop machine concurrent
with user apps. Just get the Bitcoin data off of spinning media and onto
SSD, make sure you have plenty of RAM, and leave bitcoin-qt running all the
time.

-Danny



On Wed, Feb 10, 2016 at 11:03 PM, Patrick Shirkey via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Thu, February 11, 2016 8:15 am, Chris Belcher via bitcoin-dev wrote:
> > I've been asked to post this to this mailing list too. It's time to
> > clear up some misconceptions floating around about full nodes.
> >
> > === Myth: There are only about 5500 full nodes worldwide ===
> >
> > This number comes from this and similar sites: https://bitnodes.21.co/
> > and it measured by trying to probe every nodes on their open ports.
> >
> > Problem is, not all nodes actually have open ports that can be probed.
> > Either because they are behind firewalls or because their users have
> > configured them to not listen for connections.
> >
> > Nobody knows how many full nodes there are, since many people don't know
> > how to forward ports behind a firewall, and bandwidth can be costly, its
> > quite likely that the number of nodes with closed ports is at least
> > another several thousand.
> >
> > Nodes with open ports are able to upload blocks to new full nodes. In
> > all other ways they are the same as nodes with closed ports. But because
> > open-port-nodes can be measured and closed-port-nodes cannot, some
> > members of the bitcoin community have been mistaken into believing that
> > open-port-nodes are that matters.
> >
> > === Myth: This number of nodes matters and/or is too low. ===
> >
> > Nodes with open ports are useful to the bitcoin network because they
> > help bootstrap new nodes by uploading historical blocks, they are a
> > measure of bandwidth capacity. Right now there is no shortage of
> > bandwidth capacity, and if there was it could be easily added by renting
> > cloud servers.
> >
> > The problem is not bandwidth or connections, but trust, security and
> > privacy. Let me explain.
> >
> > Full nodes are able to check that all of bitcoin's rules are being
> > followed. Rules like following the inflation schedule, no double
> > spending, no spending of coins that don't belong to the holder of the
> > private key and all the other rules required to make bitcoin work (e.g.
> > difficulty)
> >
> > Full nodes are what make bitcoin trustless. No longer do you have to
> > trust a financial institution like a bank or paypal, you can simply run
> > software on your own computer. To put simply, the only node that matters
> > is the one you use.
> >
> > === Myth: There is no incentive to run nodes, the network relies on
> > altruism ===
> >
> > It is very much in the individual bitcoin's users rational self interest
> > to run a full node and use it as their wallet.
> >
> > Using a full node as your wallet is the only way to know for sure that
> > none of bitcoin's rules have been broken. Rules like no coins were spent
> > not belonging to the owner, that no coins were spent twice, that no
> > inflation happens outside of the schedule and that all the