theymos [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 19:59:13

- reply

📅 Original date posted:2017-04-05
📝 Original message:This seems to be a serious security problem. Would it be possible to have
a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a trigger
3-6 months from release should be sufficient for enough of the economy to upgrade,
given the severity of the issue.
BIP 141 says that the the commitment is optional if there are no SegWit transactions in
the block, so will today's SegWit-ready miners always produce it even when optional
according to BIP 141, as required by this softfork?
On Wed, Apr 5, 2017, at 04:37 PM, Gregory Maxwell via bitcoin-dev wrote:
> A month ago I was explaining the attack on Bitcoin's SHA2 hashcash which
> is exploited by ASICBOOST and the various steps which could be used to
> block it in the network if it became a problem.
>
> While most discussion of ASICBOOST has focused on the overt method
> of implementing it, there also exists a covert method for using it.
>
> As I explained one of the approaches to inhibit covert ASICBOOST I
> realized that my words were pretty much also describing the SegWit
> commitment structure.
>
> The authors of the SegWit proposal made a specific effort to not be
> incompatible with any mining system and, in particular, changed the
> design at one point to accommodate mining chips with forced payout
> addresses.
>
> Had there been awareness of exploitation of this attack an effort
> would have been made to avoid incompatibility-- simply to separate
> concerns. But the best methods of implementing the covert attack
> are significantly incompatible with virtually any method of
> extending Bitcoin's transaction capabilities; with the notable
> exception of extension blocks (which have their own problems).
>
> An incompatibility would go a long way to explain some of the
> more inexplicable behavior from some parties in the mining
> ecosystem so I began looking for supporting evidence.
>
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented
> in hardware.
>
> On that basis, I offer the following BIP draft for discussion.
> This proposal does not prevent the attack in general, but only
> inhibits covert forms of it which are incompatible with
> improvements to the Bitcoin protocol.
>
> I hope that even those of us who would strongly prefer that
> ASICBOOST be blocked completely can come together to support
> a protective measure that separates concerns by inhibiting
> the covert use of it that potentially blocks protocol improvements.
>
> The specific activation height is something I currently don't have
> a strong opinion, so I've left it unspecified for the moment.
>
> <pre>
> BIP: TBD
> Layer: Consensus
> Title: Inhibiting a covert attack on the Bitcoin POW function
> Author: Greg Maxwell <greg at xiph.org>
> Status: Draft
> Type: Standards Track
> Created: 2016-04-05
> License: PD
> </pre>
>
> ==Abstract==
>
> This proposal inhibits the covert exploitation of a known
> vulnerability in Bitcoin Proof of Work function.
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119.
>
> ==Motivation==
>
> Due to a design oversight the Bitcoin proof of work function has a potential
> attack which can allow an attacking miner to save up-to 30% of their energy
> costs (though closer to 20% is more likely due to implementation overheads).
>
> Timo Hanke and Sergio Demian Lerner claim to hold a patent on this attack,
> which they have so far not licensed for free and open use by the public.
> They have been marketing their patent licenses under the trade-name
> ASICBOOST. The document takes no position on the validity or enforceability
> of the patent.
>
> There are two major ways of exploiting the underlying vulnerability: One
> obvious way which is highly detectable and is not in use on the network
> today and a covert way which has significant interaction and potential
> interference with the Bitcoin protocol. The covert mechanism is not
> easily detected except through its interference with the protocol.
>
> In particular, the protocol interactions of the covert method can block the
> implementation of virtuous improvements such as segregated witness.
>
> Exploitation of this vulnerability could result in payoff of as much as
> $100 million USD per year at the time this was written (Assuming at
> 50% hash-power miner was gaining a 30% power advantage and that mining
> was otherwise at profit equilibrium). This could have a phenomenal
> centralizing effect by pushing mining out of profitability for all
> other participants, and the income from secretly using this
> optimization could be abused to significantly distort the Bitcoin
> ecosystem in order to preserve the advantage.
>
> Reverse engineering of a mining ASIC from a major manufacture has
> revealed that it contains an undocumented, undisclosed ability
> to make use of this attack. (The parties claiming to hold a
> patent on this technique were completely unaware of this use.)
>
> On the above basis the potential for covert exploitation of this
> vulnerability and the resulting inequality in the mining process
> and interference with useful improvements presents a clear and
> present danger to the Bitcoin system which requires a response.
>
> ==Background==
>
> The general idea of this attack is that SHA2-256 is a merkle damgard hash
> function which consumes 64 bytes of data at a time.
>
> The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
> incriminating a 32-bit nonce which is at the end of this header data. This
> means that the processing of the header involves two runs of the compression
> function run-- one that consumes the first 64 bytes of the header and a
> second which processes the remaining 16 bytes and padding.
>
> The initial 'message expansion' operations in each step of the SHA2-256
> function operate exclusively on that step's 64-bytes of input with no
> influence from prior data that entered the hash.
>
> Because of this if a miner is able to prepare a block header with
> multiple distinct first 64-byte chunks but identical 16-byte
> second chunks they can reuse the computation of the initial
> expansion for multiple trials. This reduces power consumption.
>
> There are two broad ways of making use of this attack. The obvious
> way is to try candidates with different version numbers. Beyond
> upsetting the soft-fork detection logic in Bitcoin nodes this has
> little negative effect but it is highly conspicuous and easily
> blocked.
>
> The other method is based on the fact that the merkle root
> committing to the transactions is contained in the first 64-bytes
> except for the last 4 bytes of it. If the miner finds multiple
> candidate root values which have the same final 32-bit then they
> can use the attack.
>
> To find multiple roots with the same trailing 32-bits the miner can
> use efficient collision finding mechanism which will find a match
> with as little as 2^16 candidate roots expected, 2^24 operations to
> find a 4-way hit, though low memory approaches require more
> computation.
>
> An obvious way to generate different candidates is to grind the
> coinbase extra-nonce but for non-empty blocks each attempt will
> require 13 or so additional sha2 runs which is very inefficient.
>
> This inefficiency can be avoided by computing a sqrt number of
> candidates of the left side of the hash tree (e.g. using extra
> nonce grinding) then an additional sqrt number of candidates of
> the right side of the tree using transaction permutation or
> substitution of a small number of transactions. All combinations
> of the left and right side are then combined with only a single
> hashing operation virtually eliminating all tree related
> overhead.
>
> With this final optimization finding a 4-way collision with a
> moderate amount of memory requires ~2^24 hashing operations
> instead of the >2^28 operations that would be require for
> extra-nonce grinding which would substantially erode the
> benefit of the attack.
>
> It is this final optimization which this proposal blocks.
>
> ==New consensus rule==
>
> Beginning block X and until block Y the coinbase transaction of
> each block MUST either contain a BIP-141 segwit commitment or a
> correct WTXID commitment with ID 0xaa21a9ef.
>
> (See BIP-141 "Commitment structure" for details)
>
> Existing segwit using miners are automatically compatible with
> this proposal. Non-segwit miners can become compatible by simply
> including an additional output matching a default commitment
> value returned as part of getblocktemplate.
>
> Miners SHOULD NOT automatically discontinue the commitment
> at the expiration height.
>
> ==Discussion==
>
> The commitment in the left side of the tree to all transactions
> in the right side completely prevents the final sqrt speedup.
>
> A stronger inhibition of the covert attack in the form of
> requiring the least significant bits of the block timestamp
> to be equal to a hash of the first 64-bytes of the header. This
> would increase the collision space from 32 to 40 or more bits.
> The root value could be required to meet a specific hash prefix
> requirement in order to increase the computational work required
> to try candidate roots. These change would be more disruptive and
> there is no reason to believe that it is currently necessary.
>
> The proposed rule automatically sunsets. If it is no longer needed
> due to the introduction of stronger rules or the acceptance of the
> version-grinding form then there would be no reason to continue
> with this requirement. If it is still useful at the expiration
> time the rule can simply be extended with a new softfork that
> sets longer date ranges.
>
> This sun-setting avoids the accumulation of technical debt due
> to retaining enforcement of this rule when it is no longer needed
> without requiring a hard fork to remove it.
>
> == Overt attack ==
>
> The non-covert form can be trivially blocked by requiring that
> the header version match the coinbase transaction version.
>
> This proposal does not include this block because this method
> may become generally available without restriction in the future,
> does not generally interfere with improvements in the protocol,
> and because it is so easily detected that it could be blocked if
> it becomes an issue in the future.
>
> ==Backward compatibility==
>
>
> ==Implementation==
>
>
> ==Acknowledgments==
>
>
> ==Copyright==
>
> This document is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:10:27

- reply

📅 Original date posted:2013-12-08
📝 Original message:On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote:
It's not just about trust, there is the robustness factor: what if he
becomes sick, unavailable, hit by a bus? Others need the ability to
pickup and run with it. The control over the domain (including ability
to renew registration, alter nameservers) needs to be with more than
one person. That's why I suggest using the same people who have control
over the software project at sf,github
The bitcoin.org domain is controlled by me, Sirius, and an anonymous
person. Control will not be lost if Sirius becomes unavailable.
SSL is probably a good idea, and it's probably also a good idea to
separate bitcoin.org from Github. I don't know that I trust Github. I'm
sure that you can find a sponsor for a dedicated server. Let us know if
DNS changes to bitcoin.org are required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131208/576e4afb/attachment.html>

2023-06-07 12:25:51

- reply

📅 Original date posted:2012-07-23
📝 Original message:Coinbase scriptSigs aren't required to be well-formed. They're
never executed.

2023-06-07 04:53:06

- reply

📅 Original date posted:2011-12-29
🗒️ Summary of this message: OP_EVAL proposal makes script language Turing complete with a limit on recursion depth, but all operations still need to be explicitly specified. OP_CODEHASH eliminates the need for script ops to be in strings.
📝 Original message:On Thu, Dec 29, 2011, at 01:55 AM, roconnor at theorem.ca wrote:
> The number of operations executed is still bounded by the number of
> operations occurring in the script. With the OP_EVAL proposal the
> script language becomes essentially Turing complete, with only an
> artificial limit on recursion depth preventing arbitrary computation
> and there is no way to know what code will run without executing it.
Even if OP_EVAL allowed infinite depth, you'd still need to explicitly
specify all operations performed, since there is no way of looping.
I think that something like OP_EVAL will eventually be used to improve
Script in a backward-compatible way (enable the disabled math ops, fix
bugs, etc.), so the mechanism might as well be used now. The only
advantage I see with OP_CODEHASH is that script ops won't need to be in
Script "strings".

2023-06-07 04:51:23

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: A headers-only client is a temporary solution until the full blockchain is downloaded, but it breaks Bitcoin's security model. However, it is better than trusting random peers. Full nodes require expensive hardware, which may lead to transaction fees becoming noncompetitive.
📝 Original message:On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote:
> I don't like the idea of a header only client, unless this is just an
> interim action until the full block chain is downloaded in the
> background. Development of these types of clients is probably
> inevitable, but I believe that this breaks the most fundamental
> aspects of Bitcoin's security model. If a client has only headers, it
> cannot do full verification, and it is trusting the data from random
> anonymous peers.
A headers-only client is much better than trusting anyone, since an
attacker needs >50% of the network's computational power to trick
such clients.
For everyone to keep being a full node, hardware costs would need to
constantly go down enough for all nodes to be able to handle enough
transactions to meet demand. If hardware doesn't become cheap enough
quickly enough, either some people would be unable to handle being full
nodes, or the max block size wouldn't rise enough to meet demand and
transaction fees would become noncompetitive.

2023-06-07 04:51:07

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: The scalability issue in Bitcoin can be solved by having lightweight clients download only headers and Merkle trees, and requiring senders to contact recipients directly to transmit transactions. Full nodes would not answer any client queries, and a separate network could be formed for clients.
📝 Original message:On Sat, Dec 17, 2011, at 02:06 PM, Gavin Andresen wrote:
> Although I do also wonder if we'll ever run into a problem with full
> nodes refusing to answer requests from lightweight nodes (there might
> be a tragedy-of-the-commons problem lurking there).
This seems likely. Also, even if many full nodes are willing to donate
resources, there may simply be too few full nodes to handle the load.
My preferred solution for handling scalability in the future is to
have lightweight clients download only headers and Merkle trees (which
are both small and easy to distribute), and then require senders to
contact recipients directly in order to transmit their transactions.
Then lightweight clients never need full blocks to build their
balances, and full nodes don't have to handle expensive queries from
lightweight clients.
Under this scheme, the current broadcast system could be used among full
nodes for a long time. Since clients wouldn't ever need to talk to full
nodes, they could form a separate network with less reliable
broadcasting and perhaps a fancier network architecture. Members of the
full network would connect to the most reliable members of the client
network in order to broadcast headers and Merkle trees and receive
transactions. Full nodes would *not* answer any client queries, so
dealing with the client network would not require many resources, and
miners would probably have an incentive to do it. (Creating a "separate"
network like this can be done by using the services field.)
I don't think requiring senders to email some data to the recipient
would be too burdensome, though it's probably also possible to design a
system where even offline recipients can receive transactions through
the Bitcoin network.

2023-06-07 04:43:16

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Bitcoin's existing protocol for transactions to IP addresses can be modified to enable complete user handling at server.com through a few changes, including extending the protocol for signed "reply" messages and enabling DNS lookups for IP transactions. DoS attacks are already handled.
📝 Original message:Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete user at server.com handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
public key
- Extend "checkorder" messages so they can specify an account to
send BTC to. Or standardize on how to put the account into the
message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
also be used here to avoid having to use the IP transaction protocol
sometimes. The public key for signing "reply" messages can be gotten
from TXT records. This will be safe with DNSSEC and Namecoin. With
plain DNS Bitcoin could take a SSH-like approach and ask the user to
verify the public key the first time it is used, remembering it later.
DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.

2023-06-07 04:43:09

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: A DNS-based protocol for server.com model is suggested to be used with Namecoin or other DNS replacements/enhancements. The CA model is deemed broken for Bitcoin.
📝 Original message:I like the user at server.com model. The protocol should be done entirely
in DNS, though, not using HTTP connections to the server. Then the
protocol can easily be used with Namecoin or other DNS
replacements/enhancements later. Crypto to prevent MITM attacks can be
an optional part of the protocol.
Almost all users will be unable to set up *any* always-on Internet
service to answer queries, so I'm not too concerned about how easy it is
to set up the server software.
I agree that FirstBits is bad for this. Unlike DNS, "registrations" last
forever because private keys can't be transferred safely. All short
names will be taken quickly. It will also be very expensive for clients
to query this themselves.
The CA model is broken and it should never be used by Bitcoin.

2023-06-07 04:38:38

- reply

📅 Original date posted:2011-11-09
🗒️ Summary of this message: Direct-connection negotiation is best for lightweight clients; a new P2P network could be built for block headers and transaction info. 0-value outputs can be spent.
📝 Original message:For now I think requiring direct-connection negotiation is best for these kinds of things. A direct connection is OK in most cases, and more complicated schemes will be more likely to fail. Maybe the IP transactions protocol can be used.
In the future, I imagine that users of ultra-lightweight clients will connect to a new P2P network built on top of the core Bitcoin network in order to receive block headers and info about sent/received transactions without leeching off of the few full nodes. This network could also be used for indirect transaction negotiation, which is similar to the goal of finding your own received transactions.
On Wednesday, November 09, 2011 3:02 PM, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> a nValue=0 transaction can be considered 'immediately spent'
I believe it's possible to spend a 0-value output, so they can't be considered automatically spent.

2023-06-07 04:34:27

- reply

📅 Original date posted:2011-10-23
🗒️ Summary of this message: Scopes can legally define variables with conflicting names to those in higher-level scopes.
📝 Original message:It's legal for a scope to define variables with names that conflict with
the names of variables in higher-level scopes.

2023-06-07 04:29:25

- reply

📅 Original date posted:2011-09-26
🗒️ Summary of this message: A limit on coinbase maturity DoS should not immediately kick the node, and a small DoS score seems reasonable.
📝 Original message:On Monday, September 26, 2011 5:53 PM, "Luke-Jr" <luke at dashjr.org> wrote:
> It's not future. It's presently allowed in blocks. Which means it's
> perfectly valid to relay (and also perfectly value to NOT relay or
> accept). Ergo, shouldn't be punished.
Yeah, my node has always relayed these transactions. The limit seems
pointless to me, especially when it's per kB: people will just add
more data.
The coinbase maturity DoS limit should not have a chance of immediately
kicking the node, as I believe this could happen normally in rare cases.
Rejecting these transactions is also pretty cheap, AFAIK. A small DoS
score seems reasonable, though.

2023-06-07 04:27:29

- reply

📅 Original date posted:2011-09-20
🗒️ Summary of this message: The current development model introduces new bugs with code changes, making it risky to fix bugs. A stable version with bugfixes is needed.
📝 Original message:On Monday, September 19, 2011 11:00 AM, "Luke-Jr" <luke at dashjr.org> wrote:
> The problem with the current development model is that bugfixes are
> done alongside improvements, and code changes *always* have the
> potential to introduce new bugs, no matter how careful anyone is. So
> to stay on top of bugfixes right now implies risking new bugs being
> introduced. What good is getting one bug fixed, if it comes with 20
> new yet-to-be-discovered bugs?
A stable version is a good idea. This is why I'm still using 0.3.19
(with some modifications): none of the bugfixes after this version help
me much, and I don't need any of the new features. I've also thought
about starting an unofficial stable version with my modifications to
0.3.19 and some backported bugfixes.

2023-06-07 04:26:02

- reply

📅 Original date posted:2011-09-14
🗒️ Summary of this message: A better retarget strategy for Bitcoin would be to use the real average time between all blocks, but it's not worth forking the chain over. Accurate time is important for discouraging blocks and should not be adjusted by more than 40 minutes.
📝 Original message:A better retarget strategy might be to use the real average time
between all of the blocks in the interval so that no blocks are
treated specially in the calculation. I agree that this is not
important enough to fork the chain over, though. An attacker would
have to maintain control for a *very* long time because of Bitcoin's
long retarget interval. (Maybe this kind of thing is why the retarget
interval is so long?)
I don't like requiring block times to be within minutes of reality. It
would be fine if only miners had to keep accurate time, but clients will
also need to have good time in order to see if a block will be
discouraged. A discouraged block should not count toward confirmations.
If relays will also discourage blocks, then they'll need accurate
time as well.
The network should not be allowed to adjust your time by more than 40
minutes to prevent the timejacking attack, but I don't see a problem
with the other time rules. Time is only used for retargets and LockTime,
so it only needs to be generally accurate.

2023-06-07 04:24:06

- reply

📅 Original date posted:2011-09-08
🗒️ Summary of this message: Deepbit had over 50% of the position multiple times, but no alert was issued as they did not abuse their position.
📝 Original message:On Thursday, September 08, 2011 3:45 PM, "Luke-Jr" <luke at dashjr.org> wrote:
> I don't seem to recall this ever happening, despite Deepbit having over 50%
> multiple times now.
An alert would have been issued if they had abused that position.

2023-06-07 04:24:00

- reply

📅 Original date posted:2011-09-08
🗒️ Summary of this message: Alert system is crucial for network's security against attackers with >50% computational power. GUI client should restrict transactions during alerts.
📝 Original message:The alert system will be very important if there are ever any critical
problems in the network. For example, it is currently Bitcoin's only
defense against an attacker with >50% of the computational power, where
alerts would be used to tell people to stop accepting transactions.
Displaying a message is pretty harmless. In fact, I don't think the
message is prominent enough. The GUI client should not allow people to
see received transactions or send new transactions while an alert is in
effect (with an opt-out), and there should be an opt-in feature that
puts RPC into safe mode in response to an alert.
Alerts are no worse than transactions as a DoS attack vector. They're
much safer than typical HTTPS because there are no CAs that can break
its security.
(FYI: I also have a copy of the alert key.)

2023-06-07 04:18:35

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: The discussion is about enabling new 'standard' multisignature transactions to prevent wallets from getting lost or stolen, but there is concern about taking too long to agree on the details.
📝 Original message:On Wed, 24 Aug 2011 11:12 -0400, "Gavin Andresen" <gavinandresen at gmail.com> wrote:
> To organize this discussion: first, does everybody agree?
Yes. The feature will be very good.
> I still think it is a good idea to enable a set of new 'standard'
> multisignature transactions, so they get relayed and included into
> blocks. I don't want to let "the perfect become the enemy of the
> good" -- does anybody disagree?
Please do enable any transactions that seem to be a possible solution.
Even if this client doesn't ever implement any of them, alternative
clients can try them.
> My biggest worry is we'll say "Sure, it'll only take a couple days to
> agree on how to do it right" and six months from now there is still
> no consensus on exactly which digest function should be used, or
> whether or not there should be a new opcode for arbitrary boolean
> expressions involving keypairs. And people's wallets continue to get
> lost or stolen.
I agree that something should be done with what we have now. It *will*
take months to properly figure out how to add chain-forking features for
this. If we want to consider all of the unrelated feature proposals, it
might take years of discussion...
However, as I said in the forum thread, I think it would be better for
people using this protection to receive at a normal address and then
create new transactions at their end. Then no one has to handle huge
addresses, and the sender will never have to pay abnormal fees or deal
with incompatibilities. There will be a short period of time when the
recipient's money is unprotected, but I think this is worth it. A better
scheme can be made later after chain-forking features are figured out.

2023-06-07 04:16:41

- reply

📅 Original date posted:2011-08-18
🗒️ Summary of this message: Nodes will accept a block as valid even if it is not received first, and double-spend transactions will be rejected by the network.
📝 Original message:> The part of the network that did not receive my block first (which
> hopefully is most of the miners) will accept this as valid and work to
> include it in the next block.
To make this more difficult, nodes that receive new transactions via
blocks should relay the new transactions as if they had received them
normally. Then the double-spend transaction will be rejected by most of
the network because the other version is already widely-known.