<unnamed>

Public Key

npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw

Profile Code

nprofile1qqsg2le00rwpvw08z8675up6nlyh3c3wh5ne4002rpsm0k4gxdgjaeqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsq5wj37

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:48:43 CEST

- reply

📅 Original date posted:2016-02-07
📝 Original message:On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev wrote:
> > On Saturday, February 06, 2016 06:09:21 PM Jorge Timón via bitcoin-dev
> wrote:
> > > None of the reasons you list say anything about the fact that "being
> > > lost" (kicked out of the network) is a problem for those node's users.
> >
> > That's because its not.
> >
> > If you have a node that is "old" your node will stop getting new blocks.
> > The node will essentially just say "x-hours behind" with "x" getting
> larger
> > every hour. Funds don't get confirmed. etc.
>
> Until someone decides to attack you. Then you'll get 6, 10, maybe more
> blocks
> confirming a large 10000 BTC payment. If you're just a normal end user (or
> perhaps an automated system), you'll figure that payment is good and
> irreversibly hand over the title to the house.
>
There will be approximately zero percentage of hash power left on the
weaker branch of the fork, based on past soft-fork adoption by miners (they
upgrade VERY quickly from 75% to over 95%).
So it will take a week to get 6 confirmations.
If you are a full node, you are warned that your software is obsolete and
you must upgrade.
If you are a lightweight node, it SHOULD tell you something is wrong, but
even if it doesn't, given that people running lightweight nodes run them so
they don't have to be connected to the network 24/7, it is very likely
during that week you disconnect and reconnect to the network several times.
And every time you do that you increase your chances that you will connect
to full nodes on the majority branch of the chain, where you will be told
about the double-spend.
All of that is assuming that there is no OTHER mitigation done. DNS seeds
should avoid reporting nodes that look like they are in the middle of
initial block download (that are at a block height significantly behind the
rest of the network), for example.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/7956ed21/attachment.html>

2023-06-07 19:48:39 CEST

- 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 19:48:37 CEST

- reply

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

2023-06-07 19:48:36 CEST

- reply

📅 Original date posted:2016-02-07
📝 Original message:As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).
I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been argued to death in the past.
I do want to briefly address all of the concerns that stem from "what if a
significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of
the chain."
Proof of work cannot be spoofed. If there is very little (a few percent) of
hashpower mining a minority chain, confirmations on that chain take orders
of magnitude longer. I wrote about why the incentives are extremely strong
for only the stronger branch to survive here:
http://gavinandresen.ninja/minority-branches
... the debate about whether or not that is correct doesn't belong here in
bitcoin-dev, in my humble opinion.
All of the security concerns I have seen flow from an assumption that
significant hashpower continues on the weaker branch. The BIP that is under
discussion assumes that analysis is correct. I have not seen any evidence
that it is not correct; all experience with previous forks (of both Bitcoin
and altcoins) is that the stronger branch survives and the weaker branch
very quickly dies.
As for the argument that creating and testing a patch for Core would take
longer than 28 days:
The glib answer is "people should just run Classic, then."
A less glib answer is it would be trivial to create a patch for Core that
accepted a more proof-of-work chain with larger blocks, but refused to mine
larger blocks.
That would be a trivial patch that would require very little testing
(extensive testing of 8 and 20mb blocks has already been done), and perhaps
would be the best compromise until we can agree on a permanent solution
that eliminates the arbitrary, contentious limits.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/8f19d8d9/attachment.html>

2023-06-07 19:48:35 CEST

- reply

📅 Original date posted:2016-02-05
📝 Original message:This has been reviewed by merchants, miners and exchanges for a couple of
weeks, and has been implemented and tested as part of the Bitcoin Classic
and Bitcoin XT implementations.
Constructive feedback welcome; argument about whether or not it is a good
idea to roll out a hard fork now will be unproductive, so I vote we don't
go there.
Draft BIP:
https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
Summary:
Increase block size limit to 2,000,000 bytes.
After 75% hashpower support then 28-day grace period.
With accurate sigop counting, but existing sigop limit (20,000)
And a new, high limit on signature hashing
Blog post walking through the code:
http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
Blog post on a couple of the constants chosen:
http://gavinandresen.ninja/seventyfive-twentyeight
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160205/75a2eca2/attachment.html>

2023-06-07 19:48:29 CEST

- 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 19:47:46 CEST

- reply

📅 Original date posted:2016-01-08
📝 Original message:On Fri, Jan 8, 2016 at 10:46 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> And Ethan or Anthony: can you think of a similar attack scheme if you
> assume we had switched to Schnorr 2-of-2 signatures by then?
Don't answer that, I was being dense again, Anthony's scheme works with
Schnorr...
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/f1c01274/attachment.html>

2023-06-07 19:47:45 CEST

- reply

📅 Original date posted:2016-01-08
📝 Original message:Thanks, Anthony, that works!
So...
How many years until we think a 2^84 attack where the work is an ECDSA
private->public key derivation will take a reasonable amount of time?
And Ethan or Anthony: can you think of a similar attack scheme if you
assume we had switched to Schnorr 2-of-2 signatures by then?
And to everybody who might not be reading this closely: All of the above
is discussing collision attacks; none of it is relevant in the normal case
where your wallet generates the scriptPubKey.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/8f69988f/attachment.html>

2023-06-07 19:47:45 CEST

- reply

📅 Original date posted:2016-01-08
📝 Original message:And to fend off the messag that I bet somebody is composing right now:
Yes, I know about a "security first" mindset. But as I said earlier in the
thread, there is a tradeoff here between crypto strength and code
complexity, and "the strength of the crypto is all that matters" is NOT
security first.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/b0d965ec/attachment.html>

2023-06-07 19:47:44 CEST

- reply

📅 Original date posted:2016-01-08
📝 Original message:On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Matt Corallo <lf-lists at mattcorallo.com> writes:
> > Indeed, anything which uses P2SH is obviously vulnerable if there is
> > an attack on RIPEMD160 which reduces it's security only marginally.
>
> I don't think this is true? Even if you can generate a collision in
> RIPEMD160, that doesn't help you since you need to create a specific
> SHA256 hash for the RIPEMD160 preimage.
>
> Even a preimage attack only helps if it leads to more than one preimage
> fairly cheaply; that would make grinding out the SHA256 preimage easier.
> AFAICT even MD4 isn't this broken.
>
It feels like we've gone over that before, but I can never remember where
or when. I believe consensus was that if we were using the broken MD5 in
all the places we use RIPEMD160 we'd still be secure today because of
Satoshi's use of nested hash functions everywhere.
> But just with Moore's law (doubling every 18 months), we'll worry about
> economically viable attacks in 20 years.[1]
> That's far enough away that I would choose simplicity, and have all SW
> scriptPubKeys simply be "<0> RIPEMD(SHA256(WP))" for now, but it's
> not a no-brainer.
Lets see if I've followed the specifics of the collision attack correctly,
Ethan (or somebody) please let me know if I'm missing something:
So attacker is in the middle of establishing a payment channel with
somebody. Victim gives their public key, attacker creates the innocent
fund-locking script '2 V A 2 CHECKMULTISIG' (V is victim's public key, A
is attacker's) but doesn't give it to the victim yet.
Instead they then generate about 2^81scripts that are some form of
pay-to-attacker ....
... wait, no that doesn't work, because SHA256 is used as the inner hash
function. They'd have to generate 2^129 to find a cycle in SHA256.
Instead, they .. what? I don't see a viable attack unless RIPEMD160 and
SHA256 (or the combination) suffers a cryptographic break.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160108/aec650d3/attachment.html>

2023-06-07 19:47:42 CEST

- reply

📅 Original date posted:2016-01-07
📝 Original message:On Thu, Jan 7, 2016 at 6:52 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> Bitcoin does have parts that rely on economic arguments for security or
> privacy, but can we please stick to using cryptography that is up to par
> for parts where we can? It's a small constant factor of data, and it
> categorically removes the worry about security levels.
>
Our message may have crossed in the mod queue:
"So can we quantify the incremental increase in security of SHA256(SHA256)
over RIPEMD160(SHA256) versus the incremental increase in security of
having a simpler implementation of segwitness?"
I believe the history of computer security is that implementation errors
and sidechannel attacks are much, much more common than brute-force breaks.
KEEP IT SIMPLE.
(and a quibble: "do a 80-bit search for B and C such that H(A and B) = H(B
and C)" isn't enough, you have to end up with a C public key for which you
know the corresponding private key or the attacker just succeeds in burning
the funds)
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/f73f2f2c/attachment.html>

2023-06-07 19:47:40 CEST

- reply

📅 Original date posted:2016-01-07
📝 Original message:On Thu, Jan 7, 2016 at 8:26 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> So just because other attacks are possible we should weaken the crypto
> we use? You may feel comfortable weakening crypto used to protect a few
> billion dollars of other peoples' money, but I dont.
>
No...
I'm saying we can eliminate one somewhat unlikely attack (that there is a
bug in the code or test cases, today or some future version, that has to
decide what to do with "version 0" versus "version 1" witness programs) by
accepting the risk of another insanely, extremely unlikely attack.
Reference for those who are lost:
https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki#witness-program
My proposal would be to just do a version 0 witness program now, that is
RIPEMD160(SHA256(script)).
And ten or twenty years from now, if there is a plausible attack on
RIPEMD160 and/or SHA256, revisit and do a version 11 (or whatever).
It will simplify the BIP, means half as many test cases have to be written,
means a little more scalability, and is as secure as the P2SH and P2PKH
everybody is using to secure their bitcoin today.
Tell you what: I'll change my mind if anybody can describe a plausible
attack if we were using MD5(SHA256), given what we know about how MD5 is
broken.
---
I'm really disappointed with the "Here's the spec, take it or leave it"
attitude. What's the point of having a BIP process if the discussion just
comes down to "We think more is better. We don't care what you think."
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/ba55bae0/attachment.html>

2023-06-07 19:47:39 CEST

- reply

📅 Original date posted:2016-01-07
📝 Original message:Thanks, Ethan, that's helpful and I'll stop thinking that collision attacks
require 2^(n/2) memory...
So can we quantify the incremental increase in security of SHA256(SHA256)
over RIPEMD160(SHA256) versus the incremental increase in security of
having a simpler implementation of segwitness?
I'm going to claim that the difference in the first case is very, very,
very small-- the risk of an implementation error caused by having multiple
ways of interpreting the segwitness hash in the scriptPubKey is much, much
greater.
And even if there IS some risk of collision attack now or at some point in
the future, I claim that it is easy for wallets to mitigate that risk. In
fact, the principle of security in depth means wallets that don't
completely control the scriptPubKeys they're creating on behalf of users
SHOULD be coded to mitigate that risk (e.g. not allowing arbitrary data
around a user's public key in a Script so targeted substring attacks are
eliminated entirely).
Purely from a security point of view, I think a single 20-byte segwitness
in the scriptPubKey is the best design.
"Keep the design as simple and small as possible"
https://www.securecoding.cert.org/confluence/plugins/servlet/mobile#content/view/2426
Add in the implied capacity increase of smaller scriptPubKeys and I still
think it is a no-brainer.
On Thu, Jan 7, 2016 at 5:56 PM, Ethan Heilman <eth3rs at gmail.com> wrote:
> >Ethan: your algorithm will find two arbitrary values that collide. That
> isn't useful as an attack in the context we're talking about here (both of
> those values will be useless as coin destinations with overwhelming
> probability).
>
> I'm not sure exactly the properties you want here and determining
> these properties is not an easy task, but the case is far worse than
> just two random values. For instance: (a). with a small modification
> my algorithm can also find collisions containing targeted substrings,
> (b). length extension attacks are possible with RIPEMD160.
>
> (a). targeted cycles:
>
> target1 = "str to prepend"
> target2 = "str to end with"
>
> seed = {0,1}^160
> x = hash(seed)
>
> for i in 2^80:
> ....x = hash(target1||x||target2)
> x_final = x
>
> y = hash(tartget1||x_final||target2)
>
> for j in 2^80:
> ....if y == x_final:
> ........print "cycle len: "+j
> ........break
> ....y = hash(target1||y||target2)
>
> If a collision is found, the two colliding inputs must both start with
> "str to prepend" and end with the phrase "str to end with". As before
> this only requires 2^81.5 computations and no real memory. For an
> additional 2**80 an adversary has an good change of finding two
> different targeted substrings which collide. Consider the case where
> the attacker mixes the targeted strings with the hash output:
>
> hash("my name is=0x329482039483204324423"+x[1]+", my favorite number
> is="+x) where x[1] is the first bit of x.
>
> (b). length extension attacks
>
> Even if all the adversary can do is create two random values that
> collide, you can append substrings to the input and get collisions.
> Once you find two random values hash(x) = hash(y), you could use a
> length extension attack on RIPEMD-160 to find hash(x||z) = hash(y||z).
>
> Now the bitcoin wiki says:
> "The padding scheme is identical to MD4 using Merkle–Damgård
> strengthening to prevent length extension attacks."[1]
>
> Which is confusing to me because:
>
> 1. MD4 is vulnerable to length extension attacks
> 2. Merkle–Damgård strengthening does not protect against length
> extension: "Indeed, we already pointed out that none of the 64
> variants above can withstand the 'extension' attack on the MAC
> application, even with the Merkle-Damgard strengthening" [2]
> 3. RIPEMD-160 is vulnerable to length extension attacks, is Bitcoin
> using a non-standard version of RIPEMD-160.
>
> RIPEMD160(SHA256()) does not protect against length extension attacks
> on SHA256, but should protect RIPEMD-160 against length extension
> attacks as RIPEMD-160 uses 512-bit message blocks. That being said we
> should be very careful here. Research has been done that shows that
> cascading the same hash function twice is weaker than using HMAC[3]. I
> can't find results on cascading RIPEMD160(SHA256()).
>
> RIPEMD160(SHA256()) seems better than RIPEMD160() though, but security
> should not rest on the notion that an attacker requires 2**80 memory,
> many targeted collision attacks can work without much memory.
>
> [1]: https://en.bitcoin.it/wiki/RIPEMD-160
> [2]: "Merkle-Damgard Revisited: How to Construct a Hash Function"
> https://www.cs.nyu.edu/~puniya/papers/merkle.pdf
> [3]: https://www.cs.nyu.edu/~dodis/ps/h-of-h.pdf
>
> On Thu, Jan 7, 2016 at 4:06 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Maybe I'm asking this question on the wrong mailing list:
> >
> > Matt/Adam: do you have some reason to think that RIPEMD160 will be broken
> > before SHA256?
> > And do you have some reason to think that they will be so broken that the
> > nested hash construction RIPEMD160(SHA256()) will be vulnerable?
> >
> > Adam: re: "where to stop" : I'm suggesting we stop exactly at the
> current
> > status quo, where we use RIPEMD160 for P2SH and P2PKH.
> >
> > Ethan: your algorithm will find two arbitrary values that collide. That
> > isn't useful as an attack in the context we're talking about here (both
> of
> > those values will be useless as coin destinations with overwhelming
> > probability).
> >
> > Dave: you described a first preimage attack, which is 2**160 cpu time
> and no
> > storage.
> >
> >
> > --
> > --
> > Gavin Andresen
> >
> > _______________________________________________
> > 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/20160107/39e4d3d6/attachment-0001.html>

2023-06-07 19:47:38 CEST

- reply

📅 Original date posted:2016-01-07
📝 Original message:Maybe I'm asking this question on the wrong mailing list:
Matt/Adam: do you have some reason to think that RIPEMD160 will be broken
before SHA256?
And do you have some reason to think that they will be so broken that the
nested hash construction RIPEMD160(SHA256()) will be vulnerable?
Adam: re: "where to stop" : I'm suggesting we stop exactly at the current
status quo, where we use RIPEMD160 for P2SH and P2PKH.
Ethan: your algorithm will find two arbitrary values that collide. That
isn't useful as an attack in the context we're talking about here (both of
those values will be useless as coin destinations with overwhelming
probability).
Dave: you described a first preimage attack, which is 2**160 cpu time and
no storage.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/a777b3e1/attachment.html>

2023-06-07 19:47:37 CEST

- reply

📅 Original date posted:2016-01-07
📝 Original message:I'm hoisting this from some private feedback I sent on the segregated
witness BIP:
I said:
"I'd also use RIPEMD160(SHA256()) as the hash function and save the 12
bytes-- a successful preimage attack against that ain't gonna happen before
we're all dead. I'm probably being dense, but I just don't see how a
collision attack is relevant here."
Pieter responded:
"The problem case is where someone in a contract setup shows you a script,
which you accept as being a payment to yourself. An attacker could use a
collision attack to construct scripts with identical hashes, only one of
which does have the property you want, and steal coins.
So you really want collision security, and I don't think 80 bits is
something we should encourage for that. Normal pubkey hashes don't have
that problem, as they can't be constructed to pay to you."
... but I'm unconvinced:
"But it is trivial for contract wallets to protect against collision
attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off, just
ignore that arbitrary data" a wallet can just refuse. Even more likely, a
contract wallet won't even recognize that as a pay-to-gavin transaction.
I suppose it could be looking for some form of "gavin_pubkey
somebody_else_pubkey CHECKMULTISIG ... with the attacker using
somebody_else_pubkey to force the collision, but, again, trivial contract
protocol tweaks ("send along a proof you have the private key corresponding
to the public key" or "everybody pre-commits pubkeys they'll use at
protocol start") would protect against that.
Adding an extra 12 bytes to every segwit to prevent an attack that takes
2^80 computation and 2^80 storage, is unlikely to be a problem in practice,
and is trivial to protect against is the wrong tradeoff to make."
20 bytes instead of 32 bytes is a savings of almost 40%, which is
significant.
The general question I'd like to raise on this list is:
Should we be worried, today, about collision attacks against RIPEMD160 (our
160-bit hash)?
Mounting a successful brute-force collision attack would require at least
O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin
POW has computed more SHA256 hashes than that). But it also requires
O(2^80) storage, which is utterly infeasible (there is something on the
order of 2^35 bytes of storage in the entire world). Even assuming
doubling every single year (faster than Moore's Law), we're four decades
away from an attacker with THE ENTIRE WORLD's storage capacity being able
to mount a collision attack.
References:
https://en.wikipedia.org/wiki/Collision_attack
https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160107/09860830/attachment.html>

2023-06-07 19:45:45 CEST

- reply

📅 Original date posted:2015-12-11
📝 Original message:On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> This is basically what I meant by
>
> struct hashRootStruct
> {
> uint256 hashMerkleRoot;
> uint256 hashWitnessesRoot;
> uint256 hashextendedHeader;
> }
>
> but my design doesn't calculate other_root as it appears in your tree (is
> not necessary).
>
> It is necessary to maintain compatibility with SPV nodes/wallets.
Any code that just checks merkle paths up into the block header would have
to change if the structure of the merkle tree changed to be three-headed at
the top.
If it remains a binary tree, then it doesn't need to change at all-- the
code that produces the merkle paths will just send a path that is one step
deeper.
Plus, it's just weird to have a merkle tree that isn't a binary tree.....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151211/2f95a032/attachment-0001.html>

2023-06-07 19:45:44 CEST

- reply

📅 Original date posted:2015-12-09
📝 Original message:On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think it would be logical to do as part of a hardfork that moved
> commitments generally; e.g. a better position for merged mining (such
> a hardfork was suggested in 2010 as something that could be done if
> merged mining was used), room for commitments to additional block
> back-references for compact SPV proofs, and/or UTXO set commitments.
> Part of the reason to not do it now is that the requirements for the
> other things that would be there are not yet well defined. For these
> other applications, the additional overhead is actually fairly
> meaningful; unlike the fraud proofs.
>
So just design ahead for those future uses. Make the merkle tree:
root_in_block_header
/ \
tx_data_root other_root
/ \
segwitness_root reserved_for_future_use_root
... where reserved_for_future_use is zero until some future block version
(or perhaps better, is just chosen arbitrarily by the miner and sent along
with the block data until some future block version).
That would minimize future disruption of any code that produced or consumed
merkle proofs of the transaction data or segwitness data, especially if the
reserved_for_future_use_root is allowed to be any arbitrary 256-bit value
and not a constant that would get hard-coded into segwitness-proof-checking
code.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/89ff9b06/attachment.html>

2023-06-07 19:45:41 CEST

- reply

📅 Original date posted:2015-12-08
📝 Original message:On Tue, Dec 8, 2015 at 6:59 PM, Gregory Maxwell <greg at xiph.org> wrote:
> > We also need to fix the O(n^2) sighash problem as an additional BIP for
> ANY
> > blocksize increase.
>
> The witness data is never an input to sighash, so no, I don't agree
> that this holds for "any" increase.
>
Here's the attack:
Create a 1-megabyte transaction, with all of it's inputs spending
segwitness-spending SIGHASH_ALL inputs.
Because the segwitness inputs are smaller in the block, you can fit more of
them into 1 megabyte. Each will hash very close to one megabyte of data.
That will be O(n^2) worse than the worst case of a 1-megabyte transaction
with signatures in the scriptSigs.
Did I misunderstand something or miss something about the 1-mb transaction
data and 3-mb segwitness data proposal that would make this attack not
possible?
RE: fraud proof data being deterministic: yes, I see, the data can be
computed instead of broadcast with the block.
RE: emerging consensus of Core:
I think it is a huge mistake not to "design for success" (see
http://gavinandresen.ninja/designing-for-success ).
I think it is a huge mistake to pile on technical debt in
consensus-critical code. I think we should be working harder to make things
simpler, not more complex, whenever possible.
And I think there are pretty big self-inflicted current problems because
worries about theoretical future problems have prevented us from coming to
consensus on simple solutions.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/58a8269d/attachment.html>

2023-06-07 19:45:37 CEST

- reply

📅 Original date posted:2015-12-08
📝 Original message:Thanks for laying out a road-map, Greg.
I'll need to think about it some more, but just a couple of initial
reactions:
Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
coinbase is messy and will just complicate consensus-critical code (as
opposed to making the right side of the merkle tree in block.version=5
blocks the segwitness data).
It will also make any segwitness fraud proofs significantly larger (merkle
path versus merkle path to coinbase transactions, plus ENTIRE coinbase
transaction, which might be quite large, plus merkle path up to root).
We also need to fix the O(n^2) sighash problem as an additional BIP for ANY
blocksize increase. That also argues for a hard fork-- it is much easier to
fix it correctly and simplify the consensus code than to continue to apply
band-aid fixes on top of something fundamentally broken.
Segwitness will require a hard or soft-fork rollout, then a significant
fraction of the transaction-producing wallets to upgrade and start
supporting segwitness-style transactions. I think it will be much quicker
than the P2SH rollout, because the biggest transaction producers have a
strong motivation to lower their fees, and it won't require a new type of
bitcoin address to fund wallets. But it still feels like it'll be six
months to a year at the earliest before any relief from the current
problems we're seeing from blocks filling up.
Segwitness will make the current bottleneck (block propagation) a little
worse in the short term, because of the extra fraud-proof data. Benefits
well worth the costs.
------------------
I think a barrier to quickly getting consensus might be a fundamental
difference of opinion on this:
"Even without them I believe we’ll be in an acceptable position with
respect to capacity in the near term"
The heaviest users of the Bitcoin network (businesses who generate tens of
thousands of transactions per day on behalf of their customers) would
strongly disgree; the current state of affairs is NOT acceptable to them.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151208/386ffdbc/attachment.html>

2023-06-07 19:41:46 CEST

- reply

📅 Original date posted:2015-09-29
📝 Original message:I keep seeing statements like this:
On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim (Toomim Bros) via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> As a further benefit to hard forks, anybody who is ideologically opposed
> to the change can continue to use the old version successfully, as long as
> there are enough miners to keep the fork alive.
... but I can't see how that would work.
Lets say there is a hard fork, and 5% of miners stubbornly refuse to go
along with the 95% majority (for this thought experiment, it doesn't matter
if the old rules or new rules 'win').
Lets further imagine that some exchange decides to support that 5% and lets
people trade coins from that fork (one of the small altcoin exchanges would
definitely do this if they think they can make a profit).
Now, lets say I've got a lot of pre-fork bitcoin; they're valid on both
sides of the fork. I support the 95% chain (because I'm not insane), but
I'm happy to take people's money if they're stupid enough to give it to me.
So, I do the following:
1) Create a send-to-self transaction on the 95% fork that is ONLY valid on
the 95% fork (maybe I CoinJoin with a post-fork coinbase transaction, or
just move my coins into then out of an exchange's very active hot wallet so
I get coins with a long transaction history on the 95% side of the fork).
2) Transfer those same coins to the 5% exchange and sell them for whatever
price I can get (I don't care how low, it is free money to me-- I will
still own the coins on the 95% fork).
I have to do step (1) to prevent the exchange from taking the
transfer-to-exchange transaction and replaying it on the 95% chain.
I don't see any way of preventing EVERYBODY who has coins on the 95% side
of the fork from doing that. The result would be a huge free-fall in price
as I, and everybody else, rushes to get some free money from anybody
willing to pay us to remain idealogically pure.
Does anybody think something else would happen, and do you think that
ANYBODY would stick to the 5% fork in the face of enormously long
transaction confirmation times (~3 hours), a huge transaction backlog as
lots of the 95%'ers try to sell their coins before the price drops, and a
massive price drop for coins on the 5% fork.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150929/1104ed67/attachment.html>

2023-06-07 19:41:32 CEST

- reply

📅 Original date posted:2015-09-28
📝 Original message:I think three things need to happen:
1) Stop pretending that "everyone must agree to make consensus rule
changes." "Rough consensus" is what we've always gone with, and is good
enough.
2) Mr. Todd (or somebody) needs to write up a risk/benefit security
tradeoff analysis doo-hickey document and publish it. I'm reasonably
confident that the risks to SPV nodes can be mitigated (e.g. by deploying
mempool-only first, before the soft fork rolls out), but as somebody who
has only been moderately paying attention, BETTER COMMUNICATION is needed.
What should SPV wallet authors be doing right now, if anything? Once the
soft fork starts to roll out or activates, what do miners need to be aware
of? SPV wallet authors?
3) I agree CLTV is ready to roll out, that there is rough consensus a soft
fork is a reasonable way to do it, and that it should happen ASAP.
On Mon, Sep 28, 2015 at 6:48 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is *no* consensus on using a soft fork to deploy this feature. It
> will result in the same problems as all the other soft forks - SPV wallets
> will become less reliable during the rollout period. I am against that, as
> it's entirely avoidable.
>
> Make it a hard fork and my objection will be dropped.
>
> Until then, as there is no consensus, you need to do one of two things:
>
> 1) Drop the "everyone must agree to make changes" idea that people here
> like to peddle, and do it loudly, so everyone in the community is correctly
> informed
>
> 2) Do nothing
>
>
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/066eb127/attachment.html>

2023-06-07 19:40:10 CEST

- 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 19:38:18 CEST

- reply

📅 Original date posted:2015-08-27
📝 Original message:Have you talked with anybody at the Bitcoin Foundation about this proposal?
As Chief Scientist of the Foundation, I am strongly opposed to any proposal
that puts the Foundation in a position of centralized authority, so this is
unacceptable: "The Bitcoin Foundation will act as fair play party and
enforcement body to control the misuse of vast financial powers which
bitcoin has."
The idea that a central organization can be trusted to keep secrets secure
is just fundamentally wrong. In the very recent past we have seen
government organizations fail in that task (the NSA, the OPM) and we see
commercial organizations that SHOULD be highly motivated to do a good job
also fail (e.g. the Ashley Madison leak).
Even if it were technically possible, I would be opposed because
decentralization is a bedrock principle of Bitcoin.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/a456d9ea/attachment.html>

2023-06-07 19:38:18 CEST

- reply

📅 Original date posted:2015-08-27
📝 Original message:On Thu, Aug 27, 2015 at 9:39 AM, prabhat <prabhatkr at gmail.com> wrote:
> So where is the solution? What to do?
>
This is a development list; organizations like https://coincenter.org/ work
on high-level policy issues.
Last I heard, competent law enforcement organizations said they were
perfectly capable of tracking down criminals using Bitcoin using
traditional investigative techniques (like infiltrating criminal
organizations or setting up honeypots). Given how many "dark markets" have
either disappeared or been taken down, it seems they are correct.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/57a68710/attachment.html>

2023-06-07 19:33:56 CEST

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Fri, Aug 7, 2015 at 1:33 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>
> On Aug 7, 2015 5:55 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> >
> > I think there are multiple reasons to raise the maximum block size, and
> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
> of the reasons.
>
> What are the other reasons?
>
> > I take the opinion of smart engineers who actually do resource planning
> and have seen what happens when networks run out of capacity very seriously.
>
> When "the network runs out of capacity" (when we hit the limit) do we
> expect anything to happen apart from minimum market fees rising (above
> zero)?
> Obviously any consequences of fees rising are included in this concern.
>
It is frustrating to answer questions that we answered months ago,
especially when I linked to these in response to your recent "increase
advocates say that not increasing the max block size will KILL BITCOIN"
false claim:
http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
https://medium.com/@octskyward/crash-landing-f5cc19908e32
Executive summary: when networks get over-saturated, they become
unreliable. Unreliable is bad.
Unreliable and expensive is extra bad, and that's where we're headed
without an increase to the max block size.
RE: the recent thread about "better deal with that type of thing now rather
than later" : exactly the same argument can be made about changes needed
to support a larger block size-- "better to do that now than to do that
later." I don't think either of those arguments are very convincing.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/fe3f5aaa/attachment-0001.html>

2023-06-07 19:33:31 CEST

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> I guess my question (and perhaps that's what Jorge is after): do you feel
> that blocks should be increased in response to (or for fear of) such a
> scenario.
>
I think there are multiple reasons to raise the maximum block size, and
yes, fear of Bad Things Happening as we run up against the 1MB limit is one
of the reasons.
I take the opinion of smart engineers who actually do resource planning and
have seen what happens when networks run out of capacity very seriously.
And if so, if that is a reason for increase now, won't it be a reason for
> an increase later as well? It is my impression that your answer is yes,
> that this is why you want to increase the block size quickly and
> significantly, but correct me if I'm wrong.
>
Sure, it might be a reason for an increase later. Here's my message to
in-the-future Bitcoin engineers: you should consider raising the maximum
block size if needed and you think the benefits of doing so (like increased
adoption or lower transaction fees or increased reliability) outweigh the
costs (like higher operating costs for full-nodes or the disruption caused
by ANY consensus rule change).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/8f8f55fa/attachment.html>

2023-06-07 19:33:30 CEST

- reply

📅 Original date posted:2015-08-07
📝 Original message:Popping this into it's own thread:
Jorge asked:
> >> 1) If "not now", when will it be a good time to let the "market
> >> minimum fee for miners to mine a transaction" rise above zero?
>
I answered:
> > 1. If you are willing to wait an infinite amount of time, I think the
> > minimum fee will always be zero or very close to zero, so I think it's a
> > silly question.
>
Which Jorge misinterpreted to mean that I think there will always be at
least one miner willing to mine a transaction for free.
That's not what I'm thinking. It is just an observation based on the fact
that blocks are found at random intervals.
Every once in a while the network will get lucky and we'll find six blocks
in ten minutes. If you are deciding what transaction fee to put on your
transaction, and you're willing to wait until that
six-blocks-in-ten-minutes once-a-week event, submit your transaction with a
low fee.
All the higher-fee transactions waiting to be confirmed will get confirmed
in the first five blocks and, if miners don't have any floor on the fee
they'll accept (they will, but lets pretend they won't) then your
very-low-fee transaction will get confirmed.
In the limit, that logic becomes "wait an infinite amount of time, pay zero
fee."
So... I have no idea what the 'market minimum fee' will be, because I have
no idea how long people will be willing to wait, how many times they'll be
willing to retransmit a low-fee transaction that gets evicted from
memory-limited memory pools, or how much memory miners will be willing to
dedicate to storing transactions that won't confirm for a long time because
they're waiting for a flurry of blocks to be found.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/86bfb634/attachment.html>

2023-06-07 19:33:26 CEST

- reply

📅 Original date posted:2015-08-07
📝 Original message:On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> If the incentives for running a node don't weight up against the
> cost/difficulty using a full node yourself for a majority of people in the
> ecosystem, I would argue that there is a problem. As Bitcoin's fundamental
> improvement over other systems is the lack of need for trust, I believe
> that with increased adoption should also come an increased (in absolute
> terms) incentive for people to use a full node. I'm seeing the opposite
> trend, and that is worrying IMHO.
Are you saying that unless the majority of people in the ecosystem decide
to trust nothing but the genesis block hash (decide to run a full node)
there is a problem?
If so, then we do have a fundamental difference of opinion, but I've
misunderstood how you think about trust/centralization/convenience
tradeoffs in the past.
I believe people in the Bitcoin ecosystem will choose different tradeoffs,
and I believe that is OK-- people should be free to make those tradeoffs.
And given that the majority of people in the ecosystem were deciding that
using a centralized service or an SPV-level-security wallet was better even
two or three years ago when blocks were tiny (I'd have to go back and dig
up number-of-full-nodes and number-of-active-wallets at the big web-wallet
providers, but I bet there were an order of magnitude more people using
centralized services than running full nodes even back then), I firmly
believe that block size has very little to do with the decision to run a
full node or not.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/1aaa747d/attachment.html>

2023-06-07 19:33:21 CEST

- reply

📅 Original date posted:2015-08-05
📝 Original message:On Wed, Aug 5, 2015 at 7:24 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Miner A is able to process 100 M tx/block while miner B is only able
> to process 10 M tx/block.
>
> Will miner B be able to maintain itself competitive against miner B?
>
> The answer is: it depends on the consensus maximum block size.
>
No, it depends on all of the variables that go into the mining
profitability equation.
Does miner B have access to cheaper electricity than miner A?
Access to more advanced mining hardware, sooner?
Ability to use excess heat generated from mining productively?
Access to inexpensive labor to oversee their operations?
Access to inexpensive capital to finance investment in hardware?
The number of fee-paying transactions a miner can profitably include in
their blocks will certainly eventually be part of that equation (it is
insignificant today), and that's fantastic-- we WANT miners to include lots
of transactions in their blocks.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/92fa9b81/attachment.html>

2023-06-07 19:32:36 CEST

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 1:15 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> So I reformulate the question:
>
> 1) If "not now", when will it be a good time to let the "market
> minimum fee for miners to mine a transaction" rise above zero?
Two answers:
1. If you are willing to wait an infinite amount of time, I think the
minimum fee will always be zero or very close to zero, so I think it's a
silly question.
2. The "market minimum fee" should be determined by the market. It should
not be up to us to decide "when is a good time."
> 2) Do you have any criterion (automatic or not) that can result in you
> saying "no, this is too much" for any proposed size?
>
Sure, if keeping up with transaction volume requires a cluster of computers
or more than "pretty good" broadband bandwidth I think that's too far.
That's where original 20MB limit comes from, otherwise I'd have proposed a
much higher limit.
> Would you agree that blocksize increase proposals should have such a
> criterion/test?
Although I've been very clear with my criterion, no, I don't think all
blocksize increase proposals should have to justify "why this size" or "why
this rate of increase." Part of my frustration with this whole debate is
we're talking about a sanity-check upper-limit; as long as it doesn't open
up some terrible new DoS possibility I don't think it really matters much
what the exact number is.
> Regardless of the history of the consensus rule (which I couldn't care
> less about), I believe the only function that the maximum block size
> rule currently serves is limiting centralization.
> Since you deny that function, do you think the (artificial) consensus
> rule is currently serving any other purpose that I'm missing?
>
It prevents trivial denial-of-service attacks (e.g. I promise to send you a
1 Terabyte block, then fill up your memory or disk...).
And please read what I wrote: I said that the block limit has LITTLE effect
on MINING centralization. Not "no effect on any type of centralization."
If the limit was removed entirely, it is certainly possible we'd end up
with very few organizations (and perhaps zero individuals) running full
nodes.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/1dcf6602/attachment.html>

2023-06-07 19:32:35 CEST

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Thu, Aug 6, 2015 at 11:25 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> 1) If "not now" when will it be a good time to let fees rise above zero?
>
Fees are already above zero. See
http://gavinandresen.ninja/the-myth-of-not-full-blocks
> 2) When will you consider a size to be too dangerous for centralization?
> In other words, why 20 GB would have been safe but 21 GB wouldn't have
> been (or the respective maximums and respective +1 for each block
> increase proposal)?
>
http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
3) Does this mean that you would be in favor of completely removing
> the consensus rule that limits mining centralization by imposing an
> artificial (like any other consensus rule) block size maximum?
>
I don't believe that the maximum block size has much at all to do with
mining centralization, so I don't accept the premise of the question.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/a9b951db/attachment-0001.html>

2023-06-07 19:32:32 CEST

- reply

📅 Original date posted:2015-08-06
📝 Original message:On Wed, Aug 5, 2015 at 9:26 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is a much more reasonable position. I wish this had been starting
> point of this discussion instead of "the block size limit must be
> increased as soon as possible or bitcoin will fail".
>
It REALLY doesn't help the debate when you say patently false statements
like that.
My first blog post on this issue is here:
http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent
... and I NEVER say "Bitcoin will fail". I say:
"If the number of transactions waiting gets large enough, the end result
will be an over-saturated network, busy doing nothing productive. I don’t
think that is likely– it is more likely people just stop using Bitcoin
because transaction confirmation becomes increasingly unreliable."
Mike sketched out the worst-case here:
https://medium.com/@octskyward/crash-landing-f5cc19908e32
... and concludes:
"I believe there are no situations in which Bitcoin can enter an overload
situation and come out with its reputation and user base intact. Both would
suffer heavily and as Bitcoin is the founder of the cryptocurrency concept,
the idea itself would inevitably suffer some kind of negative
repercussions."
------------
So please stop with the over-the-top claims about what "the other side"
believe, there are enough of those (on both sides of the debate) on reddit.
I'd really like to focus on how to move forward, and how best to resolve
difficult questions like this in the future.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/d5606a8f/attachment.html>

2023-06-07 19:32:27 CEST

- reply

📅 Original date posted:2015-08-04
📝 Original message:On Tue, Aug 4, 2015 at 7:27 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I would say that things already demonstrately got terrible. The mining
> landscape is very centralized, with apparently a majority depending on
> agreements to trust each other's announced blocks without validation.
>
And that is a problem... why?
As far as I can tell, nobody besides miners running old and/or buggy
software lost money due to outsourced mining validation (please correct me
if I'm wrong-- I'm looking forward to Greg's post-mortem). The operators of
bitcoin.org seem to have freaked out and pushed the panic button (with dire
warnings of not trusting transactions until 20 confirmations), but theymos
was well known for using an old, patched version of Core for
blockexplorer.com so maybe that's not surprising.
As Bitcoin grows, pieces of the ecosystem will specialize. Satoshi's
original code did everything: hashing, block assembly, wallet, consensus,
network. That is changing, and that is OK.
I understand there are parts of the ecosystem you'd rather not see
specialized, like transaction selection / block assembly or validation. I
see it as a natural maturation. The only danger I see is if some unnatural
barriers to competition spring up.
> Full node count is at its historically lowest value in years, and
outsourcing of full validation keeps growing.
Both side effects of increasing specialization, in my opinion. Many
companies quite reasonably would rather hire somebody who specializes in
running nodes, keeping keys secure, etc rather than develop that expertise
themselves.
Again, not a problem UNLESS some unnatural barriers to competition spring
up.
> I believe that if the above would have happened overnight, people would
> have cried wolf. But somehow it happened slow enough, and "things kept
> working".
>
> I don't think that this is a good criterion. Bitcoin can "work" with
> gigabyte blocks today, if everyone uses the same few blockchain validation
> services, the same few online wallets, and mining is done by a cartel that
> only allows joining after signing a contract so they can sue you if you
> create an invalid block. Do you think people will then agree that "things
> got demonstratebly worse"?
>
> Don't turn Bitcoin into something uninteresting, please.
>
> Why is what you, personally, find interesting relevant?
I understand you want to build an extremely decentralized system, where
everybody participating trusts nothing except the genesis block hash.
I think it is more interesting to build a system that works for hundreds of
millions of people, with no central point of control and the opportunity
for ANYBODY to participate at any level. Permission-less innovation is what
I find interesting.
And I think the current "demonstrably terrible" Bitcoin system is still
INCREDIBLY interesting.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150804/10def7f8/attachment-0001.html>

2023-06-07 19:31:36 CEST

- reply

2023-06-07 19:31:30 CEST

- reply

2023-06-07 19:31:29 CEST

- reply

2023-06-07 19:31:27 CEST

- reply

2023-06-07 17:46:00 CEST

- reply

2023-06-07 17:45:39 CEST

- reply

2023-06-07 17:45:39 CEST

- reply

2023-06-07 17:45:35 CEST

- reply

2023-06-07 17:45:20 CEST

- reply

📅 Original date posted:2015-08-09
📝 Original message:While we're on the subject of payment hubs / lightning network...
I'd love to see somebody write up a higher-level description of what the
user experience is like, what communication happens underneath, and what
new pieces of infrastructure need to get built to make it all work.
A use-case to start with:
A customer starts with eleven on-chain bitcoin. They want to pay for a nice
cup of tea. Walk me through what happens before/during/after the
transaction, assuming I have a lightning-enabled wallet on my iPhone and
the tea shop has a lightning-enabled cash register.
Assume neither the customer nor the tea shop are technically sophisticated
-- assume the customer is using an SPV wallet and the tea shop is using a
service similar to Bitpay.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/9dcc4cd8/attachment.html>

2023-06-07 17:44:54 CEST

- reply

2023-06-07 17:44:53 CEST

- reply

2023-06-07 17:44:52 CEST

- 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 17:44:51 CEST

- reply

2023-06-07 17:43:48 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> Let's scale the block size gradually over time, according to technological
> growth.
Yes, lets do that-- that is EXACTLY what BIP101 intends to do.
With the added belt&suspenders reality check of miners, who won't produce
blocks too big for whatever technology they're using.
-------
So what do you think the scalability road map should look like? Should we
wait to hard fork until Blockstream Elements is ready for deploying on the
main network, and then have One Grand Hardfork that introduces all the
scalability work you guys have been working on (like Segregated Witness and
Lightning)?
Or is the plan to avoid controversy by people voluntarily moving their
bitcoin to a sidechain where all this scaling-up innovation happens?
No plan for how to scale up is the worst of all possible worlds, and the
lack of a direction or plan(s) is my main objection to the current status
quo.
And any plan that requires inventing brand-new technology is going to be
riskier than scaling up what we already have and understand, which is why I
think it is worthwhile to scale up what we have IN ADDITION TO working on
great projects like Segregated Witness and Lightning.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150730/d7fc3a50/attachment.html>

2023-06-07 17:42:54 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> Mainstream usage of cryptocurrency will be enabled primarily by direct
> party-to-party contract negotiation…with the use of the blockchain
> primarily as a dispute resolution mechanism. The block size isn’t about
> scaling but about supply and demand of finite resources. As demand for
> block space increases, we can address it either by increasing computational
> resources (block size) or by increasing fees. But to do the former we need
> a way to offset the increase in cost by making sure that those who
> contribute said resources have incentive to do so.
There are so many things wrong with this paragraph I just can't let it
slide.
"Mainstream usage will be enabled primarily by..." Maybe. Maybe not, we
don't know what use case(s) will primarily take cryptocurrency mainstream.
I believe it is a big mistake to pick one and bet "THIS is going to be the
winner".
"we can address it either by... or..." False dichotomy. There are lots of
things we can do to decrease costs, and a lot of things have ALREADY been
done (e.g. running a pruned full node). I HATE the "it must be this or
that" "us or them" attitude, it fosters unproductive bickering and
negativity.
(and yes, I'm human, I'm sure you can find instances in the recent past
where I did it, too... mea culpa)
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/76ddbef2/attachment.html>

2023-06-07 17:42:51 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
> > they will simply advance the front and start another battle, because
> > their true hidden faction is the "not ever side". Please, Jeff, Gavin,
> > Mike, show me that I'm wrong on this point. Please, answer my question
> > this time. If "not now", then when?
>
> Bitcoin has all the hash power. The merkle root has effectively
> infinite capacity. We should be asking HOW to scale the supporting
> information propagation system appropriately, not WHEN to limit the
> capacity of the primary time-stamping machine.
>
> We haven't tried yet. I can't answer for the people you asked, but
> personally I haven't thought much about when we should declare failure.
Yes! Lets plan for success!
I'd really like to move from "IMPOSSIBLE because... (electrum hasn't been
optimized
(by the way: you should run on SSDs, LevelDB isn't designed for spinning
disks),
what if the network is attacked? (attacked HOW???), current p2p network is
using
the simplest, stupidest possible block propagation algorithm...)"
... to "lets work together and work through the problems and scale it up."
I'm frankly tired of all the negativity here; so tired of it I've decided
to mostly ignore
all the debate for a while, not respond to misinformation I see being spread
(like "miners have some incentive to create slow-to-propagate blocks"),
work with people like Tom and Mike who have a 'lets get it done' attitude,
and
focus on what it will take to scale up.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/9a8c53b6/attachment.html>

2023-06-07 17:42:41 CEST

- reply

📅 Original date posted:2015-07-23
📝 Original message:On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Mitigate a potential CPU exhaustion denial-of-service attack by limiting
> > the maximum size of a transaction included in a block.
>
> This seems like a fairly indirect approach. The resource being watched
> for is not the size (otherwise two transactions for 200k would be
> strictly worse than one 200k transactions) but the potential of N^2
> costs related to repeated hashing in checksig; which this ignores.
>
To get a feeling for the implementation complexity / correctness tradeoff,
I implemented changes to Core to count exactly how many signature operations
are performed and how many bytes are hashed to compute sighashes:
https://github.com/gavinandresen/bitcoin-git/commit/08ecd6f67d977271faa92bc1890b8f94b15c2792
I haven't benchmarked how much keeping track of the counts affects
performance (but I expect
it to be minimal compared to ECDSA signature validation, accessing inputs
from the UTXO, etc).
I like the idea of a consensus rule that directly addresses the attack--
e.g. "validating
a transaction must not require more than X megabytes hashed to compute
signature hashes."
(or: "validating a block must not require more than X megabytes hashed..."
which is
more symmetric with the current "maximum number of sigops allowed per
block")
Thinking about this and looking at block 364,292, I think I see a simple
optimization that would
speed up validation for transactions with lots of inputs: use
SIGHASH_ANYONECANPAY
for all of the inputs instead of SIGHASH_ALL.
(which would make the transaction malleable-- if that's a concern, then
make one of the inputs
SIGHASH_ALL and the rest SIGHASH_ANYONECANPAY-- I think this is a change
that
should be made to Core and other wallets should make).
---
I'd like to hear from maintainers of other full implementations: how hard
would it be for you
to keep track of the number of bytes hashed to validate a transaction or
block, and use
it as a consensus rule?
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/f0db9377/attachment.html>

2023-06-07 17:42:40 CEST

- reply

📅 Original date posted:2015-07-21
📝 Original message:On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Mitigate a potential CPU exhaustion denial-of-service attack by limiting
> > the maximum size of a transaction included in a block.
>
> This seems like a fairly indirect approach. The resource being watched
> for is not the size (otherwise two transactions for 200k would be
> strictly worse than one 200k transactions) but the potential of N^2
> costs related to repeated hashing in checksig; which this ignores.
>
Yes. The tradeoff is implementation complexity: it is trivial to check
transaction size,
not as trivial to count signature operations, because
number-of-bytes-in-transaction
doesn't require any context.
But I would REALLY hate myself if in ten years a future version of me was
struggling to
get consensus to move away from some stupid 100,000 byte transaction size
limit
I imposed to mitigate a potential DoS attack.
So I agree, a limit on sigops is the right way to go. And if that is being
changed,
might as well accurately count exactly how many sigops a transaction
actually
requires to be validated...
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150721/258a0bc6/attachment.html>

2023-06-07 17:42:39 CEST

- reply

📅 Original date posted:2015-07-20
📝 Original message:On Mon, Jul 20, 2015 at 3:43 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This could render transactions with a locktime in the future as
> unspendable.
>
> It is pretty low probability that someone has created a >100kB locked
> transaction though.
>
> It violates the principle that no fork should render someone's coins
> unspendable.
>
Mmmm.... you'd have to:
a) Have lost or thrown away the keys to the unspent transaction outputs
b) Have created a locktime'd transaction with a lock time after the
BIP100/101 switchover times
that is more than 100,000 bytes big
c) Have some special relationship with a miner that you trust to still be
around when the transaction
unlocks that would mine the bigger-than-standard transaction for you.
I don't think adding extra complexity to consensus-critical code to support
such an incredibly unlikely
scenario is the right decision here. I think it is more likely that the
extra complexity would trigger a bug
that causes a loss of bitcoin greater than the amount of bitcoin tied up in
locktime'ed transactions
(because I think there are approximately zero BTC tied up in >100K
locktime'ed transactions).
RE: limit size of transaction+parents: Feature creep, belongs in another
BIP in my opinion. This one
is focused on fixing CVE-2013-2292
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/05a16bf2/attachment.html>

2023-06-07 17:42:39 CEST

- reply

📅 Original date posted:2015-07-20
📝 Original message:Draft BIP to prevent a potential CPU exhaustion attack if a significantly
larger maximum blocksize is adopted:
Title: Limit maximum transaction size
Author: Gavin Andresen <gavinandresen at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-07-17
==Abstract==
Mitigate a potential CPU exhaustion denial-of-service attack by limiting
the maximum size of a transaction included in a block.
==Motivation==
Sergio Demian Lerner reported that a maliciously constructed block could
take several minutes to validate, due to the way signature hashes are
computed for OP_CHECKSIG/OP_CHECKMULTISIG ([[
https://bitcointalk.org/?topic=140078|CVE-2013-2292]]).
Each signature validation can require hashing most of the transaction's
bytes, resulting in O(s*b) scaling (where n is the number of signature
operations and m is the number of bytes in the transaction, excluding
signatures). If there are no limits on n or m the result is O(n^2) scaling.
This potential attack was mitigated by changing the default relay and
mining policies so transactions larger than 100,000 bytes were not
relayed across the network or included in blocks. However, a miner
not following the default policy could choose to include a
transaction that filled the entire one-megaybte block and took
a long time to validate.
==Specification==
After deployment, the maximum serialized size of a transaction allowed
in a block shall be 100,000 bytes.
==Compatibility==
This change should be compatible with existing transaction-creation
software,
because transactions larger than 100,000 bytes have been considered
"non-standard"
(they are not relayed or mined by default) for years.
Software that assembles transactions into blocks and that validates blocks
must be
updated to reject oversize transactions.
==Deployment==
This change will be deployed with BIP 100 or BIP 101.
==Discussion==
Alternatives to this BIP:
1. A new consensus rule that limits the number of signature operations in a
single transaction instead of limiting size. This might be more compatible
with
future opcodes that require larger-than-100,000-byte transactions, although
any such future opcodes would likely require changes to the Script
validation
rules anyway (e.g. the 520-byte limit on data items).
2. Fix the SIG opcodes so they don't re-hash variations of the
transaction's data.
This is the "most correct" solution, but would require updating every
piece of transaction-creating and transaction-validating software to change
how
they compute the signature hash.
==References==
[[https://bitcointalk.org/?topic=140078|CVE-2013-2292]]: Sergio Demian
Lerner's original report
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150720/04cdfad9/attachment-0001.html>

2023-06-07 17:40:56 CEST

- 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 17:40:55 CEST

- 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 17:40:29 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:I completely agree with Pieter: usage will grow to fill whatever maximum
block size the miners decide to allow (or whatever maximum block size is
imposed by minimum transaction fees or a hard cap on block size).
I am not scared by increased usage, though: more usage and adoption means
more investment, more smart engineers, and more people with incentives to
solve whatever scaling problems crop up. All of that makes Bitcoin stronger.
And I don't feel like this process has been hurried: I've been working on
this (thinking, testing, simulating, talking, writing code, talking to key
people and companies) almost exclusively since late last year. In my humble
opinion, BIP 101 is a good compromise between "no limit, let the miners
decide" and "lower the max size so a raspberry pi running on a 56K modem
can be a full node."
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/6143a1be/attachment.html>

2023-06-07 17:39:51 CEST

- reply

📅 Original date posted:2015-06-24
📝 Original message:This BIP has been assigned number 101 by the BIP editor. I plan on filling
in the TODOs and will submit it as a pull request to the BIP repository
today.
> Title: Increase Maximum Block Size
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/b7442be1/attachment.html>

2023-06-07 17:39:46 CEST

- reply

📅 Original date posted:2015-06-23
📝 Original message:On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete at petertodd.org> wrote:
> Pieter Wuille showed with simulations that miners with bad connectivity
> are negatively affected by other miners creating larger blocks.
>
... but the effect is only significant if they have an absurdly
low-bandwidth connection and do NOTHING to work around it (like rent a
server on the other side of the bandwidth bottleneck and write some code to
make sure you're creating blocks that will propagate quickly on both sides
of the bottleneck).
Why do you think connectivity is a centralizing effect? It is just one
factor in the profitability-of-mining equation. A location with bad
connectivity (the US, maybe) but 10% cheaper electricity might be just as
good as one with great connectivity but more expensive electricity.
Having lots of variables in the profitability equation is a decentralizing
force, it means there is very likely to be several different places in the
world / on the net where mining is equally profitable.
> ... until transaction fees become significant. But by the time that
> > happens, protocol optimizations of block propagation will make the block
> > size an insignificant term in the "how profitable is it to mine in THIS
> > particular place on the Internet / part of the world" equation.
>
> These block propagation improvements are both already implemented (Matt
> Corallo's relay network, p2pool) and require co-operation.
>
Long term the p2p protocol will evolve to incorporate those optimizations,
so will require no co-operation.
> For instance, notice the recent full-RBF debate where Coinbase said
> they'd consider getting contracts directly with miners to get
> transactions they desired mined even when they otherwise would not be
> due to double-spends. This is one of many scenarios where block
> propagation improvements fail. Thus for a safety engineering
> analysis we need to talk about worst-case scenarioss
> Equally, I don't see any analysis from anyone of that % of non-optimized
> transactions need to fail for what kind of centralizing pressure.
>
> In any case, this ponts to the need for your proposal to explictly talk
> about what kind of resources are needed by miners for what kind of
> profitability, including the case where other miners are sabotaging
> their profitability.
>
Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?
I have written quite a lot about the kind of resources needed to run a full
node, and have asked you, specifically, several times "how much do you
think is too much" and received no answer.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150623/a0f02566/attachment.html>

2023-06-07 17:39:45 CEST

- reply

📅 Original date posted:2015-06-23
📝 Original message:On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> > ==Rationale==
> >
> > The initial size of 8,000,000 bytes was chosen after testing the current
> > reference implementation code with larger block sizes and receiving
> > feedback from miners stuck behind bandwidth-constrained networks (in
> > particular, Chinese miners behind the Great Firewall of China).
> >
> > The doubling interval was chosen based on long-term growth trends for CPU
> > power, storage, and Internet bandwidth. The 20-year limit was chosen
> > because exponential growth cannot continue forever.
>
> Wladimir noted that 'The original presented intention of block size
> increase was a one-time "scaling" to grant time for more decentralizing
> solutions to develop'
>
> Comments?
>
Consensus is that this process is too painful to go through once a year. I
agree.
If you disagree and would like to see a Blocksize Council meet once a year
to issue a decree on what the maximum block size shall be for the next
year, then propose a process for who gets to sit on the Council and how
their decrees are enforced.....
>
> In particular, if bandwidth scaling doesn't go according to your plan,
> e.g. the exponential exponent is too large, perhaps due to technological
> growth not keeping pace, or the political realities of actual bandwidth
> deployment making theoretical technological growth irrelevant, what
> mechanism will prevent centralization? (if any)
Simulations show that:
Latency/bandwidth matter for miners. Low latency, high bandwidth is
better. However, miners with bad connectivity can simply create smaller
blocks...
... until transaction fees become significant. But by the time that
happens, protocol optimizations of block propagation will make the block
size an insignificant term in the "how profitable is it to mine in THIS
particular place on the Internet / part of the world" equation.
(Reference:
https://www.mail-archive.com/[email protected]/msg08224.html
)
So: for the immediate future, there is no problem. And in the long term,
there is no problem.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150623/2e36743c/attachment.html>

2023-06-07 17:39:43 CEST

- reply

📅 Original date posted:2015-06-22
📝 Original message:On Mon, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <kalle at rosenbaum.se> wrote:
> * In the specification, you refer to "t_start". I guess you mean
> "time_start"?
>
Thanks, I'll fix.
> * Miners can, especially when close to a block doubling or shortly
> after activation, to some extent manipulate max block size by
> manipulating the time stamp in the block header within valid limits.
> According to the pseudo code in the specification, the first and a
> handful of subsequent blocks after activation could actually have
> negative max block sizes due to this (depending on how you define the
> % operator of the pseudo code). I haven't checked the reference
> implementation, but I do think that the specification section should
> explicitly handle this.
>
Excellent point. That could only happen if activation happened on 11 Jan
2016; instead of complicating the code and spec with another condition, I
think it would be better to specify that the activation date is the later
of the miner supermajority and 11 Jan, with the first big block two weeks
later.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/adbbace4/attachment-0001.html>

2023-06-07 17:39:43 CEST

- reply

📅 Original date posted:2015-06-22
📝 Original message:On Mon, Jun 22, 2015 at 4:46 PM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> Excellent point. That could only happen if activation happened on 11 Jan
> 2016; instead of complicating the code and spec with another condition, I
> think it would be better to specify that the activation date is the later
> of the miner supermajority and 11 Jan, with the first big block two weeks
> later.
>
.... I take that back, I'm wrong and Tier is correct: if activation
happened right at midnight 11 Jan 2016 and the next block's timestamp was
before midnight, that next block would just be limited to 1MB in size.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/385adf94/attachment.html>

2023-06-07 17:39:41 CEST

- reply

📅 Original date posted:2015-06-22
📝 Original message:As Tier says, the current network message limit is 2MB (reduced from 32MB
in the... uhh, 0.10? release).
I think keeping the consensus rules distinct from limitations of the p2p
network makes sense-- we are already seeing different protocols for
announcing transactions and blocks (Matt's relay network is, essentially, a
separate protocol). I could write a separate BIP describing the change to
the p2p network protocol, but that feels like busy-work to me.
RE: setting the DoS size check farther than 2 hours into the future: the
block, itself, will be rejected if it has a timestamp more than 2 hours in
the future. That is already a consensus rule.
RE: what happens if block timestamps are not in chronological order:
Nothing.
The activation counting happens in block-height-order, so timestamps on all
but the "activating" block are all that matters.
Code that looks for the activation condition must properly handle re-orgs
around the activation block, of course.
RE: testnet parameters: big blocks can be tested in -regtest mode with
arbitrary timestamps in the past or future. Testing maximum-8MB-blocks
mined "in the past" on testnet will just result in a testnet that is even
more useless for ordinary testing of products or services being developed
-- part of what makes testnet useful for things like testing transaction
creation code is it syncs quickly.
That said, I have thought for a while now somebody should take a fresh look
at the testnet, talk to people who might be customers for a reset testnet
or testnets (we probably want separate testnets for people testing mining
and people testing transaction creation, for example), and implement
testnets designed to make it easy to test what people need testing.
RE: scraping together money to run a few hundred full-load full-nodes:
hardware is cheap, people are expensive. You seem to expect that companies
will be willing to invest the time of their people testing something that
may never happen (8MB of transactions every ten minutes). Maybe they would,
but most companies are very busy trying to stay in business by attracting
customers to their products or services. Scaling up is a good problem to
have, and, in my experience, the way to be successful scaling up is to
tackle problems as they occur.
Because there's no use spending a bunch of person-hours hyper-optimizing
for 8MB blocks stored in MySQL if a year from now you find out your
customers don't actually want your product or MySQL 5.11 comes out and is
100 times faster....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/72da223e/attachment-0001.html>

2023-06-07 17:39:40 CEST

- reply

📅 Original date posted:2015-06-22
📝 Original message:On Mon, Jun 22, 2015 at 2:33 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
> The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than
> the standard 1000. Given that the threshold is lower than is normal for
> hard-forks, noise on the measurement could cause an activation even if less
> than 75% of miners agree. It also means that the vote has to be sustained
> for longer and inherently gives a longer notice period.
>
9,000 of last 12,000 blocks is OK with me (I don't think scanning through
the last 12,000 block headers every new block will cause performance
problems, but I'd want to benchmark it to be absolutely sure).
> Two weeks seems low for an upgrade warning. I guess there would be an
> alert on the network.
>
Do old nodes detect an upgrade by version numbers? If that was headers
> only, then they could detect that large blocks have activated.
>
Bitcoin Core will alert when automatically when 51% of blocks have a
version it doesn't understand.
It will also alert automatically if it detects a chain with more work that
it doesn't consider valid for some reason. And 0.11 contains code that
alerts if you're on a chain that is being mined really slowly.
Have you considered a "fail" condition? For example, if 750 of the last
> 1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the
> miners. Alternatively, if the rule doesn't activate by 11th Jan 2017, then
> it is disabled.
>
I like the fail-if-not-activated-by idea. Not so crazy about the vote idea
(what if miners set bits 3 AND 4 ?).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/9cf73348/attachment.html>

2023-06-07 17:39:39 CEST

- reply

📅 Original date posted:2015-06-22
📝 Original message:I promised to write a BIP after I'd implemented
increase-the-maximum-block-size code, so here it is. It also lives at:
https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
I don't expect any proposal to please everybody; there are unavoidable
tradeoffs to increasing the maximum block size. I prioritize implementation
simplicity -- it is hard to write consensus-critical code, so simpler is
better.
BIP: ??
Title: Increase Maximum Block Size
Author: Gavin Andresen <gavinandresen at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-06-22
==Abstract==
This BIP proposes replacing the fixed one megabyte maximum block size with
a maximum size that grows over time at a predictable rate.
==Motivation==
Transaction volume on the Bitcoin network has been growing, and will soon
reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte
maximum block size. Increasing the maximum size reduces the impact of that
limit on Bitcoin adoption and growth.
==Specification==
After deployment on the network (see the Deployment section for details),
the maximum allowed size of a block on the main network shall be calculated
based on the timestamp in the block header.
The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11
00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000
seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC
(timestamp 2083190400). The maximum size of blocks in between doublings
will increase linearly based on the block's timestamp. The maximum size of
blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
Expressed in pseudo-code, using integer math:
function max_block_size(block_timestamp):
time_start = 1452470400
time_double = 60*60*24*365*2
size_start = 8000000
if block_timestamp >= time_start+time_double*10
return size_start * 2^10
// Piecewise-linear-between-doublings growth:
time_delta = block_timestamp - t_start
doublings = time_delta / time_double
remainder = time_delta % time_double
interpolate = (size_start * 2^doublings * remainder) / time_double
max_size = size_start * 2^doublings + interpolate
return max_size
==Deployment==
Deployment shall be controlled by hash-power supermajority vote (similar to
the technique used in BIP34), but the earliest possible activation time is
2016-01-11 00:00:00 UTC.
Activation is achieved when 750 of 1,000 consecutive blocks in the best
chain have a version number with bits 3 and 14 set (0x20000004 in hex). The
activation time will be the timestamp of the 750'th block plus a two week
(1,209,600 second) grace period to give any remaining miners or services
time to upgrade to support larger blocks. If a supermajority is achieved
more than two weeks before 2016-01-11 00:00:00 UTC, the activation time
will be 2016-01-11 00:00:00 UTC.
Block version numbers are used only for activation; once activation is
achieved, the maximum block size shall be as described in the specification
section, regardless of the version number of the block.
==Rationale==
The initial size of 8,000,000 bytes was chosen after testing the current
reference implementation code with larger block sizes and receiving
feedback from miners stuck behind bandwidth-constrained networks (in
particular, Chinese miners behind the Great Firewall of China).
The doubling interval was chosen based on long-term growth trends for CPU
power, storage, and Internet bandwidth. The 20-year limit was chosen
because exponential growth cannot continue forever.
Calculations are based on timestamps and not blockchain height because a
timestamp is part of every block's header. This allows implementations to
know a block's maximum size after they have downloaded it's header, but
before downloading any transactions.
The deployment plan is taken from Jeff Garzik's proposed BIP100 block size
increase, and is designed to give miners, merchants, and
full-node-running-end-users sufficient time to upgrade to software that
supports bigger blocks. A 75% supermajority was chosen so that one large
mining pool does not have effective veto power over a blocksize increase.
The version number scheme is designed to be compatible with Pieter's
Wuille's proposed "Version bits" BIP.
TODO: summarize objections/arguments from
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
TODO: describe other proposals and their advantages/disadvantages over this
proposal.
==Compatibility==
This is a hard-forking change to the Bitcoin protocol; anybody running code
that fully validates blocks must upgrade before the activation time or they
will risk rejecting a chain containing larger-than-one-megabyte blocks.
Simplified Payment Verification software is not affected, unless it makes
assumptions about the maximum depth of a transaction's merkle branch based
on the minimum size of a transaction and the maximum block size.
==Implementation==
https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/15ca6d1f/attachment-0001.html>

2023-06-07 17:38:55 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:I just sent the following email to F2Pool:
I was disappointed to see Peter Todd claiming that you have (or will?) run
his replace-by-fee patch.
I strongly encourage you to wait until most wallet software supports
replace-by-fee before doing that, because until that happens replace-by-fee
just makes it easier to steal from bitcoin-accepting merchants.
I will tell you the same thing about 8MB blocks: until most merchants
support bigger blocks I will strongly encourage you keep creating
less-than-1MB blocks. If we want Bitcoin to succeed more quickly, we should
all be thinking about what is good for the whole system: users, merchants,
exchanges and miners.
As always, if you have questions or concerns feel free to email me.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/230672e9/attachment.html>

2023-06-07 17:38:32 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos at gmail.com> wrote:
> Let me take a pass at explaining how I see this.
>
> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
> the decider but he works under a process that is well understood by
> developers on the project in which he takes under reasonable consideration
> other technical opinions and prefers to have clear agreement among them.
>
Yes.
2) Changes to the consensus rules: As others have said, this isn't anyone's
> decision for anyone else.
>
Yes.
> It's up to each individual user as to what code they run and what rules
> they enforce. So then why is everyone so up in arms about what Mike and
> Gavin are proposing if everyone is free to decide for themselves? I
> believe that each individual user should adhere to the principle that there
> should be no changes to the consensus rules unless there is near complete
> agreement among the entire community, users, developers, businesses miners
> etc. It is not necessary to define complete agreement exactly because every
> individual person decides for themselves. I believe that this is what
> gives Bitcoin, or really any money, its value and what makes it work, that
> we all agree on exactly what it is. So I believe that it is misleading and
> bad for Bitcoin to tell users and business that you can just choose without
> concern for everyone else which code you'll run and we'll see which one
> wins out. No. You should run the old consensus rules (on any codebase you
> want) until you believe that pretty much everyone has consented to a change
> in the rules. It is your choice, but I think a lot of people that have
> spent time thinking about the philosophy of consensus systems believe that
> when the users of the system have this principle in mind, it's what will
> make the system work best.
>
I don't think I agree with "pretty much everybody", because status-quo bias
is a very powerful thing. Any change that disrupts the way they've been
doing things will generate significant resistance -- there will be 10 or
20% of any population that will take a position of "too busy to think about
this, everything seems to be working great, I don't like change, NO to any
change."
For example, I think some of the resistance for bigger blocks is coming
from contributors who are worried they, personally, won't be able to keep
up with a bigger blockchain. They might not be able to run full nodes from
their home network connections (or might not be able to run a full node AND
stream Game of Thrones), on their old raspberry pi machines.
The criteria for me is "clear super-majority of the people and businesses
who are using Bitcoin the most," and I think that criteria is met.
> 3) Code changes to Core that do change consensus: I think that Wladimir,
> all the other committers besides Gavin, and almost all of the other
> developers on Core would defer to #2 above and wait for its outcome to be
> clear before considering such a code change.
>
Yes, that's the way it has mostly been working. But even before stepping
down as Lead I was starting to wonder if there are ANY successful open
source projects that didn't have either a Benevolent Dictator or some clear
voting process to resolve disputes that cannot be settled with "rough
consensus."
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/cadd74c6/attachment.html>

2023-06-07 17:37:23 CEST

- 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 17:36:12 CEST

- reply

📅 Original date posted:2015-06-01
📝 Original message:RE: going to the public:
I started pushing privately for SOMETHING, ANYTHING to be done, or at the
very least for there to be some coherent plan besides "wait and see" back
in February.
As for it being unhealthy for me to write the code that I think should be
written and asking people to run it:
Ok. What would you suggest I do? I believe scaling up is the number one
priority right now. I think core devs SHOULD be taking time to solve it,
because I think the uncertainty of how it will be solved (or if it will be
solved) is bad for Bitcoin.
I think working on things like fixing transaction malleability is great...
but the reason to work on that is to enable smart contracts and all sorts
of other interesting new uses of the blockchain. But if we're stuck with
1MB blocks then there won't be room for all of those interesting new uses
on the blockchain.
Others disagree, and have the advantage of status-quo : if nothing is done,
they get what they want.
Based on some comments I've seen, I think there is also concern that "my
own personal network/computer connection might not be able to handle more
transaction volume." That is NOT a good reason to limit scalability, but I
think it is clouding the judgement of many of the core contributors who
started contributing as a spare-time hobby from their homes (where maybe
they have crappy DSL connections).
RE: decentralization:
I think this is a red-herring. I'll quote something I said on reddit
yesterday:
"I don't believe a 20MB max size will increase centralization to any
significant degree.
See
http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
and http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
And I think we will have a lot LESS centralization of payments via services
like Coinbase (or hubs in some future StrawPay/Lightning network) if the
bitcoin network can directly handle more payment volume.
The centralization trade-offs seems very clear to me, and I think the "big
blocks mean more centralized" arguments are either just wrong or are
exaggerated or ignore the tradeoff with payment centralization (I think
that is a lot more important for privacy and censorship resistance)."
RE: incentives for off-chain solutions:
I'll quote myself again from
http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea :
"The “layer 2” services that are being built on top of the blockchain are
absolutely necessary to get nearly instant real-time payments,
micropayments and high volume machine-to-machine payments, to pick just
three examples. The ten-minute settlement time of blocks on the network is
not fast enough for those problems, and it will be the ten minute block
interval that drives development of those off-chain innovations more than
the total number of transactions supported."
On Mon, Jun 1, 2015 at 8:45 AM, Jérôme Legoupil <jjlegoupil at gmail.com>
wrote:
> If during the "1MB bumpy period" something goes wrong, consensus among the
> community would be reached easily if necessary.
>
That is the problem: this will be a "frog in boiling water" problem. I
believe there will be no sudden crisis-- instead, transactions will just
get increasingly unreliable and expensive, driving more and more people
away from Bitcoin towards... I don't know what. Some less expensive, more
reliable, probably more-centralized solution.
The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
> irreversible way, for gaining short-term better user experience.
>
If by long-term security you mean "will transaction fees be high enough to
pay for enough hashing power to secure the network if there are bigger
blocks" I've written about that:
http://gavinandresen.ninja/block-size-and-miner-fees-again
If you mean something else, then please be specific.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/4417e2e4/attachment.html>

2023-06-07 17:35:58 CEST

- reply

📅 Original date posted:2015-05-31
📝 Original message:On Sun, May 31, 2015 at 9:45 AM, Alex Mizrahi <alex.mizrahi at gmail.com>
wrote:
>
>
>> That orphan rate increase will go to whoever is producing the 20MB
>> blocks, NOT you.
>>
>
> This depends on how miners are connected.
>
> E.g. suppose there are three miners, A and B have fast connectivity
> between then, and C has a slow network.
> Suppose that A miners a block and B receives it in 1 second. C receives it
> in 6 seconds.
> This means that blocks mined by C during these ~5 seconds will be orphaned
> because B gets A's block first.
>
Yes, if you are on a slow network then you are at a (slight) disadvantage.
So?
There are lots of equations that go into the "is mining profitable"
equation: cost of power, Internet cost and connectivity, cost of capital,
access to technology other miners don't have, inexpensive labor or rent,
inexpensive cooling, ability to use waste heat...
That's good. An equation with lots of variables has lots of different
maximum solutions, and that means better decentralization -- there is less
likely to be one perfect place or way to mine.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150531/11fb2d62/attachment.html>

2023-06-07 17:35:58 CEST

- reply

📅 Original date posted:2015-05-31
📝 Original message:On Sat, May 30, 2015 at 9:31 PM, Chun Wang <1240902 at gmail.com> wrote:
>
> If someone propagate a 20MB block, it will take at best 6 seconds for
> us to receive to verify it at current configuration, result of one
> percent orphan rate increase.
That orphan rate increase will go to whoever is producing the 20MB blocks,
NOT you.
Or, we can mine the next block only on
> the previous block's header, in this case, the network would see many
> more transaction-less blocks.
>
Are you sure that is the best strategy? If a big block is slow to
propagate, I suspect it will be better to punish the miner that created it
by refusing to build on it until it has been fully validated.
I'll try to find time to run a couple of simulations.
>
> Our orphan rate is about 0.5% over the past few months. If the network
> floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
> block could contain an average of 50000 transactions, hundred of
> thousands of sigops, Do you have an estimate how long it takes on the
> submitblock rpccall?
>
I can benchmark it. It should be pretty fast, and sipa has a couple of
patches pending to make the UTXO cache much faster.
It can be fast because the vast majority of the work of validating all
those transactions can happen as they are received into the memory pool.
> For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
> per month.
You should be able to handle 20MB blocks no problem; if I round up to 100MB
per block that works out to 1.3Mbps.
We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
> 100Mbps connectivity at Aliyun.
That speed will handle 20MB blocks no problem.
If each 20MB block is 100MB of data up/down the wire (I'm vastly
over-estimating, after optimization it should be 40MB) then you'll be
paying...uhhh:
0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13 $ /
GB = $57
Less than $2 per day in bandwidth, surely you can afford that.
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
That's OK, you'll 1.3Mbps or less.
> I think we can accept 5MB block at most.
>
Are you worried about paying too much, or do 20MB blocks "feel like too
much" ?
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150531/41d199dc/attachment.html>

2023-06-07 17:34:44 CEST

- reply

📅 Original date posted:2015-05-11
📝 Original message:I think long-term the chain will not be secured purely by proof-of-work. I
think when the Bitcoin network was tiny running solely on people's home
computers proof-of-work was the right way to secure the chain, and the only
fair way to both secure the chain and distribute the coins.
See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
half-baked thoughts along those lines. I don't think proof-of-work is the
last word in distributed consensus (I also don't think any alternatives are
anywhere near ready to deploy, but they might be in ten years).
I also think it is premature to worry about what will happen in twenty or
thirty years when the block subsidy is insignificant. A lot will happen in
the next twenty years. I could spin a vision of what will secure the chain
in twenty years, but I'd put a low probability on that vision actually
turning out to be correct.
That is why I keep saying Bitcoin is an experiment. But I also believe that
the incentives are correct, and there are a lot of very motivated, smart,
hard-working people who will make it work. When you're talking about trying
to predict what will happen decades from now, I think that is the best you
can (honestly) do.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150511/98eda946/attachment.html>

2023-06-07 17:34:07 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:On Fri, May 29, 2015 at 10:09 AM, Tier Nolan <tier.nolan at gmail.com> wrote:
> How do you intend to measure exchange/merchant acceptance?
>
Public statements saying "we're running software that is ready for bigger
blocks."
And looking at the version (aka user-agent) strings of publicly reachable
nodes on the network.
(e.g. see the count at https://getaddr.bitnodes.io/nodes/ )
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/f02fc1b9/attachment.html>

2023-06-07 17:34:06 CEST

- reply

📅 Original date posted:2015-05-29
📝 Original message:What do other people think?
If we can't come to an agreement soon, then I'll ask for help
reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
big increase now that grows over time so we may never have to go through
all this rancor and debate again.
I'll then ask for help lobbying the merchant services and exchanges and
hosted wallet companies and other bitcoind-using-infrastructure companies
(and anybody who agrees with me that we need bigger blocks sooner rather
than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
are running it. We'll be able to see uptake on the network by monitoring
client versions.
Perhaps by the time that happens there will be consensus bigger blocks are
needed sooner rather than later; if so, great! The early deployment will
just serve as early testing, and all of the software already deployed will
ready for bigger blocks.
But if there is still no consensus among developers but the "bigger blocks
now" movement is successful, I'll ask for help getting big miners to do the
same, and use the soft-fork block version voting mechanism to (hopefully)
get a majority and then a super-majority willing to produce bigger blocks.
The purpose of that process is to prove to any doubters that they'd better
start supporting bigger blocks or they'll be left behind, and to give them
a chance to upgrade before that happens.
Because if we can't come to consensus here, the ultimate authority for
determining consensus is what code the majority of merchants and exchanges
and miners are running.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/3480fef4/attachment.html>

2023-06-07 17:34:05 CEST

- reply

📅 Original date posted:2015-05-28
📝 Original message:On Thu, May 28, 2015 at 1:34 PM, Mike Hearn <mike at plan99.net> wrote:
> As noted, many miners just accept the defaults. With your proposed change
>> their target would effectively *drop* from 1mb to 800kb today, which
>> seems crazy. That's the exact opposite of what is needed right now.
>>
>
> I am very skeptical about this idea.
>
By the time a hard fork can happen, I expect average block size will be
above 500K.
Would you support a rule that was "larger of 1MB or 2x average size" ? That
is strictly better than the situation we're in today.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/fada3906/attachment.html>

2023-06-07 17:34:04 CEST

- reply

📅 Original date posted:2015-05-28
📝 Original message:On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Between all the flames on this list, several ideas were raised that did
> not get much attention. I hereby resubmit these ideas for consideration and
> discussion.
>
> - Perhaps the hard block size limit should be a function of the actual
> block sizes over some trailing sampling period. For example, take the
> median block size among the most recent 2016 blocks and multiply it by 1.5.
> This allows Bitcoin to scale up gradually and organically, rather than
> having human beings guessing at what is an appropriate limit.
>
A lot of people like this idea, or something like it. It is nice and
simple, which is really important for consensus-critical code.
With this rule in place, I believe there would be more "fee pressure"
(miners would be creating smaller blocks) today. I created a couple of
histograms of block sizes to infer what policy miners are ACTUALLY
following today with respect to block size:
Last 1,000 blocks:
http://bitcoincore.org/~gavin/sizes_last1000.html
Notice a big spike at 750K -- the default size for Bitcoin Core.
This graph might be misleading, because transaction volume or fees might
not be high enough over the last few days to fill blocks to whatever limit
miners are willing to mine.
So I graphed a time when (according to statoshi.info) there WERE a lot of
transactions waiting to be confirmed:
http://bitcoincore.org/~gavin/sizes_357511.html
That might also be misleading, because it is possible there were a lot of
transactions waiting to be confirmed because miners who choose to create
small blocks got lucky and found more blocks than normal. In fact, it
looks like that is what happened: more smaller-than-normal blocks were
found, and the memory pool backed up.
So: what if we had a dynamic maximum size limit based on recent history?
The average block size is about 400K, so a 1.5x rule would make the max
block size 600K; miners would definitely be squeezing out transactions /
putting pressure to increase transaction fees. Even a 2x rule (implying
800K max blocks) would, today, be squeezing out transactions / putting
pressure to increase fees.
Using a median size instead of an average means the size can increase or
decrease more quickly. For example, imagine the rule is "median of last
2016 blocks" and 49% of miners are producing 0-size blocks and 51% are
producing max-size blocks. The median is max-size, so the 51% have total
control over making blocks bigger. Swap the roles, and the median is
min-size.
Because of that, I think using an average is better-- it means the max size
will change (up or down) more slowly.
I also think 2016 blocks is too long, because transaction volumes change
quicker than that. An average over 144 blocks (last 24 hours) would be
better able to handle increased transaction volume around major holidays,
and would also be able to react more quickly if an economically irrational
attacker attempted to flood the network with fee-paying transactions.
So my straw-man proposal would be: max size 2x average size over last 144
blocks, calculated at every block.
There are a couple of other changes I'd pair with that consensus change:
+ Make the default mining policy for Bitcoin Core neutral-- have its target
block size be the average size, so miners that don't care will "go along
with the people who do care."
+ Use something like Greg's formula for size instead of bytes-on-the-wire,
to discourage bloating the UTXO set.
---------
When I've proposed (privately, to the other core committers) some dynamic
algorithm the objection has been "but that gives miners complete control
over the max block size."
I think that worry is unjustified right now-- certainly, until we have
size-independent new block propagation there is an incentive for miners to
keep their blocks small, and we see miners creating small blocks even when
there are fee-paying transactions waiting to be confirmed.
I don't even think it will be a problem if/when we do have size-independent
new block propagation, because I think the combination of the random timing
of block-finding plus a dynamic limit as described above will create a
healthy system.
If I'm wrong, then it seems to me the miners will have a very strong
incentive to, collectively, impose whatever rules are necessary (maybe a
soft-fork to put a hard cap on block size) to make the system healthy again.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/5681756b/attachment.html>

2023-06-07 17:34:04 CEST

- reply

📅 Original date posted:2015-05-28
📝 Original message:On Thu, May 28, 2015 at 1:05 PM, Mike Hearn <mike at plan99.net> wrote:
> Isn't that a step backwards, then? I see no reason for fee pressure to
>> exist at the moment. All it's doing is turning away users for no purpose:
>> mining isn't supported by fees, and the tiny fees we use right now seem to
>> be good enough to stop penny flooding.
>>
>
> Why not set the max size to be 20x the average size? Why 2x, given you
> just pointed out that'd result in blocks shrinking rather than growing.
>
Twenty is scary.
And two is a very neutral number: if 50% of hashpower want the max size to
grow as fast as possible and 50% are dead-set opposed to any increase in
max size, then half produce blocks 2 times as big, half produce empty
blocks, and the max size doesn't change. If it was 20, then a small
minority of miners could force a max size increase. (if it is less than 2,
then a minority of minors can force the block size down)
As for whether there "should" be fee pressure now or not: I have no
opinion, besides "we should make block propagation faster so there is no
technical reason for miners to produce tiny blocks." I don't think us
developers should be deciding things like whether or not fees are too high,
too low, .....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/ef414a76/attachment.html>

2023-06-07 17:34:01 CEST

- reply

📅 Original date posted:2015-05-10
📝 Original message:Let me make sure I understand this proposal:
On Fri, May 8, 2015 at 11:36 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> (*) I believe my currently favored formulation of general dynamic control
> idea is that each miner expresses in their coinbase a preferred size
> between some minimum (e.g. 500k) and the miner's effective-maximum;
> the actual block size can be up to the effective maximum even if the
> preference is lower (you're not forced to make a lower block because you
> stated you wished the limit were lower). There is a computed maximum
> which is the 33-rd percentile of the last 2016 coinbase preferences
> minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats
> larger. The effective maximum is X bytes more, where X on the range
> [0, computed_maximum] e.g. the miner can double the size of their
> block at most. If X > 0, then the miners must also reach a target
> F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1 ---
> so the maximum penalty is 2, with a quadratic shape; for a given mempool
> there will be some value that maximizes expected income. (obviously all
> implemented with precise fixed point arithmetic). The percentile is
> intended to give the preferences of the 33% least preferring miners a
> veto on increases (unless a majority chooses to soft-fork them out). The
> minus-comp_max/52 provides an incentive to slowly shrink the maximum
> if its too large-- x/52 would halve the size in one year if miners
> were doing the lowest difficulty mining. The parameters 500k/33rd,
> -computed_max/52 bytes, and f(x) I have less strong opinions about;
> and would love to hear reasoned arguments for particular parameters.
>
I'm going to try to figure out how much transaction fee a transaction would
have to pay to bribe a miner to include it. Greg, please let me know if
I've misinterpreted the proposed algorithm. And everybody, please let me
know if I'm making a bone-headed mistake in how I'm computing anything:
Lets say miners are expressing a desire for 600,000 byte blocks in their
coinbases.
computed_max = 600,000 - 600,000/52 = 588,462 bytes.
--> this is about 23 average-size (500-byte) transactions less than
600,000.
effective_max = 1,176,923
Lets say I want to maintain status quo at 600,000 bytes; how much penalty
do I have?
((600,000-588,462)/588,462)^2 + 1 = 1.00038
How much will that cost me?
The network is hashing at 310PetaHash/sec right now.
Takes 600 seconds to find a block, so 186,000PH per block
186,000 * 0.00038 = 70 extra PH
If it takes 186,000 PH to find a block, and a block is worth 25.13 BTC
(reward plus fees), that 70 PH costs:
(25.13 BTC/block / 186,000 PH/block) * 70 PH = 0.00945 BTC
or at $240 / BTC: $2.27
... so average transaction fee will have to be about ten cents ($2.27
spread across 23 average-sized transactions) for miners to decide to stay
at 600K blocks. If they fill up 588,462 bytes and don't have some
ten-cent-fee transactions left, they should express a desire to create a
588,462-byte-block and mine with no penalty.
Is that too much? Not enough? Average transaction fees today are about 3
cents per transaction.
I created a spreadsheet playing with the parameters:
https://docs.google.com/spreadsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=sharing
"We" could tweak the constants or function to get a transaction fee we
think is reasonable... but we really shouldn't be deciding whether
transaction fees are too high, too low, or just right, and after thinking
about this for a while I think any algorithm that ties difficulty to block
size is just a complicated way of dictating minimum fees.
As for some other dynamic algorithm: OK with me. How do we get consensus on
what the best algorithm is? I'm ok with any "don't grow too quickly, give
some reasonable-percentage-minority of miners the ability to block further
increases."
Also relevant here:
"The curious task of economics is to demonstrate to men how little they
really know about what they imagine they can design." - Friedrich August
von Hayek
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150510/481dae92/attachment.html>

2023-06-07 17:33:59 CEST

- reply

📅 Original date posted:2015-05-09
📝 Original message:RE: fixing sigop counting, and building in UTXO cost: great idea! One of
the problems with this debate is it is easy for great ideas get lost in all
the noise.
RE: a hard upper limit, with a dynamic limit under it:
I like that idea. Can we drill down on the hard upper limit?
There are lots of people who want a very high upper limit, right now (all
the big Bitcoin companies, and anybody who thinks as-rapid-as-possible
growth now is the best path to long-term success). This is the "it is OK if
you have to run full nodes in a data center" camp.
There are also lots of people who want an upper limit low enough that they
can continue to run Bitcoin on the hardware and Internet connection that
they have (or are concerned about centralization, so want to make sure
OTHER people can continue to run....).
Is there an upper limit "we" can choose to make both sets of people mostly
happy? I've proposed "must be inexpensive enough that a 'hobbyist' can
afford to run a full node" ...
Is the limit chosen once, now, via hard-fork, or should we expect multiple
hard-forks to change it "when necessary" ?
The economics change every time the block reward halves, which make me
think that might be a good time to adjust the hard upper limit. If we have
a hard upper limit and a lower dynamic limit, perhaps adjusting the hard
upper limit (up or down) to account for the block reward halving, based on
the dynamic limit....
RE: the lower dynamic limit algorithm: I REALLY like that idea.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/e371ad58/attachment.html>

2023-06-07 17:33:56 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:I like the bitcoin days destroyed idea.
I like lots of the ideas that have been presented here, on the bitcointalk
forums, etc etc etc.
It is easy to make a proposal, it is hard to wade through all of the
proposals. I'm going to balance that equation by completely ignoring any
proposal that isn't accompanied by code that implements the proposal (with
appropriate tests).
However, I'm not the bottleneck-- you need to get the attention of the
other committers and convince THEM:
a) something should be done "now-ish"
b) your idea is good
We are stuck on (a) right now, I think.
On Fri, May 8, 2015 at 8:32 AM, Joel Joonatan Kaartinen <
joel.kaartinen at gmail.com> wrote:
> Matt,
>
> It seems you missed my suggestion about basing the maximum block size on
> the bitcoin days destroyed in transactions that are included in the block.
> I think it has potential for both scaling as well as keeping up a constant
> fee pressure. If tuned properly, it should both stop spamming and increase
> block size maximum when there are a lot of real transactions waiting for
> inclusion.
>
> - Joel
>
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/f3bd5434/attachment.html>

2023-06-07 17:33:43 CEST

- 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 17:33:42 CEST

- 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 17:33:10 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:For reference: the blog post that (re)-started this debate, and which links
to individual issues, is here:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
In it, I asked people to email me objections I might have missed. I would
still appreciate it if people do that; it is impossible to keep up with
this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
also have time to respond thoughtfully to the objections raised.
I would very much like to find some concrete course of action that we can
come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
how much transaction volume the main Bitcoin blockchain will be able to
support over the next eleven years."
I've been pretty clear on what I think is a reasonable compromise (a
one-time increase scheduled for early next year), and I have tried to
explain why I think it it is the right set of tradeoffs.
There ARE tradeoffs here, and the hard question is what process do we use
to decide those tradeoffs? How do we come to consensus? Is it worth my
time to spend hours responding thoughtfully to every new objection raised
here, or will the same thing happen that happened last year and the year
before-- everybody eventually gets tired of arguing
angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
I AM considering contributing some version of the bigger blocksize-limit
hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a
fast Internet connection, and assume Nelson's law to increase over time),
and then encouraging merchants and exchanges and web wallets and
individuals who think it strikes a reasonable balance to run it.
And then, assuming it became a super-majority of nodes on the network,
encourage miners to roll out a soft-fork to start producing bigger blocks
and eventually trigger the hard fork.
Because ultimately consensus comes down to what software people choose to
run.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/125b7e32/attachment.html>

2023-06-07 17:28:53 CEST

- reply

📅 Original date posted:2015-01-21
📝 Original message:DERSIG BIP looks great to me, just a few nit-picky changes suggested:
You mention the "DER standard" : should link to
http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or
whatever is best reference for DER).
"this would simplify avoiding OpenSSL in consensus implementations" -->
"this would make it easier for non-OpenSSL implementations"
"causing opcode failure" : I know what you mean by "opcode failure", but
it might be good to be more explicit.
"since v0.8.0, and nearly no transactions" --> "and very few
transactions..."
"reducing this avenue for malleability is useful on itself as well" :
awkward English. How about just "This proposal has the added benefit of
reducing transaction malleability (see BIP62)."
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150121/c90302a5/attachment.html>

2023-06-07 17:28:37 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:On Mon, Jan 19, 2015 at 3:40 PM, Mike Hearn <mike at plan99.net> wrote:
> OK, I guess we can boil this down more simply. BIP 70 uses protocol
>> buffers because I designed it and implemented the original prototype (with
>> lots of input from Gavin and an earlier proposal by sipa). I used protocol
>> buffers because, beyond all their nice properties, I used to work at Google
>> and so was very familiar with them.
>>
>
What Mike said. Runner-up for encoding was JSON.
XML+ASN.1 was Right Out, because lots of us hate XML and ASN.1 with a
burning passion. Complexity is the Enemy of Security, and both XML and
ASN.1 are too complex.
--
--
Gavin Andresen
Chief Scientist, Bitcoin Foundation
https://www.bitcoinfoundation.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/e1a3fb5a/attachment.html>

2023-06-07 17:27:41 CEST

- reply

📅 Original date posted:2014-12-04
📝 Original message:On Thu, Dec 4, 2014 at 10:42 AM, Luke Dashjr <luke at dashjr.org> wrote:
> Is anyone working on a serialisation format to convey P2SH HD chains? For example,
> to give someone who wants to make recurring payments a single token that
> can be used to generate many P2SH addresses paying to a multisig script.
Seems like the wrong approach to me, because in practice you really need
a reasonable expiration date or some way of determining that whatever you
are paying
is still around (I still get random transactions to the Bitcoin Faucet's
old addresses).
See the discussion from January about extending the payment protocol for
recurring transactions:
https://www.mail-archive.com/[email protected]/msg03823.html
"Give them a single token" == "give them a recurring PaymentRequest" in my
mind. Or maybe "Give them a URL where they can fetch PaymentRequests
whenever they need to make a payment" or maybe "Give them an array of
PaymentRequests for the next X days/months/years of payments."
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141204/2bb31fe5/attachment.html>

2023-06-07 17:26:46 CEST

- reply

📅 Original date posted:2014-10-25
📝 Original message:We had a halving, and it was a non-event.
Is there some reason to believe next time will be different?
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141025/a67c8cbb/attachment.html>

2023-06-07 17:26:30 CEST

- reply

📅 Original date posted:2014-10-15
📝 Original message:RE: process:
I like author == primary control, and an "assume they will do the right
thing, revert if they don't"
RE: separate mailing list for BIP discussion:
Great idea. Jeff Garzik was looking for a better mailing list solution than
SourceForge, but assuming
there isn't a clearly better solution I think "we" should create a strictly
moderated bitcoin-bips at lists.sourceforge list.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141015/6532efb8/attachment.html>

2023-06-07 17:26:09 CEST

- reply

📅 Original date posted:2014-10-07
📝 Original message:On Sat, Oct 4, 2014 at 8:58 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> Meanwhile, what I said *is* correct. New version numbers result in only
> a log print. Being hard forked off results in both log prints *and* the
> -alertnotify being run:
>
That is easy to change; I'll submit a pull request. It is a good idea to
get an -alertnotify sooner rather than later for EITHER a hard fork or a
soft-fork. Better to be told you have to upgrade while the block.version is
on its way to being a super-majority than after you are either hard-forked
off the main chain (or soft-forked).
I don't have any opinion on the hard- versus soft- fork debate. I think
either can work.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141007/788fa260/attachment.html>

2023-06-07 17:26:06 CEST

- reply

📅 Original date posted:2014-10-01
📝 Original message:On Wed, Oct 1, 2014 at 5:04 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> On 10/01/2014 04:58 PM, Gavin Andresen wrote:
> > If the first transaction is P2SH, then the miner won't know there is
> > an advantage to holding it until it is too late (the scriptPubKey is
> > an opaque hash until the second transaction is final and
> > relayed/broadcast).
>
> If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH
> defeat the purpose of it?
>
No, the burner would supply the funding transaction plus the redeeming
script as the proof-of-burn to whoever needed the proof.
Only after at least one confirmation, if there was some risk that revealing
the redeeming script would make miners refuse to mine that first
transaction because they want to get it plus the CHECKTIMELOCKVERIFY "burn"
transaction.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141001/05ee5140/attachment.html>

2023-06-07 17:26:05 CEST

- reply

📅 Original date posted:2014-10-01
📝 Original message:On Wed, Oct 1, 2014 at 2:23 PM, Luke Dashjr <luke at dashjr.org> wrote:
> houghts on some way to have the stack item be incremented by the height at
> which the scriptPubKey was in a block? A limitation of encoding the target
> height/time directly, is that miners may choose not to mine the first
> transaction until they can also take the "burn to fee".
>
If the first transaction is P2SH, then the miner won't know there is an
advantage to holding it until it is too late (the scriptPubKey is an opaque
hash until the second transaction is final and relayed/broadcast).
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141001/dd4a8c60/attachment.html>

2023-06-07 17:26:04 CEST

- reply

📅 Original date posted:2014-10-01
📝 Original message:Very nice, semantics are clear and use cases are compelling.
Can we defer discussion of how to roll this out for a little bit, and see
if there is consensus that:
a) benefits of having this outweigh risks
b) we're all happy with exact semantics
Then we can have a knock-down drag-out argument about whether it should
roll out as a soft fork, wait for a hard fork, be combined with some other
things that it would be nice to add or change, etc.....
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141001/94a794c3/attachment.html>

2023-06-07 17:24:06 CEST

- 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 17:21:46 CEST

- reply

📅 Original date posted:2014-05-19
📝 Original message:On Mon, May 19, 2014 at 2:20 PM, Justus Ranvier <justusranvier at gmail.com>wrote:
>
> You and Gavin could do a lot better by working on a Bitcoin social
> contract - a promise of what features will *never* be added (or taken
> away) from Bitcoin, because despite what you say it's not acceptable
> to propose anything at all.
>
Now I'm really confused.
Why would Mike or I have the authority to write a "social contract" to
promise anything about future-Bitcoin?
I thought the only "social contract" was the decentralized one we have
already-- if you don't like something about the code, then don't download
and run it. Or fork it if you're able.
As the person who started this mailing list, I DO feel like I have the
authority to enforce a social contract of "no trolling or flaming or
name-calling" here. I'd very much like to delegate that authority, though;
ideally to some software algorithm that automatically censors topics or
people who don't contribute to a productive discussion.
PS: speaking of productive discussion...
... please change the Subject line when the topic wanders.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140519/c3c3e1c9/attachment.html>

2023-06-07 17:19:29 CEST

- reply

📅 Original date posted:2014-04-23
📝 Original message:>
>
> I've formulated my replies to you and this proposal in a more public
> venue, where such discussions of existential changes to the protocol
> more rightfully belong
>
>
I strongly disagree. It makes perfect sense to discuss changes here,
first, where there are lots of people who understand how the system works
at a very detailed level.
And why do you think your blog is more public than this open, publicly
archived mailing list???
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/94b199e3/attachment.html>

2023-06-07 17:17:18 CEST

- reply

📅 Original date posted:2014-04-04
📝 Original message:Using a bitcoin address repeatedly is something we're trying to move away
from.
And using a bitcoin address as a persistent identity key feels like the
wrong direction to me.
Better to use something like client certificates, the FIDO alliance's
(new!) specs:
http://fidoalliance.org/specifications/download
... or Steve Gibson's proposed SQRL system:
https://www.grc.com/sqrl/sqrl.htm
If one of those systems gets critical mass and actually starts being
successful, then I think it would make sense to specify a standard way of
using a HD wallet's deterministic seed to derive a key used for the FIDO or
SQRL systems.
On Fri, Apr 4, 2014 at 9:22 AM, Eric Larchevêque <elarch at gmail.com> wrote:
> What I'm trying to achieve, is to have a very simple way of authenticating
> yourself with one Bitcoin address from your wallet.
> For most of the people using Bitcoin, their wallet is on their phone.
>
> The UX is clear and simple :
> 1. click on "connect with Bitcoin" (the audience is normal people)
> 2. flash the QRcode with your wallet (blockchain.info, mycelium, ...)
> 3. accept the authentication request (same style than OpenID or Facebook
> connect)
> 4. user is autologged and identified by the chosen Bitcoin public address
>
> It makes sense only if major wallets are supporting the protocol. If you
> need to install a plugin or download a third party software, no one will do
> it.
> I see only benefits for the entire ecosystem, and if I'm working on such a
> proposition it is because I really need this feature.
>
> Of course, it can be done without a BIP, I just need to convince wallet
> developpers one by one to implement the feature.
> But I thought it was much better to start the "official" way, so all
> wallet could easily find and implement the same authentication mechanism.
>
> > Bitcoin and website authentication are unrelated problems
>
> I respectfully disagree. Many services require your Bitcoin address, and
> to do that they artificially request an email/password to store it.
> This is not about authentication as an identity (as "I'm Eric
> Larcheveque"), but as in "I'm proving to you that I control this address".
>
> Without such a standard protocol, you could never envision a pure Bitcoin
> physical locker rental, or booking an hotel room via Bitcoin and opening
> the door through the paying address.
>
> Eric
>
>
>
> On Fri, Apr 4, 2014 at 3:08 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> This comes up every few months. I think the problem you are trying to
>> solve is already solved by SSL client certificates, and if you want to help
>> make them more widespread the programs you need to upgrade are web browsers
>> and not Bitcoin wallets. There are certainly bits of infrastructure you
>> could reuse here and there, like perhaps a TREZOR with a custom firmware
>> extension for really advanced/keen users, but overall Bitcoin and website
>> authentication are unrelated problems.
>>
>>
>> On Fri, Apr 4, 2014 at 2:15 PM, Eric Larchevêque <elarch at gmail.com>wrote:
>>
>>> Hello,
>>>
>>> I've written a draft BIP description of an authentication protocol based
>>> on Bitcoin public address.
>>>
>>> By authentication we mean to prove to a service/application that we
>>> control a specific Bitcoin address by signing a challenge, and that all
>>> related data and settings may securely be linked to our session.
>>>
>>> The aim is to greatly facilitate sign ups and logins to services and
>>> applications, improving the Bitcoin ecosystem as a whole.
>>>
>>> https://github.com/bitid/bitid/blob/master/BIP_draft.md
>>>
>>> Demo website :
>>> http://bitid-demo.herokuapp.com/
>>>
>>> Classical password authentication is an insecure process that could be
>>> solved with public key cryptography. The problem is that it theoretically
>>> offloads a lot of complexity and responsibility on the user. Managing
>>> private keys securely is complex. However this complexity is already being
>>> addressed in the Bitcoin ecosystem. So doing public key authentication is
>>> practically a free lunch to bitcoiners.
>>>
>>> I've formatted the protocol description as a BIP because this is the
>>> only way to have all major wallets implementing it, and because it
>>> completely fits in my opinion the BIP "process" category.
>>>
>>> Please read it and let me know your thoughts and comments so we can
>>> improve on this draft.
>>>
>>> Eric Larcheveque
>>> elarch at gmail.com
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>
>
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/a545ece6/attachment.html>

2023-06-07 17:15:05 CEST

- reply

📅 Original date posted:2014-03-11
📝 Original message:On Tue, Mar 11, 2014 at 8:38 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Tue, Mar 11, 2014 at 7:43 AM, Drak <drak at zikula.org> wrote:
> > I very much like the idea of assuming each party uses HD wallets, that
> > certainly simplifies things greatly.
>
> It also assumes a reality different from our current one.
>
Multisig wallets are a different reality from our current one, so when we
move to that new reality we should do it correctly from the beginning.
--
--
Gavin Andrese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140311/b7b38273/attachment.html>

2023-06-07 17:15:01 CEST

- reply

📅 Original date posted:2014-03-10
📝 Original message:In my experience, best process for standardizing something is:
1) Somebody has a great idea
2) They implement it
3) Everybody agrees, "Great idea!" and they copy it.
4) Idea gets refined by the people copying it.
5) It gets standardized.
Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
opinion...
On Mon, Mar 10, 2014 at 1:39 PM, Drak <drak at zikula.org> wrote:
> I was wondering if there would be merit in a kind of BIP for a payment
> protocol using multisig?
>
> Currently, setting up a multisig is quite a feat. Users have to exchange
> public keys, work out how to get the public keys from their addresses. If
> one of the parties are not savvy enough, an malicious party could easily be
> setup that was 2 of 3 instead of 2 of 2 where the malicious party generates
> the multisig address+script and thus be able to run off with funds anyway.
>
> It's also terribly complex to generate and keep track of. There's been a
> nice attempt at creating an browser interface at coinb.in/multisig but it
> still lacks the kind of ease with created by the payment protocol. If there
> was a BIP then it would go a long way to aiding future usability of
> multisig wallet implementations.
>
> What are your thoughts?
>
> Drak
>
>
> ------------------------------------------------------------------------------
> 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/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/b72ac2aa/attachment.html>

2023-06-07 17:13:35 CEST

- reply

📅 Original date posted:2014-02-10
📝 Original message:RE: taking discussion elsewhere:
Yes, please, the purpose of this mailing list is technical discussions to
encourage interoperability of Bitcoin implementations, improve ease-of-use
and security, etc.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140210/165de986/attachment.html>

2023-06-07 17:13:29 CEST

- reply

📅 Original date posted:2014-02-20
📝 Original message:Great, I'm hearing rough consensus to proceed with Pieter's plan.
RE: far from confident on malleability routes: I'm reasonably confident
that we can squash malleability for IsStandard, SIGHASH_ALL transactions. A
proper proof of DSA signature un-malleability (or an lower bound for how
much work it would be to create a valid doppleganger signature) would be
great, but I don't think it is necessary to proceed.
On Thu, Feb 20, 2014 at 9:36 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > I think we should get Pieter's proposal done and implemented quickly. I
> > agree with Mike, it doesn't have to take a long time for the core
> network to
> > fully support this.
> >
> > Getting wallets to start generating transaction.version=3 might take
> years,
> > but that is OK.
>
> Sure I'm all for doing what Pieter suggested-- it's basically the plan
> we've been executing for some time already but with the version check
> to make it sane to complete.
>
> My reserved sounding comments were relative to the proposals to do
> things with nversion=1 transactions, frankly I think thats completely
> insane. Though while we're on the subject of reservations, I am far
> from confident that we've uncovered all the possible malleability
> routes-- that list gained a new, never before discussed entry, when
> Pieter was writing it a couple weeks ago. We also have no proof of
> the absence of further algebraic malleability in DSA (though I think
> its somewhat unlikely, a solid proof of it has been somewhat elusive).
>
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/3a8746e1/attachment.html>

2023-06-07 17:13:29 CEST

- reply

📅 Original date posted:2014-02-20
📝 Original message:I think we should get Pieter's proposal done and implemented quickly. I
agree with Mike, it doesn't have to take a long time for the core network
to fully support this.
Getting wallets to start generating transaction.version=3 might take years,
but that is OK.
--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140220/5383f456/attachment.html>