Gavin [ARCHIVE]

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

Public Key

npub1fvd9jpjgn33ry4tt663e3fpsw5zysxzuacumergtweqhsa6ac9gqred8pr

Profile Code

nprofile1qqsykxjeqeyfcc3j244adguc5sc82pzgrpwwuwdu359hvstcwawuz5qcc3nrl

Author Public Key

npub1fvd9jpjgn33ry4tt663e3fpsw5zysxzuacumergtweqhsa6ac9gqred8pr

Show more details

Last Notes

2023-06-07 17:48:33

- reply

📅 Original date posted:2016-02-07
📝 Original message:> On Feb 7, 2016, at 2:27 PM, <jl2012 at xbt.hk> <jl2012 at xbt.hk> wrote:
>
> Normal version number only suggests softforks, which is usually not a concern for SPV clients.
Soft forks affect the security of low-confirmation (zero or one) transactions sent to SPV wallets even more than hard forks, and because many users and businesses choose convenience over airtight security I would argue transaction validation rule changes are a VERY big concern for lightweight clients.

2023-06-07 17:48:04

- reply

📅 Original date posted:2016-01-23
📝 Original message:> On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I would extend this to say that the technical explanation also should
> contribute uniquely to the conversation; a +1 with an explanation
> the last +1 gave isn't useful.
Yes, comments should contribute to the discussion, with either technical discussion or additional relevant data. I think a +1 like the following should be encouraged:
"+1: we had eleven customer support tickets in just the last week that would have been prevented if XYZ.
Jane Doe, CTO CoinBitChainBasely.com"

2023-06-07 17:41:09

- reply

📅 Original date posted:2015-09-23
📝 Original message:> On Sep 23, 2015, at 12:28 PM, Peter R <peter_r at gmx.com> wrote:
>
> Hi Gavin,
>
> One thing that's not clear to me is whether it is even necessary--from the perspective of the block size limit--to consider block propagation.
I didn't mention the block size limit; weak blocks are a good idea no matter the limit.
As for miners paying for the work: lots of companies contributed to the Foundation, and will contribute to the DCI. When there are big, stable, profitable companies I think we'll see them task their developers to contribute code.
I think optimizing new block propagation is interesting and important, so I plan on working on it.

2023-06-07 17:37:51

- reply

📅 Original date posted:2015-08-28
📝 Original message:With this proposal, how much would it cost a miner to include an 'extra' 500-byte transaction if the average block size is 900K and it costs the miner 20BTC in electricity/capital/etc to mine a block?
If my understanding of the proposal is correct, it is:
500/900000 * 20 = 0.11111 BTC
... Or $2.50 at today's exchange rate.
That seems excessive.
--
Gavin Andresen
> On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> This is the best proposal I've seen yet. Allow me to summarize:
>
> • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their block-size votes.
> • It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to predict future market needs versus future technological capacities.
> • It avoids a large step discontinuity in the block-size limit by starting with a 1-MB limit.
> • It throttles changes to ±10% every 2016 blocks.
> • It imposes a tangible cost (higher difficulty) on miners who vote to raise the block-size limit.
> • It avoids incentivizing miners to vote to lower the block-size limit.
>
> However, this proposal currently fails to answer a very important question:
>
> • What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
>
>
> https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>
>
>> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
>> Pull request: https://github.com/bitcoin/bips/pull/187
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:49:15

- reply

2023-06-07 15:43:47

- reply

📅 Original date posted:2015-07-30
📝 Original message:> On Jul 30, 2015, at 4:21 AM, Eric Lombrozo wrote:
>
> and a number of the people most intimately familiar with the inner workings of the system (some of whom are in this thread) think that given what we now today about the Bitcoin network, increasing block size externalizes costs in dangerous ways. Remember that total cost includes not just equipment costs but also things like block propagation latency and specifically identified security risks. Some of these security risks were only appreciated relatively recently and were completely unknown in 2009.
I would like (and have been asking) those people to take the time to quantify those costs and write up those risks in a careful way.
I believe the costs and risks of 8MB blocks are minimal, and that the benefits of supporting more transaction FAR outweigh those costs and risks, but it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.

2023-06-07 15:36:36

- reply

📅 Original date posted:2015-06-04
📝 Original message:Completely off-topic for this mailing list, which is about coding/technology not people.
Stop or I will excercise my moderator superpowers and remove you from this list.
--
Gavin Andresen
> On Jun 4, 2015, at 5:52 PM, Sven Berg <svenberg at airmail.cc> wrote:
>
> 1) Hours/week have .....

2023-06-07 15:34:53

- reply

📅 Original date posted:2015-05-13
📝 Original message:Checkpoints will be replaced by compiled-in 'at THIS timestamp the main chain had THIS much proof of work.'
That is enough information to prevent attacks and still allow optimizations like skipping signature checking for ancient transactions.
I don't think anybody is proposing replacing checkpoints with nothing.
--
Gavin Andresen
> On May 13, 2015, at 8:26 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>
> Let's consider a concrete example:
>
> 1. User wants to accept Bitcoin payments, as his customers want this.
> 2. He downloads a recent version of Bitcoin Core, checks hashes and so on. (Maybe even builds from source.)
> 3. Let's it to sync for several hours or days.
> 4. After wallet is synced, he gives his address to customer.
> 5. Customer pays.
> 6. User waits 10 confirmations and ships the goods. (Suppose it's something very expensive.)
> 7. Some time later, user wants to convert some of his bitcoins to dollars. He sends his bitcoins to an exchange but they never arrive.
>
> He tries to investigate, and after some time discovers that his router (or his ISP's router) was hijacked. His Bitcoin node couldn't connect to any of the legitimate nodes, and thus got a complete fake chain from the attacker.
> Bitcoins he received were totally fake.
>
> Bitcoin Core did a shitty job and confirmed some fake transactions.
> User doesn't care that if his network was not impaired, Bitcoin Core would have worked properly.
> The main duty of Bitcoin Core is to check whether transactions are confirmed, and if it can be fooled by a simple router hack, then it does its job poorly.
>
> If you don't see it being a problem, you should't be allowed to develop anything security-related.
>
>> If a node is connected to 99 dishonest nodes and 1 honest node, it can still sync with the main network.
>
> Yes, it is good against Sybil attack, but not good against a network-level attack.
> Attack on user's routers is a very realistic, plausible attack.
> Imagine if SSL could be hacked by hacking a router, would people still use it?
>
> Fucking no.
>
>> A 3 month reversal would be devastating, so the checkpoint isn't adding much extra security.
>
> WIthout checkpoints an attacker could prepare a fork for $10.
> With checkpoints, it would cost him at least $1000, but more likely upwards of $100000.
> That's quite a difference, no?
>
> I do not care what do you think about the reasons why checkpoints were added, but it is a fact that they make the attack scenario I describe above hard to impossible.
>
> Without checkpoints, you could perform this attack using a laptop.
> With checkpoints, you need access to significant amounts of mining ASICs.
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/43b037e0/attachment.html>

2023-06-07 15:20:31

- reply

📅 Original date posted:2014-04-29
📝 Original message:Consensus is the spec should be clarified to match current behavior, so it won't change.
--
Gavin Andresen
> On Apr 29, 2014, at 9:44 AM, Jouke Hofman <jouke at bitonic.nl> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We have BIP70 already in use (over a hundred paid requests).
>
> Could you elaborate on why this needs changing?
>
>
>
>> On 28-04-14 14:39, Gavin Andresen wrote:
>> There is a discussion about clarifying how BIP70 signs payment
>> requests here: https://github.com/bitcoin/bips/pull/41
>>
>> The issue is what to do with the signature field before signing.
>> The code Mike and I initially wrote does this:
>>
>> request.set_signature(string(""));
>>
>> (sets signature to the empty string)
>>
>> I think that is a mistake; it should be:
>>
>> request.clear_signature();
>>
>> (clears signature field, so it is not serialized at all).
>>
>> So: if you are implementing, or have implemented, the payment
>> protocol, please chime in. I'd like to change the spec and the
>> reference implementation NOW, while BIP70 is still a 'Draft'.
>>
>> Because this type of "hey, I'm implementing your standard and it
>> doesn't work the way I think it should" mistake is exactly why BIPs
>> take a while before being declared 'Final.'
>>
>>
>>
>>
>> ---------------------------------------

2023-06-07 15:12:33

- reply

📅 Original date posted:2014-01-27
📝 Original message:Message encoding and length (or terminator or checksum or error correction or...) should be part of the transport protocol, in my humble opinion.
--
Gavin Andresen
> On Jan 26, 2014, at 6:01 PM, Mike Hearn <mike at plan99.net> wrote:
>
> To be more accurate, the embedded messages already have length prefixes :-)
>
>
>> On Sun, Jan 26, 2014 at 11:14 PM, Andreas Schildbach <andreas at schildbach.de> wrote:
>> Just keep in mind that if it turns out we need to retrofit messages with
>> length prefixes I fear we will have to restart with new mime-types. The
>> nature of prefixes being always at the start means this rules out simply
>> incrementing a protocol version number.
>>
>> Correcting myself:
>>
>> > it might be a good idea to apply this to all messages if any.
>>
>> Of course I only mean the "root" messages, namely PaymentRequest,
>> Payment, and PaymentACK. The embedded messages don't need length prefixes.
>>
>>
>> On 01/26/2014 11:00 PM, Mike Hearn wrote:
>> > I think for "binding" the payment protocol to those transports we should
>> > indeed use protobuf varint length prefixes. But it's unnecessary for all
>> > cases. Unless Gavin feels it'd be better to be consistent everywhere and
>> > is willing to change the spec and code - as far as I know though we're
>> > trying to ship 0.9rc1 soonish .....
>> >
>> >
>> > On Sun, Jan 26, 2014 at 10:32 PM, Andreas Schildbach
>> > <andreas at schildbach.de <mailto:andreas at schildbach.de>> wrote:
>> >
>> > Bluetooth, Wifi Direct, HTTP request/responses via broken proxies, smoke
>> > signals... basically anything that is a stream rather than a file.
>> >
>> > Right, NFC NDEF and QR codes are not affected, so we can skip the
>> > delimiter for these mediums.
>> >
>> >
>> > On 01/26/2014 10:24 PM, Mike Hearn wrote:
>> > > Which medium is this an issue for? As you note, for files and HTTP
>> > > responses it's not a problem in practice. i'd guess nor for NFC
>> > tags nor
>> > > QR codes.
>> > >
>> > >
>> > > On Sun, Jan 26, 2014 at 10:11 PM, Andreas Schildbach
>> > > <andreas at schildbach.de <mailto:andreas at schildbach.de>
>> > <mailto:andreas at schildbach.de <mailto:andreas at schildbach.de>>> wrote:
>> > >
>> > > I'm experimenting with BIP70/71 (payment protocol) usage in
>> > face to face
>> > > payments (more on that soon).
>> > >
>> > > I've excountered an issue with the protobuf format. Protobufs
>> > are not
>> > > self-delimiting. That means if you're reading from an undelimited
>> > > stream, you will read endlessly because you don't know how
>> > much to read.
>> > >
>> > > The current BIP70 implementations probably work because
>> > they're reading
>> > > either from a file or from an HTTP resource which sets the
>> > > Content-Length header. Trouble is the Content-Length header is
>> > optional,
>> > > and also there are many kinds of streams that don't have this
>> > built-in
>> > > delimiting mechanism.
>> > >
>> > > The Java protobuf API solves this by offering delimited I/O, like
>> > >
>> > > payment.writeDelimitedTo(os);
>> > >
>> > > This writes the size of the message as a varint before writing
>> > the data.
>> > > I don't know about protobuf implementations for other
>> > languages but I'd
>> > > expect them to offer something compatible.
>> > >
>> > > However, this leading varint is an incompatible change and
>> > would need to
>> > > be added to the spec.
>> > >
>> > > I specifically encountered this with PaymentMessage and
>> > PaymentACK, but
>> > > it might be a good idea to apply this to all messages if any.
>> > Open for
>> > > discussion.
>> > >
>> > >
>> > >
>> > ------------------------------------------------------------------------------
>> > > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> > > Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> > > Critical Workloads, Development Environments & Everything In
>> > Between.
>> > > Get a Quote or Start a Free Trial Today.
>> > >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> > > _______________________________________________
>> > > Bitcoin-development mailing list
>> > > Bitcoin-development at lists.sourceforge.net
>> > <mailto:Bitcoin-development at lists.sourceforge.net>
>> > > <mailto:Bitcoin-development at lists.sourceforge.net
>> > <mailto:Bitcoin-development at lists.sourceforge.net>>
>> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> > >
>> > >
>> > >
>> > >
>> > >
>> > ------------------------------------------------------------------------------
>> > > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> > > Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> > > Critical Workloads, Development Environments & Everything In Between.
>> > > Get a Quote or Start a Free Trial Today.
>> > >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > Bitcoin-development mailing list
>> > > Bitcoin-development at lists.sourceforge.net
>> > <mailto:Bitcoin-development at lists.sourceforge.net>
>> > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> > >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> > Critical Workloads, Development Environments & Everything In Between.
>> > Get a Quote or Start a Free Trial Today.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > <mailto:Bitcoin-development at lists.sourceforge.net>
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> > Critical Workloads, Development Environments & Everything In Between.
>> > Get a Quote or Start a Free Trial Today.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> >
>> >
>> >
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140126/5708a30b/attachment.html>

2023-06-07 15:08:08

- reply

📅 Original date posted:2013-10-25
📝 Original message:On Oct 26, 2013, at 11:01 AM, Jean-Paul Kogelman <jeanpaulkogelman at me.com> wrote:
>
> Would it make sense to use either fixed length strings or maybe even enums?
No. Enums or fixed length strings just make it harder to extend, for no benefit (bandwidth of 'reject' messages doesn't matter, they will be rare and are not relayed).

2023-06-07 15:01:55

- reply

📅 Original date posted:2013-05-15
📝 Original message:Busy with pre-conference stuff, not following details of this conversation...
... but it sounds a lot like the "guy fawkes" protocol Zooko was thinking about a year or so ago.

2023-06-07 10:40:00

- reply

📅 Original date posted:2012-11-26
📝 Original message:Supporting DNSSEC/DANE in the future when they are widely deployed is a great idea.
Note that the x509chain field is 'repeated', and any repeated field may have zero entries. So I would suggest supporting other PKI systems in the future by adding optional new fields (for maximum compatibility or security merchants might want to include both a x509chain AND
--
Gavin Andresen

2023-06-07 10:27:38

- reply

📅 Original date posted:2012-08-02
📝 Original message:I have no objections to a rc1 happening before I'm back.
--
Gavin Andresen
On Aug 2, 2012, at 10:45 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
> On Thu, Aug 2, 2012 at 12:43 PM, Jeff Garzik <jgarzik at exmulti.com> wrote:
>> There seems to be consensus that we should go ahead and do a release,
>> before leveldb or ultraprune or anything major lands. There is no
>> major landmark feature, but just a useful collection of small changes.
>> It seems like a good time to Release Early, Release Often and make a
>> checkpoint release.
>
> Procedural note: since Gavin is on vacation, this release obviously
> won't occur for at least a couple weeks.
>
> If Gavin appears on email or IRC, though, I might try to pounce on him
> and convince him to let us go ahead with 0.7-rc1, if the other devs
> are happy.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik at exmulti.com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 02:36:43

- reply

📅 Original date posted:2011-10-31
🗒️ Summary of this message: Verification of gitian builds and patch pulling may be delayed due to power outage, with assistance expected to resume in a day or two.
📝 Original message:We've got no power, so it might be a day or two before I can help verify gitian builds or pull patches.
Sent from my iPhone

2023-06-07 01:54:42

- reply

📅 Original date posted:2011-06-13
🗒️ Summary of this message: Proposal to improve DNS bootstrapping for Bitcoin by publishing build instructions for a simple DNS server and a script to feed it with node data. Suggests adding code to Bitcoin in a contrib/dns folder.
📝 Original message:> 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. I'd be happy to run a dns seed.

- reply

- reply

- reply

- reply

{"author":"Gavin","date":"2011-06-13T18:41:35","text":"> The most practical way I see how to improve DNS bootstrapping is\n> publishing build instructions for a simple DNS server build and a\n> script which feeds it with node data. Something simple like djbdns plus\n> a perl script, or similar zerigo API script, would do. Than anyone can\n> host it. All left to do than is to hardcode a bunch of such DNS seeds\n> into the client.\n\nAdding that code to bitcoin in a contrib/dns folder seems like a good idea. I'd be happy to run a dns seed.","summary":"📝 Summary of this message: \nProposal to improve DNS bootstrapping for Bitcoin by publishing build instructions for a simple DNS server and a script to feed it with node data. Suggests adding code to Bitcoin in a contrib/dns folder."}