<unnamed>

Public Key

npub144uewnt43hzv7xa7cmexaljalz6szep5haqvepz3eu4zxmjrhrvq5ttkf0

Profile Code

nprofile1qqs267vhf46cm3x0rwlvdunwlewl3dgpvs6t7sxvs3gu723rdepm3kqpz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqw3w5ql

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:48:35 UTC

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

- 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 15:48:24 UTC

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

2023-06-07 15:48:24 UTC

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