<unnamed>

Public Key

npub1xe4sg9zgsm90v8ge3r0h29jmwjuudcldxfwczaazuph5y5020jvqpzrjrx

Profile Code

nprofile1qqsrv6cyz3ygdjhkr5vc3hm4zedhfwwxu0knyhvpw73wqm6z2848exqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0qyxhwumn8ghj7mn0wvhxcmmv728hds

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:39:50 UTC

- 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 11:42:40 UTC

- 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 UTC

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