Gavin Andresen [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-16 to 2017-01-26
💬 Posted a total of 404 messages
📚 Participated in the following categories: Bitcoin-development, PULL, RFC, BIP 15, BIP proposal, BIP draft, softfork proposal, BIP, Bulk, bitcoin-dev, BIP Proposal, BIP Draft
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw

Profile Code

nprofile1qqsg2le00rwpvw08z8675up6nlyh3c3wh5ne4002rpsm0k4gxdgjaeqprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyghwumn8ghj7mn0wd68yv339e3k7mguceg7d

Publishing to

relay.noswhere.com

nostr21.com

relay.nostr.band

Author Public Key

npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw

Show more details

Last Notes

2023-06-07 17:48:39

- reply

📅 Original date posted:2016-02-06
📝 Original message:On Sat, Feb 6, 2016 at 12:01 PM, Adam Back <adam at cypherspace.org> wrote:
>
> It would probably be a good idea to have a security considerations
> section
Containing what? I'm not aware of any security considerations that are any
different from any other consensus rules change.
(I can write a blog post summarizing our slack discussion of SPV security
immediately after the first greater-than-1mb-block if you like).
> , also, is there a list of which exchange, library, wallet,
> pool, stats server, hardware etc you have tested this change against?
>
That testing is happening by the exchange, library, wallet, etc providers
themselves. There is a list on the Classic home page:
https://bitcoinclassic.com/
>
> Do you have a rollback plan in the event the hard-fork triggers via
> false voting as seemed to be prevalent during XT? (Or rollback just
> as contingency if something unforseen goes wrong).
>
The only voting in this BIP is done by the miners, and that cannot be faked.
Are you talking about people spinning up pseudo-full-nodes that fake the
user-agent?
As I said, there are people who have said they will spin up thousands of
full nodes to help prevent possible Sybil attacks which would become
marginally easier to accomplish immediately after the first >1mb block was
produced and full nodes that hadn't upgraded were left behind.
Would Blockstream be willing to help out by running a dozen or two extra
full nodes?
I can't imagine any even-remotely-likely sequence of events that would
require a rollback, can you be more specific about what you are imagining?
Miners suddenly getting cold feet?
> How do you plan to monitor and manage security through the hard-fork?
>
I don't plan to monitor or manage anything; the Bitcoin network is
self-monitoring and self-managing. Services like statoshi.info will do the
monitoring, and miners and people and businesses will manage the network,
as they do every day.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160206/e60b5b0c/attachment.html>

2023-06-07 17:48:29

- reply

📅 Original date posted:2016-02-04
📝 Original message:This BIP is unnecessary, in my opinion.
I'm going to take issue with items (2) and (3) that are the motivation for
this BIP:
" 2. Full nodes and SPV nodes following original consensus rules may not be
aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowingly accept devalued legacy tokens."
If a hardfork is deployed by increasing the version number in blocks (as is
done for soft forks), then there is no risk-- Full and SPV nodes should
notice that they are seeing up-version blocks and warn the user that they
are using obsolete software.
It doesn't matter if the software is obsolete because of hard or soft fork,
the difference in risks between those two cases will not be understood by
the typical full node or SPV node user.
" 3. In the case which the original consensus rules are also valid under
the new consensus rules, users following the new chain may unexpectedly
reorg back to the original chain if it grows faster than the new one.
People may find their confirmed transactions becoming unconfirmed and lose
money."
If a hard or soft fork uses a 'grace period' (as described in BIP 9 or BIP
101) then there is essentially no risk that a reorg will happen past the
triggering block. A block-chain re-org of two thousand or more blocks on
the main Bitcoin chain is unthinkable-- the economic chaos would be
massive, and the reaction to such a drastic (and extremely unlikely) event
would certainly be a hastily imposed checkpoint to get everybody back onto
the chain that everybody was using for economic transactions.
Since I don't agree with the motivations for this BIP, I don't think the
proposed mechanism (a negative-version-number-block) is necessary. And
since it would simply add more consensus-level code, I believe the
keep-it-simple principle applies.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/ae4f4cab/attachment.html>

2023-06-07 17:45:31

- reply

📅 Original date posted:2015-12-04
📝 Original message:Overall, good idea.
Is there a write-up somewhere describing in detail the 'accidental selfish
mining' problem that this mitigates? I think a link in the BIP to a fuller
description of the problem and how validation-skipping makes it go away
would be helpful.
RE: which bit to use: the draft versionbits BIP and BIP101 use bit 30; to
avoid confusion, I think it would be better to use bit 0.
I agree with Jannes Faber, behavior with respect to SPV clients should be
to only tell them about fully validated headers. And I also agree that
immediately relaying full-proof-of-work blocks before validation (with an
indication that they haven't been fully validated) is a good idea, but that
discussion didn't reach consensus when I brought it up two years ago (
https://github.com/bitcoin/bitcoin/pull/3580).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151204/ad61bf07/attachment.html>

2023-06-07 17:44:15

- reply

📅 Original date posted:2015-11-08
📝 Original message:On Thu, Nov 5, 2015 at 11:03 PM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Some thoughts, hope this is not off-topic.
>
> Maybe we should summarise the security assumptions and design
> requirements. It is often easier to have clear design discussions by
> first articulating assumptions and requirements.
>
> Validators: Economically dependent full nodes are an important part of
> Bitcoin's security model because they assure Bitcoin security by
> enforcing consensus rules. While full nodes do not have orphan
> risk, we also dont want maliciously crafted blocks with pathological
> validation cost to erode security by knocking reasonable spec full
> nodes off the network on CPU (or bandwidth grounds).
>
Agreed. That is why BIP101 / BitcoinXT includes code to limit the relay and
validation cost of blocks.
>
> Miners: Miners are in a commodity economics competitive environment
> where various types of attacks and collusion, even with small
> advantage, may see actual use due to the advantage being significant
> relative to the at times low profit margin
>
Agreed, with a quibble: mining economics means they will ALWAYS have a low
profit margin.
>
> It is quite important for bitcoin decentralisation security that small
> miners not be significantly disadvantaged vs large miners. Similarly
> it is important that there not be significant collusion advantages
> that create policy centralisation as a side-effect (for example what
> happened with "SPV mining" or validationless mining during BIP66
> deployment). Examples of attacks include selfish-mining and
> amplifying that kind of attack via artificially large or
> pathologically expensive to validate blocks. Or elevating orphan risk
> for others (a miner or collusion of miners is not at orphan risk for a
> block they created).
>
Okey dokey-- perhaps we should have another discussion about SPV mining, as
far as I know it harmed nobody besides the miners who mindlessly created
invalid, empty blocks (well, and besides being very annoying for developers
who had to figure out what was happening and get the offending miners to do
the right thing).
In any case, it seems to me all of this (except perhaps selfish mining) is
independent of the maximum block size, and solutions for all of the above
(including selfish mining) should be pursued regardless of what is done
with the max block size (e.g. I sent Ittay and Gun email a few minutes ago
with some might-be-wong-ideas for how weak block announcements might be
used to detect selfish mining).
>
> Validators vs Miner decentralisation balance:
>
> There is a tradeoff where we can tolerate weak miner decentralisation
> if we can rely on good validator decentralisation or vice versa. But
> both being weak is risky. Currently given mining centralisation
> itself is weak, that makes validator decentralisation a critical
> remaining defence - ie security depends more on validator
> decentralisation than it would if mining decentralisation was in a
> better shape.
>
I'm very disappointed you don't mention the tradeoff at "the other end of
the bathtub" -- Key-holder versus Validator decentralization balance. Did
you see the excellent Poon/Dryja "bathtub" presentation at Montreal?
https://scalingbitcoin.org/montreal2015/presentations/Day2/3-JosephPoonAndThaddeusDryja.pdf
Security:
>
> We should consider the pathological case not average or default behaviour
> because we can not assume people will follow the defaults, only the
> consensus-enforced rules.
>
Agreed, which is why BIP101/XT consider pathological behavior.
>
> We should not discount attacks that have not seen exploitation to
> date. We have maybe benefitted from universal good-will (everybody
> thinks Bitcoin is cool, particularly people with skills to find and
> exploit attacks).
>
Disagree on wording: we should not ignore attacks that have not seen
exploitation. But in the never-ending-list of things to be worried about
and to write code for, attacks that have not been seen should be lower
priority than attacks that have been seen, either in Bitcoin or elsewhere.
E.g. Bitcoin has never seen a buffer-overflow attack, but we absolutely
positively need to put a very high priority on the network attack surface
-- we know buffer-overflow attacks are commonly exploited.
On the other hand, Bitcoin has never seen a "Goldfinger attack" (take a big
short position on Bitcoin, then find a way to destroy confidence so the
price drops and you can profit), and "Goldfinger attacks" don't seem to be
common anywhere (you don't see people taking huge short positions in
companies and then bombing their factories). There might be a reason
Bitcoin is more vulnerable, or the same checks-and-balances (e.g. whoever
took the other side of the large short has a strong incentive to report
you, and assuming you got paid in something other than Bitcoin that is
probably possible).
(Aside: anybody who wants to talk about the likelihood of "Goldfinger
attacks" please start a thread somewhere else, I don't think that's
appropriate for bitcoin-dev).
>
> We can consider a hierarchy of defences most secure to least:
>
> 1. consensus rule enforced (attacker loses block reward)
> 2. economic alignment (attacker loses money)
> 3. overt (profitable, but overt attacks are less likely to be exploited)
> 4. meta-incentive (relying on meta-incentive to not damage the ecosystem
> only)
>
Agreed.
> Best practices:
>
> We might want to list some best practices that are important for the
> health and security of the Bitcoin network.
>
> Rule of thumb KISS stuff:
>
> We should aim to keep things simple in general and to avoid creating
> complex optimisation problems for transaction processors, wallets,
> miners.
>
I agree with KISS.
I think we can't avoid creating complex optimization problems sometimes--
see, for example, the difficulty of a wallet predicting what transaction
fee is needed for a transaction to get confirmed in X blocks (lots of
factors involved-- max block size, time since last block, miner policy as
expressed in previous blocks, transactions currently waiting in
mempool....). I do agree we should prefer simple optimization problems
over complex wherever we can.
> We may want to consider an incremental approach (shorter-time frame or
> less technically ambitious) in the interests of simplifying and
> getting something easier to arrive at consensus, and thus faster to
> deploy.
>
Or we may want to go with something that is already tested and deployed...
>
> We should not let the perfect be the enemy of the good. But we should
> not store new problems for the future, costs are stacked in favour of
> getting it right vs A/B testing on the live network.
>
I disagree about "storing new problems for the future." We don't know what
the problems will be in the future, so there is alway a leap of faith that
future engineers will be smart enough to fix the engineering problems that
arise (see the worries over quantum computing advances making ECDSA
obsolete) -- ESPECIALLY if we have thumbnail sketches of solutions that
we're reasonably certain will work (e.g. switching to a quantum-resistant
signature algorithm via soft-fork).
>
> Not everything maybe fixable in one go for complexity reasons or for
> the reason that there is no clear solution for some issues. We should
> work incrementally.
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
I think the disagreement is how big a change fits into the definition of
"incrementally."
As Jeff Garzik has pointed out, the recent change from "we never hit the
maximum block size limit" to "we regularly run into the maximum block size
limit" was a large, NON-incremental change...
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151108/25830bce/attachment.html>

2023-06-07 17:43:58

- reply

📅 Original date posted:2015-10-28
📝 Original message:I'm hoping this fits under the moderation rule of "short-term changes to
the Bitcoin protcol" (I'm not exactly clear on what is meant by
"short-term"; it would be lovely if the moderators would start a thread on
bitcoin-discuss to clarify that):
Should it be a requirement that ANY one-megabyte transaction that is valid
under the existing rules also be valid under new rules?
Pro: There could be expensive-to-validate transactions created and given a
lockTime in the future stored somewhere safe. Their owners may have no
other way of spending the funds (they might have thrown away the private
keys), and changing validation rules to be more strict so that those
transactions are invalid would be an unacceptable confiscation of funds.
Con: It is extremely unlikely there are any such large, timelocked
transactions, because the Core code has had a clear policy for years that
100,000-byte transactions are "standard" and are relayed and
mined, and
larger transactions are not. The requirement should be relaxed so that only
valid 100,000-byte transaction under old consensus rules must be valid
under new consensus rules (larger transactions may or may not be valid).
I had to wrestle with that question when I implemented BIP101/Bitcoin XT
when deciding on a limit for signature hashing (and decided the right
answer was to support any "non-attack"1MB transaction; see
https://bitcoincore.org/~gavin/ValidationSanity.pdf for more details).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151028/061c73f2/attachment.html>

2023-06-07 17:41:05

- reply

📅 Original date posted:2015-09-23
📝 Original message:I've been thinking about 'weak blocks' and SPV mining, and it seems to me
weak blocks will make things better, not worse, if we improve the mining
code a little bit.
First: the idea of 'weak blocks' (hat tip to Rusty for the term) is for
miners to pre-announce blocks that they're working on, before they've
solved the proof-of-work puzzle. To prevent DoS attacks, assume that some
amount of proof-of-work is done (hence the term 'weak block') to rate-limit
how many 'weak block' messages are relayed across the network.
Today, miners are incentivized to start mining an empty block as soon as
they see a block with valid proof-of-work, because they want to spend as
little time as possible mining a not-best chain.
Imagine miners always pre-announce the blocks they're working on to their
peers, and peers validate those 'weak blocks' as quickly as they are able.
Because weak blocks are pre-validated, when a full-difficulty block based
on a previously announced weak block is found, block propagation should be
insanely fast-- basically, as fast as a single packet can be relayed across
the network the whole network could be mining on the new block.
I don't see any barrier to making accepting the full-difficulty block and
CreateNewBlock() insanely fast, and if those operations take just a
microsecond or three, miners will have an incentive to create blocks with
fee-paying transactions that weren't in the last block, rather than mining
empty blocks.
.................
A miner could try to avoid validation work by just taking a weak block
announced by somebody else, replacing the coinbase and re-computing the
merkle root, and then mining. They will be at a slight disadvantage to
fully validating miners, though, because they WOULD have to mine empty
blocks between the time a full block is found and a fully-validating miner
announced their next weak block.
.................
Weak block announcements are great for the network; they give transaction
creators a pretty good idea of whether or not their transactions are likely
to be confirmed in the next block. And if we're smart about implementing
them, they shouldn't increase bandwidth or CPU usage significantly, because
all the weak blocks at a given point in time are likely to contain the same
transactions.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/ca1bbeb5/attachment.html>

2023-06-07 17:40:10

- reply

📅 Original date posted:2015-09-23
📝 Original message:I say keep it simple.
If the 75% threshold is hit, then support suddenly drops off below 50%,
"meh" -- there will be a big ruckus, everybody will freak out, and miners
will refuse to build big blocks because they'll worry that they'll get
orphaned.
Adding more complexity for a case that ain't gonna happen (and isn't a
disaster if it does) is a mistake, in my humble opinion.
On Wed, Sep 23, 2015 at 2:33 PM, Tom Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
>
>> '''Success: Activation Delay'''
>> The consensus rules related to ''locked-in'' soft fork will be enforced in
>> the second retarget period; ie. there is a one retarget period in
>> which the remaining 5% can upgrade. At the that activation block and
>> after, the bit B may be reused for a different soft fork.
>>
>>
> Rather than a simple one-period delay, should there be a one-period
> "burn-in" to show sustained support of the threshold? During this period,
> support must continuously remain above the threshold. Any lapse resets to
> inactivated state.
>
> With a simple delay, you can have the embarrassing situation where support
> falls off during the delay period and there is far below threshold support
> just moments prior to enforcement, but enforcement happens anyway.
>
> BIP 101 has this problem too.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/c8d94f63/attachment.html>

2023-06-07 17:32:41

- reply

📅 Original date posted:2015-08-03
📝 Original message:I haven't seen this excellent recent blog post by Eli Dourado referenced
here:
https://readplaintext.com/how-should-bitcoin-be-governed-680192fcd92b
I agree with his conclusions: we need better communication/organization
mechanisms among 'stakeholders' and between the various factions
(developers, miners, merchants, exchanges, end-users).
And the preliminary results of using a prediction market to try to wrestle
with the tough tradeoffs looks roughly correct to me, too:
https://blocksizedebate.com/
(my only big disagreement with those predictions is the 'Number of nodes'
-- I don't think replace-by-fee would affect that number, and I think even
with no change we will see the number of full nodes on the network drop to
a couple thousand, because the general-purpose-home-PC is headed the way of
the dodo:
http://www.businessinsider.com/pc-sales-plummet-in-q2-2015-gartner-idc-say-2015-7
).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/ed8f65cf/attachment.html>

2023-06-07 17:32:33

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> But you seem to consider that a bad thing. Maybe saying that you're
> claiming that this equals Bitcoin failing is an exaggeration, but you do
> believe that evolving towards an ecosystem where there is competition for
> block space is a bad thing, right?
>
No, competition for block space is good.
What is bad is artificially limiting or centrally controlling the supply of
that space.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/c7963bde/attachment.html>

2023-06-07 15:44:02

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Because any decentralized system is going to have high transaction costs
> and scarcity anyway.
This is a meme that keeps coming up that I think just isn't true.
What other decentralized systems can we look at as role models?
How decentralized are they?
And why did they succeed when "more efficient" centralized systems did not?
The Internet is the most successful decentralized system to date; what
lessons should we learn?
How decentralized is the technology of the Internet (put aside governance
and the issues of who-assigns-blocks-of-IPs-and-registers-domain-names)?
How many root DNS servers? How many BGP routers along the backbone would
need to be compromised to disrupt traffic? Why don't we see more
disruptions, or why are people willing to tolerate the disruptions that DO
happen?
And how did the Internet out-compete more efficient centralized systems
from the big telecom companies? (I remember some of the arguments that
unreliable, inefficient packet-switching would never replace dedicated
circuits that couldn't get congested and didn't have inefficient timeouts
and retransmissions)
What other successful or unsuccessful decentralized systems should we be
looking at?
I'm old-- I graduated from college in 1988, so I've worked in tech through
the entire rise of the Internet. The lessons I believe we should take away
is that a system doesn't have to be perfect to be successful, and we
shouldn't underestimate people's ability to innovate around what might seem
to be insurmountable problems, IF people are given the ability to innovate.
Yes, people will innovate within a 1MB (or 1MB-scaling-to-2MB by 2021) max
block size, and yes, smaller blocks have utility. But I think we'll get a
lot more innovation and utility without such small, artificial limits.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/f6a07a15/attachment-0001.html>

2023-06-07 15:40:56

- reply

📅 Original date posted:2015-06-28
📝 Original message:On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
> This is probably going to sound impolite, but I think it's pertinent.
>
> Gavin, on dwelling on the the fact that you appear to not understand
> the basics of the lightning network, I am a little alarmed about this
If I don't see how switching from using the thousands of fully-validating
bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
terms of decentralization (or security, in terms of Sybil/DoS attacks),
then I doubt other people do, either. You need to do a better job of
explaining it.
But even if you could convince me that it WAS better from a
security/decentralization point of view:
a) Lightning Network is nothing but a whitepaper right now. We are a long
way from a practical implementation supported by even one wallet.
b) The Lightning Network paper itself says bigger blocks will be needed
even if (especially if!) Lightning is wildly successful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/b1dc1232/attachment-0001.html>

2023-06-07 15:40:55

- reply

📅 Original date posted:2015-06-28
📝 Original message:On Sun, Jun 28, 2015 at 1:12 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> But ultimately, lightning usefully solves a problem where participants
> have semi-long lived payment endpoints.
Very few of my own personal Bitcoin transactions fit that use-case.
In fact, very few of my own personal dollar transactions fit that use-case
(I suppose if I was addicted to Starbucks I'd have one of their payment
cards that I topped up every once in a while, which would map nicely onto a
payment channel). I suppose I could setup a payment channel with the
grocery store I shop at once a week, but that would be inconvenient (I'd
have to pre-fund it) and bad for my privacy.
I can see how payment channels would work between big financial
institutions as a settlement layer, but isn't that exactly the
centralization concern that is making a lot of people worried about
increasing the max block size?
And if there are only a dozen or two popular hubs, that's much worse
centralization-wise compared to a few thousand fully-validating Bitcoin
nodes.
Don't get me wrong, I think the Lightning Network is a fantastic idea and a
great experiment and will likely be used for all sorts of great payment
innovations (micropayments for bandwidth maybe, or maybe paying workers by
the hour instead of at the end of the month). But I don't think it is a
scaling solution for the types of payments the Bitcoin network is handling
today.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/8b400964/attachment.html>

2023-06-07 15:37:23

- reply

📅 Original date posted:2015-06-12
📝 Original message:Nice work, Pieter. You're right that my simulation assumed bandwidth for
'block' messages isn't the bottleneck.
But doesn't Matt's fast relay network (and the work I believe we're both
planning on doing in the near future to further optimize block propagation)
make both of our simulations irrelevant in the long-run?
Or, even simpler, why couldn't the little miners just run their
block-assembling-and-announcing code on the other high-bandwidth-side of
the bandwidth bottleneck?
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150612/30ea9c9f/attachment.html>

2023-06-07 15:33:43

- reply

📅 Original date posted:2015-05-30
📝 Original message:On Fri, May 29, 2015 at 7:42 PM, Chun Wang <1240902 at gmail.com> wrote:
> Hello. I am from F2Pool. We are currently mining the biggest blocks on
> the network.
Thanks for giving your opinion!
> Bad miners could attack us and the network with artificial
> big blocks.
How?
I ran some simulations, and I could not find a network topology where a big
miner producing big blocks could cause a loss of profit to another miner
(big or small) producing smaller blocks:
http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
(the 0.3% advantage I DID find was for the situation where EVERYBODY was
producing big blocks).
> We think
> the max block size should be increased, but must be increased
> smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
> and so on. Thanks.
Why 2 MB ? You said that server bandwidth is much more expensive in
China; what would be the difference in your bandwidth costs between 2MB
blocks and 20MB blocks?
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150530/643c32da/attachment.html>

2023-06-07 15:33:42

- reply

📅 Original date posted:2015-05-29
📝 Original message:Matt brought this up on Twitter, I have no idea why I didn't respond weeks
ago (busy writing blog posts, probably):
On Thu, May 7, 2015 at 6:02 PM, Matt Corallo <bitcoin-list at bluematt.me>
wrote:
>
>
> * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today.
If block propagation isn't fixed, then mines have a strong incentive to
create smaller blocks.
So the max block size is irrelevant, it won't get hit.
> In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.
>
See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
for analysis of "but that means bigger miners can get an advantage"
argument.
Executive summary: if little miners are stupid and produce huge blocks,
then yes, big miners have an advantage.
But they're not, so they won't.
Until the block reward goes away, and assuming transaction fees become an
important source of revenue for miners.
I think it is too early to worry about that; see:
http://gavinandresen.ninja/when-the-block-reward-goes-away
> * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace.
Ok. What does this have to do with the max block size?
Are you arguing that work won't happen if the max block size increases?
* I'd like to see some better conclusions to the discussion around
> long-term incentives within the system.
Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away for
what I think about that.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/c145f6b9/attachment.html>

2023-06-07 15:29:11

- reply

📅 Original date posted:2015-01-31
📝 Original message:I agree- standards should be descriptive ("here is how this thing I did
works") and NOT proscriptive ("here's what I think will work, lets all try
to do it this way.").
On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn <mike at plan99.net> wrote:
> I could look at implementing it someday, but now I'd like to receive
>> feedback from community.
>>
>
> IMO it's better to pair a protocol spec with an implementation.
>
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150131/dbd2ac48/attachment.html>

2023-06-07 15:24:07

- reply

📅 Original date posted:2014-07-18
📝 Original message:Two more half-baked thoughts:
We should be able to assume that the majority of transaction data (except
for coinbase) has already been propagated. As Jeff said, incentivizing
nodes to propagate transactions is a very good thing (the signature cache
already gives a small incentive to miners to propagate and not 'hoard'
transactions).
So the only information that theoretically needs to be propagated is which
transactions a miner is including in their block, and in what order they
are included.
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).
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....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140718/f2b10a38/attachment.html>

2023-06-07 15:24:06

- reply

📅 Original date posted:2014-07-17
📝 Original message:A couple of half-baked thoughts:
On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley <keziahw at gmail.com> wrote:
> If there's support for this proposal, I can begin working on the specific
> implementation details, such as the bloom filters, message format, and
> capability advertisment, and draft a BIP once I have a concrete proposal
> for
> what those would look like and a corresponding precise cost/benefit
> analysis.
>
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.
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.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140717/16478b5f/attachment.html>

2023-06-07 15:04:02

- reply

📅 Original date posted:2013-06-28
📝 Original message:I vote "yes" to have MultiBit replace Bitcoin-Qt as the recommended
desktop wallet app. I think most users will be happier with it.
If I'm wrong, it is easy to change back.

2023-06-07 10:03:25

- 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:
> 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)
That seems like a perfectly reasonable protocol improvement to me.
Anybody else have an opinion?
--
--
Gavin Andresen

2023-06-07 02:18:13

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Scheduling a blockchain split is not a good idea now. New standard transactions are a good short-term solution. Revisit in N months with a roadmap and tests.
📝 Original message:This discussion is convincing me that scheduling a blockchain split is
definitely the wrong idea at this time. We can revisit in N months,
when we've got a roadmap and nice unit tests and a bunch of
well-tested patches for fixing all of the things that aught to be
fixed when we DO decide a blockchain split is necessary.
There seems to be rough consensus that new, imperfect standard
transactions are a good-enough short term solution.
--
--
Gavin Andresen

2023-06-07 02:17:37

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Multi-signature transactions are the fastest way to secure Bitcoin wallets, but there is debate over implementing new standard transactions and addresses.
📝 Original message:It seems to me the fastest path to very secure, very-hard-to-lose
bitcoin wallets is multi-signature transactions.
To organize this discussion: first, does everybody agree?
ByteCoin pointed to a research paper that gives a scheme for splitting
a private key between two people, neither of which every knows the
full key, but, together, both can DSA-sign transactions. That's very
cool, but it involves high-end cutting-edge crypto like zero-knowledge
proofs that I know very little about (are implementations available?
are they patented? have they been thoroughly vetted/tested? etc).
So I'm assuming that is NOT the fastest way to solving the problem.
If anybody has some open-source, patent-free, thoroughly-tested code
that already does DSA-key-splitting, speak up please.
I've been trying to get consensus on low-level 'standard' transactions
for transactions that must be signed by 2 or 3 keys; current draft
proposal is here:
https://gist.github.com/39158239e36f6af69d6f
and discussion on the forums here:
https://bitcointalk.org/index.php?topic=38928.0
... and there is a pull request that is relevant here:
https://github.com/bitcoin/bitcoin/pull/319
I still think it is a good idea to enable a set of new 'standard'
multisignature transactions, so they get relayed and included into
blocks. I don't want to let "the perfect become the enemy of the
good" -- does anybody disagree?
The arguments against are that if the proposed standard transactions
are accepted, then the next step is to define a new kind of bitcoin
address that lets coins be deposited into a multisignature-protected
wallet.
And those new as-yet-undefined bitcoin addresses will have to be 2 or
3 times as big as current bitcoin addresses, and will be incompatible
with old clients.
So, if we are going to have new releases that are incompatible with
old clients why not do things right in the first place, implement or
enable opcodes so the new bitcoin addresses can be small, and schedule
a block chain split for N months from now.
My biggest worry is we'll say "Sure, it'll only take a couple days to
agree on how to do it right" and six months from now there is still no
consensus on exactly which digest function should be used, or whether
or not there should be a new opcode for arbitrary boolean expressions
involving keypairs. And people's wallets continue to get lost or
stolen.
--
--
Gavin Andresen