David Vorick [ARCHIVE]

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

Public Key

npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0

Profile Code

nprofile1qqs2mj6nek7h9c4qcgj992gg0utnc664ahrm2p8lnwrpa8qz47dg04qr3j8cu

Author Public Key

npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0

Show more details

Last Notes

2023-06-07 18:20:23

- reply

📅 Original date posted:2019-08-20
📝 Original message:Glad to see this post. I have been following Miniscript for some time, and
the static
analysis that is possible with Miniscript is particularly interesting to me.
Today, new Bitcoin applications such as JoinMarket, Wasabi wallet, and
Arwen all
suffer from a problem of having novel bitcoin scripts. Bitcoin script is
not easy to
analyze, and historically it has been difficult for me to get comfortable
using these
applications because I have been unable to convince myself to have complete
confidence in the integrity of the transactions these applications want me
to sign.
Well established applications can eventually overcome this issue for users
by
getting sufficient expert review and commentary, however this proves as a
substantial barrier to entry in an ecosystem that is ideally as open as
possible.
Miniscript can make a huge difference here. With Miniscript, it possible to
create
hardware wallets that can perform static analysis on novel miniscripts and
provide
the user with assurances about the nature of the transactions. A hardware
wallet
with a Miniscript analyzer may not be able to tell you that a transaction
is a
CoinJoin transaction, but it will be able to tell you that under all
possible scenarios,
you end up with just as many coins in your addresses that you started with,
modulo
some transaction fee.
This is a big deal for novel application writers, as it significantly
reduces the barrier
for them to convince both themselves and others that the code they wrote
does not
risk user funds being lost, especially if all transactions are being
externally analyzed
and signed.
Miniscript is not of course a complete solution, for example it cannot
solve all of the
high-risk edge cases that are present in the lightning network, but it is a
big step
forward and I believe that widespread use of Miniscript would be a huge
boon to the
Bitcoin ecosystem.
On Mon, Aug 19, 2019 at 7:18 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Miniscript is a project we've been working on for the past year or so,
> and is now at a stage where I'd like to get it some more attention. It is
> joint
> work with Andrew Poelstra and Sanket Sanjalkar.
>
> It's a language for writing (a subset of) Bitcoin Scripts in a structured
> way,
> enabling analysis, composition, generic signing and more.
>
> For example the script
>
> <A> OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 <hash160(B)>
> OP_EQUALVERIFY OP_CHECKSIGVERIFY <144> OP_CSV OP_ENDIF
>
> in Miniscript notation would be
>
> or_d(c:pk(A),and_v(vc:pk_h(B),older(144)))
>
> making it human (engineer?) readable that this is a script that permits A
> to
> take the coins at any time, and B after 1 day. A full description of the
> language can be found on the project website
> http://bitcoin.sipa.be/miniscript
>
> Using Miniscript it's possible to:
> * Write descriptors for addresses for scripts that implement things more
> complicated than multisig.
> * Make software that can deal with composition of policies (e.g. have funds
> in a 2-of-3 setup where one of the 3 "keys" is itself a policy that
> involves
> perhaps multiple devices and timeouts).
> * Compile complex spending policies to efficient scripts.
> * Figure out under what necessary and/or sufficient conditions a script
> can be
> satisfied.
> * Given signatures for a sufficient set of keys (and hash preimages, if
> needed),
> generically construct a witness for arbitrary scripts, without metadata
> apart from the script itself and public keys appearing in it. This means
> generic PSBT signers are possible for this class of scripts.
> * Compute the bounds on the size of a witness for arbitrary scripts.
> * Perform static analysis to see if any of Script's resource limitations
> (ops limit, stack size, ...) might interfere with the ability to spend.
> * Who knows what else...
>
> We have two implementations:
> * a C++ one (https://github.com/sipa/miniscript)
> * a Rust library (https://github.com/apoelstra/rust-miniscript).
>
> The implementations are a work in progress, but through large scale
> randomized
> tests we have confidence that the language design and associated witnesses
> are
> compatible with the existing consensus and standardness rules.
>
> To be clear: Miniscript is designed for Bitcoin as it exists today
> (primarily
> P2WSH), and does not need any consensus changes. That said, we plan to
> extend
> the design to support future script changes Bitcoin may include.
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190820/7f2e5916/attachment.html>

2023-06-07 18:00:21

- reply

📅 Original date posted:2017-04-19
📝 Original message:On Tue, Apr 18, 2017 at 3:43 AM, Jonas Schnelli <dev at jonasschnelli.ch>
wrote:
>
> Hi Dave
>
> *1. I agree that we need to have a way for pruned nodes to partially serve
> historical blocks.*
> My personal measurements told me that around ~80% of historical block
> serving are between tip and -1’000 blocks.
> Currently, Core nodes have only two modes of operations, „server all
> historical blocks“ or „none“.
> This makes little sense especially if you prune to a target size of, lets
> say, 80GB (~80% of the chain).
> Ideally, there would be a mode where your full node can signal a third
> mode „I keep the last 1000 blocks“ (or make this more dynamic).
>
That probably makes sense with small nodes too. The past 1000 blocks are
such a small footprint compared to the rest of the chain.
>
> *2. Bootstrapping new peers*
> I’m not sure if full nodes must be the single point of historical data
> storage. Full nodes provide a valuable service (verification, relay,
> filtering, etc.). I’m not sure if serving historical blocks is one of them.
> Historical blocks could be made available on CDN’s or other file storage
> networks. You are going to verify them anyways,... the serving part is pure
> data storage.
> I’m also pretty sure that some users have stopping running full nodes
> because their upstream bandwidth consumption (because of serving historical
> blocks) was getting intolerable.
> Especially „consumer“ peers must have been hit by this (little experience
> in how to reduce traffic, upstream in general is bad for
> consumers-connections, little resources in general).
>
Perhaps it is not, but I would think that it would be pretty
straightforward to configure a global bandwidth limit within Bitcoin. I
know many torrent clients, and clients for protocols like Tor and i2p
include the ability to set both speed limits and monthly bandwidth limits.
Shipping core with sane default limits is probably sufficient to solve
bandwidth issues for most users. I don't know if default limits may result
in today's archive nodes pulling less weight though - changing the defaults
to have limits may slow the network down as a whole.
In my experience (living in a city where most people have uncapped
connections), disk usage is usually the bigger issue, but certainly
bandwidth is a known problem (especially for rural users) as well.
>
> Having a second option built into full nodes (or as an external bootstrap
> service/app) how to download historical blocks during bootstrapping could
> probably be a relieve for "small nodes“.
> It could be a little daemon that downloads historical blocks from CDN’s,
> etc. and feeds them into your full node over p2p/8333 and kickstarts your
> bootstrapping without bothering valuable peers.
> Or, the alternative download, could be built into the full nodes main
> logic.
> And, if it wasn’t obvious, this must not bypass the verification!
>
I worry about any type of CDN being a central point of failure. CDNs cost
money, which means someone is footing the bill. Torrenting typically relies
on a DHT, which is much easier to attack than Bitcoin's peer network. It's
possible that a decentralized CDN could be used, but I don't think any yet
exist (though I am building one for unrelated reasons) which are both
sufficiently secure and incentive-compatible to be considered as an
alternative to using full nodes to bootstrap.
I just don't want to end up in a situation where 90% of users are getting
their blockchain from the same 3 websites or centralized services. And I
also don't want to rely on any p2p solution which would not stand up to a
serious adversary. Right now, I think the bitcoin p2p network is by
significant margin the best we've got. The landscape for decentralized data
distribution is evolving rapidly though, perhaps in a few years there will
be a superior alternative.
> *To your proposal:*
> - Isn’t there a tiny finger-printing element if peers have to pick an
> segmentation index?
> - SPV bloom filter clients can’t use fragmented blocks to filter txns?
> Right? How could they avoid connecting to those peers?
>
> </jonas>
>
Yes, there is finger-print that happens if you have nodes pick an index.
And the fingerprint gets a lot worse if you have a node pick multiple
indexes. Though, isn't it already required that nodes have some sort of IP
address or hidden service domain? I want to say that the fingerprint
created by picking an index is not a big deal, because it can be separated
from activity like transaction relaying and mining. Though, I am not
certain and perhaps it is a problem.
To be honest, I hadn't really considered SPV nodes at the time of writing.
Small nodes would still be seeing all of the new blocks, and per your
suggestion may also be storing the 1000 or so most recent blocks, but SPV
nodes would still need some way to find all of their historical
transactions. The problem is not fetching blocks, it's figuring out which
blocks are worth fetching. It may be sufficient to have nodes store a bloom
filter for each block indicating which addresses had activity. The bloom
filter would probably only need to be about 1% of the size of the full
block. That's not too much overhead (now you are storing 21% of the block
instead of just 20%), and would retain SPV compatibility.
On Mon, Apr 17, 2017 at 12:17 PM, praxeology_guy <
praxeology_guy at protonmail.com> wrote:
>
> FYI With unspent coin snapshots, needing archive data becomes less
> important. People can synchronize from a later snapshot instead of the
> genesis block. See https://petertodd.org/2016/delayed-txo-commitments
> for my current favorite idea.
>
>
This is something that I think could help a lot too. If the build processes
included verifying the chain and then creating a utxo snapshot at say,
block 400,000, then nodes would no longer need to download, store, upload,
or share blocks prior to that height. It means that a reorg deeper than
that point would hardfork the network. But a reorg 60k blocks deep is going
to cause problems worse than a network split. Then, the only people who
would ever need to care about the early blocks are developers, and it's
more reasonable to expect developers to go through a longer process and
have more resources than everyday users.
On Mon, Apr 17, 2017 at 6:14 AM, Aymeric Vitte via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> While I fully agree with the intent (increasing full nodes so a big miner
> waking up in a bad mood can't threaten the world any longer every day as it
> is now) I am not sure to get the interest of this proposal, because:
>
> - it's probably not a good idea to encourage the home users to run full
> nodes, there are many people running servers far from their capacity that
> could easily run efficient full nodes
>
Running a full node is the only way to avoid needing to trust others. It's
also how you make your opinion worthwhile for events like hard forks and
UASFs. If decentralization is the primary motivation, it absolutely makes
sense to encourage people to run their own full nodes. Without a full node,
you are at the mercy of the governance decisions by those who do have full
nodes. But if you have a full node, you can chose to opt-out of any upgrade
(example: ethereum classic nodes).
> - if someone can't allocate 100 GB today to run a full node, then we can't
> expect him to allocate more in the future
>
That's why I'm proposing something to decrease the storage requirements.
> - this proposal is a kind of reinventing torrents, while limiting the
> number of connections to something not efficient at all, I don't see why
> something that is proven to be super efficient (torrents) would be needed
> to be reinvented, I am not saying that it should be used as the bittorrent
> network is doing but the concepts can be reused
>
It's different from torrents in that it uses specialized erasure coding to
make sure that every block is always available, even if an adversary is
running around targeting all the nodes with a particular piece.
> - I don't get at all the concept of "archival" nodes since it's another
> useless step toward centralization
>
"archival" nodes are simply nodes with the full blockchain. Nobody can
bootstrap on the network without them. Today, every bitcoin-core node is an
archival node by default.
> I think the only way to increase full nodes it to design an incentive for
> people to run them
>
The primary incentive is the sovereignty that it gives you. Running a
Bitcoin full node gives you security and protection against political
garbage that you can't get any other way. The network does currently depend
on altruism to allow people to download the blockchain, but as long as we
can keep the resource requirements of this altruism low, I think we can
expect it to continue. This proposal attempts to keep those requirements
low.
On Tue, Apr 18, 2017 at 6:50 AM, Tom Zander <tomz at freedommail.ch> wrote:
> On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote:
> > The best alternative today to storing the full blockchain is to run a
> > pruned node
>
> The idea looks a little overly complex to me.
>
> I suggested something similar which is a much simpler version;
> https://zander.github.io/scaling/Pruning/
>
> > # Random pruning mode
> >
> > There is a large gap between the two current modes of everything
> > (currently 75GB) and only what we need (2GB or so).
> >
> > This mode would have two areas, it would keep a days worth of blocks to
> > make sure that any reorgs etc would not cause a re-download, but it would
> > have additionally have an area that can be used to store historical data
> > to be shared on the network. Maybe 20 or 50GB.
> >
> > One main feature of Bitcoin is that we have massive replication. Each
> node
> > currently holds all the same data that every other node holds. But this
> > doesn't have to be the case with pruned nodes. A node itself has no need
> > for historic data at all.
> >
> > The suggestion is that a node stores a random set of blocks. Dropping
> > random blocks as the node runs out of disk-space. Additionally, we would
> > introduce a new way to download blocks from other nodes which allows the
> > node to say it doesn't actually have the block requested.
> >
> > The effect of this setup is that many different nodes together end up
> > having the total amount of blocks, even though each node only has a
> > fraction of the total amount.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
>
Your proposal has a significant disadvantage: If every peer is dropping 75%
of all blocks randomly, then you need to connect to a large number of peers
to download the whole blockchain. Any given peer has a 25% chance of
holding a block, or rather, a 75% chance of not holding a block. If you
have n peers, your probability of not being able to download a given block
is 0.75^n. If you are downloading 450,000 blocks, you will need to connect
to an expected 46 peers to download the whole blockchain.
Your proposal is also a lot less able to handle active adversaries: if
nodes are randomly dropping blocks, the probability that one block in
particular is dropped by everyone goes up significantly. And the problem
gets a lot worse in the presence of an active adversary. If there are 8000
nodes each dropping 75% of the blocks, then each block on average will only
be held by 2000 nodes. Probabilistically, some unlucky blocks will be held
by fewer than 2000 nodes. An active adversary needs only to eliminate about
2000 nodes (a chosen 2000 nodes) to knock a block off of the network. But
missing even a single block is a significant problem.
Your proposal essentially requires that archive nodes still exist and be a
part of a typical blockchain download. Given that, I don't think it would
be a sound idea to ship as a default in bitcoin core.
On Tue, Apr 18, 2017 at 9:07 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This has been discussed before.
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2015-May/008101.html
>
> including a list of nice to have features by Maxwell
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2015-May/008110.html
>
> You meet most of these rules, though you do have to download blocks from
> multiple peers.
>
> The suggestion in that thread were for a way to compactly indicate which
> blocks a node has. Each node would then store a sub-set of all the
> blocks. You just download the blocks you want from the node that has them.
>
> Each node would be recommended to store the last few days worth anyway.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
I believe that my proposal does meet all of the requirements listed by
Maxwell. Having a set of 8 random peers gives you a very high probability
of being able to recover every single block. You would need to connect to
at least 5 peers (and this is already >90% likely to be sufficient to
recover every block), but if you cannot connect to 5 random peers your node
is probably in trouble anyway. Highly parallel, high speed downloads are
just as possible with small nodes as with archive nodes. It only takes a
few bytes to indicate which part of the blockchain you have, and any 2
peers have a less than 1% chance of overlapping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170419/88f15eb2/attachment-0001.html>

2023-06-07 18:00:18

- reply

📅 Original date posted:2017-04-17
📝 Original message:Most people do not want to go out and buy new hardware to run a Bitcoin
node. The want to use the hardware that they already own, and usually that
hardware is going to have a non-generous amount of disk space. 500GB SSD
with no HDD is common in computers today.
But really, the best test is to go out and talk to people. Ask them if they
run a full node, and if they say no, ask them why not. In my experience,
the most common answer by a significant margin is that they don't want to
lose the disk space. That psychology is far more important than any example
of cheap hard drives. People don't want to go out and buy a hard drive so
that they can run Bitcoin. It's a non-starter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/11863db8/attachment.html>

2023-06-07 18:00:17

- reply

📅 Original date posted:2017-04-17
📝 Original message:*Rationale:*
A node that stores the full blockchain (I will use the term archival node)
requires over 100GB of disk space, which I believe is one of the most
significant barriers to more people running full nodes. And I believe the
ecosystem would benefit substantially if more users were running full nodes.
The best alternative today to storing the full blockchain is to run a
pruned node, which keeps only the UTXO set and throws away already verified
blocks. The operator of the pruned node is able to enjoy the full security
benefits of a full node, but is essentially leeching the network, as they
performed a large download likely without contributing anything back.
This puts more pressure on the archival nodes, as the archival nodes need
to pick up the slack and help new nodes bootstrap to the network. As the
pressure on archival nodes grows, fewer people will be able to actually run
archival nodes, and the situation will degrade. The situation would likely
become problematic quickly if bitcoin-core were to ship with the defaults
set to a pruned node.
Even further, the people most likely to care about saving 100GB of disk
space are also the people least likely to care about some extra bandwidth
usage. For datacenter nodes, and for nodes doing lots of bandwidth, the
bandwidth is usually the biggest cost of running the node. For home users
however, as long as they stay under their bandwidth cap, the bandwidth is
actually free. Ideally, new nodes would be able to bootstrap from nodes
that do not have to pay for their bandwidth, instead of needing to rely on
a decreasing percentage of heavy-duty archival nodes.
I have (perhaps incorrectly) identified disk space consumption as the most
significant factor in your average user choosing to run a pruned node or a
lite client instead of a full node. The average user is not typically too
worried about bandwidth, and is also not typically too worried about
initial blockchain download time. But the 100GB hit to your disk space can
be a huge psychological factor, especially if your hard drive only has
500GB available in the first place, and 250+ GB is already consumed by
other files you have.
I believe that improving the disk usage situation would greatly benefit
decentralization, especially if it could be done without putting pressure
on archival nodes.
*Small Nodes Proposal:*
I propose an alternative to the pruned node that does not put undue
pressure on archival nodes, and would be acceptable and non-risky to ship
as a default in bitcoin-core. For lack of a better name, I'll call this new
type of node a 'small node'. The intention is that bitcoin-core would
eventually ship 'small nodes' by default, such that the expected amount of
disk consumption drops from today's 100+ GB to less than 30 GB.
My alternative proposal has the following properties:
+ Full nodes only need to store ~20% of the blockchain
+ With very high probability, a new node will be able to recover the entire
blockchain by connecting to 6 random small node peers.
+ An attacker that can eliminate a chosen+ 95% of the full nodes running
today will be unable to prevent new nodes from downloading the full
blockchain, even if the attacker is also able to eliminate all archival
nodes. (assuming all nodes today were small nodes instead of archival nodes)
Method:
A small node will pick an index [5, 256). This index is that node's
permanent index. When storing a block, instead of storing the full block,
the node will use Reed-Solomon coding to erasure code the block using a
5-of-256 scheme. The result will be 256 pieces that are 20% of the size of
the block each. The node picks the piece that corresponds to its index, and
stores that instead. (Indexes 0-4 are reserved for archival nodes -
explained later)
The node is now storing a fragment of every block. Alone, this fragment
cannot be used to recover any piece of the blockchain. However, when paired
with any 5 unique fragments (fragments of the same index will not be
unique), the full block can be recovered.
Nodes can optionally store more than 1 fragment each. At 5 fragments, the
node becomes a full archival node, and the chosen indexes should be 0-4.
This is advantageous for the archival node as the encoded data for the
first 5 indexes will actually be identical to the block itself - there is
no computational overhead for selecting the first indexes. There is also no
need to choose random indexes, because the full block can be recovered no
matter which indexes are chosen.
When connecting to new peers, the indexes of each peer needs to be known.
Once peers totaling 5 unique indexes are discovered, blockchain download
can begin. Connecting to just 5 small node peers provides a >95% chance of
getting 5 uniques, with exponentially improving odds of success as you
connect to more peers. Connecting to a single archive node guarantees that
any gaps can be filled.
A good encoder should be able to turn a block into a 5-of-256 piece set in
under 10 milliseconds using a single core on a standard consumer desktop.
This should not slow down initial blockchain download substantially, though
the overhead is more than a rounding error.
*DoS Prevention:*
A malicious node may provide garbage data instead of the actual piece.
Given just the garbage data and 4 other correct pieces, it is impossible
(best I know anyway) to tell which piece is the garbage piece.
One option in this case would be to seek out an archival node that could
verify the correctness of the pieces, and identify the malicious node.
Another option would be to have the small nodes store a cryptographic
checksum of each piece. Obtaining the cryptographic checksum for all 256
pieces would incur a nontrivial amount of hashing (post segwit, as much as
100MB of extra hashing per block), and would require an additional ~4kb of
storage per block. The hashing overhead here may be prohibitive.
Another solution would be to find additional pieces and brute-force
combinations of 5 until a working combination was discovered. Though this
sounds nasty, it should take less than five seconds of computation to find
the working combination given 5 correct pieces and 2 incorrect pieces. This
computation only needs to be performed once to identify the malicious peers.
I also believe that alternative erasure coding schemes exist which actually
are able to identify the bad pieces given sufficient good pieces, however I
don't know if they have the same computational performance as the best
Reed-Solomon coding implementations.
*Deployment:*
Small nodes are completely useless unless the critical mass of 5 pieces can
be obtained. The first version that supports small node block downloads
should default everyone to an archival node (meaning indexes 0-4 are used)
Once there are enough small-node-enabled archive nodes, the default can be
switched so that nodes only have a single index by default. In the first
few days, when there are only a few small nodes, the previously-deployed
archival nodes can help fill in the gaps, and the small nodes can be useful
for blockchain download right away.
----------------------------------
This represents a non-trivial amount of code, but I believe that the result
would be a non-trivial increase in the percentage of users running full
nodes, and a healthier overall network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170417/513fc363/attachment.html>

2023-06-07 17:59:51

- reply

📅 Original date posted:2017-04-09
📝 Original message:On Apr 9, 2017 7:00 PM, "Jared Lee Richardson via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
I can speak from personal experience regarding another very prominent
altcoin that attempted to utilize an asic-resistant proof of work
algorithm, it is only a matter of time before the "asic resistant"
algorithm gets its own Asics. The more complicated the algorithm, the more
secretive the asic technology is developed. Even without it,
multi-megawatt gpu farms have already formed in the areas of the world with
low energy costs. I'd support the goal if I thought it possible, but I
really don't think centralization of mining can be prevented.
On Apr 9, 2017 1:16 PM, "Erik Aronesty via bitcoin-dev" <bitcoin-dev at lists.
linuxfoundation.org> wrote:
> Curious: I'm not sure why a serious discussion of POW change is not on the
> table as a part of a longer-term roadmap.
>
> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
> the proven, np-complete graph-theoretic or polygon manipulation POW would
> keep Bitcoin in commodity hardware and out of the hands of centralized
> manufacturing for many years.
>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term. I've heard the
> term "level playing field" bandied about quite a bit. And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware. Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a
> part of good maintenance of cryptocurrency in general. Killing the
> existing POW, and using an as-yet undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year.... A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date. This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
The real bottleneck today is the amount of capex required to achieve
optimal mining. I am strongly in favor of PoW research that investigates
better PoW, but I do not think that any obvious strategies are known yet to
improve substantially on computation heavy hashcash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170409/76d8a516/attachment.html>

2023-06-07 17:59:28

- reply

📅 Original date posted:2017-04-06
📝 Original message:>
> Another thing that could be done is increase the number of times SHA256 is
> performed... but now we are really talking about altering the PoW
> algorithm. Correct me if I'm wrong: The more number of times its
> performed, the less any patent-able pre or post calculation
> skipping/caching have an effect on efficiency.
>
The more complex that the PoW algorithm is, the more likely it is that
someone finds a unique and special method for optimizing it that they are
able to patent. And the more difficult it is to create specialized hardware
to run that algorithm, meaning that there will be fewer players who are
able to do so profitably (higher fixed costs).
If you want to talk about changing the PoW algorithm, you really want to be
looking to simplify it so that it's more obvious (not that you can ever be
completely sure) that there are no hidden or unexpected optimizations that
someone could patent.
We can even do a lot better than SHA. Cryptographic hash functions need to
be collision resistant, and collision resistance is the property that
usually breaks. Preimage resistance and partial preimage resistance (and
second preimage resistance) is generally easier to protect - to the best of
our knowledge, md5 would actually still be a secure PoW function today.
It's bitterly ironic to me that so much research and effort has been put
into making asic-resistant PoW algorithms when in the long run
asic-resistance only leads to problems like these - single parties who have
found significant optimizations and not shared them, completely destroying
any chance of a level playing field and giving themselves a centralized
monopoly - a result that is supremely unhealthy for the rest of the
community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/35d33b8c/attachment.html>

2023-06-07 17:59:19

- reply

📅 Original date posted:2017-04-06
📝 Original message:On Thu, Apr 6, 2017 at 2:24 AM, Jonathan Toomim via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Ethically, this situation has some similarities to the DAO fork. We have
> an entity who closely examined the code, found an unintended characteristic
> of that code, and made use of that characteristic in order to gain tens of
> millions of dollars. Now that developers are aware of it, they want to
> modify the code in order to negate as much of the gains as possible.
>
> There are differences, too, of course: the DAO attacker was explicitly
> malicious and stole Ether from others, whereas Bitmain is just optimizing
> their hardware better than anyone else and better than some of us think
> they should be allowed to.
>
> In both cases, developers are proposing that the developers and a majority
> of users collude to reduce the wealth of a single entity by altering the
> blockchain rules.
>
> In the case of the DAO fork, users were stealing back stolen funds, but
> that justification doesn't apply in this case. On the other hand, in this
> case we're talking about causing someone a loss by reducing the value of
> hardware investments rather than forcibly taking back their coins, which is
> less direct and maybe more justifiable.
>
> While I don't like patented mining algorithms, I also don't like the idea
> of playing Calvin Ball on the blockchain. Rule changes should not be
> employed as a means of disempowering and empoverishing particular entities
> without very good reason. Whether patenting a mining optimization qualifies
> as good reason is questionable.
>
Bitmain is blocking protocol upgrades to preserve their mining advantage.
This is quite distinct from someone taking advantage of a visibly broken
and highly toxic smart contract to net themselves tens of millions of
dollars. Further, Bitmain is performing a patented hardware optimization.
The patents mean that other miners are unable to capitalize on these
optimizations. These optimizations are to the tune of 30%. If you give one
player in the mining industry a permanent 30% cost advantage they will
eventually own everything. It's an industry where margins tend towards zero.
The asicboost patent is a direct threat to the health of the Bitcoin
ecosystem, and now we have visible proof. The war against segwit and the
strife with Bitcoin Unlimited was very damaging to the ecosystem, damaging
to the price, and holding back significant improvements and upgrades to the
Bitcoin protocol. I interpret this as a direct attack on the Bitcoin
ecosystem.
I don't know if changing the rules to nullify asicboost is the right move.
I'm sure this won't be the last patent that causes damage to the ecosystem.
But you need to recognize that the issue is not that Bitmain ran a hardware
optimization. It's that hardware optimizations exist which directly inhibit
upgrading the protocol. And it's that hardware optimizations exist
encumbered by patents enough to give one party a decisive advantage in
mining, decisive enough for them to build a single, centralized monopoly.
Each problem is separate, and each problem is significant, and each problem
is fundamental. The DAO attack was a one-time bout of stupidity that
threatened a fixed amount of money. asicboost is an ongoing status that
directly damages Bitcoin's ability to upgrade, and directly damage
Bitcoin's ability to retain any modicum of decentralization in the
hashrate. The DAO issue did neither of these things for ethereum.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/5ed69d3a/attachment.html>

2023-06-07 17:59:18

- reply

📅 Original date posted:2017-04-06
📝 Original message:I have a practical concern related to the amount of activation energy
required to get something like this through. We are talking about
implementing something that would remove tens to hundreds of millions of
dollars of mining revenue for miners who have already gambled that this
income would be available to them.
That's not something they are going to let go of without a fight, and we've
already seen this with the segwit resistance. Further, my understanding is
that this makes a UASF a lot more difficult. Mining hardware that has
unique optimizations on one chain only can resist a UASF beyond a simple
economic majority, because they can do more hashes on the same amount of
revenue. Threshold for success is no longer 51%, especially if you are
expecting the miners to struggle (and this is a case where they have a very
good reason to struggle). Any resistance from the hashrate during the early
days of a UASF will inevitably cause large reorgs for older nodes, and is
not much better than a hardfork.
I don't know what the right answer is. But I know that we are not going to
get segwit without a fight. We are not going to invalidate covert asicboost
without a fight. And we are working with a system that actively (and is
demonstrably very effective at doing it) resists changes which are
contentious. This is definitely a contentious change, because an important
part of the community (the miners) is going to be actively resisting it.
I urge everybody to realize how difficult something like this is going to
be to pull off. We are literally talking about invalidating hardware (or at
least the optimized bits). It's only going to succeed if everybody is
conclusively on board. As you consider proposals, realize that anything
which is not the simplest and least contentious is already dead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/e22feba7/attachment.html>

2023-06-07 17:58:33

- reply

📅 Original date posted:2017-03-30
📝 Original message:On Mar 30, 2017 12:04 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Raystonn,
Your logic is very hard to dispute. An important special case is small
miners.
Small miners use pools exactly because they want smaller, more frequent
payments.
Rising fees force them to take payments less frequently, and will only tend
to make more of them give up.
With fees rising superlinearly, this centralizing effect is much stronger
than the oft-cited worry of small miners joining large pools to decrease
orphan rates.
Miners get paid on average once every ten minutes. The size of fees and the
number of fee transactions does not change the payout rate.
Further, we are very far from the point (in my appraisal) where fees are
high enough to block home users from using the network.
Bitcoin has many high-value use cases such as savings. We should not throw
away the core innovation of monetary sovereignty in pursuit of supporting
0.1% of the world's daily transactions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/92e8b405/attachment.html>

2023-06-07 17:58:29

- reply

📅 Original date posted:2017-03-31
📝 Original message:Sure, your math is pretty much entirely irrelevant because scaling systems
to massive sizes doesn't work that way.
At 400B transactions per year we're looking at block sizes of 4.5 GB, and a
database size of petabytes. How much RAM do you need to process blocks like
that? Can you fit that much RAM into a single machine? Okay, you can't fit
that much RAM into a single machine. So you have to rework the code to
operate on a computer cluster.
Already we've hit a significant problem. You aren't going to rewrite
Bitcoin to do block validation on a computer cluster overnight. Further,
are storage costs consistent when we're talking about setting up clusters?
Are bandwidth costs consistent when we're talking about setting up
clusters? Are RAM and CPU costs consistent when we're talking about setting
up clusters? No, they aren't. Clusters are a lot more expensive to set up
per-resource because they need to talk to eachother and synchronize with
eachother and you have a LOT more parts, so you have to build in
redundancies that aren't necessary in non-clusters.
Also worth pointing out that peak transaction volumes are typically 20-50x
the size of typical transaction volumes. So your cluster isn't going to
need to plan to handle 15k transactions per second, you're really looking
at more like 200k or even 500k transactions per second to handle
peak-volumes. And if it can't, you're still going to see full blocks.
You'd need a handful of experts just to maintain such a thing. Disks are
going to be failing every day when you are storing multiple PB, so you
can't just count a flat cost of $20/TB and expect that to work. You're
going to need redundancy and tolerance so that you don't lose the system
when a few of your hard drives all fail within minutes of eachother. And
you need a way to rebuild everything without taking the system offline.
This isn't even my area of expertise. I'm sure there are a dozen other
significant issues that one of the Visa architects could tell you about
when dealing with mission-critical data at this scale.
--------
Massive systems operate very differently and are much more costly per-unit
than tiny systems. Once we grow the blocksize large enough that a single
computer can't do all the processing all by itself we get into a world of
much harder, much more expensive scaling problems. Especially because we're
talking about a distributed system where the nodes don't even trust each
other. And transaction processing is largely non-parallel. You have to
check each transaction against each other transaction to make sure that
they aren't double spending eachother. This takes synchronization and
prevents 500 CPUs from all crunching the data concurrently. You have to be
a lot more clever than that to get things working and consistent.
When talking about scalability problems, you should ask yourself what other
systems in the world operate at the scales you are talking about. None of
them have cost structures in the 6 digit range, and I'd bet (without
actually knowing) that none of them have cost structures in the 7 digit
range either. In fact I know from working in a related industry that the
cost structures for the datacenters (plus the support engineers, plus the
software management, etc.) that do airline ticket processing are above $5
million per year for the larger airlines. Visa is probably even more
expensive than that (though I can only speculate).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/229b0e3d/attachment.html>

2023-06-07 17:58:28

- reply

📅 Original date posted:2017-03-31
📝 Original message:No one is suggesting anything like this. The cost of running a node
that could handle 300% of the 2015 worldwide nonbitcoin transaction
volume today would be a rounding error for most exchanges even if
prices didn't rise.
Then explain why PayPal has multiple datacenters. And why Visa has multiple
datacenters. And why the banking systems have multiple datacenters each.
I'm guessing it's because you need that much juice to run a global payment
system at the transaction volumes that they run at.
Unless you have professional experience working directly with transaction
processors handling tens of millions of financial transactions per day, I
think we can fully discount your assessment that it would be a rounding
error in the budget of a major exchange or Bitcoin processor to handle that
much load. And even if it was, it wouldn't matter because it's extremely
important to Bitcoin's security that it's everyday users are able to and
are actively running full nodes.
I'm not going to take the time to refute everything you've been saying but
I will say that most of your comments have demonstrated a similar level of
ignorance as the one above.
This whole thread has been absurdly low quality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170331/5ce1e10b/attachment.html>

2023-06-07 17:58:26

- reply

📅 Original date posted:2017-03-30
📝 Original message:> What we want is a true fee-market where the miner can decide to make a
block
> smaller to get people to pay more fees, because if we were to go to 16MB
> blocks in one go, the cost of the miner would go up, but his reward based
on
> fees will go down!
> A block so big that 100% of the transactions will always be mined in the
> next block will just cause a large section of people to no longer feel the
> need to pay fees.
> As such I don’t fear the situation where the block size limit goes up a
lot
> in one go, because it is not in anyone’s interest to make the actual block
> size follow.
There have been attacks demonstrated where a malicious miner with
sufficient hashrate can leverage large blocks to exacerbate selfish mining.
Adversarial behaviors from miners need to be considered, it's not safe to
simply assume that a miner won't have reasons to attack the network. We
already know that large empty blocks (rather, blocks with fake
transactions) can be leveraged in ways that both damages the network and
increases miner profits.
In general, fear of other currencies passing Bitcoin is unsubstantiated.
Bitcoin has by far the strongest development team, and also is by far the
most decentralized. To the best of my knowledge, Bitcoin is the only
cryptocurrency out there that is both not-dead and also lacks a strong
central leadership.
A coin like ethereum may even be able to pass Bitcoin in market cap. But
that's okay. Ethereum has very different properties and it's not something
I would trust as a tool to provide me with political sovereignty. Ethereum
passing Bitcoin in market cap does not mean that it has proved superior to
Bitcoin. It could just mean that enterprises are really excited about
permissioned blockchains. That's not interesting to me at any market cap.
Bitcoin's core value add is and should continue to be decentralization and
trustlessness. Nobody is remotely close to competing with Bitcoin on those
fronts, and in my mind that's far more important than any of the other
mania anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170330/8cc36f43/attachment.html>

2023-06-07 17:58:20

- reply

📅 Original date posted:2017-03-29
📝 Original message:> > When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
> Why is that a given? Is there math that outlines what the risk levels
are for various configurations of node distributions, vulnerabilities,
etc? How does one even evaluate the costs versus the benefits of node
costs versus transaction fees?
It's a political assessment. Full nodes are the ultimate arbiters of
consensus. When a contentious change is suggested, only the full nodes have
the power to either accept or reject this contentious change. If home users
are not running their own full nodes, then home users have to trust and
rely on other, more powerful nodes to represent them. Of course, the more
powerful nodes, simply by nature of having more power, are going to have
different opinions and objectives from the users. And it's impossible for
5000 nodes to properly represent the views of 5,000,000 users. Users
running full nodes is important to prevent political hijacking of the
Bitcoin protocol. Running a full node yourself is the only way to guarantee
(in the absence of trust - which Bitcoin is all about eliminating trust)
that changes you are opposed to are not introduced into the network.
> Disk space is not the largest cost, either today or in the future.
Without historical checkpointing in some fashion, bandwidth costs are more
than 2 orders of magnitude higher cost than every other cost for full
listening nodes.
This statement is not true for home users, it is true for datacenter nodes.
For home users, 200 GB of bandwidth and 500 GB of bandwidth largely have
the exact same cost. I pay a fixed amount of money for my internet, and if
I use 500 GB the cost is identical to if I use 200 GB. So long as bandwidth
is kept under my home bandwidth cap, bandwidth for home nodes is _free_.
Similarly, disk space may only be $2/TB in bulk, but as a home user I have
a $1000 computer with 500 GB of total storage, 100 GB seems
(psychologically) to cost a lot closer to $200 than to $2. And if I go out
and buy an extra drive to support Bitcoin, it's going to cost about $50 no
matter what drive I pick, because that's just how much you have to spend to
get a drive. The fact that I get an extra 900 GB that I'm not using is
irrelevant - I spent $50 explicitly so I could run a bitcoin node.
The financials of home nodes follow a completely different math than the
costs you are citing by quoting datacenter prices.
> I don't know how to evaluate the impacts of RAM or CPU usage, or
consequently electricity usage for a node yet. I'm open to quantifying any
of those if there's a method, but it seems absurd that ram could even
become a signficant factor given the abundance of cheap ram nowadays with
few programs needing it.
Many home machines only have 4GB of RAM. (I am acutely aware of this
because my own software consumes about 3.5GB of RAM, which means all of our
users stuck at 4 GB cannot use my software and Chrome at the same time).
0.14 uses more than 1 GB of RAM. This I think is not really a problem for
most people, but it becomes a problem if the amount of RAM required grows
enough that they can't have all of their programs open at the same time.
1GB I think is really the limit you'd want to have before you'd start
seeing users choose not to run nodes simply because they'd rather have 300
tabs open instead.
CPU usage I think is pretty minimal. Your node is pretty busy during IBD
which is annoying but tolerable. And during normal usage a user isn't even
going to notice. Same for electricity. They aren't going to notice at the
end of the month if their electricity bill is a dollar higher because of
Bitcoin.
> The consequence of your logic that holds node operational costs down is
that transaction fees for users go up, adoption slows as various use cases
become impractical, price growth suffers, and alt coins that choose lower
fees over node cost concerns will exhibit competitive growth against
Bitcoin's crypto-currency market share. Even if you are right, that's
hardly a tradeoff not worth thoroughly investigating from every angle, the
consequences could be just as dire for Bitcoin in 10 years as it would be
if we made ourselves vulnerable.
This is very much worth considering. If transaction fees are so high that
there is no use case at all for people unwilling to buy extra hardware for
Bitcoin (a dedicated node or whatever), then there is no longer a reason to
worry about these people as users. However, I think the fees would have to
get in the $50 range for that to start to be the case. When talking about
emergency funds - that is, $10k+ that you keep in case your government
defaults, hyperinflates, seizes citizen assets, etc. etc. (situations that
many Bitcoin users today have to legitimately worry about), then you are
going to be making a few transactions per year at most, and the cost of
fees on a home node may be $150 / yr, while the cost of dedicated hardware
might be $150/yr ($600 box amortized over 4 years). We are two orders of
magnitude away from this type of fee pressure, so I think it continues to
make sense to be considering the home nodes as the target that we want to
hit.
> What about periodically committing the entire UTXO set to a special
checkpoint block which becomes the new de facto Genesis block?
This should be discussed in another thread but I don't think I'm alone in
saying that I think this could actually be done in a secure / safe /
valuable way if you did it correctly. It would reduce bandwidth pressure on
archive nodes, reduce disk pressure on full nodes, and imo make for a more
efficient network overall.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/930defe5/attachment-0001.html>

2023-06-07 17:58:17

- reply

📅 Original date posted:2017-03-29
📝 Original message:On Mar 29, 2017 12:20 PM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
wrote:
What's stopping these users from running a pruned node? Not every node
needs to store a complete copy of the blockchain.
Pruned nodes are not the default configuration, if it was the default
configuration then I think you would see far more users running a pruned
node.
But that would also substantially increase the burden on archive nodes.
Further discussion about disk space requirements should be taken to another
thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/9f1bb665/attachment.html>

2023-06-07 17:58:14

- reply

📅 Original date posted:2017-03-29
📝 Original message:Perhaps you are fortunate to have a home computer that has more than a
single 512GB SSD. Lots of consumer hardware has that little storage. Throw
on top of it standard consumer usage, and you're often left with less than
200 GB of free space. Bitcoin consumes more than half of that, which feels
very expensive, especially if it motivates you to buy another drive.
I have talked to several people who cite this as the primary reason that
they are reluctant to join the full node club.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/68629ee3/attachment.html>

2023-06-07 17:58:06

- reply

📅 Original date posted:2017-03-29
📝 Original message:On Mar 29, 2017 9:50 AM, "Martin Lízner via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Im tending to believe, that HF is necessary evil now.
I will firmly disagree. We know how to do a soft-fork blocksize increase.
If it is decided that a block size increase is justified, we can do it with
extension blocks in a way that achieves full backwards compatibility for
all nodes.
Barring a significant security motivation, there is no need to hardfork.
I am also solidly unconvinced that increasing the blocksize today is a good
move, even as little as SegWit does. It's too expensive for a home user to
run a full node, and user-run full nodes are what provide the strongest
defence against political manuveuring.
When considering what block size is acceptable, the impact of running
bitcoin in the background on affordable, non-dedicated home-hardware should
be a top consideration.
Disk space I believe is the most significant problem today, with RAM being
the second most significant problem, and finally bandwidth consumption as
the third most important consideration. I believe that v0.14 is already too
expensive on all three fronts, and that block size increases shouldn't be
considered at all until the requirements are reduced (or until consumer
hardware is better, but I believe we are talking 3-7 years of waiting if we
pick that option).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170329/873b902d/attachment.html>

2023-06-07 17:57:26

- reply

📅 Original date posted:2017-03-20
📝 Original message:I am in support of having multiple PoW forks to choose from, but it is
indeed problematic to have one chain running a rotation of algorithms.
The reason I support multiple algos is because we don't want an attacker
secretly making asics ahead of time in the event of an emergency PoW fork.
We want them to be uncertain which of a large selection of algorithms are
going to be used, making pre-emptive asic manufacturing more difficult.
But once an algorithm is chosen that should be the end of the story, just
one algo without rotation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170320/ceaa8c60/attachment.html>

2023-06-07 17:57:16

- reply

📅 Original date posted:2017-03-13
📝 Original message:That's simply a 51% attack choosing to censor transactions. We could do
that today, ban all transactions that aren't approved by the PBoC.
You respond to that with a PoW hardfork, or by finding some way to prop up
/ subsidize non-censorship miners.
On Mar 13, 2017 5:59 AM, "Nick ODell via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The problem with modifying Bitcoin to work around community norms is that
> it's a two-way street. Other people can do it too.
>
> Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
> fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
> 1506812400. It enforces every rule that UASF enforces, plus one additional
> rule. If 60% of blocks in any retargeting period signal for Double UASF,
> any descendant block that creates or spends a segregated witness output is
> invalid.
>
> Double UASF signaling never coincides with UASF signaling, because the
> signaling periods don't overlap. Full nodes happily validate the chain,
> because Double UASF doesn't break any rules; it just adds new ones. Miners
> who adopt Double UASF don't need to understand segwit, because all segwit
> transactions are banned. Miners don't need to commit to a wtxid structure,
> either. Per BIP 141, "If all transactions in a block do not have witness
> data, the commitment is optional." Segwit is activated, but useless. Miners
> who *do* adopt segwit will lose money, as their blocks are orphaned.
>
> Thanks,
> --Nick
>
> On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I recently posted about so called "user activated soft forks" and
>> received a lot of feedback. Much of this was how such methodologies could
>> be applied to segwit which appears to have fallen under the miner veto
>> category I explained in my original proposal, where there is apparently a
>> lot of support for the proposal from the economy, but a few mining pools
>> are vetoing the activation.
>>
>> It turns out Bitcoin already used flag day activation for P2SH[1
>> <https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283>],
>> a soft fork which is remarkably similar to segwit. The disadvantage of a
>> UASF for segwit is there is an existing deployment. A UASF would require
>> another wide upgrade cycle (from what I can see, around 80% of existing
>> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
>> <http://luke.dashjr.org/programs/bitcoin/files/charts/services.html>][3
>> <https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/>].
>> While absolute node count is meaningless, the uprgrade trend from version
>> to version seems significant.
>>
>> Also it is quite clear a substantial portion of the ecosystem industry
>> has put in time and resources into segwit adoption, in the form of
>> upgrading wallet code, updating libraries and various other integration
>> work that requires significant time and money. Further more, others have
>> built systems that rely on segwit, having put significant engineering
>> resources into developing systems that require segwit - such as several
>> lightning network system. This is much more significant social proof than
>> running a node.
>>
>> The delayed activation of segwit is also holding back a raft protocol of
>> innovations such as MAST, Covenants, Schnorr signature schemes and
>> signature aggregation and other script innovations of which, much of the
>> development work is already done.
>>
>> A better option would be to release code that causes the existing segwit
>> deployment to activate without requiring a completely new deployment nor
>> subject to hash power veto. This could be achieved if the economic majority
>> agree to run code that rejects non-signalling segwit blocks. Then from the
>> perspective of all existing witness nodes, miners trigger the BIP9
>> activation. Such a rule could come into effect 4-6 weeks before the BIP9
>> timeout. If a large part of the economic majority publicly say that they
>> will adopt this new client, miners will have to signal bip9 segwit
>> activation in order for their blocks to be valid.
>>
>> I have drafted a BIP proposal so the community may discuss
>> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
>> text below).
>>
>> References:
>> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/
>> main.cpp#L1281-L1283
>> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
>> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/eviden
>> ce_of_widespread_segwit_support_near50_of/
>>
>> Proposal text:
>>
>> <pre>
>> BIP: bip-segwit-flagday
>> Title: Flag day activation for segwit deployment
>> Author: Shaolin Fry <shaolinfry at protonmail.ch>
>> Comments-Summary: No comments yet.
>> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>> Status: Draft
>> Type: Informational
>> Created: 2017-03-12
>> License: BSD-3-Clause
>> CC0-1.0
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
>>
>> ==Definitions==
>>
>> "existing segwit deployment" refer to the BIP9 "segwit" deployment using bit 1, between November 15th 2016 and November 15th 2017 to activate BIP141, BIP143 and BIP147.
>>
>> ==Motivation==
>>
>> Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.
>>
>> ==Specification==
>>
>> All times are specified according to median past time.
>>
>> This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates.
>>
>> While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1<<1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.
>>
>> === Reference implementation ===
>>
>> <pre>
>> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive
>> if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
>> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) {
>> return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> }
>> }
>> </pre>
>>
>> ==Backwards Compatibility==
>>
>> This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
>>
>> ==Rationale==
>>
>> Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues
>>
>> By orphaning non-signalling blocks during the last month of the BIP9 bit 1 "segwit" deployment, this BIP can cause the existing "segwit" deployment to activate without needing to release a new deployment.
>>
>> ==References==
>>
>> [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].
>>
>> ==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
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170313/b9619fd6/attachment-0001.html>

2023-06-07 17:57:13

- reply

📅 Original date posted:2017-03-12
📝 Original message:It has taken almost 6 months for SegWit adoption to get to where it is
today. I don't think it will take that long to reach similar adoption for
UASF SegWit, but conservatively we want to give it at least that much time.
It's really important to stress here that a UASF will split and become the
minority chain if a majority of the transaction accepting nodes on the
network do not agree to strictly follow the UASF and outright reject blocks
that do not signal for SegWit at the designated date.
Before setting a flag day, I think we should get written cooperation
agreements from the largest economic players in Bitcoin. This would include:
Bitfinex
Bitflyer
BitGo
BitPay
Bitstamp
Blockchain.info
Blockcypher
Coinbase
Huobi
Kraken
Gemeni
OkCoin
Poloniex
(feel free to discuss this list)
100% cooperation is not necessary, but close to 100% cooperation is
strongly desired. It should be noted that their cooperation is only
required because they are sufficiently powerful to threaten the success of
a UASF, particularly because many of these entities hold users bitcoins.
Once a convincing majority is on-board, I suggest we release a UASF patch
that activates a full year after release. This is because a UASF is a big
gamble that requires a large majority of the economy has upgraded.
Though that is a very long time, SegWit can always be activated early with
miner cooperation.
------
As an extra note, if the UASF triggers with majority economy support and
the miners resist, a minority block reward chain may be the longest chain
for a while. However, when the majority block reward chain does catch up,
the minority reward chain will be entirely obliterated, eliminating all
block rewards, all transaction history, and making a ton of money vanish
all at once.
This makes it very dangerous for an exchange, payment processor, online
wallet, or miner to oppose the UASF if there is significant momentum behind
it. This gives the UASF a powerful snowball effect once a few major parties
(or the majority of tiny full nodes) have decided to commit to the UASF.
On the other hand, failure means a permanent coin split, so it is still
necessary to exercise caution that exceeds the caution of a normal soft
fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170312/f12ebb1f/attachment.html>

2023-06-07 17:57:11

- reply

📅 Original date posted:2017-03-12
📝 Original message:What, in your appraisal, is the purpose of the block size limit? I think we
will be more able to have a productive discussion around this proposal if
we clear that up first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170312/cb015005/attachment.html>

2023-06-07 17:57:04

- reply

📅 Original date posted:2017-03-06
📝 Original message:On Mar 5, 2017 6:48 PM, "Eric Voskuil" <eric at voskuil.org> wrote:
Independent of one's opinion on the merits of one fork or another, the
state of centralization in Bitcoin is an area of great concern. If "we" can
sit down with 75% of the economy and/or 90% of the hash power (which of
course has been done) and negotiate a change to any rule, Bitcoin is a
purely political money.
If "we" can do this, so can "they".
e
There is no doubt that politics play a big role in all of this. Also no
doubt that broader decentralization would be superior. But miner activated
soft forks and user activated soft forks do not need discussions with
centralized parties to move forward. It is merely two different methods for
pushing a soft fork through the network.
The key is that it's a soft fork. Old nodes continue to work as always,
whether the soft fork deploys or not.
User activated soft forks, or perhaps more accurately called 'economically
forced soft forks' are a tool to use if the miners are in clear opposition
to the broader economy. They only work if the broader economy actually
fully supports the soft fork, which is much more difficult to measure than
miner support. And miners with deeper pockets may be able to resist for
some time, effectively performing a rewardless 51% attack and maintaining a
split network for some time. The miners would lose lots of money, but old
nodes would feel all the burn of a hard fork, followed by a sudden deep
reorg when the network finally 'heals'.
I guess in some sense you'd be playing chicken with the miners. If the
split is not instantly successful there would be a lot of damage to old
nodes, even if the majority of new nodes had upgraded. (but there would
also be a lot of damage to the miners).
On Mar 5, 2017 9:31 PM, "Nick ODell" <nickodell at gmail.com> wrote:
>I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
I don't think that's true. Say there are two forks of Blahcoin. Alice
thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
55% chance that Fork B will succeed. Alice trades all of her Fork B coins
for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
fork or the other succeeding. Alice starts spending more time around Fork A
users; Bob starts spending his time with Fork B users.
This is not relevant to a UASF. The existing nodes on the network have a
single formal definition for longest chain. If the UASF is successful, the
old nodes will follow the new soft fork and there will be only one chain.
Spirit of Bitcoin or not, the UASF is successful and there is no coin split
or network fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170306/3ec9ee10/attachment.html>

2023-06-07 17:57:02

- reply

📅 Original date posted:2017-03-05
📝 Original message:I also think that the UASF is a good idea. Hashrate follows coin price. If
the UASF has the higher coin price, the other chain will be annihilated. If
the UASF has a lower coin price, the user activated chain can still exist
(though their coins can be trivially stolen on the majority chain).
The success of the UASF depends entirely on the price. And actually, the
price is easy to manipulate. If you, as an economically active full node,
refuse to acknowledge the old chain and demand that incoming coins arrive
over the UASF chain. In doing so, you drive down the utility of the old
chain and drive up the utility of the new chain. This ultimately impacts
the price.
I think it would be pretty easy to get high confidence of the success of a
UASF. Basically you need all the major economic hubs to agree to upgrade
and then exclusively accept UASF coins. I don't have a comprehensive list,
but if we could sign on 75% of the major exchanges and payment processors,
and get 75% of the wallets to upgrade, then the UASF would be very likely
to successfully obliterate the old rules, as miners would be unable to sell
their coins or pay their bills by stubbornly sticking to the old chain.
It's less risky than a hard fork by far, because there is zero risk of coin
split if the UASF has majority hashrate, which will follow majority
economic value.
A serious proposal I think would get all the code ready and merged, but
without setting a flag day. Then we would get signatures from the major
institutions promising to use the software and saying that they are ready
for a flag day. After that, you release a patch with a flag day 12 months
in the future. People can upgrade immediately, and have a full year to
transition.
That gives tons of time for people to upgrade, and tons of confidence that
the UASF will end up as the majority chain.
If we cannot get enough major exchanges, payment processors, and other
economic hubs to upgrade, the flag day should remain upset, as the risk of
coin split will be non-zero.
I would suggest that a carefully executed UASF is much riskier than a soft
fork, but far, far less risky than a hard fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170305/fa9b6571/attachment-0001.html>

2023-06-07 17:55:53

- reply

📅 Original date posted:2017-02-02
📝 Original message:I like the idea of having some way for developers to show that they've
given an idea legitimate consideration, as I feel some proposals are often
considered much more in depth before rejection than the proposer realizes,
however I don't think any sort of on-chain system really makes sense. It
complicates things a lot, adds code, incentives, etc. when really all you
care about is some sort of indication of consideration, support, or
rejection.
I also prefer to think of Bitcoin as a system of vetos rather than a system
of approvals. A lot of times changes will be small, highly technical, and
have no visible impact to your every day user. These types of changes don't
really need support outside the devs. Furthermore, I frankly don't give a
crap if we proposal has support from 85% of the participants if there is a
legitimate technical, social, or political reason that it is a bad idea.
And finally, I don't think it should cost money or political power to raise
an objection. A 13yo who has never been seen before should be able to raise
an objection if they indeed have a legitimate objection. Involving money is
almost certainly going to shut down important valid opinions.
And again, I mostly agree with the motivation. It would be good if it were
easier to figure out who had considered a proposal and what their
objections or praises were. But I would like to see that without any
systemization around what is required to pass or fail a proposal, and with
no barrier to entry (such as voting or sending coins or having a recognized
name like 'Bitfury') to provide an opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170202/da014829/attachment.html>

2023-06-07 17:55:51

- reply

📅 Original date posted:2017-01-29
📝 Original message:On Jan 29, 2017 2:28 PM, "Tom Harding via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
If that's true, why haven't we already seen AML/KYC required of mining
pools? That would be comparatively trivial.
Some regulators are already looking into it. Even at this point you'd
either need multinational cooperation or you'd need China to decide that
51% attacking a budding technology is a good thing to do, something that
would be sure to increase tensions across the world.
But there are two bigger reasons. The first is that regulators are used to
doing regulation at exchange points, regulating mining is new and
unfamiliar and requires a decent understanding of blockchains. And the
second is that Bitcoin is tiny potatoes at this point. To the best of my
knowledge, organized crime outside of DNMs doesn't use Bitcoin. There's
minimal reason to target it while it's so small.
Regulated mining I believe is going to be a genuine risk as Bitcoin grows.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170129/1b9673b5/attachment.html>

2023-06-07 17:55:23

- reply

📅 Original date posted:2017-01-07
📝 Original message:No, Bitcoin classic only activates if 75% of the _miners_ adopt it. That
says nothing about the broader network and indeed is much easier to achieve
through politicking, bribery, coercion, and other tomfoolery as 75% of the
hashrate is ultimately only a dozen people or so.
You have plenty of channels through which you can make your announcements,
this particular one is not okay.
On Jan 7, 2017 3:12 PM, "Chris Priest via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin Classic only activates if 75% of the network adopts it. That
> is not irresponsible or dangerous. It would only be dangerous if it
> activates at 50%, because that would create a situation where its not
> clear which side of the fork has the most proof of work.
>
> On 1/7/17, Eric Lombrozo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Your release announcement does not make it clear that Bitcoin Classic is
> > incompatible with the current Bitcoin network and its consensus rules. It
> > is a hard fork on mainnet with no safe activation as well as including
> > other unsafe changes. There is also no BIP for the hard fork. There is
> also
> > no evidence of community wide consensus for such a hard fork. This is
> > dangerous and irresponsible.
> >
> >
> > It's wrong to announce software without correctly informing people about
> > the contents or risks. Furthermore, there are no release notes in
> > https://github.com/bitcoinclassic/bitcoinclassic/tree/v1.2.0/doc nor
> > changelog. Without those, it is almost impossible for average users to
> know
> > what is under the hood or what has changed and time consuming for
> > developers to assess.
> >
> > On Fri, Jan 6, 2017 at 2:16 AM, Tom Zander via bitcoin-dev <
> > bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> Bitcoin Classic version 1.2.0 is now available from;
> >>
> >> <https://bitcoinclassic.com/gettingstarted.html>
> >>
> >> This is a new major version release, including new features, various
> >> bugfixes and performance improvements.
> >>
> >> This release marks a change in strategy for Bitcoin Classic, moving from
> >> the
> >> very conservative block size proposal based on compromise to one where
> >> Classic truly innovates and provides a long term solution for the market
> >> to
> >> choose and leave behind the restrictions of the old.
> >>
> >> The most visible change in this version is the decentralised block size
> >> solution where node operators decide on the maximum size.
> >>
> >> Bitcoin Classic is focused on providing users a way to get onto the
> >> Bitcoin
> >> network using a high quality validating node for a large set of use
> >> cases.
> >> Classic presents top notch quality processes in this release, to help
> >> anyone
> >> running Bitcoin.
> >>
> >> We include in this release various projects with the beta label. People
> >> who
> >> want to use the Classic node as an on-ramp to Bitcoin will find them
> >> interesting. These projects will need to be enabled in the config by
> >> those
> >> that want to test them.
> >>
> >> More background information on this release and Classic can be seen in
> >> this
> >> video: https://vimeo.com/192789752
> >> The full release notes are on github at
> >> https://github.com/bitcoinclassic/bitcoinclassic/releases/tag/v1.2.0
> >>
> >> --
> >> Tom Zander
> >> Blog: https://zander.github.io
> >> Vlog: https://vimeo.com/channels/tomscryptochannel
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170107/cbe422c4/attachment.html>

2023-06-07 17:49:04

- reply

📅 Original date posted:2016-02-09
📝 Original message:I do like that the volume of emails has been reduced substantially. I used
to delete hordes of dev emails because I couldn't keep up. At least now I
feel like I'm able to skim most things that look interesting and I get to
assume that if the subject seems relevant to me the content is worthwhile.
My life has improved because of the changes.
On Jan 23, 2016 8:08 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> +1
> The distinction we are making importantly requires that contributors
> provide readers with another thing to say in favor of something - another
> thing which is different than "X people support this instead of only X-1
> people." Evidence trumps votes.
>
> On Sat, Jan 23, 2016 at 1:38 PM, Gavin via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> > On Jan 23, 2016, at 3:59 PM, Peter Todd via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > I would extend this to say that the technical explanation also should
>> > contribute uniquely to the conversation; a +1 with an explanation
>> > the last +1 gave isn't useful.
>>
>> Yes, comments should contribute to the discussion, with either technical
>> discussion or additional relevant data. I think a +1 like the following
>> should be encouraged:
>>
>> "+1: we had eleven customer support tickets in just the last week that
>> would have been prevented if XYZ.
>>
>> Jane Doe, CTO CoinBitChainBasely.com"
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160209/e9c58e70/attachment-0001.html>

2023-06-07 17:48:50

- reply

📅 Original date posted:2016-02-10
📝 Original message:> I love seeing data! I was considering 0.10 nodes as 'unmaintained'
because it has been a long time since the 0.11 release.
https://packages.gentoo.org/packages/net-p2p/bitcoin-qt
The Gentoo package manager still has 0.10.2 as the most recent stable
version. Getting a later version of the software on a gentoo setup requires
explicitly telling the package manger to grab a later version. I don't know
what percent of nodes are Gentoo 0.10.2, but I think it's evidence that
0.10 should not be considered 'unmaintained'. People who update their
software regularly will be running 0.10 on Gentoo.
> many of whom have privately told me they are willing and able to run an
extra node or three (or a hundred-and-eleven) once there is a final release.
I'm not clear on the utility of more nodes. Perhaps there is significant
concern about SPV nodes getting enough bandwidth or the network struggling
from the load? Generally though, I believe that when people talk about the
deteriorating full node count they are talking about a reduction in
decentralization. Full nodes are a weak indicator of how likely something
like a change in consensus rules is to get caught, or how many people you
would need to open communication with / extort in order to be able to force
rules upon the network. Having a person spin up multiple nodes doesn't
address either of those concerns, which in my understanding is what most
people care about. My personal concern is with the percentage of the
economy that is dependent on trusting the full nodes they are connected to,
and the overall integrity of that trust. (IE how likely is it that my SPV
node is going to lie to me about whether or not I've received a payment).
I will also point out that lots of people will promise things when they are
seeking political change. I don't know what percentage of promised nodes
would actually be spun up, but I'm guessing that it's going to be
significantly less than 100%. I have similar fears for companies that claim
they have tested their infrastructure for supporting 2MB blocks. Talk is
cheap.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160210/2aed4f42/attachment.html>

2023-06-07 17:44:30

- reply

📅 Original date posted:2015-11-10
📝 Original message:Prior discussion: http://gnusha.org/bitcoin-wizards/2015-11-09.log
Goal: Increase transaction throughput without increasing miner
centralization pressure, and without putting undue burden on full
validating nodes.
'Weak Block': a block which meets a target with a lower difficulty,
typically some fraction such as 5%.
'Strong Block': a block that meets the full target. Also called a block.
---
Introduction:
One of the key sources of miner centralization is the orphan rate. Miners
with 33% hash power are guaranteed to instantly validate 33% of the blocks,
while miners with only 1% hashrate only get this advantage for 1% of the
blocks. If the average orphan rate on the network is high, miners with
significantly more hashpower will have a substantial advantage over smaller
miners.
One of the strongest reasons to keep the block size small is to keep the
orphan rate low. This is to protect smaller miners. Numerous pre-consensus
schemes have been discussed which attempt to drive the orphan rate down.
When considering these schemes, the adversarial case must be considered as
well as the average case.
The circulation of weak blocks has been discussed as a form of
preconsensus. Upon finding a weak block, miners circulate the block to the
other miners, and then when a full block is found, a diff between the weak
block and full block can be circulated instead of just the full block. This
diff is both quicker to validate and quicker to circulate, resulting in
substantially improved block propagation times and a reduced orphan rate,
thus reduced miner centralization pressure.
The adversarial case is not addressed by this scheme. It is still possible
to find and circulate a large, difficult-to-verify block that slowly
propagates through the network and drives up the orphan rate for smaller
miners. A new construction (below) introduces a set of new consensus rules
which protect small miners even from the adversarial case.
---
Construction:
After a block is found, pre-consensus for the next block begins.
Pre-consensus consists of building a chain of weak blocks which meet a
target that has 5% the difficulty of a full block. Each weak block can
introduce at most 200kb of new transactions to the weak-block chain. On
average, a new weak block will appear every 30 seconds. When the next
strong block is found, it must be at the head of a weak block chain and it
must itself introduce a maximum of 200kb in transactions new to the
weak-block chain. The maximum size of a strong block is 16mb, but can be
composed of any number of weak blocks.
Example:
[strong block] -> [weak block - 200kb] -> [weak block - 400kb] -> [strong
block - 600kb] -> [weak block - 200kb]...
---
Analysis:
On average, weak blocks will be found every 30 seconds and each block will
build on top of 20 weak blocks. The average block size will be 4mb. 80 weak
blocks are required to construct a block of the maximum size of 16mb, which
will probably happen 3 out of every 1000 blocks. The race-size for blocks
is kept low, and as explained later, adversarial mining is inherently
decentivized.
This construction establishes a 'pre-consensus' that allows miners to do
faster validation when a new block is found. Assuming that the miner has
seen most of the precursor weak blocks, only a few hundred kilobytes of
validation must be performed even when the blocks are multiple megabytes in
size. In the usual case, only 100kb of validation needs to be performed.
More consistent transaction throughput is achieved. Strong blocks that are
found in rapid succession are likely to each be small, due to having a
small number of weak blocks that they build on top of. Strong blocks that
are found a long time after the previous strong block are likely to have
many weak blocks that they build on top of.
Better censorship resistance is achieved. Creating large blocks requires
building on top of weak blocks. A miner actively trying to censor certain
transactions will have to ignore all weak-block chains that contain the
offensive transaction, and thus will be at a disadvantage due to
consistently producing smaller (and less fee-rich) blocks.
An attacker that is trying to flood the network with intentionally
slow-validating blocks can no longer easily construct blocks at the maximum
size, and instead must create and hide weak blocks which build up to a
strong block that has many unseen transactions. Hiding weak blocks has an
opportunity cost, because in building a chain of weak block is exclusive to
the attacker, the attacker is missing out on the opportunity of building on
top of the other weak blocks being produced.
Compared to Bitcoin-NG, this construction lacks the vulnerability where a
single, more easily-targeted leader is elected and placed in charge of the
next round of consensus.
Everyone has incentive to build on top of the most recent weak block. In
the event that the next weak block discovered is also a strong block, the
fees reaped by the miner will be maximized.
Larger miners appear to have an incentive to withhold weak blocks in an
attempt to drive smaller miners off of the network. Large miners
withholding weak blocks will gain an advantage that amounts to (% chance of
finding a weak block) * (% chance of finding the full block) * (average fee
addition of a weak block) / (average total block reward). Assuming that
fees make up entire block reward, the advantage for a miner performing a
withholding attack is (hashrate^2 * weak block difficulty). For a 50%
miner, that advantage comes to 1.25%. For a 20% miner, this advantage is
just 0.2%. There are probably multiple ways to decentivize this behavior,
the simplest of which involves directly rewarding miners for announcing
weak blocks.
The orphan rate for weak blocks is going to be substantially higher for
smaller miner, due to the increased rate of appearance. I do not think that
this is going to create any issues, because small miners are still going to
have high visibility of the longest weak-block chain, and are still going
to be able to create blocks that are nearly as full as the blocks created
by larger miners.
The more time that passes between mining blocks, the more a block is worth
(because it will have more weak-blocks, and therefore more transactions).
Hashrate is therefore more valuable when a block has not been found for a
while, and may result in hashrate hopping, where hashrate is disabled or
clocked-down immediately after a block is found and then clocked-up if a
block is not found for a while. This is only a problem while fees from new
transactions make up a significant portion of the block reward.
---
Conclusion:
A forced-weak-blocks scheme potentially provides a powerful way to reduce
the orphan rate, increasing the safety margins on miner centralization
pressure and allowing the overall transaction throughput to be increased as
a result.
Additional analysis is needed to be certain that there are not new attack
vectors or mal-aligned incentives that have been introduced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/cb13678f/attachment-0001.html>

2023-06-07 17:37:42

- reply

📅 Original date posted:2015-08-22
📝 Original message:I am not sure that this is on-topic for the bitcoin-dev mailing list, but
it seems politically relevant enough that I'm going to respond.
/r/bitcoin and bitcointalk.org are both discussion websites that pertain to
a specific topic. All (or nearly all) discussion websites pertaining to a
specific topic have a set of rules that get enforced to facilitate relevant
and interesting discussion. These rules help to block spam, and help to
make sure that discussions happen in their appropriate places. The rules in
place on the two primary bitcoin discussion sites have helped facilitate a
large userbase frequented by many relevant experts. I do believe that we
can thank the strict moderation policies for much of the activity that
happens which is technically interesting.
/r/bitcoin and bitcointalk.org are both centralized forums. As such, the
rules are going to be set by a centralized authority. The rules set have
been set to keep the discussion as interesting and relevant as possible.
When a certain theme becomes a massive echo chamber or little more than
beating a dead horse, it makes sense to implement moderation. Calling it
'censorship' is misleading, because a government authority is not
threatening punishment for the discussion of a certain topic. People are
not banned from visiting forums or websites where off-topic (or
against-the-rules) discussion is happening. People's /r/bitcoin rights are
not being revoked because they are subscribed to a controvertial subreddit.
That would be censorship.
Many people are clearly unhappy with the moderation happening on /r/bitcoin
and bitcointalk.org. Luckily, the switching cost for online discussion
forums is very low. I'm now going to invite people to post links to bitcoin
discussion forums where the moderation authority is different.
I know that a recently popular subreddit is /r/bitcoin_uncensored
I am interested to see what other forums people think are worth mentioning.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/83360e1e/attachment.html>

2023-06-07 15:49:08

- reply

2023-06-07 15:39:25

- reply

📅 Original date posted:2015-06-20
📝 Original message:I see it as unreasonable to expect all nodes to upgrade during a hardfork.
If you are intentionally waiting for that to happen, it's possible for an
extreme minority of nodes to hold the rest of the network hostage by simply
refusing to upgrade. However you want nodes to be able to protest until it
is clear that they have lost the battle without being at risk of getting
hardforked out of the network unexpectedly.
I think it makes sense to add a second fuse. After the 95% barrier has been
crossed, a 6 week timer starts that gives the remaining 5% time to upgrade.
If they still don't upgrade, they have intentionally forked themselves from
the network and it is not something that the remaining 95% need to be
concerned with.
On Sat, Jun 20, 2015 at 1:13 PM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/fe7f5f4e/attachment.html>

2023-06-07 15:37:05

- reply

📅 Original date posted:2015-06-20
📝 Original message:I disagree that 11 is a reasonable value. That's less than 2 hours, which
probably wouldn't even last peak trading hours. You want the mempool to be
big enough that low-fee transactions introduced during peak hours are still
around when there's much less activity (it maximizes miner profit and
prevents people/wallets from needing to resubmit after activity has died
down).
I think you'd want something closer to 72. At 1mb or even 8mb blocks, the
memory requirements are pretty reasonable. 20mb blocks and you may have to
reconsider that limit.
On Tue, Jun 9, 2015 at 3:03 PM, Raystonn . <raystonn at hotmail.com> wrote:
> You are right of course. This will work. I like this idea more than
> my own proposed fix, as it doesn’t make any big changes to the economics of
> the system in the way that burning would have.
>
> *From:* Gavin Andresen <gavinandresen at gmail.com>
> *Sent:* Tuesday, June 09, 2015 11:25 AM
> *To:* Raystonn . <raystonn at hotmail.com>
> *Cc:* Loi Luu <loi.luuthe at gmail.com> ; Bitcoin Dev
> <bitcoin-development at lists.sourceforge.net>
> *Subject:* Re: [Bitcoin-development] New attack identified and potential
> solution described: Dropped-transaction spam attack against the block size
> limit
>
> On Tue, Jun 9, 2015 at 1:52 PM, Raystonn . <raystonn at hotmail.com> wrote:
>
>> That does sound good on the surface, but how do we enforce #1 and #2?
>> They seem to be unenforceable, as a miner can adjust the size of the memory
>> pool in his local source.
>>
>
> It doesn't have to be enforced. As long as a reasonable percentage of hash
> rate is following that policy an attacker that tries to flood the network
> will fail to prevent normal transaction traffic from going through and will
> just end up transferring some wealth to the miners.
>
> Although the existing default mining policy (which it seems about 70% of
> hashpower follows) of setting aside some space for high-priority
> transactions regardless of fee might also be enough to cause this attack to
> fail in practice.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/792f2553/attachment.html>

2023-06-07 15:28:55

- reply

📅 Original date posted:2015-01-22
📝 Original message:Seems like a good change to me.
On Wed, Jan 21, 2015 at 7:32 PM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Pieter Wuille <pieter.wuille at gmail.com> writes:
> > Hello everyone,
> >
> > We've been aware of the risk of depending on OpenSSL for consensus
> > rules for a while, and were trying to get rid of this as part of BIP
> > 62 (malleability protection), which was however postponed due to
> > unforeseen complexities. The recent evens (see the thread titled
> > "OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection."
> > on this mailing list) have made it clear that the problem is very
> > real, however, and I would prefer to have a fundamental solution for
> > it sooner rather than later.
>
> OK, I worked up a clearer (but more verbose) version with fewer
> magic numbers. More importantly, feel free to steal the test cases.
>
> One weirdness is the restriction on maximum total length, rather than a
> 32 byte (33 with 0-prepad) limit on signatures themselves.
>
> Apologies for my babytalk C++. Am sure there's a neater way.
>
> /* Licensed under Creative Commons zero (public domain). */
> #include <vector>
> #include <cstdlib>
> #include <cassert>
>
> #ifdef CLARIFY
> bool ConsumeByte(const std::vector<unsigned char> &sig, size_t &off,
> unsigned int &val)
> {
> if (off >= sig.size()) return false;
>
> val = sig[off++];
> return true;
> }
>
> bool ConsumeTypeByte(const std::vector<unsigned char> &sig, size_t &off,
> unsigned int t)
> {
> unsigned int type;
> if (!ConsumeByte(sig, off, type)) return false;
>
> return (type == t);
> }
>
> bool ConsumeNonZeroLength(const std::vector<unsigned char> &sig, size_t
> &off,
> unsigned int &len)
> {
> if (!ConsumeByte(sig, off, len)) return false;
>
> // Zero-length integers are not allowed.
> return (len != 0);
> }
>
> bool ConsumeNumber(const std::vector<unsigned char> &sig, size_t &off,
> unsigned int len)
> {
> // Length of number should be within signature.
> if (off + len > sig.size()) return false;
>
> // Negative numbers are not allowed.
> if (sig[off] & 0x80) return false;
>
> // Zero bytes at the start are not allowed, unless it would
> // otherwise be interpreted as a negative number.
> if (len > 1 && (sig[off] == 0x00) && !(sig[off+1] & 0x80)) return
> false;
>
> // Consume number itself.
> off += len;
> return true;
> }
>
> // Consume a DER encoded integer, update off if successful.
> bool ConsumeDERInteger(const std::vector<unsigned char> &sig, size_t &off)
> {
> unsigned int len;
>
> // Type byte must be "integer"
> if (!ConsumeTypeByte(sig, off, 0x02)) return false;
> if (!ConsumeNonZeroLength(sig, off, len)) return false;
> // Now the BE encoded value itself.
> if (!ConsumeNumber(sig, off, len)) return false;
>
> return true;
> }
>
> bool IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
> // Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
> [sighash]
> // * total-length: 1-byte length descriptor of everything that follows,
> // excluding the sighash byte.
> // * R-length: 1-byte length descriptor of the R value that follows.
> // * R: arbitrary-length big-endian encoded R value. It cannot start
> with any
> // null bytes, unless the first byte that follows is 0x80 or
> higher, in which
> // case a single null byte is required.
> // * S-length: 1-byte length descriptor of the S value that follows.
> // * S: arbitrary-length big-endian encoded S value. The same rules
> apply.
> // * sighash: 1-byte value indicating what data is hashed.
>
> // Accept empty signature as correctly encoded (but invalid) signature,
> // even though it is not strictly DER.
> if (sig.size() == 0) return true;
>
> // Maximum size constraint.
> if (sig.size() > 73) return false;
>
> size_t off = 0;
>
> // A signature is of type "compound".
> if (!ConsumeTypeByte(sig, off, 0x30)) return false;
>
> unsigned int len;
> if (!ConsumeNonZeroLength(sig, off, len)) return false;
>
> // Make sure the length covers the rest (except sighash).
> if (len + 1 != sig.size() - off) return false;
>
> // Check R value.
> if (!ConsumeDERInteger(sig, off)) return false;
>
> // Check S value.
> if (!ConsumeDERInteger(sig, off)) return false;
>
> // There should exactly one byte left (the sighash).
> return off + 1 == sig.size() ? true : false;
> }
> #else
> bool IsValidSignatureEncoding(const std::vector<unsigned char> &sig) {
> // Format: 0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S]
> [sighash]
> // * total-length: 1-byte length descriptor of everything that follows,
> // excluding the sighash byte.
> // * R-length: 1-byte length descriptor of the R value that follows.
> // * R: arbitrary-length big-endian encoded R value. It must use the
> shortest
> // possible encoding for a positive integers (which means no null
> bytes at
> // the start, except a single one when the next byte has its
> highest bit set).
> // * S-length: 1-byte length descriptor of the S value that follows.
> // * S: arbitrary-length big-endian encoded S value. The same rules
> apply.
> // * sighash: 1-byte value indicating what data is hashed (not part of
> the DER
> // signature)
>
> // Accept empty signature as correctly encoded (but invalid) signature,
> // even though it is not strictly DER. This avoids needing full DER
> signatures
> // in places where any invalid signature would do. Given that the
> empty string is
> // always invalid as signature, this is safe.
> if (sig.size() == 0) return true;
>
> // Minimum and maximum size constraints.
> if (sig.size() < 9) return false;
> if (sig.size() > 73) return false;
>
> // A signature is of type 0x30 (compound).
> if (sig[0] != 0x30) return false;
>
> // Make sure the length covers the entire signature.
> if (sig[1] != sig.size() - 3) return false;
>
> // Extract the length of the R element.
> unsigned int lenR = sig[3];
>
> // Make sure the length of the S element is still inside the signature.
> if (5 + lenR >= sig.size()) return false;
>
> // Extract the length of the S element.
> unsigned int lenS = sig[5 + lenR];
>
> // Verify that the length of the signature matches the sum of the
> length
> // of the elements.
> if ((size_t)(lenR + lenS + 7) != sig.size()) return false;
>
> // Check whether the R element is an integer.
> if (sig[2] != 0x02) return false;
>
> // Zero-length integers are not allowed for R.
> if (lenR == 0) return false;
>
> // Negative numbers are not allowed for R.
> if (sig[4] & 0x80) return false;
>
> // Null bytes at the start of R are not allowed, unless R would
> // otherwise be interpreted as a negative number.
> if (lenR > 1 && (sig[4] == 0x00) && !(sig[5] & 0x80)) return false;
>
> // Check whether the S element is an integer.
> if (sig[lenR + 4] != 0x02) return false;
>
> // Zero-length integers are not allowed for S.
> if (lenS == 0) return false;
>
> // Negative numbers are not allowed for S.
> if (sig[lenR + 6] & 0x80) return false;
>
> // Null bytes at the start of S are not allowed, unless S would
> otherwise be
> // interpreted as a negative number.
> if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80))
> return false;
>
> return true;
> }
> #endif
>
> #define COMPOUND 0x30
> #define NOT_COMPOUND 0x31
>
> // Len gets adjusted by check() to be actual length with this offset.
> #define LEN_OK 0
> #define LEN_TOO_BIG 1
> #define LEN_TOO_SMALL 0xff
>
> #define INT 0x02
> #define NOT_INT 0x03
>
> #define MINIMAL_SIGLEN 1
> #define MINIMAL_SIGVAL 0x0
>
> #define NORMAL_SIGLEN 32
> #define NORMAL_SIGVAL(S) S, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, \
> 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, \
> 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, \
> 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f
>
> // 33 bytes is possible, with 0 prepended.
> #define MAXIMAL_SIGLEN 33
> #define MAXIMAL_SIGVAL(S) NORMAL_SIGVAL(S), 0x20
>
> #define OVERSIZE_SIGLEN 34
> #define OVERSIZE_SIGVAL(S) MAXIMAL_SIGVAL(S), 0x21
>
> #define ZEROPAD_SIGLEN (1 + NORMAL_SIGLEN)
> #define ZEROPAD_SIGVAL(S) 00, NORMAL_SIGVAL(S)
>
> #define SIGHASH 0xf0
>
> static bool check(const std::vector<unsigned char> &sig)
> {
> std::vector<unsigned char> fixed = sig;
>
> // Fixup length
> if (fixed.size() > 1)
> fixed[1] += fixed.size() - 3;
> return IsValidSignatureEncoding(fixed);
> }
>
> #define good(arr) assert(check(std::vector<unsigned char>(arr,
> arr+sizeof(arr))))
> #define bad(arr) assert(!check(std::vector<unsigned char>(arr,
> arr+sizeof(arr))))
>
> // The OK cases.
> static unsigned char zerolen[] = { };
> static unsigned char normal[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char min_r[] = { COMPOUND, LEN_OK,
> INT, MINIMAL_SIGLEN, MINIMAL_SIGVAL,
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char min_s[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x1),
> INT, MINIMAL_SIGLEN, MINIMAL_SIGVAL,
> SIGHASH };
> static unsigned char max_r[] = { COMPOUND, LEN_OK,
> INT, MAXIMAL_SIGLEN, MAXIMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char max_s[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x1),
> INT, MAXIMAL_SIGLEN, MAXIMAL_SIGVAL(0x2),
> SIGHASH };
> // As long as total size doesn't go over, a single sig is allowed > 33
> bytes
> static unsigned char wierd_s_len[] = { COMPOUND, LEN_OK,
> INT, OVERSIZE_SIGLEN,
> OVERSIZE_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char wierd_r_len[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, OVERSIZE_SIGLEN,
> OVERSIZE_SIGVAL(0x2),
> SIGHASH };
> static unsigned char zeropad_s[] = { COMPOUND, LEN_OK,
> INT, ZEROPAD_SIGLEN,
> ZEROPAD_SIGVAL(0x81),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char zeropad_r[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, ZEROPAD_SIGLEN,
> ZEROPAD_SIGVAL(0x82),
> SIGHASH };
>
>
> // The fail cases.
> static unsigned char not_compound[] = { NOT_COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char short_len[] = { COMPOUND, LEN_TOO_SMALL,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char long_len[] = { COMPOUND, LEN_TOO_BIG,
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char r_notint[] = { COMPOUND, LEN_OK,
> NOT_INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char s_notint[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN, NORMAL_SIGVAL(0x1),
> NOT_INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char s_oversig[] = { COMPOUND, LEN_OK,
> INT, OVERSIZE_SIGLEN,
> OVERSIZE_SIGVAL(0x1),
> INT, MAXIMAL_SIGLEN,
> MAXIMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char r_oversig[] = { COMPOUND, LEN_OK,
> INT, MAXIMAL_SIGLEN,
> MAXIMAL_SIGVAL(0x1),
> INT, OVERSIZE_SIGLEN,
> OVERSIZE_SIGVAL(0x2),
> SIGHASH };
> static unsigned char s_negative[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x81),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char r_negative[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x82),
> SIGHASH };
> static unsigned char zeropad_bad_s[] = { COMPOUND, LEN_OK,
> INT, ZEROPAD_SIGLEN,
> ZEROPAD_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char zeropad_bad_r[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, ZEROPAD_SIGLEN,
> ZEROPAD_SIGVAL(0x2),
> SIGHASH };
> static unsigned char missing_sighash[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2) };
> static unsigned char extra_byte[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH, 0 };
>
> // Bad signature lengths
> static unsigned char zerolen_r[] = { COMPOUND, LEN_OK,
> INT, 0,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char zerolen_s[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, 0,
> SIGHASH };
> static unsigned char overlen_r_by_1[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN + 1 + 1 +
> NORMAL_SIGLEN + 1 + 1, NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char overlen_s_by_1[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN+1+1,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char underlen_r_by_1[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN-1,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
> static unsigned char underlen_s_by_1[] = { COMPOUND, LEN_OK,
> INT, NORMAL_SIGLEN,
> NORMAL_SIGVAL(0x1),
> INT, NORMAL_SIGLEN-1,
> NORMAL_SIGVAL(0x2),
> SIGHASH };
>
> int main()
> {
> good(zerolen);
> good(normal);
> good(min_r);
> good(min_s);
> good(max_r);
> good(max_s);
> good(wierd_s_len);
> good(wierd_r_len);
> good(zeropad_s);
> good(zeropad_r);
>
> // Try different amounts of truncation.
> for (size_t i = 1; i < sizeof(normal)-1; i++)
> assert(!check(std::vector<unsigned char>(normal, normal+i)));
>
> bad(not_compound);
> bad(short_len);
> bad(long_len);
> bad(r_notint);
> bad(s_notint);
> bad(s_oversig);
> bad(r_oversig);
> bad(s_negative);
> bad(r_negative);
> bad(s_negative);
> bad(r_negative);
> bad(zeropad_bad_s);
> bad(zeropad_bad_r);
> bad(zerolen_r);
> bad(zerolen_s);
> bad(overlen_r_by_1);
> bad(overlen_s_by_1);
> bad(underlen_r_by_1);
> bad(underlen_s_by_1);
> bad(missing_sighash);
> bad(extra_byte);
>
> return 0;
> }
>
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150121/fba1f709/attachment.html>

2023-06-07 15:11:29

- reply

📅 Original date posted:2014-01-04
📝 Original message:It's meant to be in favor of merge mining.
Dogecoin uses scrypt, which is a very popular algorithm. If any large
currency were to be attacked through merge mining, it would probably be
litecoin miners attacking dogecoin. But if you control enough of the
litecoin network to do attack mining against dogecoin, you almost certainly
have a huge vested interest in cryptocurrencies doing well. By attacking
dogecoin successfully, you'll cast doubt on the entire cryptocurrency
ecosystem and hurt yourself in the process.
On Sat, Jan 4, 2014 at 5:05 AM, Jorge Timón <jtimon at monetize.io> wrote:
> On 1/4/14, David Vorick <david.vorick at gmail.com> wrote:
> > If you have the resources to attack one of the bigger altcoins, you
> > probably have a significant investment in the cryptocurrency space, and a
> > significant interest in protecting it. Compromising even something like
> > dogecoin would cause a lot of questions to be raised and likely drop the
> > value of bitcoin as well as all the cryptocurrencies using the same work
> > function as dogecoin.
> >
> > Right now, there's very little benefit to attacking a significant
> currency,
> > because it would be very expensive and likely traumatize the whole
> system.
> > Unless it's some power like the NSA, I don't think there's much to worry
> > about.
>
> The launch thread says it clear: "very scrypt, such random, much
> profit, wow, many coin".
> So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt
> like most of the other scamcoins.
> Anyway, I don't see anything in your comment in favor or against
> merged mining...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140104/b5885f64/attachment.html>

2023-06-07 15:11:28

- reply

📅 Original date posted:2014-01-04
📝 Original message:If you have the resources to attack one of the bigger altcoins, you
probably have a significant investment in the cryptocurrency space, and a
significant interest in protecting it. Compromising even something like
dogecoin would cause a lot of questions to be raised and likely drop the
value of bitcoin as well as all the cryptocurrencies using the same work
function as dogecoin.
Right now, there's very little benefit to attacking a significant currency,
because it would be very expensive and likely traumatize the whole system.
Unless it's some power like the NSA, I don't think there's much to worry
about.
On Tue, Dec 31, 2013 at 2:38 AM, <rob.golding at astutium.com> wrote:
> > But there's so much 'dry powder' out there (GPUs), I wonder if *not*
> > supporting merge-mining is any better? At least the attacker has to do
> > some unique PoW, so you hope it's costing them something.
>
> With lots of people having access to 100TH+ there's not really much
> 'cost' to doing a 51% attack on an alt-coin beyond a short-term
> diversion away from 'profitable' mining.
>
> At least by supporting merged mining, more miners are likely to
> 'support' multiple coin types, thus making a 51% attack from an
> individual/group less straightforward.
>
> >> The rational decision for a non-scam altcoin, is to take advantage of
> >> merged mining to get as much security as possible.
>
> Exactly.
>
> Rob
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140104/9c382479/attachment.html>

2023-06-07 15:02:20

- reply

📅 Original date posted:2013-05-21
📝 Original message:I've been wondering why a blockchain is necessary at all. Ripple doesn't
have one (I haven't looked closely at their implementation but it seems
reasonable to go without one).
When you do blockchain based transaction confirmations, you give full
authority to the miner that finds the transaction block. That miner gets to
decide which transactions are real and which transactions are fraudulent,
and even has the option to not include any particular transaction (maybe
they used dirty coins, or something like that). The advantage to using a
blockchain is that any tough decisions to choose between two conflicting
transactions can be decided in an easy manner. The person who finds the
next block picks their favorite and tells everybody else.
But this has a huge downside: network confirmation can take more than 10
minutes (for an unlucky block). If you really want to be certain, a
confirmation can take more than an hour (multi-block confirmations).
For a transaction with no conflict, the network should be able to confirm
the transaction within a few seconds, because the information can propagate
to all of the nodes that quickly. The new issue is that if conflicting
transactions appear on opposite sides of the network, there needs to be
some way for the network to determine which transaction gets priority.
Right now the method is to wait for a miner to find a block and then go
with his decision, but perhaps there's some way to resolve a double spend
conflict without waiting for a block.
All you really need is for 51% of the nodes in the network to confirm a
transaction as legitimate in order for it to be 'confirmed' by the entire
network. Malicious nodes (nodes that confirm both conflicting transactions,
or nodes that refuse to confirm a transaction even though there are no
conflicts) can be excommunicated. The two challenges then would be
1. telling everybody when a transaction has hit 51% confirmation
2. dealing with a triple-or-more spend: A has 25% confirmation, B has 40%
confirmation, C has 35% confirmation, who wins?
For the first problem, each node only needs to see the transaction twice:
once when the node sees it for the first time and confirms it, and a second
time after the transaction hits 51% and is announced to the network as
confirmed. The first node to see the transaction hit 51% will make the
announcement.
The second problem could be reduced to a majority-wins problem. If a node
sees that 94% of votes are in, and one of the transactions is more than 6%
ahead of the others, that transaction is the winner.
If for whatever reason a clear majority is not hit by the time the next
mining block is found, the miner could just choose the transaction that had
the most votes when it saw it. It may be outdated but would clear up any
issues. This delay would only occur for a transaction if the spender of the
coins was attempting a double spend, and would indicate dishonesty to the
merchants. They could then choose to wait and see if their account is the
winner or they could just refuse to give out their goods.
On Tue, May 21, 2013 at 9:05 AM, Peter Todd <pete at petertodd.org> wrote:
> On Mon, May 20, 2013 at 08:54:25PM -0700, Gregory Maxwell wrote:
> > One point that was only recently exposed to me is that replacement
> > combined with child-pays-for-parent creates a new kind of double spend
> > _defense_: If someone double spends a payment to an online key of
> > yours, you can instantly produce a child transaction that pays 100% of
> > the double spend to fees... so a double spender can hurt you but not
> > profit from it. (and if your side of the transaction is
> > potentially/partially reversible he will lose)...
>
> You can do better than that actually: you can arrange the transaction
> such that the double-spender is hurt by asking them to pay an excess on
> top of the initial payment, and having that excess get returned to them
> in a subsequent transaction. Of course, that's trusting the merchant,
> but you're trusting the merchant to ship to a product anyway so...
>
> A really interesting example for this though would be applications where
> you are making a deposit. You credit the customer account immediately
> with half of the deposit amount, allowing them to immediately spend that
> portion for something transferable. (perhaps an alt-coin) If the
> customer tries to double-spend you burn half to fees, still leaving the
> other half to pay for what they did spend. If they don't double-spend,
> the rest of the balance becomes available after n confirmations. A
> BTC->alt-coin exchange could use this mechanism for instance, although
> it only works with widespread replace-by-fee adoption; blockchain.info's
> shared-send service is another application, as is SatoshiDice. (the
> failed bet tx can be the refund)
>
> What's nice here is even if the customer tries to pay a miner to do the
> dirty work, a short-term rational miner still has an incentive to screw
> over the customer by accepting the merchant's double-spend. Now the
> customer can promise the miner future business, but they've shown
> themselves to be dishonest... how much honor is there among thieves?
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000f31f5cd20f915e3edb8e3fceea49580235b984fea63f1f882c
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130521/bf07e21d/attachment.html>