Will [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-09-08 to 2015-08-07
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:32:59

- reply

📅 Original date posted:2015-08-06
📝 Original message:I think the key is comity and humility in terms of being honest about our inability to predict future trends in a meaningful way while passing through scrutiny coming from divergent perspectives. 8MB + 40% annually (at whatever increase frequency is preferred, at coinbase halvings seems most ideal) is the proposal to use.
What if 40% is too fast?
If 40% turns out to be excessive, miners have a built in incentive to cap their blocks at a lower amount that meets the supply / demand equilibrium vs. the price of bitcoin trading on the free market. The key here is to understand “price of bitcoin on the free market”. Most developers don’t understand free market economics beyond gambling, which is a good bit of the problem here.
Bottom line is, miners directly benefit from higher bitcoin prices when denominated in other currencies. This fact will naturally limit excessive growth of blk*.dat. size, because if the storage requirements for bitcoin grow out of reach of amateurs, it will lead to excessive centralization and capture by powerful interests, which would threaten to convert bitcoin to a form of sovereign currency and kill free demand for bitcoin (and tank the price). Miners don’t want that without some other body paying them to make econonically distorted decisions. They will limit the size themselves if they see this as an emerging threat. It’s in their best interests and will keep them in business longer.
Now, is there a risk that some excessively well funded entity could artificially inflate the price of bitcoin while this bribing miners to let blk*.dat size grow out of hand (distorting miner economics) in some sort of “subsidies for increased liquidity” corruption scheme? No there isn’t, because we are going to have a cap on the size that is reasonable enough that we know it won’t force out any amateurs for at least 5 years, and likely longer.
What if 40% is too slow?
That’s a problem anyone who actually owns bitcoin would like to have. We’ll gladly support an increase in the rate if demand supports it later with a subsequent change. We’ll have to do this eventually anyway when SHA256 and RIPEMD160 exhibit collisions, or some other non-self imposed existential threat rears its head.
Long game
Now, this entire scheme is predicated on the price going higher over the extended term. I would argue that if we are doing a good job, the price should go higher. Isn’t that the best barometer of performance? Demand for the scarce units inside the protocol denominated in other currencies?
8MB is 1MB + 40% a year from January 2009 to today. 40% a year is as good as we are going to get in terms of our extrapolated estimation of future ability to host full nodes. Anything else is overengineering something we can’t predict anyway. Any arguments against this setting and rate of growth that aren’t exclusively focused on the computer science side of the debate are misguided at best, and corrupted by competing incentives at worst. This is because it’s not possible to predict the future any better than using an extrapolation of the past, which is exactly what 8MB + 40% represents.
So TLDR? Go with 8MB + 40% annually and we will cross any (likely imaginary) bridges when we come to them down the road.
Will
From: Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Reply: Pieter Wuille <pieter.wuille at gmail.com>>
Date: August 6, 2015 at 5:32:20 PM
To: Dave Scotese <dscotese at litmocracy.com>>
Cc: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Wrapping up the block size debate with voting
On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
"Miners can do this unilaterally" maybe, if they are a closed group, based on the 51% rule. But aren't they using full nodes for propagation? In this sense, anyone can vote by coding.
They don't need to use full nodes for propagation. Miners don't care when other full nodes hear about their blocks, only whether they (eventually) accept them.
And yes, full nodes can change what blocks they accept. That's called a hard fork :)
--
Pieter
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/862f7099/attachment.html>

2023-06-07 15:45:13

- reply

2023-06-07 15:39:53

- reply

📅 Original date posted:2015-06-26
📝 Original message:Moving averages have upsides and downsides vs fixed growth. Moving averages are backwards looking and don't handle seasonalities or unanticipated increases in demand very well.
Think "Black Friday" or the horribly named "Cyber
Monday" in retail or market hysteria where millions of noobs jump into or out of bitcoin.
If you want to create fee pressure I think this can be done, but I would keep both of these in mind before choosing a value for N. Adjustments would need to be frequent and nimble enough to handle seasonalities and other unanticipated outliers.
> On Jun 26, 2015, at 1:39 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
>
>> On Fri, Jun 26, 2015 at 11:13 AM, Will <will.madden at novauri.com> wrote:
>> Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.
>
> I think the default block size is an orthogonal issue to the max block size.
>
> HOWEVER: I think changing the default 'target' block size from the current, fixed 750K to the average of the size of the last N blocks would have some nice properties. It is policy-neutral (we should get out of the business of deciding the right block size and let the miners who care drive block size up or down) and if there are a significant proportion of lazy miners going with defaults it gives the system a healthy "fee pressure."
>
> --
> --
> Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/7bb2f08e/attachment-0001.html>

2023-06-07 15:39:52

- reply

📅 Original date posted:2015-06-26
📝 Original message:Make the default soft vote = to previous max block size * 1.09 every 12k (or whatever mirrors the hard cap growth rate) and don't allow voting to lower the soft limit and I think you have something.
You need a default that grows because most miners are lazy and will do squirrelly things like hard code 8000000 as their vote permanently.
Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.
> On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam at cypherspace.org> wrote:
>> The hard-cap serves the purpose of a safety limit in case our
>> understanding about the economics, incentives or game-theory is wrong
>> worst case.
>
> True.
>
> BIP 100 and 101 could be combined. Would that increase consensus?
>
> - Miner vote threshold reached
> - Wait notice period or until earliest start time
> - Block size default target set to 1 MB
> - Soft limit set to 1MB
> - Hard limit set to 8MB + double every 2 years
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum)
>
> Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks.
>
> Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size.
>
> Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block.
>
> If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it.
>
> The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/14ba600c/attachment.html>

2023-06-07 15:39:50

- reply

📅 Original date posted:2015-06-24
📝 Original message:Yes, but with a key distinction. Today miners may collude to (or unintentionally) lower the block size limit for blocks they win. BIP-100 introduces the possibility of lowering the block size limit for everyone over the next 12,000 blocks.
Another gap involves laziness. What is a far more likely issue is not a conspiracy but that miners will be lazy and hard code their vote values, requiring arm twisting later to change them. Preventing this headache introduces the need for more complexity, either by making the default a non-vote (which makes it easier to game the system with less voting power), or by making the default vote = MAX_BLOCK_SIZE * 1.09 (which makes the default similar is to Gavin's proposal).
I think with a default vote that is ~9% larger than the previous max block size and no option to lower the max block size then BIP-100 could work without added risk or defeating the intended purpose. Still, one has to ask if the benefit is there to justify the additional moving parts.
> On Jun 23, 2015, at 11:49 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
>
> Miners can collude today to lower the block size limit.
>
> In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software: http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
>
>
>
>> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden at novauri.com> wrote:
>> Here are refutations of the approach in BIP-100 here:
>> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>>
>> To recap BIP-100:
>>
>> 1) Hard form to remove static 1MB block size limit
>> 2) Add new floating block size limit set to 1MB
>> 3) Historical 32MB message limit remains
>> 4) Hard form on testnet 9/1/2015
>> 5) Hard form on main 1/11/2016
>> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
>> threshold by 90% of blocks
>> 7) Limit increase or decrease may not exceed 2x in any one step
>> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
>> scriptSig, e.g. "/BV8000000/" to vote for 8M.
>> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
>> most common floor (minimum) is chosen.
>>
>> 8MB limits doubling just under every 2 years makes a static value grow
>> in a predictable manner.
>>
>> BIP-100 makes a static value grow (or more importantly potentially
>> shrink) in an unpredictable manner based on voting mechanics that are
>> untested in this capacity in the bitcoin network. Introducing a highly
>> variable and untested dynamic into an already complex system is
>> unnecessarily risky.
>>
>> For example, the largely arbitrary voting rules listed in 9 above can be
>> gamed. If I control pools or have affiliates involved in pools that
>> mine slightly more than 20% of blocks, I could wait until block sizes
>> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
>> "/BV5000001/" for the remaining 10%. If others don't consistently vote
>> for the same "/BV#/" value, vote too consistently and have their value
>> thrown out as the top 20%, I could win the resize to half capacity
>> "/BV5000001/" because it was the lowest repeated value not in the bottom
>> 20%.
>>
>> I could use this to force an exodus to my sidechain/alt coin, or to
>> choke out the bitcoin network. A first improvement would be to only let
>> BIP-100 raise the cap and not lower it, but if I can think of a
>> vulnerability off the top of my head, there will be others on the other
>> side of the equation that have not been thought of. Why bother
>> introducing a rube goldberg machine like voting when a simple 8mb cap
>> with predictable growth gets the job done, potentially permanently?
>>
>>
>> On 6/23/2015 9:43 PM, odinn wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > 1) Hard fork not (necessarily) needed
>> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
>> > your stuff," but rather simply to say, "Better you should work with
>> > Garzik to implement BIP-100, that would be good")
>> > 3) See points 1 and 2 above
>> > 4) If still reading... changes should be (as you seem to have been
>> > trying to lean towards)... lean towards gradual change; hence, changes
>> > that would flow from this BIP would be better off oriented in a
>> > process that dies not require the "way you have done it."
>> >
>> > You did address that, to be fair - in your TODO, this link:
>> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>> >
>> > contained the following link:
>> >
>> > http://gavinandresen.ninja/bigger-blocks-another-way
>> >
>> > However, in reading that, I didn't see any meaningful statements that
>> > would refute the approach in Garzik's BIP-100.
>> >
>> > Maybe a better way to say this is,
>> >
>> > Work with Jeff Garzik (which I am sure you are already having such
>> > discussions in private) as well as the list discussions,
>> > Move forward on BIP-100 with Garzik and other developers (not such a
>> > bad plan really) and don't get caught up in XT. (If you feel you can
>> > develop XT further, that is your thing but it would perhaps make you
>> > lose focus, work together with other developers.)
>> >
>> > Relax into the process. Things will be ok.
>> >
>> > Respectfully,
>> >
>> > - -O
>> >
>> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
>> >> I promised to write a BIP after I'd implemented
>> >> increase-the-maximum-block-size code, so here it is. It also lives
>> >> at:
>> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>> >>
>> >> I don't expect any proposal to please everybody; there are
>> >> unavoidable tradeoffs to increasing the maximum block size. I
>> >> prioritize implementation simplicity -- it is hard to write
>> >> consensus-critical code, so simpler is better.
>> >>
>> >>
>> >>
>> >>
>> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
>> >> <gavinandresen at gmail.com <mailto:gavinandresen at gmail.com>> Status:
>> >> Draft Type: Standards Track Created: 2015-06-22
>> >>
>> >> ==Abstract==
>> >>
>> >> This BIP proposes replacing the fixed one megabyte maximum block
>> >> size with a maximum size that grows over time at a predictable
>> >> rate.
>> >>
>> >> ==Motivation==
>> >>
>> >> Transaction volume on the Bitcoin network has been growing, and
>> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
>> >> the one megabyte maximum block size. Increasing the maximum size
>> >> reduces the impact of that limit on Bitcoin adoption and growth.
>> >>
>> >> ==Specification==
>> >>
>> >> After deployment on the network (see the Deployment section for
>> >> details), the maximum allowed size of a block on the main network
>> >> shall be calculated based on the timestamp in the block header.
>> >>
>> >> The maximum size shall be 8,000,000 bytes at a timestamp of
>> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
>> >> every 63,072,000 seconds (two years, ignoring leap years), until
>> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
>> >> blocks in between doublings will increase linearly based on the
>> >> block's timestamp. The maximum size of blocks after 2036-01-06
>> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
>> >>
>> >> Expressed in pseudo-code, using integer math:
>> >>
>> >> function max_block_size(block_timestamp):
>> >>
>> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
>> >> 8000000 if block_timestamp >= time_start+time_double*10 return
>> >> size_start * 2^10
>> >>
>> >> // Piecewise-linear-between-doublings growth: time_delta =
>> >> block_timestamp - t_start doublings = time_delta / time_double
>> >> remainder = time_delta % time_double interpolate = (size_start *
>> >> 2^doublings * remainder) / time_double max_size = size_start *
>> >> 2^doublings + interpolate
>> >>
>> >> return max_size
>> >>
>> >> ==Deployment==
>> >>
>> >> Deployment shall be controlled by hash-power supermajority vote
>> >> (similar to the technique used in BIP34), but the earliest possible
>> >> activation time is 2016-01-11 00:00:00 UTC.
>> >>
>> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
>> >> best chain have a version number with bits 3 and 14 set (0x20000004
>> >> in hex). The activation time will be the timestamp of the 750'th
>> >> block plus a two week (1,209,600 second) grace period to give any
>> >> remaining miners or services time to upgrade to support larger
>> >> blocks. If a supermajority is achieved more than two weeks before
>> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
>> >> 00:00:00 UTC.
>> >>
>> >> Block version numbers are used only for activation; once activation
>> >> is achieved, the maximum block size shall be as described in the
>> >> specification section, regardless of the version number of the
>> >> block.
>> >>
>> >>
>> >> ==Rationale==
>> >>
>> >> The initial size of 8,000,000 bytes was chosen after testing the
>> >> current reference implementation code with larger block sizes and
>> >> receiving feedback from miners stuck behind bandwidth-constrained
>> >> networks (in particular, Chinese miners behind the Great Firewall
>> >> of China).
>> >>
>> >> The doubling interval was chosen based on long-term growth trends
>> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
>> >> was chosen because exponential growth cannot continue forever.
>> >>
>> >> Calculations are based on timestamps and not blockchain height
>> >> because a timestamp is part of every block's header. This allows
>> >> implementations to know a block's maximum size after they have
>> >> downloaded it's header, but before downloading any transactions.
>> >>
>> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
>> >> block size increase, and is designed to give miners, merchants,
>> >> and full-node-running-end-users sufficient time to upgrade to
>> >> software that supports bigger blocks. A 75% supermajority was
>> >> chosen so that one large mining pool does not have effective veto
>> >> power over a blocksize increase. The version number scheme is
>> >> designed to be compatible with Pieter's Wuille's proposed "Version
>> >> bits" BIP.
>> >>
>> >> TODO: summarize objections/arguments from
>> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>> >>
>> >> TODO: describe other proposals and their advantages/disadvantages
>> >> over this proposal.
>> >>
>> >>
>> >> ==Compatibility==
>> >>
>> >> This is a hard-forking change to the Bitcoin protocol; anybody
>> >> running code that fully validates blocks must upgrade before the
>> >> activation time or they will risk rejecting a chain containing
>> >> larger-than-one-megabyte blocks.
>> >>
>> >> Simplified Payment Verification software is not affected, unless
>> >> it makes assumptions about the maximum depth of a transaction's
>> >> merkle branch based on the minimum size of a transaction and the
>> >> maximum block size.
>> >>
>> >> ==Implementation==
>> >>
>> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>> >>
>> >>
>> >>
>> >> _______________________________________________ bitcoin-dev mailing
>> >> list bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >
>> > - --
>> > http://abis.io ~
>> > "a protocol concept to enable decentralization
>> > and expansion of a giving economy, and a new social good"
>> > https://keybase.io/odinn
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1
>> >
>> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
>> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
>> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
>> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
>> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
>> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
>> > =ft62
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/cc0ad835/attachment-0001.html>

2023-06-07 15:29:32

- reply

📅 Original date posted:2015-02-03
📝 Original message:Hi Adam - the conversation was pretty open regarding the factor / channel used to sign at the bottom. No argument from me and I agree completely that hardened single purpose computers are more secure than desktop browsers, browser extensions, SMS, or mobile apps when involved in multisig authorization. The point below was that risks with other channels are far higher if auth data is input from two channels through one, such as entering a 2FA phone token and desktop password into the same desktop browser session - MITM phishing attack on websites that bypasses phone 2FA as an example, serendipitously timed yet tragic example of this scam with coinbase today: https://www.reddit.com/r/Bitcoin/comments/2ungby/fuck_i_just_got_scammed/
On the topic of hardened single purpose computers, and I mean no offense to our friends at Trezor, Case, or similar but I think the future of this type of security approach with bitcoin is extremely bright. It’s just far more likely to involve chips integrated directly in PC / Mac motherboards and mobile devices / wearables where signing is done in the hardware inaccessible to the OS or BIOS. This is a way for mainstream users to use bitcoin securely, integrate it with apps running from popular OS’s and get bitcoin into the internet on a very granular level, and Joe six pack and Sally soccer mom never even know they are using multisig. It took 20+ years for people to get used to cards vs. cash. The telephone took 50 years to catch on and become cost competitive. I think the key is making it invisible to the user.
From: Adam Weiss <adam at signal11.com>
Reply: Adam Weiss <adam at signal11.com>>
Date: February 3, 2015 at 12:25:20 PM
To: Will <will.madden at novauri.com>>
Cc: bitcoin-development at lists.sourceforge.net <bitcoin-development at lists.sourceforge.net>>
Subject: Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware
Using a desktop website and mobile device for 2/3 multisig in lieu of a hardware device (trezor) and desktop website (mytrezor) works, but the key is that the device used to input the two signatures cannot be in the same band. What you are protecting against are MITM attacks. The issue is that if a single device or network is compromised by malware, or if a party is connecting to a counterparty through a channel with compromised security, inputing 2 signatures through the same device/band defeats the purpose of 2/3 multisig.
Maybe I'm not following the conversation very well, but if you have a small hardware device that first displays a signed payment request (BIP70) and then only will sign what is displayed, how can a MITM attacker do anything other than deny service? They'd have to get malware onto the signing device, which is the vector that a simplified signing device is specifically designed to mitigate.
TREZOR like devices with BIP70 support and third party cosigning services are a solution I really like the sound of. I suppose though that adding BIP70 request signature validation and adding certificate revocation support starts to balloon the scope of what is supposed to be a very simple device though.
Regardless, I think a standard for passing partially signed transactions around might make sense (maybe a future extension to BIP70), with attention to both PC <-> small hardware devices and pushing stuff around on the Internet. It would be great if users had a choice of hardware signing devices, local software and third-party cosigning services that would all interoperate out of the box to enable easy multisig security, which in the BTC world subsumes the goals of 2FA.
--adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150203/795311df/attachment.html>

2023-06-07 15:29:31

- reply

📅 Original date posted:2015-02-03
📝 Original message:An idea for the bitcoin malware proposal below, the idea is at the bottom…
Using a desktop website and mobile device for 2/3 multisig in lieu of a hardware device (trezor) and desktop website (mytrezor) works, but the key is that the device used to input the two signatures cannot be in the same band. What you are protecting against are MITM attacks. The issue is that if a single device or network is compromised by malware, or if a party is connecting to a counterparty through a channel with compromised security, inputing 2 signatures through the same device/band defeats the purpose of 2/3 multisig. This is the same as how MITM defeats 2FA via mobile phone if the token is entered into the same website as the password - the token is simply passed through by the attacker to the secure session with the provider, allowing unfettered access or reuse of tokens for transactions other than those intended by the real user.
Companies have found clever ways around MITM attacks using SSL sniff and derivatives by embedding code in mobile apps that communicate not with the website authenticating the user, but with 3rd party company that authenticates the token and passes the authentication to the website through a different secure channel, making the MITM attack far much more difficult. The trick here is that instead of one channel, we now have two channels that must be compromised. Also, the second channel is between a security company and a (hopefully) professionally run financial services website. There are other approaches to defeat MITM, such as fingerprinting pages to detect spoofs. The former (secure 3rd party channel) is very secure but requires a trusted third party. The latter (fingerprinting) is a crap shoot with very high false positive rates.
Anyway, the exact same principles apply here to this conversation. The second signature must be presented from a separate band to maintain a higher degree of security. If one signature occurs via HTTP(s) from application 1, another should be SMS through a carrier network, etc via application 2.
The trick we need to look at is how to use the bitcoin network as a delivery mechanism to bypass the need for the trusted third party in the example above. Instead of the second factor routing through a 3rd party to the intended recipient, we have another option - one that doesn’t require core development either.
1) Sender > signs signature 1 via desktop > bitcoin network 2/3 P2SH
2) Mobile app also used by sender receives req. from bitcoin network to sign signature - not through the site in 1 (similar to the 2nd channel between the website and security company above)
3) Sender > signs signature 2 via mobile app (or any separate device operating on a different network - heck could be radio) > 2/3 signatures, transaction authorized
Any wallet service provider can use this model, all they must do is develop two independent applications such a secure browser plugin and a website, or a mobile app and a website that use 2/3 multisig to authorize transactions. No core development required - just better security design and execution by those developing wallets. If the protocol could natively communicate via two separate networks, that might be something to consider, but really developers should already have all the tools they need, assuming they are competent.
If there was a way to perform 2/3 multisig without requiring a second band, performing the function safely by somehow knowing if the service is performed from a compromised device through some sort of on-blockchain anti-malware check by validating the signature of the signing application by comparing it to a signature recorded when the multisig address was funded, that would be a really neat breakthrough. Food for thought, but I can’t see how that could be executed in a way where signatures couldn’t be spoofed from a compromised device. If someone cracks that problem, it’s a really big advance for information security.
On 02/02/2015 02:54 PM, Eric Voskuil wrote:
> On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote:
>>
>> In sending the first-signed transaction to another for second
>> signature, how does the first signer authenticate to the second
>> without compromising the independence of the two factors?
>>
>> Not sure what you mean. The idea is the second factor displays the
>> transaction and the user confirms it matches what they input to the
>> first factor. Ideally, using BIP70, but I don't know if BA actually
>> uses that currently.
>>
>> It's the same model as the TREZOR, except with a desktop app instead
>> of myTREZOR and a phone instead of a dedicated hardware device.
>
> Sorry for the slow reply, traveling.
>
> My comments were made in reference to this proposal:
>
>>> On Feb 2, 2015, at 10:40 AM, Brian Erdelyi <brian.erdelyi at gmail.com
>>> <mailto:brian.erdelyi at gmail.com>> wrote:
>>>
>>> Another concept...
>>>
>>> It should be possible to use multisig wallets to protect against
>>> malware. For example, a user could generate a wallet with 3 keys and
>>> require a transaction that has been signed by 2 of those keys. One
>>> key is placed in cold storage and anther sent to a third-party.
>>>
>>> It is now possible to generate and sign transactions on the users
>>> computer and send this signed transaction to the third-party for the
>>> second signature. This now permits the use of out of band transaction
>>> verification techniques before the third party signs the transaction
>>> and sends to the blockchain.
>>>
>>> If the third-party is malicious or becomes compromised they would not
>>> have the ability to complete transactions as they only have one
>>> private key. If the third-party disappeared, the user could use the
>>> key in cold storage to sign transactions and send funds to a new wallet.
>>>
>>> Thoughts?
My comments below start out with the presumption of user platform
compromise, but the same analysis holds for the case where the user
platform is clean but a web wallet is compromised. Obviously the idea is
that either or both may be compromised, but integrity is retained as
long as both are not compromised and in collusion.
> In the multisig scenario the presumption is of a user platform
> compromised by malware. It envisions a user signing a 2 of 3 output with
> a first signature. The precondition that the platform is compromised
> implies that this process results in a loss of integrity of the private
> key, and as such if it were not for the second signature requirement,
> the malware would be able to spend the output. This may be extended to
> all of the keys in the wallet.
>
> The scenario envisions sending the signed transaction to an another
> ("third") party. The objective is for the third party to provide the
> second signature, thereby spending the output as intended by the user,
> who is not necessarily the first signer. The send must be authenticated
> to the user. Otherwise the third party would have to sign anything it
> received, obviously rendering the second signature pointless. This
> implies that the compromised platform must transmit a secret, or proof
> of a secret, to the third party.
>
> The problem is that the two secrets are not independent if the first
> platform is compromised. So of course the malware has the ability to
> sign, impersonate the user and send to the third party. So the third
> party *must* send the transaction to an *independent* platform for
> verification by the user, and obtain consent before adding the second
> signature. The user, upon receiving the transaction details, must be
> able to verify, on the independent platform, that the details match
> those of the transaction that user presumably signed. Even for simple
> transactions this must include amount, address and fees.
>
> The central assumptions are that, while the second user platform may be
> compromised, the attack against the second platform is not coordinated
> with that of the first, nor is the third party in collusion with the
> first platform.
>
> Upon these assumptions rests the actual security benefit (increased
> difficulty of the coordinated attack). The strength of these assumptions
> is an interesting question, since it is hard to quantify. But without
> independence the entire security model is destroyed and there is thus no
> protection whatsoever against malware.
>
> So for example a web-based or other third-party-provisioned
> implementation of the first platform breaks the anti-collusion
> assumption. Also, weak comsec allows an attack against the second
> platform to be carried out against its network. So for example a simple
> SMS-based confirmation could be executed by the first platform alone and
> thereby also break the the anti-collusion assumption. This is why I
> asked how independence is maintained.
>
> The assumption of a hardware wallet scenario is that the device itself
> is not compromised. So the scenario is not the same. If the user signs
> with a hardware wallet, nothing can collude with that process, with one
> caveat.
>
> While a hardware wallet is not subject to onboard malware, it is not
> inconceivable that its keys could be extracted through probing or other
> direct attack against the hardware. It's nevertheless an assumption of
> hardware wallets that these attacks require loss of the hardware.
> Physical possession constitutes compromise. So the collusion model with
> a hardware wallet does exist, it just requires device possession.
> Depending on the implementation the extraction may require a non-trivial
> amount of time and money.
>
> In a scenario where the user signs with HW, then sends the transaction
> to a third party for a second of three signatures, and finally to a
> second platform for user verification, a HW thief needs to collude with
> the third party or the second platform before the owner becomes aware of
> the theft (notifying the third party). This of course implies that
> keeping both the fist and second platforms in close proximity
> constitutes collusion from a physical security standpoint. This is
> probably sufficient justification for not implementing such a model,
> especially given the cost and complexity of stealing and cracking a
> well-designed device. A device backup would provide comparable time to
> recover with far less complexity (and loss of privacy).
>
> Incidentally the hardware wallet idea breaks down once any aspect of the
> platform or network to which it connects must be trusted, so for these
> purposes I do not consider certain hybrid models as hardware wallets at
> all. For example one such device trusts that the compromised computer
> does not carry out a MITM attack between the signing device and a shared
> secret entered in parts over time by the user. This reduces to a single
> factor with no protection against a compromised platform.
>
> Of course these questions address integrity, not privacy. Use of a third
> party implies loss of privacy to that party, and with weak comsec to the
> network. Similarly, use of hardware signing devices implies loss of
> privacy to the compromised platforms with which they exchange transactions.
>
> e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
------------------------------
Message: 3
Date: Mon, 2 Feb 2015 16:44:37 -0800
From: Pieter Wuille <pieter.wuille at gmail.com>
Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER
signatures
To: Gregory Maxwell <gmaxwell at gmail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Message-ID:
<CAPg+sBjjYLf4NZ8ezK7ML_OO-e6C8_V1i12AXejjrgp+wFB-pg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> So I think we should just go ahead with R/S length upper bounds as
> both IsStandard and in STRICTDER.
I would like to fix this at some point in any case.
If we want to do that, we must at least have signatures with too-long
R or S values as non-standard.
One way to do that is to just - right now - add a patch to 0.10 to
make those non-standard. This requires another validation flag, with a
bunch of switching logic.
The much simpler alternative is just adding this to BIP66's DERSIG
right now, which is a one-line change that's obviously softforking. Is
anyone opposed to doing so at this stage?
--
Pieter
------------------------------
Message: 4
Date: Tue, 3 Feb 2015 02:21:24 +0000
From: Gregory Maxwell <gmaxwell at gmail.com>
Subject: Re: [Bitcoin-development] [softfork proposal] Strict DER
signatures
To: Pieter Wuille <pieter.wuille at gmail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Message-ID:
<CAAS2fgQKbsaU5f+UPp8z2nEgXOfNhsFJoY=2j76ArXnBRsiV6g at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> The much simpler alternative is just adding this to BIP66's DERSIG
> right now, which is a one-line change that's obviously softforking. Is
> anyone opposed to doing so at this stage?
Thats my preference.
------------------------------
Message: 5
Date: Mon, 02 Feb 2015 23:38:07 -0800
From: Eric Voskuil <eric at voskuil.org>
Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware
To: Brian Erdelyi <brian.erdelyi at gmail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Message-ID: <54D07ADF.8060809 at voskuil.org>
Content-Type: text/plain; charset="utf-8"
On 02/02/2015 11:58 AM, Brian Erdelyi wrote:>
>>Confusing or not, the reliance on multiple signatures as offering
>>greater security than single relies on the independence of multiple
>secrets. If the secrets cannot be shown to retain independence in the
>>envisioned threat scenario (e.g. a user's compromised operating
>>system) then the benefit reduces to making the exploit more difficult
>>to write, which, once written, reduces to no benefit. Yet the user
>>still suffers the reduced utility arising from greater complexity,
>>while being led to believe in a false promise.
>
>Just trying to make sure I understand what you?re saying. Are you
>eluding to that if two of the three private keys get compromised there
>is no gain in security? Although the likelihood of this occurring is
>lower, it is possible.
No, that's not it. Sorry for not being clear. Independence of control is
the central issue in the analysis of a multiple factor system. If an
attack compromises one factor there must be no way for that attack to
reduce the difficulty of obtaining the other factors.
Some factors (secrets), like a fingerprint, aren't very secret at all.
But getting someone's fingerprint doesn't also help the attacker get a
PIN. That factor must be attacked independently. But if the PIN is
encrypted with the fingerprint in a public store, then the PIN is not
independent of the fingerprint and there is really only one secret.
If multiple factors are coincident (located within the same security
perimeter) they are compromized coincidentally. Coincidence has the same
effect as dependence. Consider a credit card with a "security code"
printed on the back. A successful attack on the leather wallet yields
both secrets.
Individual environments can be compromised with some difficulty (e.g.
desktop malware, fingerprint lift, dictionary attack, brute force PIN,
etc.). For the sake of simplicity, let that chance of successful
independent attack on any factor be 1 in 2 and the resulting probability
of successful concurrent attack on any n factors be 1 in 2^n. If m
factors are dependent/coincident on others the relation becomes 1 in
2^(n-m).
Any multi-factor web wallet that handles the user's keys in the browser
and authenticates the user in the browser to authorize service signing
is effectively single factor. One attack may be launched by an insider,
or externally, against the web app, executing in the browser, gaining
coincident access to two secrets. Browser/desktop malware can accomplish
the same. The difficulty is 1 in 2 vs. the expected 1 in 4.
>As more malware targets bitcoins I think the utility is evident.
>Given how final Bitcoin transactions are, I think it?s worth trying to
>find methods to help verify those transactions (if a user deems it to
>be high-risk enough) before the transaction is completed. The balance
>is trying to devise something that users do not find too burdensome.
I'm not questioning the motive, I agree it's worth trying. But trying is
not succeeding. Increasing user (and/or system) complexity without
increasing integrity or privacy is a poor trade, and worse if the user
is misled.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
------------------------------
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
End of Bitcoin-development Digest, Vol 45, Issue 11
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150203/9471fbf8/attachment.html>

2023-06-07 15:04:25

- reply

📅 Original date posted:2013-07-09
📝 Original message:Omaha - which is the automatic update framework that Google Chrome uses -
is open sourced:
https://code.google.com/p/omaha/
It might be a bit heavyweight for just one package though.
Will
On 9 July 2013 13:04, Mike Hearn <mike at plan99.net> wrote:
> For the auto update, is there an existing auto update framework that we
> can modify to support threshold signed updates? I'm sure such a thing must
> exist. The updates would download in the background and then the app can
> just ask the user to restart it once the update is locally available, as
> Chrome does.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130709/7d9ba533/attachment.html>

2023-06-07 11:42:40

- reply

📅 Original date posted:2013-04-01
📝 Original message:The threat of a SHA1 collision attack to insert a malicious pull request
are tiny compared with the other threats - e.g. github being compromised,
one of the core developers' passwords being compromised, one of the core
developers going rogue, sourceforge (distribution site) being compromised
etc etc... believe me there's a lot more to worry about than a SHA1
attack...
Not meaning to scare, just to put things in perspective - this is why we
all need to peer review each others commits and keep an eye out for
suspicious commits, leverage the benefits of this project being open source
and easily peer reviewed.
Will
On 1 April 2013 23:52, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>
>
>
> On 1 April 2013 20:28, Petr Praus <petr at praus.net> wrote:
>
>> An attacker would have to find a collision between two specific pieces of
>> code - his malicious code and a useful innoculous code that would be
>> accepted as pull request. This is the second, much harder case in the
>> birthday problem. When people talk about SHA-1 being broken they actually
>> mean the first case in the birthday problem - find any two arbitrary values
>> that hash to the same value. So, no I don't think it's a feasible attack
>> vector any time soon.
>>
>> Besides, with that kind of hashing power, it might be more feasible to
>> cause problems in the chain by e.g. constantly splitting it.
>>
>
> OK, maybe im being *way* too paranoid here ... but what if someone had
> access to github, could they replace one file with one they had prepared at
> some point?
>
>
>>
>>
>> On 1 April 2013 03:26, Melvin Carvalho <melvincarvalho at gmail.com> wrote:
>>
>>> I was just looking at:
>>>
>>> https://bitcointalk.org/index.php?topic=4571.0
>>>
>>> I'm just curious if there is a possible attack vector here based on the
>>> fact that git uses the relatively week SHA1
>>>
>>> Could a seemingly innocuous pull request generate another file with a
>>> backdoor/nonce combination that slips under the radar?
>>>
>>> Apologies if this has come up before ...
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Own the Future-Intel® Level Up Game Demo Contest 2013
>>> Rise to greatness in Intel's independent game demo contest.
>>> Compete for recognition, cash, and the chance to get your game
>>> on Steam. $5K grand prize plus 10 genre and skill prizes.
>>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130402/85ab62f9/attachment.html>

2023-06-07 10:45:50

- reply

📅 Original date posted:2012-12-04
📝 Original message:...or should we be directing people to a (vetted) list of cloud services -
I think this has a significantly lower entry cost than any client. I know
the mybitcoin debacle has clouded (pun intended) people's views of these
providers, but blockchain.info (for example) really does seem quite well
engineered, and satisfies many of the features in particular a very low
cost of entry, cross platform support and what appears to be very good
security (e.g. two factor)
Will
On 4 December 2012 17:46, Mike Hearn <mike at plan99.net> wrote:
> At the moment if you visit bitcoin.org then you're recommended to
> download the full client. I think we all agree that at some point we
> need to start presenting users with something more like this:
>
>
> To get started, download wallet apps A or B.
>
> If you'd like to contribute your computing resources to the Bitcoin
> network and have a fast computer with an unfiltered internet
> connection, download:
>
> - for desktop machines, Bitcoin-Qt
> - for servers, bitcoind
>
>
>
> Obviously not that exact wording.
>
> I personally feel it's a bit early for this, but it's true that users
> are being turned away by the fact that they're pointed to Bitcoin-Qt
> by default, so having some kind of roadmap or plan for changing that
> would be good.
>
> I think MultiBit is maturing into a client that I'd feel comfortable
> recommending to end users who take the fast-start path, though it
> still has a few serious lacks (encrypted wallets aren't released yet,
> bloom filters will help performance a lot, needs to catch up with some
> newer features). But there doesn't have to be a one true client.
>
> The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> not convinced this is the best use of time, but if somebody steps up
> to do it, that could also work. MultiBit has some unique features that
> are quite useful like integrating charting and exchange rate feeds.
>
> What does everyone think on this?
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/cca423f4/attachment.html>

2023-06-07 02:45:45

- reply

📅 Original date posted:2011-12-12
🗒️ Summary of this message: The OpenPGP Spec RFC2440 defines key types for EC, but it is unclear if they were ever implemented on the keyserver side.
📝 Original message:Are there any PGP key servers that support EC key pairs? OpenPGP Spec
RFC2440 defines key types for EC, just not sure if they were ever
implemented on the keyserver side. Could even have a similar 'web of
trust' using private keys to sign people's identities similar to PGP.
Will
On 12 December 2011 23:16, Zell Faze <zellfaze at yahoo.com> wrote:
> I agree with Luke-Jr. We need to try to find a decentralized solution if
> we are going to implement BIP 15. Bitcoin needs to remain decentralized in
> every aspect of the protocol or we lose its greatest strength.
>
> I feel like the HTTPS idea would be a great idea for a client feature, but
> not really something that should be added to the protocol.
>
> --- On Mon, 12/12/11, Luke-Jr <luke at dashjr.org> wrote:
>
> > From: Luke-Jr <luke at dashjr.org>
> > Subject: Re: [Bitcoin-development] [BIP 15] Aliases
> > To: bitcoin-development at lists.sourceforge.net, "Amir Taaki" <
> zgenjix at yahoo.com>
> > Date: Monday, December 12, 2011, 5:32 PM
> > FirstBits looks nice at glance, but
> > is bound to create a gold-rush to grab
> > every nice-looking FirstBits address.
> >
> > HTTPS is only as secure as the (centralized) CAs, thus not
> > really any better
> > than TXT records.
> >
> > I don't think an address of some form is avoidable.
>
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111212/25918c42/attachment.html>

2023-06-07 02:23:51

- reply

📅 Original date posted:2011-09-08
🗒️ Summary of this message: The alert system should relay messages regardless of the key used, but be cautious of DDoS potential and consider proof-of-work.
📝 Original message:> In fact, I think the alert system should relay (note, NOT display) messages
> *regardless of the key used*, so it isn't yet another "our client gets
> special
> status" thing, and can be used for other clients as well.
>
>
> Be careful though, if you relay everything, it suddenly *does* have DDoS
potential...
no more than other messages such as transactions.
>Maybe require a proof-of-work then?
kind of defeats the purpose of the alert if it takes a long time to issue
one.
I think leave the alert in, but relay alert messages even if they don't use
the correct key. This means that if we later decide to add new keys to the
alert root trust then older clients will still relay these.
my .02btc
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110908/584a4849/attachment.html>