Yifu Guo [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 17:48:48

- reply

📅 Original date posted:2016-02-09
📝 Original message:Happy Lunar New Year Everyone!
Gavin,
> I suspect there ARE a significant percentage of un-maintained full
> nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for
> three reasons:
The notion of large set ( 30% to 40% ) of un-maintained full nodes are not
evident on the network. below is data based on a personal snap shot taken
around Dec, 2015. with the following assumptions.
1) nodes running non standard version strings are considered a preference
by the node operator and are not included.
2) nodes below 0.10 are counted as so called "un-maintained" even though
they also can be a choice of the node operator.
Satoshi:0.9.3, 105
Satoshi:0.8.6, 74
Satoshi:0.9.1, 49
Satoshi:0.9.2.1, 42
Satoshi:0.8.5, 39
Satoshi:0.8.1, 35
Satoshi:0.9.5, 14
Satoshi:0.8.3, 12
Satoshi:0.9.4, 10
Satoshi:0.9.99, 10
Satoshi:0.9.0, 5
Satoshi:0.9.2, 5
Satoshi:0.8.0, 4
Satoshi:0.8.99, 1
Satoshi:0.8.4, 1
There are 406 nodes total that falls under the un-maintained category,
which is below 10% of the network.
Luke also have some data here that shows similar results.
http://luke.dashjr.org/programs/bitcoin/files/charts/versions.txt
> The network could shrink by 60% and it would still have plenty of open
> connection slots
I'm afraid we have to agree to disagree if you think dropping support for
60% of the nodes on the network when rolling out an upgrade is the sane
default.
>
> > People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.
thousands of nodes?! where did you get this figure? who are these people?
*Please* elaborate.
> We could wait a year and pick up maybe 10 or 20% more.
I don't understand this statement at all, please explicate.
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
On Sat, Feb 6, 2016 at 10:37 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said,
> I surveyed several of the biggest infrastructure providers and the btcd
> lead developer and they all agree "28 days is plenty of time."
>
> For individuals... why would it take somebody longer than 28 days to
> either download and restart their bitcoind, or to patch and then re-run
> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?
>
> For the Bitcoin Core project: I'm well aware of how long it takes to roll
> out new binaries, and 28 days is plenty of time.
>
> I suspect there ARE a significant percentage of un-maintained full nodes--
> probably 30 to 40%. Losing those nodes will not be a problem, for three
> reasons:
> 1) The network could shrink by 60% and it would still have plenty of open
> connection slots
> 2) People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.
> 3) We could wait a year and pick up maybe 10 or 20% more.
>
> I strongly disagree with the statement that there is no cost to a longer
> grace period. There is broad agreement that a capacity increase is needed
> NOW.
>
> To bring it back to bitcoin-dev territory: are there any TECHNICAL
> arguments why an upgrade would take a business or individual longer than 28
> days?
>
>
> Responding to Luke's message:
>
> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>> wrote:
>> >> Blog post on a couple of the constants chosen:
>> >> http://gavinandresen.ninja/seventyfive-twentyeight
>> >
>> > Can you put this in the BIP's Rationale section (which appears to be
>> mis-named
>> > "Discussion" in the current draft)?
>>
>
> I'll rename the section and expand it a little. I think standards
> documents like BIPs should be concise, though (written for implementors),
> so I'm not going to recreate the entire blog post there.
>
>
>> >
>> >> Signature operations in un-executed branches of a Script are not
>> counted
>> >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature
>> for a
>> >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the
>> top
>> >> of the execution stack, it is counted as one signature operation. If
>> it is
>> >> satisfied by the public key nearest the bottom of the execution stack,
>> it
>> >> is counted as twenty signature operations. Signature operations
>> involving
>> >> invalidly encoded signatures or public keys are not counted towards the
>> >> limit
>> >
>> > These seem like they will break static analysis entirely. That was a
>> noted
>> > reason for creating BIP 16 to replace BIP 12. Is it no longer a
>> concern? Would
>> > it make sense to require scripts to commit to the total accurate-sigop
>> count
>> > to fix this?
>>
>
> After implementing static counting and accurate counting... I was wrong.
> Accurate/dynamic counting/limiting is quick and simple and can be
> completely safe (the counting code can be told the limit and can
> "early-out" validation).
>
> I think making scripts commit to a total accurate sigop count is a bad
> idea-- it would make multisignature signing more complicated for zero
> benefit. E.g. if you're circulating a partially signed transaction to that
> must be signed by 2 of 5 people, you can end up with a transaction that
> requires 2, 3, 4, or 5 signature operations to validate (depending on which
> public keys are used to do the signing). The first signer might have no
> idea who else would sign and wouldn't know the accurate sigop count.
>
>
>> >
>> >> The amount of data hashed to compute signature hashes is limited to
>> >> 1,300,000,000 bytes per block.
>> >
>> > The rationale for this wasn't in your blog post. I assume it's based on
>> the
>> > current theoretical max at 1 MB blocks? Even a high-end PC would
>> probably take
>> > 40-80 seconds just for the hashing, however - maybe a lower limit would
>> be
>> > best?
>>
>
> It is slightly more hashing than was required to validate block number
> 364,422.
>
> There are a couple of advantages to a very high limit:
>
> 1) When the fork is over, special-case code for dealing with old blocks
> can be eliminated, because all old blocks satisfy the new limit.
>
> 2) More importantly, if the limit is small enough it might get hit by
> standard transactions, then block creation code (CreateNewBlock() /
> getblocktemplate / or some external transaction-assembling software) will
> have to solve an even more complicated bin-packing problem to optimize for
> fees paid.
>
> In practice, the 20,000 sigop limit will always be reached before
> MAX_BLOCK_SIGHASH.
>
>
>
>> >
>> >> Miners express their support for this BIP by ...
>> >
>> > But miners don't get to decide hardforks. How does the economy express
>> their
>> > support for it? What happens if miners trigger it without consent from
>> the
>> > economy?
>>
>
> "The economy" does support this.
>
>
>
>> >
>> > If you are intent on using the version bits to trigger the hardfork, I
>> suggest
>> > rephrasing this such that miners should only enable the bit when they
>> have
>> > independently confirmed economic support (this means implementations
>> need a
>> > config option that defaults to off).
>>
>
> Happy to add words about economic majority.
>
> Classic will not implement a command-line option (the act of running
> Classic is "I opt in"), but happy to add one for a pull request to Core,
> assuming Core would not see such a pull request as having any hostile
> intent.
>
>
> >
>> >> SPV (simple payment validation) wallets are compatible with this
>> change.
>> >
>> > Would prefer if this is corrected to "Light clients" or something.
>> Actual SPV
>> > wallets do not exist at this time, and would not be compatible with a
>> > hardfork.
>>
>
> Is there an explanation of SPV versus "Light Client" written somewhere
> more permanent than a reddit comment or forum post that I can point to?
>
>
>> >
>> >> In the short term, an increase is needed to continue the current
>> economic
>> >> policies with regards to fees and block space, matching market
>> expectations
>> >> and preventing market disruption.
>> >
>> > IMO this sentence is the most controversial part of your draft, and it
>> > wouldn't suffer a loss to remove it (or at least make it subjective).
>>
>
> Happy to remove.
>
>
>> > I would also prefer to see any hardfork:
>> >
>> > 1. Address at least the simple tasks on the hardfork wishlist (eg,
>> enable some
>> > disabled opcodes; fix P2SH for N-of->15 multisig; etc).
>>
>
> Those would be separate BIPs. (according to BIP 1, smaller is better)
>
> After this 2MB bump, I agree we need to agree on a process for the next
> hard fork to avoid all of the unnecessary drama.
>
> > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
>> > insecure.
>>
>
> I haven't been paying attention to all of the
> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
> mean. Is THAT written up somewhere?
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20160209/4029590c/attachment-0001.html>

2023-06-07 17:48:35

- reply

📅 Original date posted:2016-02-05
📝 Original message:"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."
On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage ( in 28 days ) on the network for a hard fork is good
enough?
There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
> https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
> Increase block size limit to 2,000,000 bytes.
> After 75% hashpower support then 28-day grace period.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
>
> Blog post walking through the code:
> http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160205/e9662b77/attachment.html>

2023-06-07 17:38:16

- reply

📅 Original date posted:2015-08-27
📝 Original message:I've done some work in this area. see http://coinvalidation.com/ it's
currently shelved due to lack of legal and regulatory framework.
1. this should not be directly implemented on the protocol level. I believe
its Jeff Garzik who once said "stolen bitcoins is a legal problem, not a
technical one." Legal problems are not technical problems.
2. it is the responsibility of company and individuals to answer questions.
example, stolen bitcoins gets send to address X, and address X is a payment
address of company Y. it is company Y's responsibility to answer to
corresponding agencies responsible. What actions comes out of that is yet
to be determent.
other examples such as, you are using a wallet app, and sending bitcoin
payments to a known malicious address. ( e.g. crypto-locker or other
malware address that replaces the output address.), does the wallet app
warn its users?
Again, while these are not technical problems, they will need answers
eventually. I'll be happy to discuss further off this mailing list as it is
off-topic.
On Thu, Aug 27, 2015 at 10:00 PM, odinn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> No.
>
> On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote:
> > Hi,
> >
> > I am proposing to create a AML-KYC module to control the network
> > and also qualify use cases in OFAC compliant way. Here is the
> > attached doc.
> >
> > Please provide your feedback and suggestions.
> >
> > Best, Prabhat Kumar Singh
> >
> >
> > _______________________________________________ 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
>
> iQEcBAEBAgAGBQJV38DGAAoJEGxwq/inSG8CkYkIAJwHOnjesbq+UHogUkGJsuph
> 2ipSIcBEzbeVH8fQ2sij5jKULE0n8J7K/DtfzzRJj+IiaYB1Ecjl0kLVQ0ug6T/8
> p5iuGQ2fvt1tMOy9+ptZbOZhtjUTWWSMqmFgsPkh5s/uGHeKy/jBjYsZv4FZ57Hm
> DUUvGYIdaGQ2eYm4y4dLnvI0T5WFQvf0Vs4wvWZdKvD5oliSwGy4KNVIxlcGya8w
> FPYaDe8q0rN5Aqp4V2jjfuF4KBC8dwHa9dyHTfSPA43I1qbcIVraSdJg1lCJ/bXh
> rFz+MXcGmsxxzHMbv6C4y+YSET2TPuNUs4w6MVw2ZO0lYe1suWYeYvfccQA1+Uk=
> =17NP
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/658cace8/attachment.html>

2023-06-07 17:38:16

- reply

2023-06-07 17:36:52

- reply

📅 Original date posted:2015-08-21
📝 Original message:accordingly to public release[1], They.
1. agreed that blocksize increase is needed.
2. opposed original 20mb, suggest 8mb instead as it is more technically
reasonable.
3. do not want blocksize to change in the "short term future" ( direct
translation. ) and in the document states.
"after discussion we are in agreement that the blocksize should be within
the ball park of 8mb for the short term future."
They have no explicitly rejected or supported the other components of
BIP101. It's my opinion that as long as the change is < 8mb. they'll take
it.
I don't believe in trying to predict the future, on adoption, technology
growth, nor geopolitics. I think it matters very little which BIP we need
up deploying, as long as all the attack vectors are covered, especially for
the dynamically adjustable ones.
One thing is for sure though, not increasing the blocksize is not an option.
we can't predict the future, in the mean time, Hardfork Responsibly™.
[1]
http://7fvhfe.com1.z0.glb.clouddn.com/@/wp-content/uploads/2015/06/%E5%8C%BA%E5%9D%97%E6%89%A9%E5%AE%B9%E8%8D%89%E6%A1%88.jpg
On Fri, Aug 21, 2015 at 7:28 AM, Btc Drak <btcdrak at gmail.com> wrote:
> On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I like the intend of this attempt to bring more clarity to the blocksize
> > debate, however it would be more help to make this a information site
> about
> > the current outstanding BIPs and summarize their differences rather than
> > voting mechanism.
> > (ofcourse the author of the BIPs would "vote" for their own proposals.)
> >
> > It would be good to include supporting and counter statements regards to
> > these BIPs on the site.
> > in addition to highlight certain things like pools in china have voiced
> > their opinion that increase should happen, and 8mb is something they are
> > comfortable with, which is not directly related to a single BIP, but
> never
> > the less relevant in this discussion.
>
> I was rather surprised by the tweet from AntPool[1] today saying that
> they support big blocks and would be prepared to upgrade to XT. Pools
> have stated that they are willing to increase to a maximum of 8MB, but
> upgrading to XT puts them on a schedule towards 8GB which is clearly
> not what they have agreed to.
>
> Do you have any insights into what's going on there?
>
> Also do you have any insight into what Chinese pools would accept as a
> compromise in terms of raising the blocksize limit?
>
> Drak
>
> [1] https://twitter.com/JihanWu/status/633288343338381314
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/ee4db6f3/attachment.html>

2023-06-07 17:36:51

- reply

📅 Original date posted:2015-08-21
📝 Original message:I like the intend of this attempt to bring more clarity to the blocksize
debate, however it would be more help to make this a information site about
the current outstanding BIPs and summarize their differences rather than
voting mechanism.
(ofcourse the author of the BIPs would "vote" for their own proposals.)
It would be good to include supporting and counter statements regards to
these BIPs on the site.
in addition to highlight certain things like pools in china have voiced
their opinion that increase should happen, and 8mb is something they are
comfortable with, which is not directly related to a single BIP, but never
the less relevant in this discussion.
On Fri, Aug 21, 2015 at 5:35 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On 21 August 2015 02:31:51 GMT-07:00, Btc Drak <btcdrak at gmail.com> wrote:
> >On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
> ><bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> What might be valuable is to ask devs to explain what their threat
> >models are, what should be at the root of their thinking about the
> >blocksize.
> >
> >That's exactly what the "Technical Opinion" column is for.
>
> What if could be used for; theres value in being more explicit.
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV1vDG
> AAoJEMCF8hzn9Lncz4MIAIMtLLA4q7KJiwrYrpjFWme1ys9iyPZiADJGQWG3qKlH
> Q4pEcwWt69jfTUCjLYfegsDW4eEMarejs568iSF70hvGB4OPWrYK3YiM1cWlWtDD
> seN3G/4dJjehL7h1Nz+/OTjTlePkguHctRlJTavel8sI7fg356iMJc1Ggm5Q1ZFl
> CLrivr/CEO7Qk9Uo5ewhnwConKjLygSyv67SSaMJW7pZB06uTX6M3lk11c/RB/C6
> JKPqxkvOmNIX9U8S/G3Y2pYf3/up72IhP0Ugp31iOsz629B2WvEsDYu/0SP61+oZ
> za9HrP2g8OsxVq6SUD3MukmbRVKklvcnro4vk5sOlYI=
> =Jfl+
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/0f577099/attachment.html>

- reply

- reply

- reply

- reply

📅 Original date posted:2015-06-18
📝 Original message:Nice insight Peter,
This further confirms the real problem, which doesn't have much to do with
blocksize but rather the connectivity of nodes in countries with
not-so-friendly internet policies and deceptive connectivity.
On Thu, Jun 18, 2015 at 6:00 PM, Tom Harding <tomh at thinlink.com> wrote:
> On 06/12/2015 06:51 PM, Pieter Wuille wrote:
> >> However, it does very clearly show the effects of
> >> larger blocks on centralization pressure of the system.
>
> On 6/14/2015 10:45 AM, Jonas Nick wrote:
> > This means that your scenario is not the result of a cartel but the
> result of a long-term network partition.
> >
>
> Pieter, to Jonas' point, in your scenario the big miners are all part of
> the majority partition, so "centralization pressure" (pressure to merge
> with a big miner) cannot be separated from "pressure to be connected to
> the majority partition".
>
> I ran your simulation with a large (20%) miner in a 20% minority
> partition, and 16 small (5%) miners in a majority 80% partition, well
> connected. The starting point was your recent update, which had a more
> realistic "slow link" speed of 100 Mbit/s (making all of the effects
> smaller).
>
> To summarize the results across both your run and mine:
>
> ** Making small blocks when others are making big ones -> BAD
> ** As above, and fees are enormous -> VERY BAD
>
> ** Being separated by a slow link from majority hash power -> BAD
>
> ** Being a small miner with blocksize=20MB -> *NOT BAD*
>
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
> * Expected average block size: 4800000.000000
> * Average fee per block: 0.250000
> * Fee per byte: 0.0000000521
> Result:
> * Miner group 0: 20.404704% income (factor 1.020235 with hashrate)
> * Miner group 1: 79.595296% income (factor 0.994941 with hashrate)
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
> * Expected average block size: 20000000.000000
> * Average fee per block: 0.250000
> * Fee per byte: 0.0000000125
> Result:
> * Miner group 0: 19.864232% income (factor 0.993212 with hashrate)
> * Miner group 1: 80.135768% income (factor 1.001697 with hashrate)
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 1000000.000000
> * Expected average block size: 4800000.000000
> * Average fee per block: 25.000000
> * Fee per byte: 0.0000052083
> Result:
> * Miner group 0: 51.316895% income (factor 2.565845 with hashrate)
> * Miner group 1: 48.683105% income (factor 0.608539 with hashrate)
>
> Configuration:
> * Miner group 0: 20.000000% hashrate, blocksize 20000000.000000
> * Miner group 1: 80.000000% hashrate, blocksize 20000000.000000
> * Expected average block size: 20000000.000000
> * Average fee per block: 25.000000
> * Fee per byte: 0.0000012500
> Result:
> * Miner group 0: 19.865943% income (factor 0.993297 with hashrate)
> * Miner group 1: 80.134057% income (factor 1.001676 with hashrate)
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/ef7b5861/attachment.html>

2023-06-07 15:36:06

- reply

📅 Original date posted:2015-06-01
📝 Original message:Nielsen's Law of Internet Bandwidth is simply not true, but if you look at
data points like http://www.netindex.com/upload/ which will show we are at
least on the right track, but this is flawed still.
The fact of the matter is these speed tests are done from local origin to
local destination within the city, let alone the country ( see note about
how these test are only conducted 300 miles within the server). and our
current internet infrastructure is set up with CDNs for the web and media
consumption.
these data points can not and should not be used to model the connectivity
of a peer to peer network.
Uplink bandwidth is scarce is China and expensive, avg about $37 per 1mbps
after 5, but this is not the real problem. the true issue lies in the
ISP transparent proxy they run. this is not a problem isolated in just
China, Thailand and various other countries in Asia like Lebanon. I have
also heard in various IRCs that southern France also face this similar
issue due to poor routing configurations they have that prevents
connections to certain parts of the world, unsure if this is a mistake or a
geopolitical by-product.
As for your question earlier Gavin, from Dallas TX to a VPS in Shanghai
on 上海电信/Shanghai telecom, which is capped at 5mbps the data results match
my concerns, I've gotten low as 83 Kbits/sec and as high as 9.24 Mbits/sec.
and other ranges in between, none are consistent. ping avg is about 250ms.
The temporary solution I recommend again from earlier is MPTCP:
http://www.multipath-tcp.org/ which allows you to multiple
interfaces/networks for a single TCP connection, this is mainly developed
for mobile3g/wifi transition but I found uses to improve bandwidth and
connection stability on the go by combining a local wifi/ethernet
connection with my 3g phone tether. this allows you to set up a middlebox
somewhere, put shadowsocks server on it, and on your local machine you can
route all TCP traffic over the shadow socks client and MPTCP will
automatically pick the best path for upload and download.
On Mon, Jun 1, 2015 at 9:59 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902 at gmail.com> wrote:
>
>> I cannot believe why Gavin (who seems to have difficulty to spell my
>> name correctly.) insists on his 20MB proposal regardless the
>> community. BIP66 has been introduced for a long time and no one knows
>> when the 95% goal can be met. This change to the block max size must
>> take one year or more to be adopted. We should increase the limit and
>> increase it now. 20MB is simply too big and too risky, sometimes we
>> need compromise and push things forward. I agree with any solution
>> lower than 10MB in its first two years.
>>
>>
> Thanks, that's useful!
>
> What do other people think? Would starting at a max of 8 or 4 get
> consensus? Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years? (I think predictability is
> REALLY important).
>
> I chose 20 because all of my testing shows it to be safe, and all of my
> back-of-the-envelope calculations indicate the costs are reasonable.
>
> If consensus is "8 because more than order-of-magnitude increases are
> scary" -- ok.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/3c8e46e8/attachment.html>

2023-06-07 15:36:06

- reply

2023-06-07 15:36:00

- reply

📅 Original date posted:2015-05-31
📝 Original message:I will abstain on this wrangle of "when",
Instead I'd like to address some of the network topology health issues
that's been brought up in this debate.
Due to how blocks are being broadcast by miners at the moment, it is not
difficult to find the origin node of these blocks. These more influential
origin nodes are a minority, about <100 out of ~6000, <2%. These data
points are important to certain attack vectors. It is highly recommended
that pools adopt broadcast logic that rotates broadcasting nodes and
increase their node count.. Eloipool has this implanted for those seeking
to adopt/see it in action in the wild.
China is a particular worse-case due to the sporadic nature of their
internet infrastructure, especially connecting from/to outside of gfw, on a
average node-walk I can get up to a 10% difference while I know for a fact
some of the nodes shown to be down are up.
In F2Pool's case, I see 6 replay nodes, I don't know if that's enough or
that's all the nodes F2Pool runs, but it may be beneficial to set up
multi-homing with shadowsocks over mptcp to increase the stability. also
see if you can get a CERNET connection to be part of your rotations since
their backbone is quite good.
comments, question and grievances welcome.
On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902 at gmail.com> wrote:
> On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> >> Bad miners could attack us and the network with artificial
> >> big blocks.
> >
> >
> > How?
> >
> > I ran some simulations, and I could not find a network topology where a
> big
> > miner producing big blocks could cause a loss of profit to another miner
> > (big or small) producing smaller blocks:
> >
> > http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
> >
> > (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> > producing big blocks).
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase. Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month. We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun. For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
>
> I think we can accept 5MB block at most.
>
> (sorry forgot to cc to the mailing list)
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150531/6cbb311b/attachment.html>

2023-06-07 15:36:00

- reply