Jeff Garzik [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-12 to 2015-12-21
💬 Posted a total of 545 messages
📚 Participated in the following categories: Bitcoin-development, ANN, PATCH, ANNOUNCE, PATCH, try2, RFC, BIP proposal, BIP draft, softfork proposal, bitcoin-dev, Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!, patch
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58

Profile Code

nprofile1qqstyhssufw5wrvmy92jrdgd5r070gsfhmrlah448psv8cvqllwgcygprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueq8zdh6c

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58

Show more details

Last Notes

2023-06-07 17:46:50

- reply

📅 Original date posted:2015-12-18
📝 Original message:My preference is height activation + one step per block (i.e. also
height). Height seems KISS.
AFAICT most of the attacks would occur around the already-heavily-watched
flag day activation event, in a height based environment, a useful
attribute.
However I would like to hear from others about possible attacks with the
various approaches, before diverging from the default community approach of
switch-based-on-time.
On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> Well, if it's not going to be height, I think median time of the previous
> block is better than the time of the current one, and would also solve Chun
> Wang's concerns.
> But as said I prefer to use heights that correspond to diff recalculation
> (because that's the window that bip9 will use for the later 95%
> confirmation anyway).
> On Dec 18, 2015 9:02 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
>
>> From a code standpoint, based off height is easy.
>>
>> My first internal version triggered on block 406,800 (~May 5), and each
>> block increased by 20 bytes thereafter.
>>
>> It was changed to time, because time was the standard used in years past
>> for other changes; MTP flag day is more stable than block height.
>>
>> It is preferred to have a single flag trigger (height or time), rather
>> than the more complex trigger-on-time, increment-on-height, but any
>> combination of those will work.
>>
>> Easy to change code back to height-based...
>>
>>
>>
>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I agree that nHeight is the simplest option and is my preference.
>>> Another option is to use the median time from the previous block (thus
>>> you know whether or not the next block should start the miner confirmation
>>> or not). In fact, if we're going to use bip9 for 95% miner upgrade
>>> confirmation, it would be nice to always pick a difficulty retarget block
>>> (ie block.nHeight % DifficultyAdjustmentInterval == 0).
>>> Actually I would always have an initial height in bip9, for softforks
>>> too.
>>> I would also use the sign bit as the "hardfork bit" that gets activated
>>> for the next diff interval after 95% is reached and a hardfork becomes
>>> active (that way even SPV nodes will notice when a softfork or hardfork
>>> happens and also be able to tell which one is it).
>>> I should update bip99 with all this. And if the 2 mb bump is
>>> uncontroversial, maybe I can add that to the timewarp fix and th recovery
>>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
>>> follow bip99's recommendations and doesn't want to give 6 full months as
>>> the pre activation grace period).
>>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> In many BIPs we have seen, include the latest BIP202, it is the block
>>>> time that determine the max block size. From from pool's point of
>>>> view, it cannot issue a job with a fixed ntime due to the existence of
>>>> ntime roll. It is hard to issue a job with the max block size unknown.
>>>> For developers, it is also easier to implement if max block size is a
>>>> function of block height instead of time. Block height is also much
>>>> more simple and elegant than time.
>>>> _______________________________________________
>>>> 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/20151218/42f35752/attachment-0001.html>

2023-06-07 17:46:49

- reply

📅 Original date posted:2015-12-18
📝 Original message:>From a code standpoint, based off height is easy.
My first internal version triggered on block 406,800 (~May 5), and each
block increased by 20 bytes thereafter.
It was changed to time, because time was the standard used in years past
for other changes; MTP flag day is more stable than block height.
It is preferred to have a single flag trigger (height or time), rather than
the more complex trigger-on-time, increment-on-height, but any combination
of those will work.
Easy to change code back to height-based...
On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I agree that nHeight is the simplest option and is my preference.
> Another option is to use the median time from the previous block (thus you
> know whether or not the next block should start the miner confirmation or
> not). In fact, if we're going to use bip9 for 95% miner upgrade
> confirmation, it would be nice to always pick a difficulty retarget block
> (ie block.nHeight % DifficultyAdjustmentInterval == 0).
> Actually I would always have an initial height in bip9, for softforks too.
> I would also use the sign bit as the "hardfork bit" that gets activated
> for the next diff interval after 95% is reached and a hardfork becomes
> active (that way even SPV nodes will notice when a softfork or hardfork
> happens and also be able to tell which one is it).
> I should update bip99 with all this. And if the 2 mb bump is
> uncontroversial, maybe I can add that to the timewarp fix and th recovery
> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
> follow bip99's recommendations and doesn't want to give 6 full months as
> the pre activation grace period).
> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> In many BIPs we have seen, include the latest BIP202, it is the block
>> time that determine the max block size. From from pool's point of
>> view, it cannot issue a job with a fixed ntime due to the existence of
>> ntime roll. It is hard to issue a job with the max block size unknown.
>> For developers, it is also easier to implement if max block size is a
>> function of block height instead of time. Block height is also much
>> more simple and elegant than time.
>> _______________________________________________
>> 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/20151218/770de789/attachment.html>

2023-06-07 17:43:51

- reply

📅 Original date posted:2015-10-22
📝 Original message:Here is the beginnings of an implementation to replace leveldb with sqlite:
https://github.com/jgarzik/bitcoin/tree/2015_sqlite
It builds, but still needs work before passing tests.
It was noted that leveldb is unmaintained, and this is part of researching
alternatives that are maintained and reliable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/751780a6/attachment.html>

2023-06-07 17:37:30

- reply

📅 Original date posted:2015-08-24
📝 Original message:There is a duplicated column.
BIP 100 voting is /BV\d+/
On Fri, Aug 21, 2015 at 9:24 AM, Christian Decker via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I hacked together a simple tracking page for the 'block votes', it
> currently includes the 8MB vote and XT, as well as the /BV\d+/ vote for
> generic size:
> http://bitcoinstats.com/network/votes/
>
> On Fri, Aug 21, 2015 at 7:25 AM odinn via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello Nicolas,
>>
>> On 08/20/2015 08:49 PM, Nicolas Dorier via bitcoin-dev wrote:
>> >> A visualization I would like to see would include:
>> >
>> >> pie graph(s) of what % are voting for (BIP 100, BIP 101, 8MB, BIP
>> >> sipa
>> > etc) based on what's published in blocks.
>> >
>> > If such a vote existed, I would gladly show the pie on BIPxDevs.
>> > However there is no standard way for miners to vote informally BIP
>> > they support.
>>
>> What about formal votes? Is there a way to visually have them appear
>> in a pie chart as the votes become apparent in blocks?
>>
>> I appreciate good visualizations and am trying to get a (visual)
>> comparison of the votes on these competing proposals.
>>
>> >
>> >
>> >
>> > _______________________________________________ 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
>>
>> iQEcBAEBAgAGBQJV1rZSAAoJEGxwq/inSG8CuNgIAIOIpHavzz6EJ5AOGBg2T859
>> MV7rsPfk1HBV4K1Yf4HfrlD/1SY0L57SANpRodi1NME3pl27QQCDnuwNLAqOLKtA
>> P/sHXnk9LuSG8Czk0PHOslZ+f1fDbmNm9gtR3QWXGOx0jP2b+WQ8RhkPhqQ++S/i
>> oXmjyrk+8TTu1hxMbuCcG5bqeS0lBm0SyrSbRTPWH+4U1jGYbxQNKkHnuZGByX4B
>> HBWuKvIylQzHCfy0ToUW+Z29Y+78wQNQUOA10eq7qpZCZvfRZUov1KBVXLx8GAKy
>> Y5WGSJYIAt+Rwn9eMxhpD91ZR1vwtqtRZn7M+NtrStPBJt+n4ET9VmPpsMAc/Zc=
>> =AHv3
>> -----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/20150824/6ea02715/attachment-0001.html>

2023-06-07 15:48:56

- reply

2023-06-07 15:48:35

- reply

📅 Original date posted:2015-08-19
📝 Original message:bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
discussion?
As Jorge notes, a general discussion list has existed for a long time with
little use.
On Wed, Aug 19, 2015 at 5:58 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
>> Apparently that existed already:
>> http://sourceforge.net/p/bitcoin/mailman/
>> But technical people run away from noise while non-technical people
>> chase them wherever their voices sounds more loud.
>>
>
> Regarding disruptors, if there are clear rules about what is acceptable on
> -dev, one can simply moderate out offenders. It's absolutely necessary we
> have a forum where we can share and discuss purely academic and technical
> matters. No-one can accuse censorship because all moderation would say
> would be to "take it to the other list". It's essential for all people who
> are developing and maintaining Bitcoin protocol software, or services that
> rely on it. The mailing list used to be very low volume.
>
> While we are at it, we should also think about a bitcoin-announce read
> only list which consumers of Bitcoin Core can subscribe for announcements
> about new versions of Bitcoin Core, and any critical warnings. Miners and
> service providers would particularly benefit from this. The list is
> moderated so only say Bitcoin Core commit engineers are allowed to post.
>
>
>> One thing that I would like though, is separating Bitcoin
>> Core-specific development from general bips and consensus discussions.
>>
>
> The potential downside is too much separation becomes confusing although I
> would not oppose such a change. My own suggestion would be try just a -dev
> and -discuss list and see how that goes first. It used to work well.
> Whatever the case I am very confident we need a general discussion mailing
> list.
>
>
>
> _______________________________________________
> 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/20150819/bc1f9aa4/attachment.html>

2023-06-07 15:43:05

- reply

📅 Original date posted:2015-07-22
📝 Original message:I wouldn't go quite that far. The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:
Quoting BC,
> Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or staying on an older version are all valid
choices. If the majority of the network chooses not to endorse a specific
change, then the majority of the network will continue to operate just fine
without it, and properly structured consensus rules will pull the minority
along as well.
The developers *propose* a new version, by publishing a new release. The
individual network nodes choose to accept or reject that.
So I respectfully disagree with "core devs don't control the network" and
"core devs control the network" both.
There are checks-and-balances that make the system work. Consensus is most
strongly measured by user actions after software release. If the
developers fail to reflect user consensus, the network will let us know.
On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have
>> no authority to set its rules.
>>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make
> a release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> 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/20150722/f4c37787/attachment-0001.html>

2023-06-07 15:40:14

- reply

📅 Original date posted:2015-06-25
📝 Original message:On Thu, Jun 25, 2015 at 6:41 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Wladimir is doing an amazing job under difficult circumstances. Give the
> guy a break, please
A+ agreed. He is not an elected decider - he is the Bitcoin Core release
manager, and has been doing a damn fine job.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/035d6855/attachment.html>

2023-06-07 15:40:03

- reply

📅 Original date posted:2015-06-24
📝 Original message:BIPs are accepted into BIP repo with a low "reasonable" threshold.
Code is accepted into the Bitcoin Core repo when it is likely that the
community will accept a change.
There is no voting in the way you think. Devs commit changes the users will
accept and use. Users "fire" developers by choosing different devs or
different software.
Standard open source method.
On Jun 24, 2015 4:41 PM, "Raystonn" <raystonn at hotmail.com> wrote:
> I would like to start a civil discussion on an undefined, or at least
> unwritten, portion of the BIP process. Who should get to vote on approval
> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
> these voters sufficient for approval? If not, then what is?
>
> Raystonn
> _______________________________________________
> 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/5eae6595/attachment-0001.html>

2023-06-07 15:37:35

- reply

📅 Original date posted:2015-06-14
📝 Original message:Since you missed it, here is the suggestion again:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
On Sun, Jun 14, 2015 at 6:06 AM, Mats Henricson <mats at henricson.se> wrote:
> Jeff,
>
> with all due respect, but I've seen you saying this a few times
> now, that this decision is oh so difficult and important.
>
> But this is not helpful. We all know that. Even I.
>
> Make a suggestion, or stay out of the debate!
>
> Mats
>
> On 06/14/2015 07:36 AM, Jeff Garzik wrote:
> > The choice is very real and on-point. What should the block size limit
> > be? Why?
> >
> > There is a large consensus that it needs increasing. To what? By what
> > factor?
> >
> > The size limit literally defines the fee market, the whole damn thing.
> If
> > software high priests choose a size limit of 300k, space is scarce, fees
> > are bid high. If software high priests choose a size limit of 32mb,
> space
> > is plentiful, fees are near zero. Market actors take their signals
> > accordingly. Some business models boom, some business models fail, as a
> > direct result of changing this unintentionally-added speedbump.
> Different
> > users value adoption, decentralization etc. differently.
> >
> > The size limit is an economic policy lever that needs to be transitioned
> > -away- from software and software developers, to the free market.
> >
> > A simple, e.g. hard fork to 2MB or 4MB does not fix higher level
> governance
> > problems associated with actors lobbying developers, even if a cloistered
> > and vetted Technical Advisory Board as has been proposed.
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
> >
> >> I definitely think we need some voting system for metaconsensus…but if
> >> we’re going to seriously consider this we should look at the problem
> much
> >> more generally. Using false choices doesn’t really help, though ;)
> >>
> >> - Eric Lombrozo
> >>
> >>
> >> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> >>
> >> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com>
> >> wrote:
> >>
> >>> 2) BIP100 has direct economic consequences…and particularly for miners.
> >>> It lends itself to much greater corruptibility.
> >>>
> >>>
> >> What is the alternative? Have a Chief Scientist or Technical Advisory
> >> Board choose what is a proper fee, what is a proper level of
> >> decentralization, a proper growth factor?
> >>
> >>
> >>
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/073f0190/attachment.html>

2023-06-07 15:37:33

- reply

📅 Original date posted:2015-06-14
📝 Original message:Exactly -- both block size proponents and block size change conservatives
seem to be glossing over this aspect - much to my dismay.
Choosing the size limit is choosing the size of a scarce resource. By fiat.
It is wrong to think that a "technical consensus" can choose what is best
here.
The block size limit defines the scope of a resource for which all fee
market actors bid. That, in turn, defines who is in the fee market and how
they behave, what market choices are made.
It doesn't matter how or why the limit was originally enacted, what Satoshi
meant to do. What matters, economically, is what is. What the software
and our $3B economy & market knows and sees today. (I think some block
size change proponents miss this!)
The solution lies in transitioning this size limit to the free market. In
the end, the users must choose their desired level of growth,
decentralization, etc. We cannot rely on some dev's idea of the proper
level of fee, proper level of growth, proper level of decentralization.
And IMO, a "floating limit with training wheels" is better and stronger for
bitcoin's health from a governance, user choice and free market perspective
than simply "hard fork to 2MB, come back again in 6 months."
On Sun, Jun 14, 2015 at 6:34 AM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> "The size limit is an economic policy lever that needs to be
> transitioned -away- from software and software developers, to the free
> market."
>
> Exactly right. Bitcoin does not have a free market for fee though, and
> literally all the discussion so far has neglected some fundamental
> aspect of this, as you described. It's not at all a "technical" or
> "engineering" decision. It's the question of how to potentially
> re-design a fundamental part of Bitcoin, and the proposals so far
> don't address this. What is the price of the scarce resource of the
> blockchain and the mechanism to decide on price, once the subsidy runs
> out?
>
> On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats at henricson.se>
> wrote:
> > Jeff,
> >
> > with all due respect, but I've seen you saying this a few times
> > now, that this decision is oh so difficult and important.
> >
> > But this is not helpful. We all know that. Even I.
> >
> > Make a suggestion, or stay out of the debate!
> >
> > Mats
> >
> > On 06/14/2015 07:36 AM, Jeff Garzik wrote:
> >> The choice is very real and on-point. What should the block size limit
> >> be? Why?
> >>
> >> There is a large consensus that it needs increasing. To what? By what
> >> factor?
> >>
> >> The size limit literally defines the fee market, the whole damn thing.
> If
> >> software high priests choose a size limit of 300k, space is scarce, fees
> >> are bid high. If software high priests choose a size limit of 32mb,
> space
> >> is plentiful, fees are near zero. Market actors take their signals
> >> accordingly. Some business models boom, some business models fail, as a
> >> direct result of changing this unintentionally-added speedbump.
> Different
> >> users value adoption, decentralization etc. differently.
> >>
> >> The size limit is an economic policy lever that needs to be transitioned
> >> -away- from software and software developers, to the free market.
> >>
> >> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level
> governance
> >> problems associated with actors lobbying developers, even if a
> cloistered
> >> and vetted Technical Advisory Board as has been proposed.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
> >>
> >>> I definitely think we need some voting system for metaconsensus…but if
> >>> we’re going to seriously consider this we should look at the problem
> much
> >>> more generally. Using false choices doesn’t really help, though ;)
> >>>
> >>> - Eric Lombrozo
> >>>
> >>>
> >>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> >>>
> >>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com>
> >>> wrote:
> >>>
> >>>> 2) BIP100 has direct economic consequences…and particularly for
> miners.
> >>>> It lends itself to much greater corruptibility.
> >>>>
> >>>>
> >>> What is the alternative? Have a Chief Scientist or Technical Advisory
> >>> Board choose what is a proper fee, what is a proper level of
> >>> decentralization, a proper growth factor?
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/48bfb14a/attachment.html>

2023-06-07 15:37:32

- reply

📅 Original date posted:2015-06-14
📝 Original message:On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> 2) BIP100 has direct economic consequences…and particularly for miners. It
> lends itself to much greater corruptibility.
>
>
What is the alternative? Have a Chief Scientist or Technical Advisory
Board choose what is a proper fee, what is a proper level of
decentralization, a proper growth factor?
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/82643684/attachment.html>

2023-06-07 15:37:32

- reply

📅 Original date posted:2015-06-14
📝 Original message:The choice is very real and on-point. What should the block size limit
be? Why?
There is a large consensus that it needs increasing. To what? By what
factor?
The size limit literally defines the fee market, the whole damn thing. If
software high priests choose a size limit of 300k, space is scarce, fees
are bid high. If software high priests choose a size limit of 32mb, space
is plentiful, fees are near zero. Market actors take their signals
accordingly. Some business models boom, some business models fail, as a
direct result of changing this unintentionally-added speedbump. Different
users value adoption, decentralization etc. differently.
The size limit is an economic policy lever that needs to be transitioned
-away- from software and software developers, to the free market.
A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
problems associated with actors lobbying developers, even if a cloistered
and vetted Technical Advisory Board as has been proposed.
On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> I definitely think we need some voting system for metaconsensus…but if
> we’re going to seriously consider this we should look at the problem much
> more generally. Using false choices doesn’t really help, though ;)
>
> - Eric Lombrozo
>
>
> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>> 2) BIP100 has direct economic consequences…and particularly for miners.
>> It lends itself to much greater corruptibility.
>>
>>
> What is the alternative? Have a Chief Scientist or Technical Advisory
> Board choose what is a proper fee, what is a proper level of
> decentralization, a proper growth factor?
>
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/b1a4825d/attachment.html>

2023-06-07 15:37:31

- reply

📅 Original date posted:2015-06-14
📝 Original message:On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang <1240902 at gmail.com> wrote:
> To tell you the truth. It is only because most miners are not located
> in the West. If Slush, Eligius and BTC Guild still on top 3, the core
> developers, including brain-dead Mike Hearn, would be very happy to do
> BIP100 just like they did BIP34 and BIP66. Shame on you!
>
BIP 100 requires a hard fork to engage. Users proactively opt-in.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/718f5a1c/attachment.html>

2023-06-07 15:32:24

- reply

📅 Original date posted:2015-04-09
📝 Original message:On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse <stephencalebmorse at gmail.com>
wrote:
> Is hashing transaction data once for each input really a huge bottleneck,
> though? Do mobile devices have an issue with this?
>
Think about what slow transaction verification speed means. Slower
propagation across the network. More work per node. Greater opportunity
for algorithmic attacks, races and other shenanigans by attackers.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150409/dbb8cb15/attachment.html>

2023-06-07 15:28:31

- reply

📅 Original date posted:2015-01-14
📝 Original message:Sounds like this warrants a micro-BIP just to get everybody on the same
page.
On Wed, Jan 14, 2015 at 11:37 AM, Ruben de Vries <ruben at blocktrail.com>
wrote:
> For p2sh multisig TXs the order of the public keys affect the hash and
> there doesn't seem to be an agreed upon way of sorting the public keys.
>
> If there would be a standard (recommended) way of sorting the public keys
> that would make it easier for services that implement some form of multisig
> to be compatible with each other without much hassle and making it possible
> to import keys from one service to another.
>
> I'm not suggesting forcing the order, just setting a standard to
> recommend, there doesn't seem to be much reason for (new) services to not
> follow that recommendation.
>
> Ryan from BitPay broad this up before (
> https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in
> bitcore they've implemented lexicographical sorting on the hex of the
> public key.
> In a short search I can't find any other library that has a sorting
> function, let alone using it by default, so bitcore is currently my only
> reference.
>
>
> Ruben de Vries
> CTO, BlockTrail
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150114/2468d959/attachment.html>

2023-06-07 15:27:03

- reply

📅 Original date posted:2014-10-30
📝 Original message:That's what we do for testnet today: https://en.bitcoin.it/wiki/Testnet
If no block is found for 20 minutes, one minimum-diff block may be mined.
On Thu, Oct 30, 2014 at 7:18 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi all,
>
> I've been toying with an algorithm to place a ceiling on
> confirmation latency by allowing weaker blocks after a certain time.
> Hope this isn't noise, but thought someone must have considered this
> before, or know of flaws in the scheme?
>
> Gory details:
> http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html
>
> Thanks,
> Rusty.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:25:44

- reply

📅 Original date posted:2014-09-13
📝 Original message:That claim is horse manure :) He never signed private emails sent to
me, nor the forum posts.
He -might- have signed the occasional thing related to releases, I'm not sure.
On Sat, Sep 13, 2014 at 9:55 AM, Peter Todd <pete at petertodd.org> wrote:
> So far I have zero evidence that the common claim that "Satoshi PGP
> signed everything" was true; I have no evidence he ever
> cryptographically signed any communications at all.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000ce4f740fb700bb8a9ed859ac96ac9871567a20fca07f76a
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:25:00

- reply

📅 Original date posted:2014-08-08
📝 Original message:gmaxwell noted on IRC that enabling TLS could be functionally, if not
literally, a DoS on the pool servers. Hence the thought towards a
more lightweight method that simply prevents client payout redirection
+ server impersonation.
On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn <mike at plan99.net> wrote:
>> Certificate validation isn't needed unless the attacker can do a direct
>> MITM
>> at connection time, which is a lot harder to maintain than injecting a
>> client.reconnect.
>
>
> Surely the TCP connection will be reset once the route reconfiguration is
> completed, either by the MITM server or by the client TCP stack when it
> discovers the server doesn't know about the connection anymore?
>
> TLS without cert validation defeats the point, you can still be connected to
> a MITM at any point by anyone who can simply interrupt or corrupt the
> stream, forcing a reconnect.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:24:35

- reply

📅 Original date posted:2014-07-30
📝 Original message:Seeing this on one of my public nodes:
2014-07-30 13:13:26 receive version message:
/getaddr.bitnodes.io:0.1/: version 70001, blocks=313169,
us=162.219.2.72:8333, peer=11847
2014-07-30 13:13:33 receive version message:
/getaddr.bitnodes.io:0.1/: version 70001, blocks=290000,
us=162.219.2.72:8333, peer=11848
2014-07-30 13:14:21 receive version message:
/getaddr.bitnodes.io:0.1/: version 70001, blocks=313169,
us=162.219.2.72:8333, peer=11849
That is abusive, taking up public slots. There is no reason to
connect so rapidly to the same node.
Other seeders are also rapidly reconnect'ers, though the time window
is slightly more wide:
2014-07-30 13:09:35 receive version message: /bitcoinseeder:0.01/:
version 60000, blocks=230000, us=162.219.2.72:8333, peer=11843
2014-07-30 13:12:42 receive version message: /bitcoinseeder:0.01/:
version 60000, blocks=230000, us=162.219.2.72:8333, peer=11846
The version message helpfully tells me my own IP address but not theirs ;p
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:24:09

- reply

📅 Original date posted:2014-07-18
📝 Original message:Related: We must handle some legitimate miner-privately-mined cases,
such as miner payout TXs (outside coinbase) or side chain conditional
TXs[1].
[1] https://bitcointalk.org/index.php?topic=676703.msg7682680#msg7682680
On Fri, Jul 18, 2014 at 3:51 PM, Kaz Wesley <keziahw at gmail.com> wrote:
> I've updated the gist, and added an additional proposal that I think
> meshes well:
> https://gist.github.com/kazcw/43c97d3924326beca87d#ultra-fast-block-validation
>
> sparseblocks + UFBV would tighten the new-block process to this (when
> txes have been received in advance):
> - receive block (~2kB for 1000 tx)
> - check whether block contains txes known to belong to conflict-sets,
> and if so whether more than one tx from a single conflict-set has been
> included (a few operations on very small sets)
> - relay block (~2kB)
>
> The benefits of these changes only occur when the transactions have
> been seen in advance, but incentivizing ahead-of-block transaction
> propogation is a plus, as Jeff mentioned; working on a block without
> first ensuring peers have its transactions would be very expensive
> from a miner's point of view.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:24:08

- reply

📅 Original date posted:2014-07-18
📝 Original message:On a flood-fill network, you don't want to create a storm of "I
already have this" replies.
On Fri, Jul 18, 2014 at 1:39 PM, Kaz Wesley <keziahw at gmail.com> wrote:
> Peers exchanging mempool priority policies is great; that accomplishes
> the flexibility in what txes to remember that I was going for with the
> forget-filters, but much more neatly, with less overhead and some side
> benefits.
>
> Here's what I'm picturing now:
> - exchange priority policies in peer introductions
> - assign unique sequential IDs in the order the transactions were
> inved (per peer)
> - receiving a getdata for a tx updates last-known-peer-received inv to
> all invs up to the one referenced
> - include ID-last-received, last-known-peer-received in sparse block
> - reference txes in sparse block by index in receiver's
> prioritiziation with peer's sent invs up to ID-last-received and
> sender's prior invs up to last-known-peer-received
>
> Possible new messages:
> - sparseblock
> - invack message a node can send at times when it's received a bunch
> of invs it already has, so it hasn't acked with a getdata in a while
> - gettx: getdata, but using new sequential ID to save 28 bytes per tx
>
> It seems important for ordering policies to be able to be specified in
> as much detail as possible. Parameters that should be available:
> - total inputs
> - total outputs
> - bytes
> - coin days destroyed
> - net UTXO size change
> - sigops
> - is data carrier
> - is output raw multisig
> - age in mempool
> - what else?
> This parameter set should be extensible to allow for unforeseen future factors.
>
> Ordering policies should allow arbitrary algebraic combinations of
> their parameters, as well as thresholds. Boolean combinations of
> sub-policies would also be desirable. This could be implemented with a
> tx-script-like stack-based language, in which each supported tx
> property is pushed onto the stack by a particular opcode, and
> +-*//min/max/boolean operators combine them to yield the sort key.
>
> Difficult parameters:
> * Coin-days-destroyed: changes, peers need agreement on when (if?)
> it's recalculated. Probably can just not recalculate, but peers still
> need agreement on "time seen" to get CDD.
> * Age in mempool: seems intractable in terms of time, but could be
> done easily in terms of "how many txes old is this sequential ID"
>
> One potential pitfall: this allows for an environment of completely
> heterogeneous mempool policies. I think that's a good thing, but we
> need to avoid a situation where only least-common-denominator
> transactions make it farther than a hop or two, and we don't want
> nodes to have a strong preference for connecting to like-minded peers
> since clustering reduces overall connectivity. It may be worthwhile to
> add a parallel mechanism for relay policies, to differentiate between
> what a node would keep in its mempool vs. what it wouldn't even relay
> and doesn't want to see at all. Relay policies could be specified just
> like prioritization policies, but with the final stack value evaluated
> in a boolean context.
>
> An interesting additional use of policy-scripts would be a
> standardized way for miners to include a policy script in a coinbase,
> allowing miners a mechanism to advertise things like their relative
> price of sigops vs bytes. Nodes may then choose to take this
> information into account in order to optimize their mempool policies
> for likelihood of consistency with future blocks. Since policy scripts
> provide only relative information on prices of different transaction
> properties rather than an absolute fee, this should not allow miners
> to "vote fees up", although care would need to be taken they wouldn't
> be able to drive up prices by claiming common transaction types are at
> the high end of the fee scale.
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:24:07

- reply

📅 Original date posted:2014-07-18
📝 Original message:On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> I'd encourage you to code up a prototype first (or at the same time), in
> whatever programming language / networking library you're most familiar
> with.
+1
> Maybe not even using the existing p2p protocol; there could be a mining-only
> very-fast-block-propagation network separate from the existing p2p network.
>
> Combining your optimizations with "broadcast as many near-miss blocks as
> bandwidth will allow" on a mining backbone network should allow insanely
> fast propagation of most newly solved blocks.
Yes, I would encourage thinking along these lines. That was the
motivation of the UDP P2P protocol extension I wrote:
https://bitcointalk.org/index.php?topic=156769.0
The intention was to experiment with sending block header + tx list +
coinbase, via UDP best effort broadcast.
Incentives:
If your neighbors receiving this message already have the TXs in the
TX list, then the block is complete, and may be relayed further.
If your neighbors do not have all TXs in the block, they must fetch
them at additional time/latency cost.
Thus, you have an incentive to relay blocks containing TXs already
distributed out into network mempools and cached in the signature
cache.
We want to capture that incentive in whatever protocol is eventually
used. Miners have a TX fee incentive to include many transactions.
In theory, they want to include as many TX as possible. It will help
us scale quite a bit to solve this problem.

2023-06-07 15:24:07

- reply

📅 Original date posted:2014-07-18
📝 Original message:On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> But if there was some agreed-upon canonical ordering, then it should
> theoretically be possible to take shortcuts in the "what order".
>
> You'd start with setof(transactions I think everybody knows about)
> Select some subset, based on miner's policy
> Sort that subset with the canonical ordering algorithm
> Very efficiently broadcast, taking all sorts of shortcuts assuming most of
> your peers already know the set you started with and expect the same
> canonical ordering (see gmaxwell's thoughts on block encoding).
Related implementation detail: Having pursued this train of thought,
I noted that you don't want to include too-young transactions that you
received in the past few seconds, because those are likely still
propagating around the network.
> Second half-baked thought:
> I wonder if broadcasting your transaction selection policy ("11KB of free
> transactions, sorted by priority, then 111K of fee-paying transactions,
> sorted by fee") might make it possible to save even more bandwidth by
> letting your peers create a very good approximation of your block with just
> that information....
Absolutely. One path I would like to see pursued is multiple
p2pool-esque chains. Each with their own policy, perhaps with their
own administrative team. ie. you could have a fully decentralized
p2pool-like chain, or multiple such chains, each with a stated
policy/reward pattern. Or, GHash/BTCGuild/Eligius could run a
semi-centrally managed chain ultimately guaranteed not only by
protocol but by administrators' digital signatures.
In each case, advertising technical attributes about your pool [chain]
policy would give nodes the better ability to predict what is in an
upcoming block.
And the flip side of that, such predictions are never perfect. Need
to make sure the fallback case, while undoubtedly more costly than the
Fast Path, is not overly painful.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:24:04

- reply

📅 Original date posted:2014-07-18
📝 Original message:Yes. That, and several other things. If you can figure out how to
propagate a block without re-propagating all the transactions everyone
already has, you address the large-blocks-slower-to-relay problem, and
additionally create an incentive for miners to mine blocks consisting
of publicly broadcast transactions (versus a bunch of secret ones
mined with secret agreements).
Democratizing transaction selection takes a bit of power away from the
miners and gives it back to the network at large. GBT is another
piece of that puzzle.
On Fri, Jul 18, 2014 at 6:43 AM, Mike Hearn <mike at plan99.net> wrote:
> Oops, sorry, I see the subject line changed. This is what I get for working
> down the thread list top to bottom :)
>
> I think the best path forward now is to finish off getblocktemplate support
> in the various tools so it's possible to pool for payout purposes without
> giving up control of block creation modulo the coinbase. Combined with the
> recent sipa performance enhancing goodness, it would hopefully persuade some
> non-trivial chunk of hashpower to go back to running their own node and
> start the process of turning pools merely into payout trackers rather than
> block selectors.
>
>
> On Fri, Jul 18, 2014 at 12:41 PM, Mike Hearn <mike at plan99.net> wrote:
>>
>> Jeff, I think the message you're replying to got clipped.
>>
>> Satoshi's only comment AFAIK on the topic of GPU mining was to wish for a
>> gentlemen's agreement to postpone it as long as possible, to help make sure
>> the distribution of coins was as even as possible. Indeed this predated
>> pooled mining.
>>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:22:30

- reply

📅 Original date posted:2014-06-06
📝 Original message:We are considering pulling in https://github.com/bitcoin/bitcoin/pull/2340
"Discourage fee sniping with nLockTime"
Comments from other wallet implementors in particular are welcomed.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:22:17

- reply

📅 Original date posted:2014-06-04
📝 Original message:Yes, check macros like that can be useful.
I like the kernel's policy, which parallels our direction:
1) Enable and use lightweight assertions for most users.
2) No assertions with side effects
If you want to compile them out, that's fine, but they should always
be present in production software.
On Wed, Jun 4, 2014 at 6:20 AM, Mike Hearn <mike at plan99.net> wrote:
>> As a matter of procedure we do not use assertions with side effects— the
>> codebase did at one point, but have cleaned them up. In an abundance of
>> caution we also made it refuse to compile without assertions enabled: A
>> decision who's wisdom was clearly demonstrated when not long after, some
>> additional side-effect having assert was contributed. In the real world
>> errors happen here and there, and making robust software involves defense in
>> depth.
>
>
> I think this class of errors could be removed entirely by just saying it's
> OK for assertions to have side effects and requiring them to be enabled, as
> is currently done.
>
> The glog library:
>
> http://google-glog.googlecode.com/svn/trunk/doc/glog.html
>
> provides CHECK macros that print stack traces when they fail. Using them
> would also be good.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:17:00

- reply

📅 Original date posted:2014-04-02
📝 Original message:At first, this is a poor choice of URL.
But it really looks like a phishing attempt that no one should visit.
On Tue, Apr 1, 2014 at 4:00 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
> I've sat on this for some time after starting this. I have forked this
> from bitcoin core and am working on a secure tax "mode" for bitcoin. It
> is written in Autoit. I know I know, scripting language alert! I would
> like people to look at:
> http://www.githubb.com/bitcoin/bitcoin
> Look at it, and let's have an open dialog about it. I want to know the
> good, the bad, and the ugly!
>
> --
> Kevin
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:16:17

- reply

📅 Original date posted:2014-03-27
📝 Original message:On Thu, Mar 27, 2014 at 3:09 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> A notable suggestion was to instead of building a directory of magic numbers
> (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bitcoin",
> "Litecoin", "Dogecoin", so collosion is unlikely and
> cetral directory is not needed.
+1 good idea
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:15:36

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 1:18 PM, Mark Friedenbach <mark at monetize.io> wrote:
> Using milli- and micro- notation for currency units is also not very
> well supported. Last time this thread was active, I believe there was a
> suggestion to use 1 XBT == 1 uBTC. This would bring us completely within
> the realm of supported behavior in accounting applications.
Yes. That was in Tamas's recursive link, and also brought up on
github by jcorgan. +1
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:08:27

- reply

📅 Original date posted:2013-11-02
📝 Original message:On Sat, Nov 2, 2013 at 12:52 PM, Melvin Carvalho
<melvincarvalho at gmail.com> wrote:
> Identity need not be a hard problem. In my view it is a solved problem.
Yes: https://en.bitcoin.it/wiki/Identity_protocol_v1

2023-06-07 15:07:42

- reply

📅 Original date posted:2013-10-21
📝 Original message:On Mon, Oct 21, 2013 at 11:46 AM, Andreas Schildbach
<andreas at schildbach.de> wrote:
> I accept the nomination as a backup (-:
Cool.
> So the duty of the editor is merging pull requests and/or proxying
> between email and git for those who do not use git?
Correct. And assigning BIP numbers. Ideally a boring administrative
position. :)
The main tensions will be in gauging whether there is sufficient
consensus and review to boost a draft into BIP/proposed status, and
then promoting a numbered BIP to the final/accepted status.
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:07:42

- reply

📅 Original date posted:2013-10-21
📝 Original message:Added: I'm happy with gmaxwell as BIP editor as well, as he is
apparently the current BIP-number-assigner-in-chief. :)
The goal is to improve the process, hash-seal our specs, and create an
easy way for anyone with at least an email address to participate.
On Mon, Oct 21, 2013 at 10:30 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> This summarizes some rambling on IRC about revising the BIPS process.
>
> Right now, the BIPS process is a bit haphazard. Previously, BIPS were
> in a git repo, and the BIPS on the wiki were locked against editing.
> The BIPS editor at the time started off well, but was eventually
> M.I.A. So the BIPS "home" moved de facto to where everyone was
> reading them anyway, the wiki. They were made editable, and it became
> easier to Just Pick A Number And Write One. However, this inevitably
> became a bit disorganized. Further, there was a recent incident --
> easily reverted -- where someone hopped on the wiki and started
> arbitrarily editing an existing standard.
>
> BIPs need to move back to git, in my opinion. Standards should be
> hash-sealed against corruption. Anything less would be uncivilized,
> and un-bitcoin. However, many on IRC pointed out requiring a git pull
> request might be a burdensome process, and discourage some
> contributors. The following is a sketch of an improved process.
>
> 1) BIP Draft.
>
> Modelled after IETF drafts. Anybody may submit a BIP draft, as long
> as it meets two very loose requirements:
> * At least somewhat related to bitcoin. Note, I did not say "crypto-currency".
> * Formatted similarly to existing BIPs (i.e. markdown, or whatever the
> community prefers)
>
> BIP drafts may be submitted via git pull request, or by emailing an
> attachment to bips.editor at bitcoin.org. This mirrors the Linux kernel
> change submission process: git is preferred, but there is always a
> non-git method for folks who cannot or do not wish to use git or
> github.
>
> BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
> are not automatically assigned a BIPS number.
>
> 2) Time passes. Software for BIP drafts is developed, tested,
> published, and publicly discussed in a typical open source manner.
>
> 3) If interest and use cases remain strong, a BIP number may be
> requested, and the BIP draft is moved to
> git://github.com/bitcoin/bips.git main directory.
>
> 4) If there is general consensus that the BIP should be adopted, the
> BIP status is changed to "accepted."
>
> There are no specified time limits. Sometimes consensus about a BIP
> is reached in days, sometimes 12+ months or more. It varies widely
> depending on the feature's complexity and impact.
>
> As with the IETF, it will be q
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc. https://bitpay.com/
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:07:41

- reply

📅 Original date posted:2013-10-21
📝 Original message:This summarizes some rambling on IRC about revising the BIPS process.
Right now, the BIPS process is a bit haphazard. Previously, BIPS were
in a git repo, and the BIPS on the wiki were locked against editing.
The BIPS editor at the time started off well, but was eventually
M.I.A. So the BIPS "home" moved de facto to where everyone was
reading them anyway, the wiki. They were made editable, and it became
easier to Just Pick A Number And Write One. However, this inevitably
became a bit disorganized. Further, there was a recent incident --
easily reverted -- where someone hopped on the wiki and started
arbitrarily editing an existing standard.
BIPs need to move back to git, in my opinion. Standards should be
hash-sealed against corruption. Anything less would be uncivilized,
and un-bitcoin. However, many on IRC pointed out requiring a git pull
request might be a burdensome process, and discourage some
contributors. The following is a sketch of an improved process.
1) BIP Draft.
Modelled after IETF drafts. Anybody may submit a BIP draft, as long
as it meets two very loose requirements:
* At least somewhat related to bitcoin. Note, I did not say "crypto-currency".
* Formatted similarly to existing BIPs (i.e. markdown, or whatever the
community prefers)
BIP drafts may be submitted via git pull request, or by emailing an
attachment to bips.editor at bitcoin.org. This mirrors the Linux kernel
change submission process: git is preferred, but there is always a
non-git method for folks who cannot or do not wish to use git or
github.
BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
are not automatically assigned a BIPS number.
2) Time passes. Software for BIP drafts is developed, tested,
published, and publicly discussed in a typical open source manner.
3) If interest and use cases remain strong, a BIP number may be
requested, and the BIP draft is moved to
git://github.com/bitcoin/bips.git main directory.
4) If there is general consensus that the BIP should be adopted, the
BIP status is changed to "accepted."
There are no specified time limits. Sometimes consensus about a BIP
is reached in days, sometimes 12+ months or more. It varies widely
depending on the feature's complexity and impact.
As with the IETF, it will be q
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:07:41

- reply

📅 Original date posted:2013-10-21
📝 Original message:Continuing. (grumble gmail grumble)
As with the IETF, there will be a great many drafts that do not make
it to BIPS status. That is normal, and a sign of a healthy process.
I'll volunteer as the BIPS editor.
There needs to be some backups with commit access to bips.git, in case
the BIPS editor is hit by a bus or goes crazy or on vacation. This
can be some core devs, but I would like at least one or two folks who
are not Satoshi-client devs on the list. Maybe Andreas, Michael G,
Alan R, and others working on non-Satoshi clients.
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:07:36

- reply

📅 Original date posted:2013-10-20
📝 Original message:On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete at petertodd.org> wrote:
> FWIW I think that BIP's should have been done as a github repository,
> allowing for dealing with this stuff transparently as a pull-request.
> It'd also be useful to handle BIP's that way to make it easy to archive
> them, update them, and keep a log of what and why they were updated.
> Just put them in markdown format, which is pretty much feature
> equivalent to the wiki now that markdown supports images.
Agreed -- let's do it. I nominate you to do the conversion, and we'll
put it up at github.com/bitcoin/bips.git.
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:03:57

- reply

📅 Original date posted:2013-06-27
📝 Original message:On Thu, Jun 27, 2013 at 1:10 PM, Jim <jim618 at fastmail.co.uk> wrote:
> Hello Everybody,
>
> Over the last few months we have been steadily adding
> functionality to MultiBit including:
> + encrypted wallets
> + sign and verify message
> + stability improvements and bug fixes.
>
> As a result of these efforts I think MultiBit is now
> suitable for the entry level Bitcoin user. I propose
> that we put MultiBit as the default desktop client
> on the bitcoin.org "Choose your wallet" page.
>
> I think a typical new user comes to bitcoin.org from a
> google search or a Bitcoin news article. We want them to
> peruse the bitcoin.org site and try out a wallet. They
> should be able to get MultiBit up and running in a tea break.
> Then perhaps they get a colleague to send them some bitcoin
> from an Android phone by zapping a QR code.
This is definitely a great discussion to have. Here are some initial,
unprioritized thoughts. As an engineer, there is never a clear
answer, but a balance of costs and benefits.
Arguments in favor of moving away from Bitcoin-Qt/bitcoind for wallet services:
* Bitcoin-Qt is admittedly a very simple wallet. I see it's core
strengths more as a "P2P router" for the public blockchain data.
* Wallet feature innovation moves more slowly than
Armory/bitcoinj/blockchain.info.
* Requires the full blockchain, which is resource-intensive versus SPV.
Arguments in favor of retaining Bitcoin-Qt/bitcoind default:
* More field experience, code review and testing on desktop than others
* Very real possibility of an overall net reduction of full nodes on P2P network
Arguments in favor of multibit default:
* Good user interface, perhaps more friendly for entry level users as
you describe
* Based on bitcoinj, which has field experience and a very large
installed base thanks to Bitcoin Wallet/Schildbach
Arguments against multibit default:
* Less testing, field experience on desktop
I'm sure others can come up with a few more.
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/

2023-06-07 15:01:35

- reply

📅 Original date posted:2013-05-09
📝 Original message:On Thu, May 9, 2013 at 11:40 AM, Mike Hearn <mike at plan99.net> wrote:
> 2038 issues only apply to use of signed timestamps, I thought we treat
> this field as unsigned? Is it really a big deal?
Not a big deal at all, no.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 15:01:32

- reply

📅 Original date posted:2013-05-08
📝 Original message:On Wed, May 8, 2013 at 9:00 PM, John Dillon
<john.dillon892 at googlemail.com> wrote:
> Perhaps Satoshi did this delibrately, knowing that at some point a hard-fork
> would be a good idea, so that we all would have a good excuse to do one?
Guffaw :) The year 2038 is so far in the future that it is not really
relevant, from that angle.
We need a hard fork to break the 1MB limit, and Satoshi explicitly
presumed that would happen sometime in the future.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 15:01:31

- reply

📅 Original date posted:2013-05-08
📝 Original message:On Wed, May 8, 2013 at 7:39 PM, Addy Yeow <ayeowch at gmail.com> wrote:
> Hi list,
>
> Can someone explain why do we have 32-bit and 64-bit timestamp fields
> instead of all being 64-bit?
>
> https://en.bitcoin.it/wiki/Protocol_specification
Hysterical raisins.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 15:01:18

- reply

📅 Original date posted:2013-05-06
📝 Original message:On Mon, May 6, 2013 at 1:19 PM, Peter Todd <pete at petertodd.org> wrote:
> For phone stuff you should work with The Guardian Project - they've
> implemented Tor on Android among other things and want to find easier
> ways for apps to use it.
You know my feelings about Java ;p but for hidden services, there
really does need to be a lib for server apps.
A proxy server approach is much more fragile, in certain scenarios,
than directly implementing an internal Tor hidden service node, and
handling the TLS connections within your own network framework.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 15:01:16

- reply

📅 Original date posted:2013-05-06
📝 Original message:On Mon, May 6, 2013 at 12:12 PM, Peter Todd <pete at petertodd.org> wrote:
> I've noticed on my Android phone how it often takes quite awhile to find
> a peer that will actually accept an incoming connection, which isn't
> surprising really: why should a regular node care about responding to
> SPV nodes quickly?
>
> For fast startup you would be better served with dedicated nodes that
> are backed by fast hardware and high bandwidth internet connections.
> You can discourage non-SPV use by refusing to relay full blocks.
>
> You can have trusted individuals vouch for these special servers with
> SSL certificates so you run less of a risk of connecting to a malicious
> one trying to limit what information you see. For the initial
> implementation, maybe just make a quick SSL accessible service with HTTP
> GET so you don't have to integrate SSL into the network protocol and
> have a couple of these HTTP GETable servers running. (IE, the trust is
> actually that the SPV seed is honest)
>
> Security will be no worse than before - if any one server/seed is honest
> you're ok - and hopefully better due to the accountability. Obviously
Indeed, the DNS seeds are just servers run by trusted individuals anyway.
In either case, bitcoinj definitely wants fixing for its over-reliance
on DNS seeds. This has been noted as a problem for a while.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 15:01:13

- reply

📅 Original date posted:2013-05-01
📝 Original message:On Wed, May 1, 2013 at 10:05 AM, Andy Parkins <andyparkins at gmail.com> wrote:
> On Tuesday 30 April 2013 21:11:47 Jeff Garzik wrote:
>
>> Hardly. The storage format is bitcoin protocol wire format, plus a
>> tiny header. It is supported in multiple applications already, and is
>> the most efficient storage format for bitcoin protocol blocks.
>
> "Most efficient" for what purpose? There is more that one might do than just
> duplicate bitcoind exactly. I can well imagine storing bitcoin blocks parsed
> and separated out into database fields.
[...]
>> You don't have to create anything on the fly, if you store blocks in
>> their native P2P wire protocol format.
>
> If. What if I'm writing a client and don't want to store them the way
> bitcoind has?
That posits -expanding- blocks from their native form into a larger
form, and then squashing them back down again upon request. A lot of
extra work from the point of view of clients downloading blocks
themselves.
But sure, if you want to do it, yes, it is possible to design an
interface like that.
>> This is a whole new client interface. It's fun to dream this up, but
>> it is far outside the scope of an efficient HTTP protocol that
>> downloads blocks.
>
> Except the alternative is no schema at all -- essentially it's just give
> access to a file on disk. Well, that hardly needs discussion at all, and it
> hardly needs the involvement of bitcoind, apache could do it right now.
Correct, Apache today could easily serve an HTTP-based layout of
blkNNNN.dat, plus a tiny JSON metadata file.
That's not "no schema", just a different layout.
>> Your proposal is closer to a full P2P rewrite over HTTP (or a proxy
>> thereof).
>
> I don't think it's a "rewrite". The wire protocol is only a small part of
> what bitcoind does. Adding another thread listening for HTTP requests at the
> same time as on 8333 for stadnard format.
>
> Anyway -- I've obviously misunderstood what the idea behind a HTTP protocol
> was, and it's not like I was volunteering to do any of the work ;-)
In the context of this thread: distributing and downloading blocks.
All current users require the native binary block format.
A generalized HTTP REST query protocol would be a nice addition... it
is just off-topic for this thread. On IRC yesterday, we discussed an
HTTP query interface like you suggested. It was agreed that it was a
nice interface, and might be a nice addition to bitcoind.
That is a separate topic for a separate email thread, though.
As an example, see the pull request I wrote for an HTTP REST interface
that downloads an encrypted wallet backup:
https://github.com/bitcoin/bitcoin/pull/1982
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 15:01:12

- reply

📅 Original date posted:2013-05-16
📝 Original message:On Thu, May 16, 2013 at 7:26 AM, Ricardo Filipe
<ricardojdfilipe at gmail.com> wrote:
> We would only end up with few copies of the historic data if users
> could choose what parts of the blockchain to store. Simply store
> chunks randomly, according to users available space, and give priority
> to the "N most recent" chunks to have more replicas in the network.
>
> You don't need bittorrent specifically for a DHT, if publicity is a
> problem. There are many DHT proposals and implementations, and i bet
> one of them should be more suitable to the bitcoin network than
> bittorrent's.
That's just about the worst thing you could do for bitcoin. DoS one
part of the DHT, you DoS the entire blockchain by breaking the chain.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 15:01:10

- reply

📅 Original date posted:2013-05-04
📝 Original message:On Sat, May 4, 2013 at 2:07 PM, John Dillon
<john.dillon892 at googlemail.com> wrote:
> After all Peter, just like you have implemented alternate block header
> distribution over twitter, in the future we should have many different means of
> peer discovery. Right now we have DNS seeds, a fixed list, and IRC discovery
> that does not work because the servers it was pointed too no longer exist. Not
> a good place to be.
Let's not confuse bootstrapping with overall peer discovery.
Peer exchange between P2P nodes is the primary and best method of
obtaining free peers.
Obviously you need to bootstrap into that, though. DNS seed and fixed
list are those bootstrap methods (IRC code was deleted), but are only
used to limp along until you can contact a real P2P node, at which
point peer discovery truly begins.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 14:56:17

- reply

📅 Original date posted:2013-05-01
📝 Original message:On Sun, Apr 28, 2013 at 11:51 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> Hello all,
>
> I think it is time to move forward with pruning nodes, i.e. nodes that fully
> validate and relay blocks and transactions, but which do not keep (all)
> historic blocks around, and thus cannot be queried for these.
>
> The biggest roadblock is making sure new and old nodes that start up are
> able to find nodes to synchronize from. To help them find peers, I would
> like to propose adding two extra service bits to the P2P protocol:
> * NODE_VALIDATE: relay and validate blocks and transactions, but is only
> guaranteed to answer getdata requests for (recently) relayed blocks and
> transactions, and mempool transactions.
> * NODE_BLOCKS_2016: can be queried for the last 2016 blocks, but without
> guarantee for relaying/validating new blocks and transactions.
> * NODE_NETWORK (which existed before) will imply NODE_VALIDATE and guarantee
> availability of all historic blocks.
In general, I support this, as anybody on IRC knows.
Though it does seem to open the question about snapshotting.
Personally, it seems important to enable running a fully validating
node, that may bootstrap from a UTXO snapshot + all blocks since that
snapshot.
NODE_BLOCKS_2016, in particular, is too short. For users, I've seen
plenty of use cases in the field where you start a network sync after
a 2-week period.
Set a regular interval for creating a UTXO snapshot, say 3 months
(6*2016 blocks), and serve all blocks after that snapshot. For older
nodes, they would contact an archive node or torrent for >3 month
blocks, and then download normally <= 3 month blocks (if the archive
node didn't serve up to present day).
Where are we on nailing down a stable, hash-able UTXO serialization?
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 11:30:34

- reply

📅 Original date posted:2013-01-27
📝 Original message:On Sun, Jan 27, 2013 at 5:27 AM, Peter Todd <pete at petertodd.org> wrote:
> On Fri, Jan 25, 2013 at 09:23:28PM -0500, Jeff Garzik wrote:
>> On Thu, Jan 24, 2013 at 2:01 AM, Peter Todd <pete at petertodd.org> wrote:
>> > Everything is running on a dedicated Amazon EC2 micro instance. Just
>> > IPv4 is supported right now as EC2 doesn't support IPv6; even tunnels
>> > are broken. I also haven't setup tor yet. I can do both if there is
>> > demand.
>>
>> How long do you plan to run this? Indefinitely [presuming there is
>> interest and users]?
>
> Indefinitely. It's a pretty cheap thing to run, about $7.5/month. If
> anyone else wants I can give them a machine image copy easily too.
Cool. ACK on adding your seed to the ref client.
>> > Also, FWIW, it looks like the pnSeed list is way out of date...
>>
>> Yes. Usually nanotube does the update when poked. That can happen,
>> or something different.
>>
>> A nice alternative might be a simple script that transforms Pieter's
>> seeds.txt into pnSeed[]
>
> seed.txt? You mean the dumpfile produced by bitcoin-seeder? That has
Correct.
> uptime info, although only a months worth if I understand it correctly.
>
> pnSeed probably should be filtered with SORB's dynamic ip list or
> similar too, and additionally add an expiry time. (1 year?)
That's fine. The main point was to create something scripted and
repeatable. Then pnSeed[] becomes easier to maintain _and_ easier to
audit. Right now it is a bit opaque with a list of hex constants. A
script or makefile rule could do
cd src
../contrib/gen-seeds.py > seeds.h
and seeds might look like
#ifndef __SEEDS_AUTOGEN_H__ etc.
unsigned int pnSeed[] = {
0xABCD1234, /* IP addr 12.34.56.78 */
};
I think Satoshi liked them opaque and not easily searchable, so
printing the readable IP address in a comment may not be desired.
Anyway, that output would make updating the list more transparent and
easy to maintain.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 11:30:28

- reply

📅 Original date posted:2013-01-26
📝 Original message:On Thu, Jan 24, 2013 at 2:01 AM, Peter Todd <pete at petertodd.org> wrote:
> Everything is running on a dedicated Amazon EC2 micro instance. Just
> IPv4 is supported right now as EC2 doesn't support IPv6; even tunnels
> are broken. I also haven't setup tor yet. I can do both if there is
> demand.
How long do you plan to run this? Indefinitely [presuming there is
interest and users]?
> I guess the next step is to create a new strTestNetDNSSeed in the
> satoshi client, although it'd be better if at least one more person had
No objection
> a testnet seed to include in the list. Probably best to leave IRC
> enabled too.
Yes, IRC must remain enabled
> Also, FWIW, it looks like the pnSeed list is way out of date...
Yes. Usually nanotube does the update when poked. That can happen,
or something different.
A nice alternative might be a simple script that transforms Pieter's
seeds.txt into pnSeed[]
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 11:30:11

- reply

📅 Original date posted:2013-01-14
📝 Original message:On Mon, Jan 14, 2013 at 5:44 AM, Peter Todd <pete at petertodd.org> wrote:
> Basically on testnet we should give people the chance to test how their
> code handles attempts to spend the genesis block coinbase, as well as
> other tx's made to the genesis block address. After all, potentially
> Satoshi is still out there, still has that key, and still may cause
> exactly that situation himself.
ACK
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 11:29:31

- reply

📅 Original date posted:2013-01-11
📝 Original message:On Thu, Jan 10, 2013 at 10:59 PM, Matt Corallo <bitcoin-list at bluematt.me> wrote:
> Ive been missing lately, when is 0.8 targeted for freeze?
0.8rc1 will probably happen when the core ultraprune/leveldb stuff is stable.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:21:59

- reply

📅 Original date posted:2012-07-09
📝 Original message:On Mon, Jul 9, 2012 at 12:04 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> If you had authored this as a pull request rather than making the
> change unilaterally I would have recommended leaving it so the
> reference client was always first. I also would have suggested that it
> use JS randomization instead of jekyll in order to get more even
> coverage, though I think thats a more minor point.
Agreed, and this would be why I support revert -- pull requests are
for anything non-trivial. This practice of pull requests clearly
should be followed in the case of controversial changes.
> Some people were concerned when this page was created that it would
> just be a source of useless disputes. I think its becoming clear that
> this is the case. I think the cost of dealing with this page is
> starting to exceed the benefit it provides and we should probably
> consider removing it.
Agreed.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:09:49

- reply

📅 Original date posted:2012-05-24
📝 Original message:On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
> Block times are not accurate enough for that.
The times in your log are very accurate, assuming your system clock is
remotely accurate.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:04:36

- reply

📅 Original date posted:2012-04-15
📝 Original message:2012/4/15 Jorge Timón <timon.elviejo at gmail.com>:
> On 4/12/12, Jeff Garzik <jgarzik at exmulti.com> wrote:
>> 1. N = 1 or 2 or whatever the community prefers. Ideally enough time
>> for a third-tier miner, mining strange TXs, finds a block.
>> 2. H1 = height of block chain, when a TX is received
>> 3. H2 = H1 + (144 * N)
>> 4. If block chain height reaches H2, and TX has not made it into a
>> block, drop TX from memory pool
>
> Why not just adding a field expiration_block = H2?
> It seems more explicit and flexible than using a 144 * N constant.
> You're changing the protocol anyway, right?
No, not changing the protocol.
Further, adding a field to TX would imply the client needed to rewrite
the TX for each retransmit, changing the hash. Not good at all.
> Another question, aren't different peers going to get different H1 for
> the same tx?
Typically no, because 99.9% of TX's make it throughout the network in
seconds. But yes it is possible, just like it is possible today to
receive a TX at various times.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:04:26

- reply

📅 Original date posted:2012-04-14
📝 Original message:On Sat, Apr 14, 2012 at 5:27 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote:
>> Some HTTP derivative would probably make life easier for mobile
>> payments and firewalled scenarios, and for client->merchant
>> communications, for instance.
>
> Have you ever read https://gist.github.com/1237788 ?
Looks like you're already headed in the right direction :)
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:04:20

- reply

📅 Original date posted:2012-04-14
📝 Original message:On Sat, Apr 14, 2012 at 11:13 AM, Mike Hearn <mike at plan99.net> wrote:
>> So, to be specific... a A->B chain of transactions, that collectively
>> meet the network's fee requirements?
>
> Yes.
ACK on the concept
>> Ideally the fee, if any, is market based and negotiated. Problem is... like
>> democracy, no matter how ugly it is, people have trouble finding a
>> better system :)
>
> I think this is something we can explore over the coming years. I
> favor having people commonly pass transactions around outside the
> broadcast network with the transactions and their dependencies being
> broadcast only when there's a lack of trust between recipient and
> sender. The block chain is an optional service after all.
Agreed. A TX is just a signed message. No reason why it -must- use
mainnet's distributed notary service.
>> Furthermore, many of these ideas -- like sending TX's directly to the
>> merchant -- involve far more direct payee<->payer communication on the
>> part of the wallet client than is currently envisioned
>
> Yes, though it's worth remembering that the original Bitcoin design
> did have participants communicate directly. When I talked with Satoshi
> in 2009 he saw the pay-to-IP-address mode imagined as the normal way
> to make payments, with pay-to-address being used as a kind of backup
> for when the recipient was offline.
>
> In the end that's not how things evolved, but it the pendulum could
> easily swing back the other way.
IIRC pay-to-IP was removed because it was unreliable -and- detrimental
to privacy? ISTR Satoshi specifically disliking the privacy elements
of p2ip.
But I also have a "gut feeling" that these sorts of payments and
direct communication should be done via a wholly separate protocol
than the bitcoin P2P protocol. Doing p2ip as it was done originally,
inside the bitcoin P2P protocol, was a mistake. Extensible as it is,
I think a better job -- and faster evolution -- can be done with a
separate protocol on a separate port.
Some HTTP derivative would probably make life easier for mobile
payments and firewalled scenarios, and for client->merchant
communications, for instance.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:04:13

- reply

📅 Original date posted:2012-04-13
📝 Original message:On Fri, Apr 13, 2012 at 6:04 AM, Mike Hearn <mike at plan99.net> wrote:
> It sounds OK as long as you exclude nLockTimed transactions.
ACK, agreed
> That said, if you broadcast a transaction that does not meet the fee
> rules, you should be able to notice that it wasn't accepted by your
> peers immediately. Today it's painful because the protocol isn't very
> chatty - in bitcoinj I plan to do this by announcing to half the
> connected peers and waiting to see if the transaction comes back on
> the other half. Getting a response from a peer that the TX was dropped
> for reasons {x,y,z} is a better design but needs another protocol
> change.
>
> So having transactions expire would address the case where somebody
> broadcasts a transaction that successfully propagates across the
> network, but then isn't actually accepted by miners for some reason.
Correct. As mentioned, this change should impact few TXs on the
existing network.
It's mostly about getting everyone to collectively agree that
transactions should expire, if they don't make it into a block.
(excl. nLockTime stuff) A minor technical step, but also a useful
policy step.
> For instance due to a change in the default fee schedules. That risk
> can be mitigated somewhat by being careful about such changes (timed
> phase ins set multiple months out so people have time to upgrade,
> alerts announcing it, etc).
>
> I'm not sure we should be encouraging users to attach fees to
> transactions though. Even if you can replace a transaction after a
> couple of days, the user experience of trying to get the fee "right"
> is atrocious.
Yes -- I think there is near-universal agreement on this user experience point.
> I don't think any sensible merchant will actually be
> willing to put their customers through this nonsense. If somebody
> broadcasts a transaction that successfully propagates across a big
> chunk of the network but then gets stuck due to lacking sufficient
> fees, the best fix is for the merchant to broadcast another
> transaction that spends the first and increases the fees on it that
> way. After this happens a few times, if I was a merchant I'd be
> tempted to just ask buyers to submit the TX to me directly and I'll
> handle keeping up with what miners currently charge and attaching
> fees. I don't want my customers to have to think about this and have
> trades spuriously fail when they forget.
>
> That design requires a minor change to how fees are calculated inside
> the memory pool, to include fees on un-included dependencies. But that
> seems fairly uncontroversial to me. It's best for users, merchants and
> miners to not leave chains of transactions in limbo when together
> their fees add up to the minimum required amount.
So, to be specific... a A->B chain of transactions, that collectively
meet the network's fee requirements? It seems quite reasonable to
accept that, sure. ACK on concept. A chain of length 2 seems like it
would be most common, and limiting total chain length (to 10? 100?)
for any one chain in the memory pool seems prudent.
As to the larger issue of fees... I will readily admit I have no good ideas.
The user's experience is pretty poor: while it might make economic
sense, from the network's standpoint, to charge for the service of
verifying and storing a transaction, the user has limited means to
determine an ideal fee. There are also other valid economic models
(receiver pays fee) out there that may successfully sustain the
network.
Ideally the fee, if any, is market based and negotiated. The current
method is loose-consensus, mainly aimed at (a) combating dust spam or
(b) ensuring it becomes increasingly more expensive to fill a block,
up to the current 1MB maximum. I think almost everyone agrees the
current fee system is an ugly, warty hack. Problem is... like
democracy, no matter how ugly it is, people have trouble finding a
better system :)
Furthermore, many of these ideas -- like sending TX's directly to the
merchant -- involve far more direct payee<->payer communication on the
part of the wallet client than is currently envisioned by the bitcoin
P2P network design, which is broadcast-oriented. So, it remains an
open question whether we want the base bitcoin layer to even worry
about real-time fee negotiation and direct TX transmission.
It is possible that an instant-payments layer evolves on top of the
base bitcoin block chain layer, with bitcoin transactions evolving
largely into settlements between instant-payment intermediaries large
and small.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:04:03

- reply

📅 Original date posted:2012-04-12
📝 Original message:On Thu, Apr 12, 2012 at 3:19 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> My one big concern about this that users find a way to exploit this behavior
> for themselves. If it's too easy for users to create tx they know will get
> stuck and expire, it's no different than letting them cancel their zero-conf
> transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so I send it
> using a combination of inputs and fees that I know will lead to it being
> stuck and expire.
>
> On the other hand, if such conditions are deterministic enough, it could be
> detected by the recipient and flagged.
>
> It's not a huge deal, but it's something to consider.
Do you have a -specific- concern that you feel may be exploited?
Expiration already occurs at random, as nodes shut down and restart,
log on and log off the network.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:03:57

- reply

📅 Original date posted:2012-04-12
📝 Original message:Not sure whether this rises to the level of a BIP or not, as it is
largely an implementation change.
One of my From-Day-One complaints about bitcoin is that transactions
behavior could be far more deterministic (predictable), from a user
standpoint. Transactions in the current system can easily remain in
limbo forever.
One big step in making transactions behave more predictably would be
to remove transactions from the memory pool, if they have not made it
into a block for a couple days. i.e.
1. N = 1 or 2 or whatever the community prefers. Ideally enough time
for a third-tier miner, mining strange TXs, finds a block.
2. H1 = height of block chain, when a TX is received
3. H2 = H1 + (144 * N)
4. If block chain height reaches H2, and TX has not made it into a
block, drop TX from memory pool
Although this only impacts a small amount of TX's ultimately, what it
does do is give us the ability -- once miners have upgraded to this
rule -- to tell bitcoin users that their transactions "expire" after N
days.
Backwards compatibility should not be an issue; clients are free to
retransmit their TX at any time, as usual, thereby "resetting the
clock" for all peers who have forgotten the TX in question.
Once in place, clients may then implement code that notices a TX has
expired (read: likely to have been forgotten by the network, assuming
they themselves have stopped retransmitting it). Then you can start
working on wallet/coin recovery, perhaps resending with a higher fee
etc.
The above change is not really "fill-or-kill" but it should be a big
step, opening the door to deterministic TX behavior.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:03:35

- reply

📅 Original date posted:2012-04-12
📝 Original message:On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt <sirk390 at gmail.com> wrote:
> Hi,
>
> I would like to discuss the following bitcoin protocol improvement proposal:
>
> Adding request/reply id in all messages (in the message header,
> based on what was done for the "checksum" field)
>
> The original reason is that I found it very hard to implement robust
> blockchain downloading as we are missing context information:
> The download protocol relies on the other peer sending one (or more) "inv"
> reponse(s) to "getblocks" and sending the "hashContinue".
> But if the other peer doesn't send a response to getblock, send a partial
> response to getblocks, mixes it with some unrelated blocks inventories
> or doesn't send the "hashContinue" it is very hard to detect and handle
> (e.g. ban the peer and switch to another). This could cause some DoS
> attacks by misbehaving peers.
If the peer is misbehaving, then disconnect. Your protocol change
does not offer any clear benefits in this area, as these sorts of
attacks/misbehaviors/bugs are still just as possible, and just as
damaging (or not).
Just disconnect the strange peer!
> The problems are that 1/ we don't know how many "inv" messages to wait for
> after "getblocks" and 2/ we don't know how to distinguish between result of
> "getblocks" and spontaneous "inv" notifications.
> The same is true for "addr" messages (it is both a notification and reply)
> but this is less of a problem as a lack of response to getaddr
> doesn't constitute a DoS.
>
> The idea would be to add a new "requestid" field in messages and define the
> following:
Stateless protocols have a lot of value. They are easiest to
implement, and easier to prove correct. Existing clients like
ArtForz' half-a-node, variants of which are deployed all over the
place in bitcoin-land, rely on the stateless-ness to one degree or
another.
Stateful protocols, too, have their problems as well. One must add
code to help remain "synchronized" between local and remote states,
which your suggested change only hints at. NFSv4 and RPC have a long
history of dealing with stateful-ness issues. Obviously bitcoin P2P
is nowhere near as complex, but the history of NFS development offers
several lessons applicable to your proposed change.
Overall, IMO your listed reasons for needing this major change
(stateless->stateful) do not really justify the change. Handling
initial block download can be accomplished in a number of ways, and
peer(s) may crash or return odd results. You must handle these cases
properly, regardless of the presence of req/reply id's.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:03:17

- reply

📅 Original date posted:2012-04-11
📝 Original message:On Wed, Apr 11, 2012 at 11:42 AM, Luke-Jr <luke at dashjr.org> wrote:
> On Wednesday, April 11, 2012 11:32:18 AM Mike Hearn wrote:
>> Jeff asked for a BIP for the pong message, so here it is:
>>
>> https://en.bitcoin.it/wiki/BIP_0031
>
> I thought we were going with 60001 for the protocol version bump?
See pull #1081, which makes a few minor revisions along these lines.
Mike's original pull still has my ACK, FWIW, too. Can pull either.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 10:02:15

- reply

📅 Original date posted:2012-04-02
📝 Original message:On Mon, Apr 2, 2012 at 11:23 AM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> Any opinions about a numbering scheme? Currently the value 60000 is used. We could
> simply start increasing the number one by one now for every change, or we could
> do a "cleanup" to 100000 first, and start incrementing from there.
It would be nice to have 100000 as the baseline, "frozen" protocol.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 09:09:51

- reply

📅 Original date posted:2011-06-11
🗒️ Summary of this message: 0.3.23-rc1, a fast bugfix-only release of git HEAD, has been proposed to Gavin and the dev team, with builds ready to upload pending his approval.
📝 Original message:Current git HEAD has been proposed to Gavin & the rest of the dev team
as 0.3.23-rc1.
As soon as Gavin gives his ACK, we have builds ready to upload.
We wanted this to be a fast, bugfix-only release. The main focus was
to deploy a fix for connections taking forever, due to a large portion
of the network not accepting incoming TCP connections.
git shortlog for 0.3.23-rc1 (presuming Gavin's ACK):
Dean Lee (1):
Updated Chinese Simp translation
Doug Huff (3):
Fix rfc1918 and rfc3927 compliance for ignoring non-internet-routable host
Add common temp files to .gitignore.
Demystify a few magic numbers.
Han Lin Yap (2):
Added Swedish translation
Remove unused variable
Jeff Garzik (4):
Bump version to 0.3.23.
Reduce minimum TX fee for new transactions, to 0.0005.
Lower minimum relay TX fee to 0.0001 (from 0.0005) BTC.
Add minimal release process docs.
Matt Corallo (1):
Fix CPU Usage bug when using -nolisten and have no connections.
Nils Schneider (1):
create keypool in LoadWallet()
Pieter Wuille (3):
Update transactions already in the wallet when rescanning.
Fix for small change outputs
Faster timeout when connecting
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 02:55:55

- reply

📅 Original date posted:2012-01-15
📝 Original message:On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> How is this not the most important world issue right now?
>
> EVERYTHING is under threat. Go nuclear to show our nerd-rage.
>
> Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy.
There are always issues that raise ire and moral outrage. I would
rather that bitcoin.org stay apolitical -- our users will appreciate
this in the long run.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 02:18:16

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Gavin Andresen and Jeff Garzik agree that scheduling a blockchain split is not a good idea at the moment. It can be revisited later.
📝 Original message:On Wed, Aug 24, 2011 at 1:57 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> This discussion is convincing me that scheduling a blockchain split is
> definitely the wrong idea at this time. We can revisit in N months,
Strongly agreed...
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:55:36

- reply

📅 Original date posted:2011-06-15
🗒️ Summary of this message: Jeff Garzik proposes mini-proposals for the Satoshi Client to better prepare the Bitcoin protocol for the long term, including avoiding four-component version numbers and splitting protocol and client versions.
📝 Original message:This issue has been simmering for a while...
I agree with the following general principles, and it sounds like
others on the forums do too:
GP1) Alternative implementations of a protocol are beneficial to the ecosystem.
GP2) Tying together protocol and client version is sub-optimal, and
undesirable long term.
The current, coarse-grained scheme was clearly preferred by satoshi.
He knew what a chore creating a fully compliant client would be, and
when I joined (July 2010), was actively discouraging alternative
client efforts. Also, tying protocol and client version together
certainly eased the deployment of changes.
Protocol development has clearly slowed, and we have at least one
major alternative client in the works (bitcoinj), so it seems fair to
revisit those assumptions and preferences.
Here are several mini-proposals for the Satoshi Client (anyone got a
better nickname?) along these lines, which should better prepare the
bitcoin protocol for the long term:
MP1) Avoid creating four-component version numbers (W.X.Y.Z), and use
pszSubVer as a client identification string. This proposal originally
came from Mike Hearn, IIRC.
MP2) remove IP transactions in v0.4
MP3) create constants for protocol version, and audit code to split
client version from protocol version. This is a THORNY patch, and far
more difficult than https://github.com/bitcoin/bitcoin/pull/63
implies. The code has various data structures and such versioned, so
it is difficult to pick out at quick glance which 'version' is which.
MP4) split protocol and client versions in v0.4 -- though you will not
actually notice a change until v0.4.1, when the client version changes
but the protocol version does not.
MP5) Use a single bit inside 'nServices' to indicate the presence of
an optional "capabilities" message. The purpose of this is to enable
minor protocol changes without having to change the protocol version.
Thus, nodes may advertise /features/ rather than simply "I support all
features >= version X". Most mature protocols support this sort of
thing, rather than the simpler, coarse-grained version number system.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:36:20

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: Using BitTorrent trackers, even HTTP-based ones, could help scale Bitcoin and make it harder for attackers to compromise clients. However, discovering HTTP trackers presents challenges.
📝 Original message:On Mon, Jun 13, 2011 at 5:38 AM, Christian Decker
<decker.christian at gmail.com> wrote:
> BitTorrent trackers are used to handle several thousands of requests, so
> they would probably scale well enough. I'm not even talking about using the
> DHT trackers, but using old fashioned HTTP based trackers. The fact that
> each bitcoin client would contact the tracker would make it very hard for an
> attacker to get bootstrapping clients to exclusively connect to his
> compromised clients. I would say that using a tracker such as OpenBittorrent
> provides the same advantages as using an IRC channel.
And how does the client discover HTTP trackers? You're either
hardcoding -those- into the client, or adding an additional bootstrap
step to discover them. Either way, it has the same problems as other
current methods.
The history and experience of gnutella's web caches vs. UDP host
caches seems highly relevant here.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:36:13

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: A proposal to adopt BitTorrent tracker bootstrapping for Bitcoin nodes was discussed, but concerns were raised about potential vulnerabilities and Sybil attacks on DHTs.
📝 Original message:On Mon, Jun 13, 2011 at 4:55 AM, Christian Decker
<decker.christian at gmail.com> wrote:
> We have quite a few bootstrapping mechanisms, starting with the overly
> complex (IMHO) IRC bootstrapping, which is often suspected as bot-activity.
> Then we have a few hardcoded nodes and some fallback nodes. I was wondering
> why we didn't adopt BitTorrent tracker bootstrapping until now? It's
> basically all it does. Given a hash (SHA1 hash of the genesis bloc would be
> nice ^^) it gives you a list of other nodes with the same hash.
It seems to offer few benefits over DNS seeding, while potentially
potentially creating a vulnerable hot spot in the DHT. Sybil attacks
on DHTs are well documented.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:22:15

- reply

📅 Original date posted:2011-06-18
🗒️ Summary of this message: Sipa's wallet code movement and class stuff require a rebase for wallet import/export and crypto. Other code also needs merging.
📝 Original message:OK, sipa pulled his wallet code movement + wallet class stuff.
Wallet import/export and crypto will need a rebase. Other code will
too, but those are the big ticket items that we want to merge in the
short term.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:21:55

- reply

📅 Original date posted:2011-06-17
🗒️ Summary of this message: Jeff Garzik suggests calling the github/bitcoin/bitcoin.git the Satoshi Client, regardless of whether it has a GUI or not.
📝 Original message:On Fri, Jun 17, 2011 at 4:37 PM, Luke-Jr <luke at dashjr.org> wrote:
> So long as we can get a solid name for it. Obviously I can't continue to call
> it wxBitcoin if it's strictly Qt...
I've started calling the github/bitcoin/bitcoin.git the Satoshi
Client, GUI or not.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:21:14

- reply

📅 Original date posted:2011-06-16
🗒️ Summary of this message: Scaling-up issues, wallet security, and unit testing framework are critical needs for Bitcoin. Testing in the field is more effective than unit testing.
📝 Original message:On Thu, Jun 16, 2011 at 12:32 PM, Gavin Andresen
<gavinandresen at gmail.com> wrote:
> 1) Scaling-up issues, like disconnections when downloading the block chain.
>
> 2) Wallet security.
Agreed, though security professionals (and luke-jr) are already
pointing out the wallet crypto mainly eliminates a bit of bad PR,
rather than being a major crime deterrent.
zooko on IRC had a pretty good suggestion: introduce a built-in
facility for air-gapped wallets (multiple wallets), so that loss of
your everyday transactional wallet does not mean loss of everything.
You can do this manually, but we need something for all the people who
(a) don't know crypto, and (b) simply download and run the client
without thinking much about security.
> 3) Unit testing framework. There was a PULL that had the start of
> boost unit tests; I think that is a critical need, along with a good
> suite of test cases.
Three points, on testing:
T1) autotools has a minimal testing framework built into it. "make
check" builds, and then runs tests. Each test is a program or script,
that returns 0 on success and 1 on failure. "make distcheck" builds,
runs tests, and then creates the distribution tarball if the tests
succeed.
T2) I wouldn't narrow the focus to "unit tests", as stress tests and
other comprehensive, automated tests are quite useful as well
but most importantly...
T3) Don't hold v0.4 release for this. As we say in kernel-land, we
have a test lab called "the internet" Test suites have clear software
engineering value, but they largely "guard the past" -- making sure
you don't repeat past mistakes, rather than being a good indicator of
possible upcoming problems. The best testing is always in the field.
That always finds more problems than unit testing ever does.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:20:18

- reply

2023-06-07 01:20:08

- reply

📅 Original date posted:2011-06-14
🗒️ Summary of this message: The scalability limitation of flood control in Bitcoin's P2P code is causing issues with large block sizes. Solutions include raising the limit or lowering the batch size.
📝 Original message:On Tue, Jun 14, 2011 at 12:44 PM, Mike Hearn <mike at plan99.net> wrote:
> Block sizes have started to get quite large once again. Whilst testing
> chain download today I was disconnected due to going over the 10mb
> flood control limit. Infuriatingly, I can't reproduce this reliably.
> But at 500 blocks an average of 20kb per block will cause this. As we
> can see from the block explorer, the average is probably quite close
> to that.
>
> The flood control seems like a pretty serious scalability limitation.
> I can see a few solutions. One is to raise the limit again. Another is
> to raise the limit and simultaneously lower the batch size. 500 blocks
> in one message means very large messages no matter how big the flood
> control limit is. Going down to 100 or even 50 would hurt chain
> download speed quite a bit in high latency environments, but chain
> download is already a serious bottleneck.
The main goal was not flood control but preventing an internal buffer
memory explosion. We already have the block chain on disk, so in
theory, if we can -eliminate- the outgoing network buffer and simply
use a pointer into the block chain file, we can send as much data as
we want.
HTTP servers certainly don't buffer huge amounts in memory; they would
keel over if so. HTTP servers have been working on the reverse, in
fact: moving the data-pushing over to sendfile(2) syscall and similar
optimizations.
This is an unfortunate relic of how bitcoin P2P code is written. If
the remote side has reduced their TCP window to zero, bitcoin will
still buffer so that it may continue processing other P2P traffic from
other nodes. That makes sense in the case of tiny, 31-byte address
messages -- one must handle the case of a half-sent message before
write(2) refuses additional data -- but not huge block chain download
messages.
The P2P code just wasn't written for huge amounts of streaming data,
and needs some serious thinking... I agree 100% that it is an issue
we will start bumping into, if we haven't already.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:53

- reply

📅 Original date posted:2011-06-15
🗒️ Summary of this message: Allowing wallet.dat location in preferences is suggested for easy physical disconnection. However, all databases must be in datadir, making it difficult to move one file.
📝 Original message:On Wed, Jun 15, 2011 at 10:27 AM, Mark Visser <mjmvisser at gmail.com> wrote:
> I humbly suggest allowing the wallet.dat location to be specified in the preferences. Being able to easily physically disconnect a wallet by unplugging a USB key seems like a good idea.
That's what -datadir is for. Unfortunately -all- databases must be in
the datadir, because wallet.dat is a berkeley db, and we need a
transactional environment. That makes it difficult to move just one
file.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:47

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: Jeff Garzik suggests prioritizing wallet crypto in the next version due to increased reports of stolen wallets. Pull requests are welcome.
📝 Original message:With increased reports of stolen wallets, I humbly submit that wallet
crypto should be a top priority for the next version.
https://github.com/bitcoin/bitcoin/pull/232
Anyway... start pulling :)
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:41

- reply

📅 Original date posted:2011-06-16
🗒️ Summary of this message: Bitcoin 0.3.23 minor updates include a regenerated Linux tarball, added Win32 .zip archive, and PGP-signed SHA1SUM.asc added to SF.
📝 Original message:Some minor updates to the released files:
1. Linux tarball regenerated with properly named directory inside.
2. Win32 .zip archive added.
3. PGP-signed SHA1SUM.asc added to SF
The following are the updated checksums:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
d7a34e1151dedfba5af1bf7496ed041f5b4955e5 bitcoin-0.3.23-linux.tar.gz
42e8a86a97edcafb12d09fa69b56ad0451baa140 bitcoin-0.3.23-macosx.zip
779c6bb227801a51084be9594dc185d0a054ed53 bitcoin-0.3.23-src.tar.gz
12952b1c4a15ce55564500dace18ee22eb2feaa8 bitcoin-0.3.23-win32-setup.exe
89194d3b3ee87f450f520cf365b863e0fab8bc9f bitcoin-0.3.23-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUBTfp5k9odwg8tvwyoAQIJ9Q/9GHiSA8oEuQM29qu1laCD45AY9lnsJeNN
ZNRiAE92WJ7SiSKxW6V1M1phMk4IMG/0MmR8L/PRqJfWDg+6FQzAzpZLobH0Hnfl
MujhKIhRcP1zs7m/t/zwjQxRXT+N6UotfdwvO+GLbBnUSVZC2zr/9XdSs65gLIhq
lMkJUwYLEBvuXvo98Sbp5MeXHdfWUqAQufuYnMvRsCT9BcX5cP8cmaxvICLANRbc
89kU+7JQ7fauiHTnYJ0GkK/xIyCnlwfGsEe8GQsIgWF0RBpayszCxSOsuzFYMsED
7cIjN9AscDiJ3UmhXSg6xbRi4LZGXm195TmMdxJdRNHWqjfpFkxEXoW7iuUvxVDU
tiMMA+yXMTUSdbn2IxdZFLqKpgXcpf05T91g9w/ll1VMxkmOOcTSZc5dCbMMUn0z
kA12PagjDlH+xz3Qab9GNV13XlHKbG0VT8AsE1No+HJCV8qugMdI6hgZqMDucbmQ
U2KiG0EpwNx2G31l2K99yIxuumE7nDslhkfzSosVXhgHwqzr4ukl5ykFwfZnJjHF
BJ0zrcWCViGes+3awHwASQvlIGcvXprEzC0ZKEsbalZkAoCYYiGoZbNHtEMq3lZq
d0siUzwEPA31xfS/dACbX8ml8jC0jBmEy296WZ2LX7pZOcqa2ayMbGE81tg+5Nvy
UYihPYX4FS0=
=9NXu
-----END PGP SIGNATURE-----
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:38

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: Bitcoin v0.3.23 has been released with a reduced transaction fee and improved P2P connect-to-node logic to deal with new users.
📝 Original message:Win32, Linux and source releases (MacOSX soon) for bitcoin v0.3.23
have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/
This is another quick bugfix release, trying to deal with the influx
of new bitcoin users.
Priority for next version: wallet encryption
Main items of note:
* P2P connect-to-node logic changed to reduce timeout a bit. The
network saw a huge influx of new users, who do not permit incoming
connections. This change is a short-term hack, to more quickly hunt
for useful P2P connections. Better "leaf node" logic is in the works,
but this should let us limp along until then.
* Transaction fee reduced to 0.0005 for new transactions (see note below)
* Client will relay transactions with fees as low as 0.0001 BTC
(see note below)
NOTE: There has been some fee confusion recently. Free transactions
are supported and relayed as they always have been, according to
special anti-spam rules. See
https://en.bitcoin.it/wiki/Transaction_fees for details.
Full git changelog:
Dean Lee (1):
Updated Chinese Simp translation
Doug Huff (3):
Fix rfc1918 and rfc3927 compliance for ignoring non-internet-routable host
Add common temp files to .gitignore.
Demystify a few magic numbers.
Han Lin Yap (2):
Added Swedish translation
Remove unused variable
Jeff Garzik (4):
Bump version to 0.3.23.
Reduce minimum TX fee for new transactions, to 0.0005.
Lower minimum relay TX fee to 0.0001 (from 0.0005) BTC.
Add minimal release process docs.
Matt Corallo (1):
Fix CPU Usage bug when using -nolisten and have no connections.
Nils Schneider (1):
create keypool in LoadWallet()
Pieter Wuille (3):
Update transactions already in the wallet when rescanning.
Fix for small change outputs
Faster timeout when connecting
There were no changes between -rc1 and -final. Wanted to get this out
ASAP, and move on to wallet crypto.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:33

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: Version 0.3.23 is ready for release as testing has been unremarkable. Jeff Garzik approves the final release.
📝 Original message:(cc'd the devs that I'm not sure are on the dev mailing list yet)
Version 0.3.23 doesn't seem to have major issues, and testing has been
unremarkable. I think we can go ahead and push it out.
ACK for final release of 0.3.23?
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:27

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: Jeff Garzik suggests improving DNS bootstrapping for Bitcoin by creating an RPC that returns a random selection of fresh P2P node addresses. He plans to add this code to Bitcoin in a contrib/dns folder.
📝 Original message:On Mon, Jun 13, 2011 at 2:41 PM, Gavin <gavinandresen at gmail.com> wrote:
>> The most practical way I see how to improve DNS bootstrapping is
>> publishing build instructions for a simple DNS server build and a
>> script which feeds it with node data. Something simple like djbdns plus
>> a perl script, or similar zerigo API script, would do. Than anyone can
>> host it. All left to do than is to hardcode a bunch of such DNS seeds
>> into the client.
>
> Adding that code to bitcoin in a contrib/dns folder seems like a good idea.
Agreed. I'll see if I can put together a couple different solutions,
and stick them in there. ETA 3-4 weeks though, given current bugfix
workload + personal issues (moving to a new house).
I had a thought related to this, but readily admit I haven't thought
this through: create an RPC in bitcoin that returns a random
selection of fresh P2P node addresses, from addr.dat. One problem I
was running into was accessing this data from outside bitcoin.
Using ArtForz' half-a-node as a base was a possibility, but creating
"getnodes" RPC seemed far easier.
djbdns (tinydns) is great for this: it is highly scalable and stable,
and its input is a -very- simple text format, easier to generate than
BIND zone files.
> I'd be happy to run a dns seed.
Great! A big missing piece is simply trusted people running DNS seeds
on stable connectivity, once the DNS software is there.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:18

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: A proposal was made to use HTTP requests to a tracker instead of IRC and DNS Seeds for Bitcoin network, but it was argued that DNS Seeds are still more efficient.
📝 Original message:On Mon, Jun 13, 2011 at 7:48 AM, Christian Decker
<decker.christian at gmail.com> wrote:
> The advantages over IRC and DNS Seeds are:
> - sporadic HTTP requests to a tracker, as opposed to keeping an IRC
> connection open at all times
No advantage over DNS (you're talking about IRC)
> - no virus/botnet like behaviour (automatically join IRC channel with
> cryptic name), ISPs tend to bother network admins (like myself) with alerts
> when they see this...
No advantage over DNS (you're talking about IRC)
> - adapts faster than DNS Seeds which require configuration changes on seed
> should the nodes become unreachable
False. A proper DNS seed actively samples the bitcoin network for live nodes.
> - we already use HTTP to determine our external IP, so it would be a
> consolidation of transports
Irrelevant -- it's still a bunch of additional code. We "already use"
DNS lookups as well, so I could apply similar logic to DNS seeding.
> - more peers than DNS Seeds (better load balancing)
This is an invalid assumption, based on an overly simplistic sampling.
DNS seeds are perfectly capable of returning new and useful peers on
each query.
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:19:08

- reply

2023-06-07 01:19:02

- reply

2023-06-07 01:18:53

- reply

📅 Original date posted:2011-06-12
🗒️ Summary of this message: Bitcoin v0.3.23rc1 has been released with reduced transaction fees and faster P2P connect-to-node logic to handle new users.
📝 Original message:Win32, Linux and source releases for bitcoin v0.3.23rc1 have been uploaded to
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/test/
This is another quick bugfix release, trying to deal with the influx
of new bitcoin users.
Main items of note:
* P2P connect-to-node logic changed to reduce timeout a bit. The
network saw a huge influx of new users, who do not permit incoming
connections. This change is a short-term hack, to more quickly hunt
for useful P2P connections. Better "leaf node" logic is in the works,
but this should let us limp along until then.
* Transaction fee reduced to 0.0005 for new transactions (NOTE: free
transactions are, of course, still supported as they always were)
* Client will relay transactions with fees as low as 0.0001 BTC
Full git changelog:
Dean Lee (1):
Updated Chinese Simp translation
Doug Huff (3):
Fix rfc1918 and rfc3927 compliance for ignoring non-internet-routable host
Add common temp files to .gitignore.
Demystify a few magic numbers.
Han Lin Yap (2):
Added Swedish translation
Remove unused variable
Jeff Garzik (4):
Bump version to 0.3.23.
Reduce minimum TX fee for new transactions, to 0.0005.
Lower minimum relay TX fee to 0.0001 (from 0.0005) BTC.
Add minimal release process docs.
Matt Corallo (1):
Fix CPU Usage bug when using -nolisten and have no connections.
Nils Schneider (1):
create keypool in LoadWallet()
Pieter Wuille (3):
Update transactions already in the wallet when rescanning.
Fix for small change outputs
Faster timeout when connecting
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com

2023-06-07 01:18:48

- reply