Patrick Shirkey [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-02-10 to 2021-03-06
💬 Posted a total of 5 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:30:38

- reply

📅 Original date posted:2021-03-06
📝 Original message:Hi,
Given recent discussions around possible cracks to RSA, ECDSA and even sha256 we have been looking at possible options for hardening Bitcoin against those potential attack vectors. While most consider it a low priority, IMO it is better to discuss this issue than ignore it especially given recent developments. Possible solutions may not be quick to implement, test, deploy and prevention is better than the cure.
We humbly present a few seeds of ideas which might be viable defenses. These are not deeply thought out at the technical level but may inspire some useful discussion for a few new BIPs.
We have discussed these ideas in private before submitting to shake out weaknesses. We are aware that the ideas are challenging and probably contentious. We are not seeking didruption. The goal is to defeat potential attacks. Apologies if these ideas are not new and have already been dismissed.
Possible defense strategies:
1. Alternate hashing methods. Not sha256. Exposing them sooner rather than later to enable a smooth transition.
2. Per address seed phrases. In addiition to mulitisig, segwit, P2SH, schnorr, taproot.
3. Removing private keys from a wallet for safe storage in a seperate location.
4. Completely removing wallets from the blockchain for 'absolute' cold storage*. If possible there would no longer be any trace of the wallet or associated addresses. Possibly in combination with the next suggestion.
- Bonus for general maintenance.
5. Burning old coins and generating 'new' coins to 'reset' tx history.
A 'Burn and Reissue' FIFO queue with set miner fees. Satoshis submitted to the queue are permanently 'disabled and no longer in use. Replacement satoshis are added to new blocks and distributed by queue priority. Suggest a set fee to avoid excessively high processessing fees and/or getting stuck in the queue.
* We realise this would require some significant changes that may not be technically possible.
--
Patrick Shirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210306/cb59c212/attachment.html>

2023-06-07 18:12:02

- reply

📅 Original date posted:2018-05-10
📝 Original message:> On 3/17/18, someone posted on the Lightning-dev list, "Can I try
> Lightning without running a fully-fledged bitcoin block chain? (Yubin
> Ruan)." The inquirer was asking because he didn't have much space to
> store the entire blockchain on his laptop.
>
> I replied:
>
> "Developers,
>
> On THIS note and slightly off-topic but relevant, why can't chunks of
> blockchain peel off the backend periodically and be archived, say on
> minimum of 150 computers across 7 continents?
>
> It seems crazy to continue adding on to an increasingly long chain to
> infinity if the old chapters (i.e. more than, say, 2 years old) could be
> stored in an evenly distributed manner across the planet. The same 150
> computers would not need to store every chapter either, just the index
> would need to be widely distributed in order to reconnect with a chapter
> if needed. Then maybe it is no longer a limitation in the future for
> people like Yubin. "
>
> It was suggested by a couple of lightning developers that I post this
> idea on the bitcoin-dev list. So, here I post :).
>
You can already use the "prune" flag to get a snapshot of the blockchain
but it is incompatible with "txindex" and "rescan" so maybe that is and
issue for lightning nodes?
--
Patrick Shirkey
Boost Hardware

2023-06-07 17:49:31

- reply

📅 Original date posted:2016-03-03
📝 Original message:On Thu, March 3, 2016 10:02 am, Peter Todd via bitcoin-dev wrote:
> On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev
> wrote:
>> > A 6 month investment with 3 months on the high subsidy and 3 months on
>> low subsidy would not be madeâ€¦
>>
>>
>>
>> Yes, this is the essential point. All capital investments are made based
>> on expectations of future returns. To the extent that futures are
>> perfectly knowable, they can be perfectly factored in. This is why
>> inflation in Bitcoin is not a tax, itâ€™s a cost. These step functions
>> are made continuous by their predictability, removing that
>> predictability will make them -- unpredictable.
>
> You know, I do agree with you.
>
> But see, this is one of the reasons why we keep reminding people that
> strictly speaking a hardfork *is* an altcoin, and the altcoin can change
> any rule currently in Bitcoin.
>
> It'd be perfectly reasonable to create an altcoin with a 22-million-coin
> limit and an inflation schedule that had smooth, rather than abrupt,
> drops. It'd also be reasonable to make that altcoin start with the same
> UTXO set as Bitcoin as a means of initial coin distribution.
>
> If miners choose to start mining that altcoin en-mass on the halving,
> all the more power to them. It's our choice whether or not we buy those
> coins. We may choose not to, but if 95% of the hashing power decides to
> go mine something different we have to accept that under our current
> chosen rules confirmations might take a long time.
>
>
> Of course, personally I agree with Gregory Maxwell: this is all fairly
> unlikely to happen, so the discussion is academic. But we'll see.
>
Bitcoin is a success.
The success has forced various hardfork discussions.
Hard forking is contentious. If a softfork cannot be achieved the
alternate to a hardfork is creating a new bitcoin. ex bitcoin 2.0
Similar to silver, gold, palladium, etc...
Bitcoins success partly stems from it's brand awareness. Any new
officially supported bitcoin will also benefit from this brand awareness.
If the market values the new improved bitcoin they will put their money
into it. This doesn't require any consensus.
Let the market decide which option has the most value. If everyone
switches to the new bitcoin then the old bitcoin miners will follow.
--
Patrick Shirkey
Boost Hardware Ltd

2023-06-07 17:49:04

- reply

📅 Original date posted:2016-02-11
📝 Original message: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 terms of user experience.
>
> If you cannot spare the disk space to store the blockchain, you can
> enable pruning as in:
> https://bitcoin.org/en/release/v0.11.0#block-file-pruning. In Bitcoin
> Core 0.12, pruning being enabled will leave the wallet enabled.
> Altogether this should require less than 1.5GB of hard disk space.
>
> If you cannot spare the bandwidth to upload blocks to other nodes, there
> are number of options to reduce or eliminate the bandwidth requirement
> found in https://bitcoin.org/en/full-node#reduce-traffic . These include
> limiting connections, bandwidth targetting and disabling listening.
> Bitcoin Core 0.12 has the new option -blocksonly, where the node will
> not download unconfirmed transaction and only download new blocks. This
> more than halves the bandwidth usage at the expense of not seeing
> unconfirmed transactions.
>
> Synchronizing the blockchain for a new node has improved since 2012 too.
> Features like headers-first
> (https://bitcoin.org/en/release/v0.10.0#faster-synchronization) and
> libsecp256k1 have greatly improved the initial synchronization time.
>
> It can be further improved by setting -dbcache=6000 which keeps more of
> the UTXO set in memory. It reduces the amount of time reading from disk
> and therefore speeds up synchronization. Tests showed that the entire
> blockchain can now be synchronized in less than _3 and a half hours_
> (See
> https://github.com/bitcoin/bitcoin/pull/6954#issuecomment-154993958)
> Note that you'll need Bitcoin Core 0.12 or later to get all these
> efficiency improvements.
>
> === How to run a full node as your wallet ===
>
> I think every moderate user of bitcoin would benefit by running a full
> node and using it as their wallet. There are several ways to do this.
>
> * Run a bitcoin-qt full node (https://bitcoin.org/en/download).
>
> * Use wallet software that is backed by a full node e.g. Armory
> (https://bitcoinarmory.com/) or JoinMarket
> (https://github.com/AdamISZ/JMBinary/#jmbinary)
>
> * Use a lightweight wallet that connects only to your full node (e.g.
> Multibit connecting only to your node running at home, Electrum
> connecting only to your own Electrum server)
>
> So what are you waiting for? The benefits are many, the downsides are
> not that bad. The more people do this, the more robust and healthy the
> bitcoin ecosystem is.
>
>
This is very useful information but from my experience it is not viable to
have a full node running full time on a desktop system i.e sharing the
system with a normal desktop workload.
With a very powerful "Desktop" machine bitcoin-qt dominates CPU/GPU
resources. Surely the majority of nodes NOT running open ports are being
run on desktop systems. It's likely that the vast majority of the
"normal/desktop" user base are not going to setup dedicated machines to
run a full node full time.
It's likely that the vast majority of full nodes that are not running open
ports are used occasionally when the user wants to make a transaction or
"catch up" with the blockchain.
That creates a divide between those who do have the resources to
contribute to the system on a full time basis (minority) and those who do
not (majority).
Does the power of p2p decentralization lie with the vast majority or the
"wealthy" resource rich minority?
How will the move to 2MB hard fork affect the vast majority of nodes?
For example Debian unstable currently provides the following:
apt-cache madison bitcoin-qt
bitcoin-qt | 0.11.2-1 | http://ftp.lug.ro/debian/ unstable/main amd64
Packages
bitcoin | 0.11.2-1 | http://ftp.lug.ro/debian/ unstable/main Sources
The rollout affect of the hard fork on the entire bitcoin ecosystem is a
difficult process to plan in advance. It's not viable to simply rely on
press releases to encourage users to upgrade their nodes. The debacle with
Pulse Audio during the mid 2000's should be a lesson for those who seek
that route.
Compare that to the requirements for spinning up "bitcoin-2.0" and
enabling users to move their wallets to the new blockchain at their
leisure.
The ecosystem doesn't suffer from instant degradation. Bitcoin "brand"
loyalty will ensure that users who want to move forward with the economic
potential of the 2MB blocksize will be able to keep their existing funds
safe while testing the waters with the new blocksize.
After all Bitcoin is still the only game in town when it comes to scale
and proven history of financial return.
As the new blockchain builds momentum the old one will eventually become
obsolete. However it may also become the digital equivalency of Silver and
that is also a useful, profitable and viable alternative with a proven
history of success.
--
Patrick Shirkey
Boost Hardware Ltd

2023-06-07 17:48:50

- reply

📅 Original date posted:2016-02-10
📝 Original message:On Wed, February 10, 2016 5:14 pm, David Vorick via bitcoin-dev wrote:
>> 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.
>
This is a good point. The rollout procedure needs to be fully tested
*before* any changes are enforced.
Has anyone provided conclusive results on system load demands with an
increase to 2MB? Extrapolating further to higher blocksizes will also be
useful to get an idea of the scope of the problem. If the system does jump
to 2MB it is unlikely that will be the ultimate limit so 4, 8, 16 etc...
should also be quantified.
We already hear of the high system load (energy/cost) requirements* for
nodes under the current blocksize which appears to have created a barrier
to entry for a lot of miners. If increasing to 2MB makes it even more
expensive in terms of hardware and energy costs to run a node that will
consolidate the nodes into the control of a few wealthy parties who can
afford to run the most powerful hardware. Conversely if the increase helps
the system and individual nodes run more efficiently then that would be a
big incentive for miners to upgrade.
* (these reports might be false/wrong/propaganda)
--
Patrick Shirkey
Boost Hardware Ltd