<unnamed>

Public Key

npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u

Profile Code

nprofile1qqspccwejk2fe0a0znmkw7zwze4aapju0wrc84a280c2r5q5kuxqq6gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsj2kszv

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-09 14:48:36 CEST

- reply

📅 Original date posted:2018-01-17
📝 Original message:
It is not the case that all instances where you might have negative fees would have loops. One instance where you want this feature is when the network becomes too weighted in one side of the graph. Another is when the other side is a non-routable endpoint. In both cases would be useful to signal to others that you were willing to pay to rebalance, and this hand wavy argument about loops doesn’t seem to apply.
> On Jan 17, 2018, at 12:40 PM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Benjamin Mord <ben at mord.io> writes:
>> It isn't obvious to me from the BOLTs if fees can be negative, and I'm
>> finding uint in the go source code - which suggests not. In scenarios where
>> the funding of a payment channel has been fully committed in one direction,
>> why not allow negative fees to incent unwinding, in scenarios where nodes
>> consider that cheaper than on-chain rebalancing?
>
> After discussing this for a while we decided not to allow negative fees
> in channel announcements (for now), because they actually do not add to
> the flexibility and require special handling for route finding.
>
> The main argument for negative fees has always been that they allow a
> channel operator to rebalance its channels. However it is neither
> required, nor is it really all that helpful. If a node wants to
> rebalance he needs to find a cycle, that it can use to rebalance. The
> simplest rebalancing is that the node itself sends a payment along that
> cycle back to itself, giving the rebalancing node full control over the
> amount to rebalance, timing and costs.
>
> The negative fees were intended to encourage other participants to use
> any cycle and rebalance for the node offering the negative fees. However
> that results in less control over the rebalancing for the node, e.g.,
> how many payments to incentivize, amounts, etc. This is compounded by
> the inherent delay of channel updates being disseminated in the
> network. So if a rebalancing node gets too many payments that try to
> take advantage of the negative fees, what should it do? It'd result in
> either losses for the node, or many forward rejections. So why not use
> the funds one would have used towards negative fees for the active way
> of rebalancing.
>
> It is preferable to have payments be routed around an exhausted channel,
> after all if there is a cycle there must be an alternative route, rather
> than trying to artificially rebalance.
>
> So overall, allowing only positive fees makes routing simpler, and still
> allows for active rebalancing. As for other applications some have
> alluded to, this constraint is only for the routing gossip. Should there
> be a good reason to allow increasing the amount forwarded by a peer,
> e.g., node n receives x from the previous hop and forwards x+e to the
> next hop, that can still be negotiated out of band or even in the onion
> payload for that node.
>
> Cheers,
> Christian
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:48:35 CEST

- reply

📅 Original date posted:2018-01-17
📝 Original message:
Negative fees also come up in the context of peer to peer credit using self issued IOUs (over colored coins or whatever) that are atomically swapped via a lightning HTLC. In this case negative fees may be the norm as there is incentive to rebalance from higher to lower interest IOUs.
> On Jan 16, 2018, at 2:45 PM, Will Yager <lists at yager.io> wrote:
>
> I agree. Negative shadow prices are incredibly important for optimality of constrained network markets where flows in opposite directions cancel (as is the case with lightning). See for example FTRs. It’s unclear to me how well the analogy holds, but it’s worth considering.
>
> —Will
>
>> On Tue, Jan 16, 2018 at 3:32 PM, Benjamin Mord <ben at mord.io> wrote:
>>
>> Thanks. It sounds like it was dropped due to difficulty in the routing protocol. Is that difficulty documented somewhere I can review? If so, I might take a crack at a solution to it. But regardless I suggest the protocol should support negative fees, even if an individual routing implementation prefers to treat as 0 for simplicity. That should be up to the implementation I think, and not a protocol constraint.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180116/46be8616/attachment-0001.html>

2023-06-09 14:48:11 CEST

- reply

📅 Original date posted:2017-12-28
📝 Original message:
Splitting a single payment into multiple invoices has bad semantic properties. Beyond implementation difficulties it also makes the payment no longer atomic. You can end up in a situation where part of a transaction has gone through but then channel capacity has been exhausted. The. What do you do?
While an annoying (and potentially exploitable) edge case for payments, it also makes it basically impossible in practice to build higher level smart contracts on top of lightning channels as primitives, since those constructs typically use a single HTLC revelation as the decision gate between multiple contingent outcomes.
I had always assumed the protocol limits were training wheels, and would be shocked and dismayed if that were not the case (and would immediately begin work on an alternative fork because such limits would make lightning useless for my intended applications).
On the topic of cold storage, I think perhaps that is less of a settled issue than you take for granted. I think the value proposition of bitcoin is exactly its ability to serve as non custodial collateral and I do not anticipate a future where large portions of the bitcoin monetary base are not held as collateral in smart contract payment channels. Indeed I would consider that a failure mode both worth designing for...
> On Dec 27, 2017, at 12:13 PM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
> Good morning Daniel,
>
>
>
>> -------- Original Message --------
>> Subject: Re: [Lightning-dev] General questions about channels
>> Local Time: December 27, 2017 10:30 PM
>> UTC Time: December 27, 2017 2:30 PM
>> From: therealsangaman at gmail.com
>> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>
>> Andy Schroder <info at andyschroder.com>, lightning-dev at lists.linuxfoundation.org <lightning-dev at lists.linuxfoundation.org>
>>
>> I've only really been getting my hands into LN the past few weeks but
>> I thought I'd share my thoughts here.
>>
>> ZmnSCPxj via Lightning-dev lightning-dev at lists.linuxfoundation.org wrote:
>> Perhaps some day, in the LONG TERM, the limits may be increased
>>
>> I was always under the impression that the channel and payment limits
>> were intended to be training wheels, this is the first I've heard of
>> them intended to stick around long term. I find the channel limit to
>> be particularly restrictive, as it hinders some use cases I'd envision
>> where large payment channels between two parties are useful and can
>> also be used for routing LN payments. Large payments afaik can be
>> broken up into smaller ones without incurring too much cost or
>> trouble,
>
> Splitting up large payments would require multiple invoices at least for now (whether this is troublesome or not may be a matter of opinion, bit I suspect juggling more than a few invoices would be painful as a user experience). Routing larger payments over multiple routes automatically while using a single invoice, is harder as multiple routes need to be set up, and each route must have different preimages: further it is likely you want the entire large payment to be done atomically, which would be harder to arrange.
>
>> but that's not the case for creating channels. As the channel
>> itself involves only two parties - and in sticking to my general
>> political/philosophical mantra - there is really no justification for
>> limits to be imposed on this. Which brings me to my next point.
>>
>
> Perhaps our definition of "long term" is askew. A year after mainnet release, I doubt anyone would feel safe implementing removal of the limit; this is my "long term". Five years, I imagine quite a few will use the nonlimited version and may form a subnetwork among themselves. But possibly by then it would be unlikely that most people using Bitcoin at all would evem be capable of putting 150 mBTC in spending money on a hot wallet, in which case whether there is a 167 mBTC limit per channel or not is largely a moot point. Or perhaps I simply imagine hyperbitcoinization by then, with people putting entire bitcoins into hot wallets equivalent to people putting thousands of USD today in their back pockets as invitation to be attacked.
>
>>
>> There is also again the wisdom, that one should keep most of the funds in
>> cold storage, and only a small amount for spending in hot wallets like
>> Lightning nodes
>>
>> I think this is a top-down way of thinking that runs counter to the
>> spirit of bitcoin. The "wisest" thing to do in fact may be to simply
>> buy inflation-adjusted treasury bonds and not mess with bitcoin at
>> all, much less the experimental lightning network. As advice this is
>> perfectly fine to share with others for them to follow on a voluntary
>> basis, but I don't see why this ought to be enforced as a rule on a
>> protocol level.
>>
>
> Possibly. At the protocol level, a limit encourages the growth of the network towards a mesh network rather than more central forms, however. I merely put this since it is unlikely that most people following this "wisdom" would have an incentive to even run software with the limit removed: that is, by the time Lightning becomes fully deployed the limit may not even be reached in practice.
>
>>
>> Also, I personally can't see a reason why a node would reject a large
>> channel being made with it, where is the downside or risk? The party
>> committing funds to the channel is the one risking loss or delay of
>> funds.
>>
>
> But the party committing funds to the channel is known via node gossip, and it is known also who the other end of the channel is. If you were to propose opening for example a 5BTC channel to me with the funds coming from you, I would consider the possibility that I might get attacked in order to get to your funds (and I might not have the resources to protect against such an attack on my end, even if you might). Further, putting 5BTC implies that at some point there is the future possibility, due to routing and so on, that the channel will have around 5BTC belonging to me, and at some point before you can spend the entire 5BTC I would want to close the channel and commit the funds that I now own into cold storage (so that the ability to channel 5BTC from you to me is a moot point).
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171228/42da9b77/attachment-0001.html>

2023-06-09 14:45:08 CEST

- reply

📅 Original date posted:2015-11-19
📝 Original message:
The basic idea of the soft-fork plan is very simple --- have the
scriptPubKey be just the 20-byte hash of the redeem script. The scriptSig
of the spending input is empty. The actual scriptSig, with the redeem
script and signatures, is contained in a separate Merkle tree committed to
elsewhere in the block (e.g. in the last output of the coinbase, or the
last output of the last transaction).
On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders <gsanders87 at gmail.com> wrote:
> The hardfork variant is quite simple, if I understood it correctly. You
> just stick the signatures in another parallel merkle tree. So if you don't
> want to validate signatures, just don't download them, and validate
> everything else. TXIDs don't use the signature at all. Nothing to malleate,
> AFAIK. Not sure what the softfork plan is, but it will be a talk at Scaling
> Bitcoin HK.
>
> On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD <glenn at tarbox.org>
> wrote:
>
>>
>> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com <sickpig at gmail.com>
>> wrote:
>>
>>> Hi Pierre
>>>
>>> you could start here
>>>
>>>
>>> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
>>>
>>> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
>>> https://github.com/ElementsProject/elements
>>
>>
>> There was a brief blip on Reddit:
>>
>>
>> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh
>>
>> Its weird how little information there is on Segregated Witness. I'm
>> guessing its a simple concept and those working on it (sipa / gmaxwell)
>> haven't felt the need to write it up.
>>
>> That it "apparently" can be done with a soft fork similar to P2SH is good
>> news... I guess...
>>
>>
>> --
>> Glenn H. Tarbox, PhD
>> =]|[=
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/e557c246/attachment.html>

2023-06-07 20:10:06 CEST

- reply

📅 Original date posted:2018-01-23
📝 Original message:I had the opposite response in private, which I will share here. As recently as Jan 9th feedback on BIP 117 was shared on this list by Pieter Wuille and others suggesting we adopt native MAST template instead of the user programmable combination of BIPs 116 and 117. Part of my response then was, I quote:
I havent the hubris to suggest that we know exactly what a templated MAST *should* look like. It's not used in production anywhere. Even if we did have the foresight, the tail-call semantics allow for other constructions besides MAST and for the sake of the future we should allow such permission-less innovation. The proper sequence of events should be to enable features in a generic way, and then to create specialized templates to save space for common constructions. Not the other way around. [1]
I take this advance as further evidence in favor of this view. As recently as 24 hours ago if you had asked what a native-MAST template would have looked like, the answer would have been something like Johnson Lau’s BIP 114, with some quibbling over details. Taproot is a clearly superior approach. But is it optimal? I don’t think we can claim that now. Optimality of these constructs isn’t something easily proven, with the nearest substitute being unchanging consensus over extended periods of time.
Every time we add an output type specialization, we introduce a new codepath in the core of the script consensus that must be maintained forever. Take P2SH: from this point forward there is no reason to use it in new applications, ever. But it must be forever supported. In an alternate universe we could have deployed a native MAST proposal, like BIP 114, only to have Taproot-like schemes discovered after activation. That would have been a sucky outcome. It is still the case that we could go for Taproot right now, and then in six months or a year’s time we find an important tweak or a different approach entirely that is even better, but the activation process had already started. That would be a sucky outcome we haven’t avoided yet.
This is not an argument against template specialization for common code paths, especially those which increase fungibility of coins. I do think we should have a native MAST template eventually, using Taproot or something better. However if I may be allowed I will make an educated guess about the origin of Taproot: I think it’s no coincidence that Greg had this insight and/or wrote it up simultaneous with a push by myself and others for getting MAST features into bitcoin via BIPs 98, 116, and 117, or 114. Cryptographers tend to only think up solutions to problems that are on their minds. And the problems on most people’s minds are primarily those that are deployable today, or otherwise near-term applicable.
BIPS 116 and 117 each provide a reusable component that together happens to enable a generic form of MAST. Even without the workarounds required to avoid CLEANSTACK violations, the resulting MAST template is larger than what is possible with specialization. However let’s not forget that (1) they also enable other applications like honeypots, key trees, and script delegation; and relevant to this conversation (2) they get the MAST feature available for use in production by the wider community. I don’t think I’d personally be willing to bet that we found the optimal MAST structure in Greg’s Taproot until we have people doing interesting production work like multisig wallets, lightning protocol, and the next set of consensus features start putting it into production and exploring edge cases. We may find ways Taproot can be tweaked to enable other applications (like encoding a hash preimage as well) or simplify obscure corner cases.
I feel quite strongly that the correct approach is to add support for generic features to accomplish the underlying goal in a user programmable way, and THEN after activation and some usage consider ways in which common use cases can be made more efficient through output specialization. To take a more obvious example, lightning protocol is still an active area or research and I think it is abundantly clear that we don’t know yet what the globally optimal layer-2 caching protocol will be, even if we have educated guesses as to its broad structure. A proposal right now to standardize a more compact lightning script type would be rightly rejected. It is less obvious but just as true that the same should hold for MAST.
I have argued these points before in favor of permission less innovation first, then application specialization later, in [1] and at the end of the rather long email [2]. I hope you can take the time to read those if you still feel we should take a specialized template approach instead of the user programmable BIPSs 116 and 117.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015537.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015537.html>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015029.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015029.html>
> On Jan 22, 2018, at 6:51 PM, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Thanks Greg!
>
> I'd be hesitant to deploy a MAST proposal without this clever application of pay-to-contract-hash now! Looks like the overhead over a more-naive MAST construction is rather trivial, too!
>
> Matt
>
> On January 23, 2018 12:30:06 AM UTC, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
> areas: efficiency and privacy. Efficiency because unexecuted forks of
> a script can avoid ever hitting the chain, and privacy because hiding
> unexecuted code leaves scripts indistinguishable to the extent that
> their only differences are in the unexecuted parts.
>
> As Mark Friedenbach and others have pointed out before it is almost
> always the case that interesting scripts have a logical top level
> branch which allows satisfaction of the contract with nothing other
> than a signature by all parties. Other branches would only be used
> where some participant is failing to cooperate. More strongly stated,
> I believe that _any_ contract with a fixed finite participant set
> upfront can be and should be represented as an OR between an N-of-N
> and whatever more complex contract you might want to represent.
>
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments. Otherwise, if the
> anonymity set of fancy usage is only other fancy usage it may not be
> very large in practice. One suggestion has been that ordinary
> checksig-only scripts should include a dummy branch for the rest of
> the tree (e.g. a random value hash), making it look like there are
> potentially alternative rules when there aren't really. The negative
> side of this is an additional 32-byte overhead for the overwhelmingly
> common case which doesn't need it. I think the privacy gains are
> worth doing such a thing, but different people reason differently
> about these trade-offs.
>
> It turns out, however, that there is no need to make a trade-off. The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.
>
> Let's say we want to create a coin that can be redeemed by either
> Alice && Bob or by CSV-timelock && Bob.
>
> Alice has public A, Bob has pubkey B.
>
> We compute the 2-of-2 aggregate key C = A + B. (Simplified; to
> protect against rogue key attacks you may want to use the MuSig key
> aggregation function [1])
>
> We form our timelock script S = "<timeout> OP_CSV OP_DROP B OP_CHECKSIGVERIFY"
>
> Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.
>
> (This is the attack hardened pay-to-contract construction described in [2])
>
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].
>
> Now Alice and Bob-- assuming they are both online and agree about the
> resolution of their contract-- can jointly form a 2 of 2 signature for
> P, and spend as if it were a payment to a single party (one of them
> just needs to add H(C||S) to their private key).
>
> Alternatively, the Taproot consensus rules would allow this script to
> be satisfied by someone who provides the network with C (the original
> combined pubkey), S, and does whatever S requires-- e.g. passes the
> CSV check and provides Bob's signature. With this information the
> network can verify that C + H(C||S) == P.
>
> So in the all-sign case there is zero overhead; and no one can tell
> that the contract alternative exists. In the alternative redemption
> branch the only overhead is revealing the original combined pubkey
> and, of course, the existence of the contract is made public.
>
> This composes just fine with whatever other merkelized script system
> we might care to use, as the S can be whatever kind of data we want,
> including the root of some tree.
>
> My example shows 2-of-2 but it works the same for any number of
> participants (and with setup interaction any threshold of
> participants, so long as you don't mind an inability to tell which
> members signed off).
>
> The verification computational complexity of signature path is
> obviously the same as any other plain signature (since its
> indistinguishable). Verification of the branch redemption requires a
> hash and a multiplication with a constant point which is strictly more
> efficient than a signature verification and could be efficiently fused
> into batch signature validation.
>
> The nearest competitor to this idea that I can come up with would
> supporting a simple delegation where the output can be spent by the
> named key, or a spending transaction could provide a script along with
> a signature of that script by the named key, delegating control to the
> signed script. Before paying into that escrow Alice/Bob would
> construct this signature. This idea is equally efficient in the common
> case, but larger and slower to verify in the alternative spend case.
> Setting up the signature requires additional interaction between
> participants and the resulting signature must be durably stored and
> couldn't just be recomputed using single-party information.
>
> I believe this construction will allow the largest possible anonymity
> set for fixed party smart contracts by making them look like the
> simplest possible payments. It accomplishes this without any overhead
> in the common case, invoking any sketchy or impractical techniques,
> requiring extra rounds of interaction between contract participants,
> and without requiring the durable storage of other data.
>
>
> [1] https://eprint.iacr.org/2018/068 <https://eprint.iacr.org/2018/068>
> [2] https://blockstream.com/sidechains.pdf <https://blockstream.com/sidechains.pdf> Appendix A
>
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <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/20180123/3b3b7dd0/attachment-0001.html>

2023-06-07 20:06:53 CEST

- reply

📅 Original date posted:2017-10-09
📝 Original message:The problem of fast acting but non vulnerable difficulty adjustment algorithms is interesting. I would certainly like to see this space further explored, and even have some ideas myself.
However without commenting on the technical merits of this specific proposal, I think it must be said upfront that the stated goal is not good. The largest technical concern (ignoring governance) over B2X is that it is a rushed, poorly reviewed hard fork. Hard forks should not be rushed, and they should receive more than the usual level of expert and community review.
I’m that light, doing an even more rushed hard fork on an even newer idea with even less review would be hypocritical at best. I would suggest reframing as a hardfork wishlist research problem for the next properly planned hard fork, if one occurs. You might also find the hardfork research group a more accommodating venue for this discussion:
https://bitcoinhardforkresearch.github.io/
> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Sorry, my previous email did not have the plain text I intended.
>
> Background:
>
> The bitcoin difficulty algorithm does not seem to be a good one. If there
> is a fork due to miners seeking maximum profit without due regard to
> security, users, and nodes, the "better" coin could end up being the
> minority chain. If 90% of hashrate is really going to at least initially go
> towards using SegWit2x, BTC would face 10x delays in confirmations
> until the next difficulty adjustment, negatively affecting its price relative
> to BTC1, causing further delays from even more miner abandonment
> (until the next adjustment). The 10% miners remaining on BTC do not
> inevitably lose by staying to endure 10x delays because they have 10x
> less competition, and the same situation applies to BTC1 miners. If the
> prices are the same and stable, all seems well for everyone, other things
> aside. But if the BTC price does not fall to reflect the decreased hashrate,
> he situation seems to be a big problem for both coins: BTC1 miners will
> jump back to BTC when the difficulty adjustment occurs, initiating a
> potentially never-ending oscillation between the two coins, potentially
> worse than what BCH is experiencing. They will not issue coins too fast
> like BCH because that is a side effect of the asymmetry in BCH's rise and
> fall algorithm.
>
> Solution:
>
> Hard fork to implement a new difficulty algorithm that uses a simple rolling
> average with a much smaller window. Many small coins have done this as
> a way to stop big miners from coming on and then suddenly leaving, leaving
> constant miners stuck with a high difficulty for the rest of a (long) averaging
> window. Even better, adjust the reward based on recent solvetimes to
> motivate more mining (or less) if the solvetimes are too slow (or too fast).
> This will keep keep coin issuance rate perfectly on schedule with real time.
>
> I recommend the following for Bitcoin, as fast, simple, and better than any
> other difficulty algorithm I'm aware of. This is the result of a lot of work the
> past year.
>
> === Begin difficulty algorithm ===
> # Zawy v6 difficulty algorithm (modified for bitcoin)
> # Unmodified Zawy v6 for alt coins:
> # http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html
> # All my failed attempts at something better:
> # https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a
> #
> # Keep negative solvetimes to correct bad timestamps.
> # Do not be tempted to use:
> # next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
> # ST= Solvetime, TS = timestamp
>
> # set constants until next hard fork:
>
> T=600; # coin's TargetSolvetime
> N=30; # Averaging window. Smoother than N=15, faster response than N=60.
> X=5;
> limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
> adjust = 1/(1+0.67/N); # keeps avg solvetime on track
>
> # begin difficulty algorithm
>
> avg_ST=0; avg_D=0;
> for ( i=height; i > height-N; i--) { # go through N most recent blocks
> avg_ST += (TS[i] - TS[i-1]) / N;
> avg_D += D[i]/N;
> }
> avg_ST = T*limit if avg_ST > T*limit;
> avg_ST = T/limit if avg_ST < T/limit;
>
> next_D = avg_D * T / avg_ST * adjust;
>
> # Tim Olsen suggested changing reward to protect against hash attacks.
> # Karbowanek coin suggested something similar.
> # I could not find anything better than the simplest idea below.
> # It was a great surprise that coin issuance rate came out perfect.
> # BaseReward = coins per block
>
> next_reward = BaseReward * avg_ST / T;
>
> ======= end algo ====
>
> Due to the limit and keeping negative solvetimes in a true average,
> timestamp errors resulting in negative solvetimes are corrected in the next
> block. Otherwise, one would need to do like Zcash and cause a 5-block
> delay in the response by resorting to the median of past 11 blocks (MPT)
> as the most recent timestamp, offsetting the timestamps from their
> corresponding difficulties by 5 blocks. (it does not cause an averaging
> problem, but it does cause a 5-block delay in the response.)
> _______________________________________________
> 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/20171009/198043c0/attachment.html>

2023-06-07 20:06:48 CEST

- reply

📅 Original date posted:2017-10-01
📝 Original message:I would also suggest that the 520 byte push limitation be removed for v1 scripts as well. MERKLEBRANCHVERIFY in particular could benefit from larger proof sizes. To do so safely would require reworking script internals to use indirect pointers and reference counting for items on stack, but this is worth doing generally, and introducing a per-input hashing limit equal to a small multiple of the witness size (or retaining the opcount limit).
> On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I've put together a first draft for what I hope to be a good next step for
> Segwit and Bitcoin scripting:
> https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki
>
> This introduces 5 key changes:
>
> 1. Minor versions for witnesses, inside the witness itself. Essentially the
> witness [major] version 1 simply indicates the witness commitment is SHA256d,
> and nothing more.
>
> The remaining two are witness version 1.0 (major 1, minor 0):
>
> 2. As previously discussed, undefined opcodes immediately cause the script to
> exit with success, making future opcode softforks a lot more flexible.
>
> 3. If the final stack element is not exactly true or false, it is interpreted
> as a tail-call Script and executed. (Credit to Mark Friedenbach)
>
> 4. A new shorter fixed-length signature format, eliminating the need to guess
> the signature size in advance. All signatures are 65 bytes, unless a condition
> script is included (see #5).
>
> 5. The ability for signatures to commit to additional conditions, expressed in
> the form of a serialized Script in the signature itself. This would be useful
> in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the
> whole replay protection argument by introducing it early to Bitcoin before any
> further splits.
>
> This last part is a big ugly right now: the signature must commit to the
> script interpreter flags and internal "sigversion", which basically serve the
> same purpose. The reason for this, is that otherwise someone could move the
> signature to a different context in an attempt to exploit differences in the
> various Script interpretation modes. I don't consider the BIP deployable
> without this getting resolved, but I'm not sure what the best approach would
> be. Maybe it should be replaced with a witness [major] version and witness
> stack?
>
> There is also draft code implementing [the consensus side of] this:
> https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
>
> Thoughts? Anything I've overlooked / left missing that would be
> uncontroversial and desirable? (Is any of this unexpectedly controversial for
> some reason?)
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:06:48 CEST

- reply

📅 Original date posted:2017-10-01
📝 Original message:> On Oct 1, 2017, at 2:32 PM, Johnson Lau <jl2012 at xbt.hk> wrote:
>
> So there are 3 proposals with similar goal but different designs. I try to summarise some questions below:
>
> 1. How do we allow further upgrade within v1 witness? Here are some options:
> a. Minor version in witness. (Johnson / Luke) I prefer this way, but we may end up with many minor versions.
I'm not sure I agree with the "minor version" nomenclature, or that we would necessarily end up with any consensus-visible fields beyond 2. There are two separate soft-fork version fields that were, I think it is fair to say now, inappropriately merged in the "script version” feature of segregated witness as described in BIP141.
First there is the witness type, which combined with the length of the commitment that follows specifies how data from the witness stack is used to calculate/verify the witness commitment in the scriptPubKey of the output being spent. For v0 with a 20-byte hash, it says that those 20 bytes are the HASH160 of the top element of the stack. For v0 with a 32-byte hash, it says that those 32 bytes are the HASH256 of the top element of the stack.
Second there is the script version, which is not present as a separate field for witness type v0. Implicitly though, the script version for v0,20-byte is that the witness consists of two elements, and these are interpreted as a pubkey and a signature. For v0,32-byte the script version is that the witness consists of 1 or more elements; with max 520 byte size constraints for all but the top element, which has a higher limit of 10,000 bytes; and the top-most element is interpreted as a script and executed with the modified CHECKSIG behavior defined by BIP141 and the CLEANSTACK rule enforced.
These are separate roles, one not being derivative of the other. In an ideal world the witness type (of which there are only 16 remaining without obsoleting BIP141) is used only to specify a new function for transforming the witness stack into a commitment for verification purposes. Merklized script would be one example: v2,32-byte could be defined to require a witness stack of at least two elements, the top most of which is a Merkle inclusion proof of the second item in a tree whose root is given in the 32-byte payload of the output. Maybe v3 would prove inclusion by means of some sort of RSA accumulator or something.
Such a specification says nothing about the features of the subscript drawn from the Merkle tree, or even whether it is bitcoin script at all vs something else (Simplicity, DEX, RISC-V, Joy, whatever). All that is necessary is that a convention be adopted about where to find the script version from whatever data is left on the stack after doing the witness type check (hashing the script, calculating a Merkle root, checking inclusion in an RSA accumulator, whatever). A simple rule is that it is serialized and prefixed to the beginning of the string that was checked against the commitment in the output.
So v0,32-byte says that the top item is hashed and that hash must match the 32-byte value in the output. This new v1,32-byte witness type being talked about in this thread would have exactly the same hashing rules, but will execute the resulting string based on its prefix, the script version, which is first removed before execution.
Sure first script version used could be a cleaned up script with a bunch of the weirdness removed (CHECKMULTISIG, I'm looking at you!); CLTV, CSV, and MBV drop arguments; disabled opcodes and unassigned NOPs become "return true"; etc. Maybe v2 adds new opcodes. But we can imagine script version that do something totally different, like introduce a new script based on a strongly-typed Merklized lambda calculus, or a RISC-V executable format, or whatever.
This has pragmatic implications with the separation of witness type and script version: we could then define a "MAST" output that proves the script used is drawn from a set represented by the Merkle tree. However different scripts in that tree can use different versions. It would be useful if the most common script is the key aggregated everyone-signs outcome, which looks like a regular bitcoin payment, and then contingency cases can be handled by means of a complicated script written in some newly added general computation language or a whole emulated RISC-V virtual machine.
> b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114 but now I think it doesn’t interact well with signature aggregation, and I worry that it would have some other unexpected effects.
> c. Generalised NOP method: user has to provide the returned value, so even VERIFY-type code could do anything
I see no reason to do either. Gate new behavior based on script execution flags, which are set based on the script version. Script versions not understood are treated as "return true" to begin with. The interpreter isn't even going to try to decode the script according to the old rules, let alone try to execute it, so there's no reason for the old soft-fork compatability tricks.
The new soft-fork trick is that you increment the script version number. That is all.
> 2. Do we want to allow signature-time commitment of extra scripts?
> I think all proposals allow this, just with different way
> a. Tail-call semantics with CHECKSIGFROMSTACK (Mark). I think this is too rigid as it works only with specially designed scriptPubKey
This is not signature-time commitment of extra script. Not without CHECKSIGFROMSTACK or something like it.
> b. scriptWitCode: extra scripts are put in some fixed location in witness (Johnson). This makes sure static analysability.
> c. Extra-data as script in OP_CHECKSIG (Luke)
Propose these as their own script updates. Script versioning makes such new features cheap. There's no reason to create some sort of complex omnibus overhaul that does everything.
> 3. Do we want to allow static analysis of sigop?
> BIP114 and the related proposals are specifically designed to allow static analysis of sigop. I think this was one of the main reason of OP_EVAL not being accepted. This was also the main reason of Ethereum failing to do a DAO hacker softfork, leading to the ETH/ETC split. I’m not sure if we really want to give up this property. Once we do it, we have to support it forever.
Again, this is off-topic for this thread. I don't think a v1 witness type upgrade should do any of these things. The v1 witness type should add a proper script version in the witness, and remove or simplify limits or unnecessary verification rules that are no longer necessary and/or hindering progress. That’s it.
For example, I don't think a v1 witness version should be coupled with my tail-call semantics or the introduction of MERKLEBRANCHVERIFY (but if MBV was released already we could have it drop its arguments, which would be nice). However it should drop the CLEANSTACK rule in favor of something else (like signatures committing to the witness depth and/or weight) since the tail-call BIP demonstrates it to be an impediment to extensibility and alternatives are not. And it should drop the 520 byte push limitation, as the MBV BIP demonstrates use cases that have serialized proofs larger than that, like a k-of-N threshold with N=16.

2023-06-07 20:06:47 CEST

- reply

📅 Original date posted:2017-10-01
📝 Original message:> On Oct 1, 2017, at 12:41 PM, Russell O'Connor <roconnor at blockstream.io> wrote:
>
> Creating a Bitcoin script that does not allow malleability is difficult and requires wasting a lot of bytes to do so, typically when handling issues around non-0-or-1 witness values being used with OP_IF, and dealing with non-standard-zero values, etc.
Script validation flags of the correct place to do this. We already have policy validation flags that check for these things. They were not made consensus rules with Segwit v0 mainly due to concern over scope creep in an already large overhaul, of my memory is correct. Script versions and quadratic hashing fixes where the minimum necessary to allow segwit to activate safely while still enabling future upgrades that would otherwise have been hard forks. We knew that we would be later changing the EC signature scheme to be something that supported signature aggregation, and that would be more appropriate time to discuss such changes. As we are considering to do now (although witness versions means we don’t need to omnibus the script upgrade here either, so a v1 before signature aggregation is ready is fine IMHO).
In any case if there is any general witness malleability due to opcode semantics that it’s not fixed by one of our existing policy flags, that is a bug and I would encourage you to report it.
> I'll argue that I don't want my counter-party going off and using a very deeply nested key in order to subvert the fee rate we've agreed upon after I've signed my part of the input. If we are doing multi-party signing of inputs we need to communicate anyways to construct the transaction. I see no problem with requiring my counter-party to choose their keys before I sign so that I know up front what our fee rate is going to be. If they lose their keys and need a backup, they should have to come back to me to resign in order that we can negotiate a new fee rate for the transaction and who is going to be covering how much of the fee and on which inputs.
Arguing that every single user should be forced to restart an interactive signing session. That’s a very strong statement based on something that I would say is a preference that depends on circumstances.
What about an optional commitment to witness size in bytes? The value zero meaning “I don’t care.” I would argue that it should be a maximum however, and therefor serialized as part of the witness. The serialization of this would be very compact (1 plus the difference between actual and maximum, with zero meaning not used.)

2023-06-07 20:06:46 CEST

- reply

📅 Original date posted:2017-10-01
📝 Original message:> On Oct 1, 2017, at 12:05 PM, Russell O'Connor <roconnor at blockstream.io> wrote:
>
> Given the proposed fixed signature size, It seems better to me that we create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.
For what benefit? If your script actually uses all the items on the stack, and if your script is not written in such a way as to allow malleability (which cannot be prevented in general), then they’re equivalent. Using weight instead of depth only needlessly restricts other parties to select a witness size up-front.
And to be clear, signing witness weight doesn’t mean the witness is not malleable. The signer could sign again with a different ECDSA nonce. Or if the signer is signing from a 2-of-3 wallet, a common scenario I hope, there are 3 possible key combinations that could be used. If using MBV, a 3-element tree is inherently unbalanced and the common use case can have a smaller proof size.
Witnesses are not 3rd party malleable and we will maintain that property going forward with future opcodes.
> Mark, you seem to be arguing that in general we still want weight malleability even with witness depth fixed, but I don't understand in what scenario we would want that.
Any time all parties are not online at the same time in an interactive signing protocol, or for which individual parties have to reconfigure their signing choices due to failures. We should not restrict our script signature system to such a degree that it becomes difficult to create realistic signing setups for people using best practices (multi-key, 2FA, etc.) to sign. If I am a participant in a signing protocol, it would be layer violating to treat me as anything other than a black box, such that internal errors and timeouts in my signing setup don’t propagate upwards to the multi-party protocol.
For example, I should be able to try to 2FA sign, and if that fails go fetch my backup key and sign with that. But because it’s my infrequently used backup key, it might be placed deeper in the key tree and therefore signatures using it are larger. All the other signers need care is that slot #3 in the witness is where my Merkle proof goes. They shouldn’t have to restart and resign because my proof was a little larger than anticipated — and maybe they can’t resign because double-spend protections!

2023-06-07 20:06:45 CEST

- reply

📅 Original date posted:2017-09-30
📝 Original message:The CLEANSTACK rule should be eliminated, and instead the number of items on the stack should be incorporated into the signature hash. That way any script with a CHECKSIG is protected from witness extension malleability, and those rare ones that do not use signature operations can have a “DEPTH 1 EQUALVERIFY” at the end. This allows for much simpler tail-call evaluation as you don’t need to pass arguments on the alt-stack.
> On Sep 30, 2017, at 6:13 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I've put together a first draft for what I hope to be a good next step for
> Segwit and Bitcoin scripting:
> https://github.com/luke-jr/bips/blob/witnessv1/bip-witnessv1.mediawiki
>
> This introduces 5 key changes:
>
> 1. Minor versions for witnesses, inside the witness itself. Essentially the
> witness [major] version 1 simply indicates the witness commitment is SHA256d,
> and nothing more.
>
> The remaining two are witness version 1.0 (major 1, minor 0):
>
> 2. As previously discussed, undefined opcodes immediately cause the script to
> exit with success, making future opcode softforks a lot more flexible.
>
> 3. If the final stack element is not exactly true or false, it is interpreted
> as a tail-call Script and executed. (Credit to Mark Friedenbach)
>
> 4. A new shorter fixed-length signature format, eliminating the need to guess
> the signature size in advance. All signatures are 65 bytes, unless a condition
> script is included (see #5).
>
> 5. The ability for signatures to commit to additional conditions, expressed in
> the form of a serialized Script in the signature itself. This would be useful
> in combination with OP_CHECKBLOCKATHEIGHT (BIP 115), hopefully ending the
> whole replay protection argument by introducing it early to Bitcoin before any
> further splits.
>
> This last part is a big ugly right now: the signature must commit to the
> script interpreter flags and internal "sigversion", which basically serve the
> same purpose. The reason for this, is that otherwise someone could move the
> signature to a different context in an attempt to exploit differences in the
> various Script interpretation modes. I don't consider the BIP deployable
> without this getting resolved, but I'm not sure what the best approach would
> be. Maybe it should be replaced with a witness [major] version and witness
> stack?
>
> There is also draft code implementing [the consensus side of] this:
> https://github.com/bitcoin/bitcoin/compare/master...luke-jr:witnessv1
>
> Thoughts? Anything I've overlooked / left missing that would be
> uncontroversial and desirable? (Is any of this unexpectedly controversial for
> some reason?)
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:06:37 CEST

- reply

📅 Original date posted:2017-09-29
📝 Original message:This is correct. Under assumptions of a continuous mempool model however this should be considered the outlier behavior, other than a little bit of empty space at the end, now and then. A maximum fee rate calculated as a filter over past block rates could constrain this outlier behavior from ever happening too.
> On Sep 29, 2017, at 3:43 AM, Daniele Pinna <daniele.pinna at gmail.com> wrote:
>
> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner is incentivized to limit the amount of transactions in a block to capture the maximum fee of the ones included?
>
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If I were to submit a transaction paying 1 btc in maximal money fees, then the miner would be incentivized to include my transaction alone to avoid that lower fee paying transactions reduce the amount of fees he can earn from my transaction alone. This would mean that I could literally clog the network by paying 1btc every ten minutes.
>
> Am I missing something?
>
> Daniele

2023-06-07 20:06:35 CEST

- reply

📅 Original date posted:2017-09-28
📝 Original message:> On Sep 28, 2017, at 7:02 PM, Peter Todd <pete at petertodd.org> wrote:
>
>> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote:
>> Unlike other proposed fixes to the fee model, this is not trivially
>> broken by paying the miner out of band. If you pay out of band fee
>> instead of regular fee, then your transaction cannot be included with
>> other regular fee paying transactions without the miner giving up all
>> regular fee income. Any transaction paying less fee in-band than the
>> otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate
>> difference fee to make up for that lost income. So out of band fee is
>> only realistically considered when it pays on top of a regular feerate
>> paying transaction that would have been included in the block anyway.
>> And what would be the point of that?
>
> This proposed fix is itself broken, because the miner can easily include *only*
> transactions paying out-of-band, at which point the fee can be anything.
And in doing so either reduce the claimable income from other transactions (miner won’t do that), or require paying more non-rebateable fee than is needed to get in the block (why would the user do that?)
This is specifically addressed in the text you quoted.
> Equally, miners can provide fee *rebates*, forcing up prices for everyone else
> while still allowing them to make deals.
Discounted by the fact rebates would not be honored by other miners. The rebate would have to be higher than what they could get from straight fee collection, making it less profitable than doing nothing.
> Also, remember that you can pay fees via anyone-can-spend outputs, as miners
> have full ability to control what transactions end up spending those outputs.
You’d still have to pay the minimum fee rate of the other transactions or you’d bring down the miners income. Otherwise this is nearly the same cost as the rebate fee, since they both involve explicit outputs claimed by the miner, but the rebate goes back to you. So why would you not want to do that instead?
A different way of looking at this proposal is that it creates a penalty for out of band payments.

2023-06-07 20:06:22 CEST

- reply

📅 Original date posted:2017-09-27
📝 Original message:First, there’s been no discussion so far for address expiration to be part of “the protocol” which usually means consensus rules or p2p. This is purely about wallets and wallet information exchange protocols.
There’s no way for the sender to know whether an address has been used without a complete copy of the block chain and more indexes than even Bitcoin Core maintains. It’s simply not an option now, let alone as the blockchain grows into the future.
> On Sep 27, 2017, at 1:23 PM, Nick Pudar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> As a long term silent reader of this list, I felt compelled to comment on this address expiration topic. I don't believe that address expiration should be part of the protocol. I think instead that the "sending" feature should by default offer guidance to request a fresh address from the recipient. Also allow the receiver of funds to be able to generate an "invoice" that the sender acts on.
>
> I also think that re-directs are fraught with privacy issues. At the end of the day, the ultimate burden is on the sender (with much self interest from the receiver) that the correct address is being used.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/f8b622f6/attachment-0001.html>

2023-06-07 20:06:20 CEST

- reply

📅 Original date posted:2017-09-27
📝 Original message:While there is a lot that I would like to comment on, for the moment I will just mention that you should consider using the 17 bit relative time format used in CSV as an offset from the birthdate of the address, a field all addresses should also have.
This would also mean that addresses cannot last more than a year without user override, which might actually be a plus, but you could also extend the field by a few bits too if that was deemed not acceptable. An address should not be considered valid longer than anticipated lifetime of the underlying cryptosystem in any case, so every address should have an expiry.
> On Sep 27, 2017, at 9:06 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen; there
> are multiple examples of exchanges getting hacked, with users continuing to
> lose funds well after the actual hack has occured due to continuing deposits.
> This also makes it difficult operationally to rotate private keys. I personally
> have even lost funds in the past due to people sending me BTC to addresses that
> I gave them long ago for different reasons, rather than asking me for fresh
> one.
>
> To help combat this problem, I suggest that we add a UI-level expiration time
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time is
> reached.
>
> Unfortunately, this proposal inevitably will raise a lot of UI and terminology
> questions. Notably, the entire notion of addresses is flawed from a user point
> of view: their experience with them should be more like "payment codes", with a
> code being valid for payment for a short period of time; wallets should not be
> displaying addresses as actually associated with specific funds. I suspect
> we'll see users thinking that an expired address risks the funds themselves;
> some thought needs to be put into terminology.
>
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
>
> Both options have the advantage of working well at the UI level regardless of
> timezone: the former is sufficiently short that UI's can simply display an
> "exact" time (though note different leap second interpretations), while the
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the advantage of making
> it easy for services like exchanges to use addresses with relatively short
> validity periods, to reduce the risks of losses after a hack. Also, using at
> least hour-level ensures we don't have any year 2038 problems.
>
> Thoughts?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:05:44 CEST

- reply

📅 Original date posted:2017-09-07
📝 Original message:TL;DR I'll be updating the fast Merkle-tree spec to use a different
IV, using (for infrastructure compatability reasons) the scheme
provided by Peter Todd.
This is a specific instance of a general problem where you cannot
trust scripts given to you by another party. Notice that we run into
the same sort of problem when doing key aggregation, in which you must
require the other party to prove knowledge of the discrete log before
using their public key, or else key cancellation can occur.
With script it is a little bit more complicated as you might want
zero-knowledge proofs of hash pre-images for HTLCs as well as proofs
of DL knowledge (signatures), but the basic idea is the same. Multi-
party wallet level protocols for jointly constructing scriptPubKeys
should require a 'delinearization' step that proves knowledge of
information necessary to complete each part of the script, as part of
proving the safety of a construct.
I think my hangup before in understanding the attack you describe was
in actualizing it into a practical attack that actually escalates the
attacker's capabilities. If the attacker can get you to agree to a
MAST policy that is nothing more than a CHECKSIG over a key they
presumably control, then they don't need to do any complicated
grinding. The attacker in that scenario would just actually specify a
key they control and take the funds that way.
Where this presumably leads to an actual exploit is when you specify a
script that a curious counter-party actually takes the time to
investigate and believes to be secure. For example, a script that
requires a signature or pre-image revelation from that counter-party.
That would require grinding not a few bytes, but at minimum 20-33
bytes for either a HASH160 image or the counter-party's key.
If I understand the revised attack description correctly, then there
is a small window in which the attacker can create a script less than
55 bytes in length, where nearly all of the first 32 bytes are
selected by the attacker, yet nevertheless the script seems safe to
the counter-party. The smallest such script I was able to construct
was the following:
<fake-pubkey> CHECKSIGVERIFY HASH160 <preimage> EQUAL
This is 56 bytes and requires only 7 bits of grinding in the fake
pubkey. But 56 bytes is too large. Switching to secp256k1 serialized
32-byte pubkeys (in a script version upgrade, for example) would
reduce this to the necessary 55 bytes with 0 bits of grinding. A
smaller variant is possible:
DUP HASH160 <fake-pubkey-hash> EQUALVERIFY CHECKSIGVERIFY HASH160 <preimage> EQUAL
This is 46 bytes, but requires grinding 96 bits, which is a bit less
plausible.
Belts and suspenders are not so terrible together, however, and I
think there is enough of a justification here to look into modifying
the scheme to use a different IV for hash tree updates. This would
prevent even the above implausible attacks.
> On Sep 7, 2017, at 11:55 AM, Russell O'Connor <roconnor at blockstream.io> wrote:
>
>
>
> On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach > wrote:
> I've been puzzling over your email since receiving it. I'm not sure it
> is possible to perform the attack you describe with the tree structure
> specified in the BIP. If I may rephrase your attack, I believe you are
> seeking a solution to the following:
>
> Want: An innocuous script and a malign script for which
>
> double-SHA256(innocuous)
>
> is equal to either
>
> fast-SHA256(double-SHA256(malign) || r) or
> fast-SHA256(r || double-SHA256(malign))
>
> or fast-SHA256(fast-SHA256(double-SHA256(malign) || r1) || r0)
> or fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) || r0)
> or ...
>
> where r is a freely chosen 32-byte nonce. This would allow the
> attacker to reveal the innocuous script before funds are sent to the
> MAST, then use the malign script to spend.
>
> Because of the double-SHA256 construction I do not see how this can be
> accomplished without a full break of SHA256.
>
> The particular scenario I'm imagining is a collision between
>
> double-SHA256(innocuous)
>
> and
>
> fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || r1) || r0).
>
> where innocuous is a Bitcoin Script that is between 32 and 55 bytes long.
>
> Observe that when data is less than 55 bytes then double-SHA256(data) = fast-SHA256(fast-SHA256(padding-SHA256(data)) || 0x8000...100) (which is really the crux of the matter).
>
> Therefore, to get our collision it suffices to find a collision between
>
> padding-SHA256(innocuous)
>
> and
>
> fast-SHA256(double-SHA256(malign) || r2) || r1
>
> r1 can freely be set to the second half of padding-SHA256(innocuous), so it suffices to find a collision between
>
> fast-SHA256(double-SHA256(malign) || r2)
>
> and the first half of padding-SHA256(innocuous) which is equal to the first 32 bytes of innocuous.
>
> Imagine the first opcode of innocuous is the push of a value that the attacker claims to be his 33-byte public key.
> So long as the attacker doesn't need to prove that they know the discrete log of this pubkey, they can grind r2 until the result of fast-SHA256(double-SHA256(malign) || r2) contains the correct first couple of bytes for the script header and the opcode for a 33-byte push. I believe that is only about 3 or 4 bytes of they need to grind out.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170907/63af0292/attachment.html>

2023-06-07 20:05:42 CEST

- reply

📅 Original date posted:2017-09-06
📝 Original message:This design purposefully does not distinguish leaf nodes from internal nodes. That way it chained invocations can be used to validate paths longer than 32 branches. Do you see a vulnerability due to this lack of distinction?
> On Sep 6, 2017, at 6:59 PM, Russell O'Connor <roconnor at blockstream.io> wrote:
>
> The fast hash for internal nodes needs to use an IV that is not the standard SHA-256 IV. Instead needs to use some other fixed value, which should itself be the SHA-256 hash of some fixed string (e.g. the string "BIP ???" or "Fash SHA-256").
>
> As it stands, I believe someone can claim a leaf node as an internal node by creating a proof that provides a phony right-hand branch claiming to have hash 0x80000..0000100 (which is really the padding value for the second half of a double SHA-256 hash).
>
> (I was schooled by Peter Todd by a similar issue in the past.)
>
>> On Wed, Sep 6, 2017 at 8:38 PM, Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Fast Merkle Trees
>> BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
>> Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/e53c24c8/attachment.html>

2023-06-07 20:05:40 CEST

- reply

📅 Original date posted:2017-09-22
📝 Original message:There is no harm in the value being a maximum off by a few bytes.
> On Sep 22, 2017, at 2:54 PM, Sergio Demian Lerner <sergio.d.lerner at gmail.com> wrote:
>
> If the variable size increase is only a few bytes, then three possibilities arise:
>
> - one should allow signatures to be zero padded (to reach the maximum size) and abandon strict DER encoding
>
> - one should allow spare witness stack elements (to pad the size to match the maximum size) and remove the cleanstack rule. But this is tricky because empty stack elements must be counted as 1 byte.
>
> - signers must loop the generation of signatures until the signature generated is of its maximum size.

2023-06-07 20:05:39 CEST

- reply

📅 Original date posted:2017-09-22
📝 Original message:You generally know the witness size to within a few bytes right before signing. Why would you not? You know the size of ECDSA signatures. You can be told the size of a hash preimage by the other party. It takes some contriving to come up with a scheme where one party has variable-length signatures of their chosing
> On Sep 22, 2017, at 2:32 PM, Sergio Demian Lerner <sergio.d.lerner at gmail.com> wrote:
>
> But generally before one signs a transaction one does not know the signature size (which may be variable). One can only estimate the maximum size.

2023-06-07 20:05:38 CEST

- reply

📅 Original date posted:2017-09-19
📝 Original message:> On Sep 18, 2017, at 8:09 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
> On Tuesday 19 September 2017 12:46:30 AM Mark Friedenbach via bitcoin-dev
> wrote:
>> After the main discussion session it was observed that tail-call semantics
>> could still be maintained if the alt stack is used for transferring
>> arguments to the policy script.
>
> Isn't this a bug in the cleanstack rule?
Well in the sense that "cleanstack" doesn't do what it says, sure.
However cleanstack was introduced as a consensus rule to prevent a
possible denial of service vulnerability where a third party could
intercept any* transaction broadcast and arbitrarily add data to the
witness stack, since witness data is not covered by a checksig.
Cleanstack as-is accomplishes this because any extra items on the
stack would pass through all realistic scripts, remaining on the stack
and thereby violating the rule. There is no reason to prohibit extra
items on the altstack as those items can only arrive there
purposefully as an action of the script itself, not a third party
malleation of witness data. You could of course use DEPTH to write a
script that takes a variable number of parameters and sends them to
the altstack. Such a script would be malleable if those extra
parameters are not used. But that is predicated on the script being
specifically written in such a way as to be vulnerable; why protect
against that?
There are other solutions to this problem that could have been taken
instead, such as committing to the number of items or maximum size of
the stack as part of the sighash data, but cleanstack was the approach
taken. Arguably for a future script version upgrade one of these other
approaches should be taken to allow for shorter tail-call scripts.
Mark
* Well, almost any. You could end the script with DEPTH EQUAL and that
is a compact way of ensuring the stack is clean (assuming the script
finished with just "true" on the stack). Nobody does this however
and burning two witness bytes of every redeem script going forward
as a protective measure seems like an unnecessary ask.

2023-06-07 20:05:35 CEST

- reply

📅 Original date posted:2017-09-11
📝 Original message:My apologies for a delay in responding to emails on this list; I have
been fighting a cold.
(Also my apologies to Johnson Lau, as I forgot to forward this to the list.)
On Sep 8, 2017, at 2:21 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
> Tail-call execution semantics require "unclean stake" , i.e. final
> stake with more than one item. However, "unclean stake" is invalid
> (not just non-standard) in BIP141, so you could only use it with
> legacy P2SH (which is totally pointless....). A different design
> like OP_EVAL might be needed, or you need a new witness script
> version.
I believe you meant "unclean stack," and you are correct. This was
also pointed out last tuesday by a participant at the in-person
CoreDev meetup where the idea was presented.
This doesn't kill the idea, it just complicates the implementation
slightly. A simple fix would be to allow tail-recursion to occur if
the stack is not clean (as can happen with legacy P2SH as you point
out, or yet to be defined version 1+ forms of segwit script), OR if
there is a single item on the stack and the alt-stack is not empty.
For segwit v0 scripts you then have to move any arguments to the alt
stack before ending the redeem script, leaving just the policy script
on the main stack.
> I think you have also missed the sigOp counting of the executed
> script. As you can't count it without executing the script, the
> current static analysability is lost. This was one of the reasons
> for OP_EVAL being rejected. Since sigOp is a per-block limit, any
> OP_EVAL-like operation means block validity will depend on the
> precise outcome of script execution (instead of just pass or fail),
> which is a layer violation.
I disagree with this design requirement.
The SigOp counting method used by bitcoin is flawed. It incorrectly
limits not the number of signature operations necessary to validate a
block, but rather the number of CHECKSIGs potentially encountered in
script execution, even if in an unexecuted branch. (Admitedly MAST
makes this less of an issue, but there are still useful compact
scripts that use if/else constructs to elide a CHECKSIG.) Nor will it
account for aggregation when that feature is added, or properly
differentiate between signature operations that can be batched and
those that can not.
Additionally there are other resources used by script that should be
globally limited, such as hash operations, which are not accounted for
at this time and cannot be statically assessed, even by the flawed
mechanism by which SigOps are counted. I have maintained for some time
that bitcoin should move from having multiple separate global limits
(weight and sigops, hashed bytes in XT/Classic/BCH) to a single linear
metric that combines all of these factors with appropriate
coefficients.
A better way of handling this problem, which works for both SigOps and
HashOps, is to have the witness commit to the maximum resources
consumed by validation of the spend of the coin, to relay this data
with the transaction and include it in the SigHash, and to use the
committed maximum for block validation. This could be added in a
future script version upgrade. This change would also resolve the
issue that led to the clean stack rule in segwit, allowing future
versions of script to use tail-call recursion without involving the
alt-stack.
Nevertheless it is constructive feedback that the current draft of the
BIP and its implementation do not count SigOps, at all. There are a
couple of ways this can be fixed by evaluating the top-level script
and then doing static analysis of the resulting policy script, or by
running the script and counting operations actually performed.
Additionally, it is possible that we take this time to re-evaluate
whether we should be counting SigOps other than for legacy consensus
rule compliance. The speed of verification in secp256k1 has made
signature operations no longer the chief concern in block validation
times.
> Witness script versioning is by design fully compatible with P2SH
> and BIP173, so there will be no hurdle for existing wallets to pay
> to BIP114. Actually it should be completely transparent to them.
This is correct. Your feedback will be incorporated.
> For code complexity, the minimal BIP114 could be really simple, like
> <30 lines of code? It looks complex now because it does much more
> than simply hiding scripts in a hash.
Is there a repo that contains the latest implementation of BIP 114,
for comparison purposes?
Kind regards,
Mark Friedenbach

2023-06-07 20:05:34 CEST

- reply

📅 Original date posted:2017-09-06
📝 Original message:I would like to propose two new script features to be added to the
bitcoin protocol by means of soft-fork activation. These features are
a new opcode, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution
semantics.
In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force
redemption to use values selected from a pre-determined set committed
to in the scriptPubKey, but without requiring revelation of unused
elements in the set for both enhanced privacy and smaller script
sizes. Tail-call execution semantics allows a single level of
recursion into a subscript, providing properties similar to P2SH while
at the same time more flexible.
These two features together are enough to enable a range of
applications such as tree signatures (minus Schnorr aggregation) as
described by Pieter Wuille [1], and a generalized MAST useful for
constructing private smart contracts. It also brings privacy and
fungibility improvements to users of counter-signing wallet/vault
services as unique redemption policies need only be revealed if/when
exceptional circumstances demand it, leaving most transactions looking
the same as any other MAST-enabled multi-sig script.
I believe that the implementation of these features is simple enough,
and the use cases compelling enough that we could BIP 8/9 rollout of
these features in relatively short order, perhaps before the end of
the year.
I have written three BIPs to describe these features, and their
associated implementation, for which I now invite public review and
discussion:
Fast Merkle Trees
BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
MERKLEBRANCHVERIFY
BIP: https://gist.github.com/maaku/bcf63a208880bbf8135e453994c0e431
Code: https://github.com/maaku/bitcoin/tree/merkle-branch-verify
Tail-call execution semantics
BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368
Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics
Note: I have circulated this idea privately among a few people, and I
will note that there is one piece of feedback which I agree with but
is not incorporated yet: there should be a multi-element MBV opcode
that allows verifying multiple items are extracted from a single
tree. It is not obvious how MBV could be modified to support this
without sacrificing important properties, or whether should be a
separate multi-MBV opcode instead.
Kind regards,
Mark Friedenbach

2023-06-07 20:05:05 CEST

- reply

📅 Original date posted:2017-08-28
📝 Original message:> On Aug 28, 2017, at 8:29 AM, Alex Nagy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob can safely issue Native P2WPKH outputs to Alice?
>
No, and the whole issue of compressed vs uncompressed is a red herring. If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, she is saying to Bob “I will accept payment to the scriptPubKey [DUP HASH160 PUSHDATA(20)[e4e517ee07984a4000cd7b00cbcb545911c541c4] EQUALVERIFY CHECKSIG]”.
Payment to any other scriptPubKey may not be recognized by Alice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170828/80188ca0/attachment.html>

2023-06-07 20:04:56 CEST

- reply

📅 Original date posted:2017-08-22
📝 Original message:A fun exercise to be sure, but perhaps off topic for this list?
> On Aug 22, 2017, at 1:06 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > The initial message I replied to stated:
>
> Yes, 3 years is silly. But coin expiration and quantum resistance is something I've been thinking about for a while, so I tried to steer the conversation away from stealing old money for no reason ;). Plus I like the idea of making Bitcoin "2000 year proof".
>
> - I cannot imagine either SHA256 or any of our existing wallet formats surviving 200 years, if we expect both moores law and quantum computing to be a thing. I would expect the PoW to be rendered obsolete before the Bitcoin addresses.
>
> - A PoW change using Keccak and a flexible number of bits can be designed as a "future hard fork". That is: the existing POW can be automatically rendered obsolete... but only in the event that difficulty rises to the level of obsolescence. Then the code for a new algorithm with a flexible number of bits and a difficulty that can scale for thousands of years can then automatically kick in.
>
> - A new addresses format and signing protocols that use a flexible number of bits can be introduced. The maximum number of supported bits can be configurable, and trivially changed. These can be made immediately available but completely optional.
>
> - The POW difficulty can be used to inform the expiration of any addresses that can be compromised within 5 years assuming this power was somehow used to compromise them. Some mechanism for translating global hashpower to brute force attack power can be researched, and consesrvative estimates made. Right now, it's like "heat death of the universe" amount of time to crack with every machine on the planet. But hey... things change and 2000 years is a long time. This information can be used to inform the expiration and reclamation of old, compromised public addresses.
>
> - Planning a hard fork 100 to 1000 years out is a fun exercise
>
>
>
>
>> On Tue, Aug 22, 2017 at 2:55 PM, Chris Riley <criley at gmail.com> wrote:
>> The initial message I replied to stated in part, "Okay so I quite like this idea. If we start removing at height 630000 or 840000 (gives us 4-8 years to develop this solution), it stays nice and neat with the halving interval...."
>>
>> That is less than 3 years or less than 7 years away. Much sooner than it is believed QC or Moore's law could impact bitcoin. Changing bitcoin so as to require that early coins start getting "scavenged" at that date seems unneeded and irresponsible. Besides, your ECDSA is only revealed when you spend the coins which does provide some quantum resistance. Hal was just an example of people putting their coins away expecting them to be there at X years in the future, whether it is for himself or for his kids and wife.
>>
>> :-)
>>
>>
>>
>>> On Tue, Aug 22, 2017 at 1:33 PM, Matthew Beton <matthew.beton at gmail.com> wrote:
>>> Very true, if Moore's law is still functional in 200 years, computers will be 2^100 times faster (possibly more if quantum computing becomes commonplace), and so old wallets may be easily cracked.
>>>
>>> We will need a way to force people to use newer, higher security wallets, and turning coins to mining rewards is better solution than them just being hacked.
>>>
>>>
>>>> On Tue, 22 Aug 2017, 7:24 pm Thomas Guyot-Sionnest <dermoth at aei.ca> wrote:
>>>> In any case when Hal Finney do not wake up from his 200years cryo-preservation (because unfortunately for him 200 years earlier they did not know how to preserve a body well enough to resurrect it) he would find that advance in computer technology made it trivial for anyone to steal his coins using the long-obsolete secp256k1 ec curve (which was done long before, as soon as it became profitable to crack down the huge stash of coins stale in the early blocks)
>>>>
>>>> I just don't get that argument that you can't be "your own bank". The only requirement coming from this would be to move your coins about once every 10 years or so, which you should be able to do if you have your private keys (you should!). You say it may be something to consider when computer breakthroughs makes old outputs vulnerable, but I say it's not "if" but "when" it happens, and by telling firsthand people that their coins requires moving every once in a long while you ensure they won't do stupid things or come back 50 years from now and complain their addresses have been scavenged.
>>>>
>>>> --
>>>> Thomas
>>>>
>>>>
>>>>> On 22/08/17 10:29 AM, Erik Aronesty via bitcoin-dev wrote:
>>>>> I agree, it is only a good idea in the event of a quantum computing threat to the security of Bitcoin.
>>>>>
>>>>>> On Tue, Aug 22, 2017 at 9:45 AM, Chris Riley via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>> This seems to be drifting off into alt-coin discussion. The idea that we can change the rules and steal coins at a later date because they are "stale" or someone is "hoarding" is antithetical to one of the points of bitcoin in that you can no longer control your own money ("be your own bank") because someone can at a later date take your coins for some reason that is outside your control and solely based on some rationalization by a third party. Once the rule is established that there are valid reasons why someone should not have control of their own bitcoins, what other reasons will then be determined to be valid?
>>>>>>
>>>>>> I can imagine Hal Finney being revived (he was cryo-preserved at Alcor if you aren't aware) after 100 or 200 years expecting his coins to be there only to find out that his coins were deemed "stale" so were "reclaimed" (in the current doublespeak - e.g. stolen or confiscated). Or perhaps he locked some for his children and they are found to be "stale" before they are available. He said in March 2013, "I think they're safe enough" stored in a paper wallet. Perhaps any remaining coins are no longer "safe enough."
>>>>>>
>>>>>> Again, this seems (a) more about an alt-coin/bitcoin fork or (b) better in bitcoin-discuss at best vs bitcoin-dev. I've seen it discussed many times since 2010 and still do not agree with the rational that embracing allowing someone to steal someone else's coins for any reason is a useful change to bitcoin.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 22, 2017 at 4:19 AM, Matthew Beton via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>> Okay so I quite like this idea. If we start removing at height 630000 or 840000 (gives us 4-8 years to develop this solution), it stays nice and neat with the halving interval. We can look at this like so:
>>>>>>>
>>>>>>> B - the current block number
>>>>>>> P - how many blocks behind current the coin burning block is. (630000, 840000, or otherwise.)
>>>>>>>
>>>>>>> Every time we mine a new block, we go to block (B-P), and check for stale coins. These coins get burnt up and pooled into block B's miner fees. This keeps the mining rewards up in the long term, people are less likely to stop mining due to too low fees. It also encourages people to keep moving their money around the enconomy instead of just hording and leaving it.
>>>>
>>
>
> _______________________________________________
> 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/20170822/4be654a2/attachment-0001.html>

2023-06-07 20:03:27 CEST

- reply

📅 Original date posted:2017-06-20
📝 Original message:Why do you say activation by August 1st is likely? That would require an entire difficulty adjustment period with >=95% bit1 signaling. That seems a tall order to organize in the scant few weeks remaining.
> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If segwit is activated before Aug 1, as now seems likely, there will be no split that day. But if activation is via Segwit2x (also likely), and at least some nodes do & some don't follow through with the HF 3mo later (again, likely), agreed w/ Greg that *then* we'll see a split - probably in Sep/Oct. How those two chains will match up and how the split will play out is anyone's guess...
>
>
>
> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Ironically, it looks like most of the segwit2x signaling miners are
> > faking it (because they're not signaling segwit which it requires).
> > It'll be unfortunate if some aren't faking it and start orphaning
> > their own blocks because they are failing to signal segwit.
>
> Well, they're doing some kind of "pre-signaling" in the coinbase at the moment, because the segwit2x project is still in alpha-phase according to the timeline. They're just showing commitment.
> I'm sure they will begin signaling on version bit 4/BIP91 as well as actually running a segwit2x node when the time comes.
>
>
> > As far as prevent a chain split goes, all those things
> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> > don't think that holds.
>
> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or BIP148) node, because they wouldn't have the new consensus rule of requiring all blocks to signal for segwit.
> I don't believe there would be any long lasting chainsplit though (because of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get unlucky.
>
> Hampus
>
> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>:
>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Because a large percentage of miners are indifferent, right now miners have
>> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>
>> Miners can simply continuing signaling segwit, which will leave them
>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>> what "segwit2x" is since they keep changing the actual definition and
>> do not have a specification; but last I saw the near-term behavior the
>> same as BIP91 but with a radically reduced activation window, so the
>> story would be the same there in the near term).
>>
>> Ironically, it looks like most of the segwit2x signaling miners are
>> faking it (because they're not signaling segwit which it requires).
>> It'll be unfortunate if some aren't faking it and start orphaning
>> their own blocks because they are failing to signal segwit.
>>
>> I don't think the rejection of segwit2x from Bitcoin's developers
>> could be any more resolute than what we've already seen:
>> https://en.bitcoin.it/wiki/Segwit_support
>>
>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > I think it is very naïve to assume that any shift would be temporary.
>> > We have a hard enough time getting miners to proactively upgrade to
>> > recent versions of the reference bitcoin daemon. If miners interpret
>> > the situation as being forced to run non-reference software in order
>> > to prevent a chain split because a lack of support from Bitcoin Core,
>> > that could be a one-way street.
>>
>> I think this is somewhat naive and sounds a lot like the repeat of the
>> previously debunked "XT" and "Classic" hysteria.
>>
>> There is a reason that segwit2x is pretty much unanimously rejected by
>> the technical community. And just like with XT/Classic/Unlimited
>> you'll continue to see a strong correlation with people who are
>> unwilling and unable to keep updating the software at an acceptable
>> level of quality-- esp. because the very founding on their fork is
>> predicated on discarding those properties.
>>
>> If miners want to go off and create an altcoin-- welp, thats something
>> they can always do, and nothing about that will force anyone to go
>> along with it.
>>
>> As far as prevent a chain split goes, all those things
>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>> don't think that holds.
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20170620/607ef338/attachment-0001.html>

2023-06-07 20:03:26 CEST

- reply

📅 Original date posted:2017-06-20
📝 Original message:I think it is very naïve to assume that any shift would be temporary.
We have a hard enough time getting miners to proactively upgrade to
recent versions of the reference bitcoin daemon. If miners interpret
the situation as being forced to run non-reference software in order
to prevent a chain split because a lack of support from Bitcoin Core,
that could be a one-way street.
On Tue, Jun 20, 2017 at 9:49 AM, Hampus Sjöberg via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't think it's a huge deal if the miners need to run a non-Core node
> once the BIP91 deployment of Segwit2x happens. The shift will most likely be
> temporary.
>
> I agree that the "-bip148"-option should be merged, though.
>
> 2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>:
>>
>> Are we going to merge BIP91 or a -BIP148 option to core for inclusion in
>> the next release or so?
>>
>> Because a large percentage of miners are indifferent, right now miners
>> have to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>
>> Should we be forcing miners to choose to run non-core code in order to
>> activate a popular feature?
>>
>> - Erik
>>
>> _______________________________________________
>> 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
>

2023-06-07 19:46:36 CEST

- reply

📅 Original date posted:2015-12-19
📝 Original message:Not entirely correct, no. Edge cases also matter. Segwit is described as
4MB because that is the largest possible combined block size that can be
constructed. BIP 102 + segwit would allow a maximum relay of 8MB. So you
have to be confident that an 8MB relay size would be acceptable, even if a
block full of actual transactions would be closer to 3.5MB.
On Fri, Dec 18, 2015 at 6:01 PM, sickpig--- via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Anthony,
>
>
> On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev
>> wrote:
>> > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Timón wrote:
>> > > Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
>> > > equivalent to the 2-4-8 "compromise" proposal [...]
>> > isn't SegWit gain ~75%? hence 2mb x 1.75 = 3.5.
>>
>> Segwit as proposed gives a 75% *discount* to witness data with the
>> same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up
>> of 650kB of base block data plus 1.4MB of witness data; where 650kB +
>> 1.4MB/4 = 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus
>> 2.8MB of witness, for 1.3MB+2.8MB/4 = 2MB at a 2MB limit.
>>
>> > 4x is theoric gain you get in case of 2-2 multisig txs.
>>
>> With segregated witness, 2-2 multisig transactions are made up of 94B
>> of base data, plus about 214B of witness data; discounting the witness
>> data by 75% gives 94+214/4=148 bytes. That compares to about 301B for
>> a 2-2 multisig transaction with P2SH rather than segwit, and 301/148
>> gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed
>> to get the numbers above.
>>
>> You get further improvements with, eg, 3-of-3 multisig, but to get
>> the full, theoretical 4x gain you'd need a fairly degenerate looking
>> transaction.
>>
>> Pay to public key hash with segwit lets you move about half the
>> transaction data into the witness, giving about a 1.6x improvement by
>> my count (eg 1.6MB = 800kB of base data plus 800kB of witness data,
>> where 800kB+800kB/4=1MB), so I think a gain of between 1.6 and 2.0 is
>> a reasonable expectation to have for the proposed segwit scheme overall.
>>
>>
> many thanks for the explanation.
>
> so it should be fair to say that BIP 102 + SW would bring a gain between
> 2*1.6 and 2*2.
>
> Just for the sake of simplicity if we take the middle of the interval we
> could say
> that BIP102 + SW will bring us a max block (virtual) size equal to 1MB * 2
> * 1.8 = 3.6
>
> Is it right?
>
>
>
>
> _______________________________________________
> 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/20151219/991342c9/attachment-0001.html>

2023-06-07 19:45:44 CEST

- reply

📅 Original date posted:2015-12-09
📝 Original message:My apologies for the apparent miscommunication earlier. It is of interest
to me that the soft-fork be done which is necessary to put a commitment in
the most efficient spot possible, in part because that commitment could be
used for other data such as the merged mining auxiliary blocks, which are
very sensitive to proof size.
Perhaps we have a different view of how the commitment transaction would be
generated. Just as GBT doesn't create the coinbase, it was my expectation
that it wouldn't generate the commitment transaction either -- but
generation of the commitment would be easy, requiring either the coinbase
txid 100 blocks back, or the commitment txid of the prior transaction (note
this impacts SPV mining). The truncation shouldn't be an issue because the
commitment txn would not be part of the list of transactions selected by
GBT, and in any case the truncation would change the witness data which
changes the commitment.
On Wed, Dec 9, 2015 at 4:03 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> > From this question one could think that when you said "we can do the
> > cleanup hardfork later" earlier you didn't really meant it. And that
> > you will oppose to that hardfork later just like you are opposing to
> > it now.
> > As said I disagree that making a softfork first and then move the
> > commitment is less disruptive (because people will need to adapt their
> > software twice), but if the intention is to never do the second part
> > then of course I agree it would be less disruptive.
> > How long after the softfork would you like to do the hardfork?
> > 1 year after the softfork? 2 years? never?
>
> I think it would be logical to do as part of a hardfork that moved
> commitments generally; e.g. a better position for merged mining (such
> a hardfork was suggested in 2010 as something that could be done if
> merged mining was used), room for commitments to additional block
> back-references for compact SPV proofs, and/or UTXO set commitments.
> Part of the reason to not do it now is that the requirements for the
> other things that would be there are not yet well defined. For these
> other applications, the additional overhead is actually fairly
> meaningful; unlike the fraud proofs.
> _______________________________________________
> 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/20151209/0736595c/attachment.html>

2023-06-07 19:45:43 CEST

- reply

📅 Original date posted:2015-12-09
📝 Original message:Greg, if you have actual data showing that putting the commitment in the
last transaction would be disruptive, and how disruptive, that would be
appreciated. Of the mining hardware I have looked at, none of it cared at
all what transactions other than the coinbase are. You need to provide a
path to the coinbase for extranonce rolling, but the witness commitment
wouldn't need to be updated.
I'm sorry but it's not clear how this would be an incompatible upgrade,
disruptive to anything other than the transaction selection code. Maybe I'm
missing something? I'm not familiar with all the hardware or pooling setups
out there.
On Wed, Dec 9, 2015 at 2:29 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler <rryananizer at gmail.com> wrote:
> >>I agree, but nothing I have advocated creates significant technical
> >>debt. It is also a bad engineering practice to combine functional
> >>changes (especially ones with poorly understood system wide
> >>consequences and low user autonomy) with structural tidying.
> >
> > I don't think I would classify placing things in consensus critical code
> > when it doesn't need to be as "structural tidying". Gavin said "pile on"
> > which you took as implying "a lot", he can correct me, but I believe he
> > meant "add to".
>
> Nothing being discussed would move something from consensus critical
> code to not consensus critical.
>
> What was being discussed was the location of the witness commitment;
> which is consensus critical regardless of where it is placed. Should
> it be placed in an available location which is compatible with the
> existing network, or should the block hashing data structure
> immediately be changed in an incompatible way to accommodate it in
> order to satisfy an ascetic sense of purity and to make fraud proofs
> somewhat smaller?
>
> I argue that the size difference in the fraud proofs is not
> interesting, the disruption to the network in an incompatible upgrade
> is interesting; and that if it really were desirable reorganization to
> move the commitment point could be done as part of a separate change
> that changes only the location of things (and/or other trivial
> adjustments); and that proceeding int this fashion would minimize
> disruption and risk... by making the incompatible changes that will
> force network wide software updates be as small and as simple as
> possible.
>
> >> (especially ones with poorly understood system wide consequences and low
> >> user autonomy)
> >
> > This implies there you have no confidence in the unit tests and
> functional
> > testing around Bitcoin and should not be a reason to avoid refactoring.
> > It's more a reason to increase testing so that you will have confidence
> when
> > you refactor.
>
> I am speaking from our engineering experience in a public,
> world-wide, multi-vendor, multi-version, inter-operable, distributed
> system which is constantly changing and in production contains private
> code, unknown and assorted hardware, mixtures of versions, unreliable
> networks, undisclosed usage patterns, and more sources of complex
> behavior than can be counted-- including complex economic incentives
> and malicious participants.
>
> Even if we knew the complete spectrum of possible states for the
> system the combinatioric explosion makes complete testing infeasible.
>
> Though testing is essential one cannot "unit test" away all the risks
> related to deploying a new behavior in the network.
> _______________________________________________
> 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/20151209/5924c67f/attachment.html>

2023-06-07 19:45:38 CEST

- reply

📅 Original date posted:2015-12-08
📝 Original message:A far better place than the generation transaction (which I assume means
coinbase transaction?) is the last transaction in the block. That allows
you to save, on average, half of the hashes in the Merkle tree.
On Tue, Dec 8, 2015 at 11:55 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote:
> > Stuffing the segwitness merkle tree in the coinbase
>
> If such a change is going to be deployed via a soft fork instead of a
> hard fork, then the coinbase is the worst place to put the segwitness
> merkle root.
>
> Instead, put it in the first output of the generation transaction as an
> OP_RETURN script.
>
> This is a better pattern because coinbase space is limited while output
> space is not. The next time there's a good reason to tie another merkle
> tree to a block, that proposal can be designated for the second output
> of the generation transaction.
>
>
> _______________________________________________
> 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/20151209/040dbf84/attachment.html>

2023-06-07 19:44:10 CEST

- reply

📅 Original date posted:2015-11-04
📝 Original message:At the first Scaling Bitcoin workshop in Montreal I presented on the topic
of "bad blocks" that take an excessive amount of time to validate. You can
read a transcript of this talk here:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/alternatives-to-block-size-as-aggregate-resource-limits/
The core message was that the assumption made by the design parameters of
the system, namely that validation costs scale linearly with transaction or
block size, is wrong. In particular, in certain kinds of transactions there
are validation costs which scale quadraticly with size. For example, the
construction of SIGHASH_ALL results in each input signing a different
message digest, meaning that the entire transaction (minus the scriptSigs)
is rehashed for each input. As another example, the number of signature
operation performed during block validation is unlimited if the validations
are contained within the scriptPubKey (this scales linearly but with a very
large constant factor). The severity of these issues increase as the
aggregate limits in place on maximum transaction and block size increase.
There have been various solutions suggested, and I would like to start a
public discussion to see if consensus can be reached over a viable approach.
Gavin, for example, has written code that tracks the number of bytes hashed
and enforces a separate limit for a block over this aggregate value. Other
costs could be constrained in a similar whack-a-mole way. I have two
concerns with this approach:
1. There would still exist a gap between the average-case validation cost
of a full block and the worst case validation cost of a block that was
specifically constructed to hit every limit.
2. Transaction selection and by extension fee determination would become
much more complicated multi-dimensional optimization problems. Since fee
management in particular is code replicated in a lot of infrastructure, I
would be very concerned over making optimal behavior greatly more difficult.
My own suggestion, which I submit for consideration, is to use a linear
function of the various costs involved (signatures verified, bytes hashed,
inputs consumed, script opcodes executed, etc.). The various algorithms
used for transaction selection and fee determination can then be reused,
using the output of this new linear function as the "size" of the
transaction.
Separately, many others including Greg Maxwell have advocated for a
"net-UTXO" metric instead of, or in combination with a validation-cost
metric. In the pure form the block size limit would be replaced with a
maximum UTXO set increase, thereby applying a cost in extra fee required to
create unspent outputs. This has the distinct advantage of making dust
outputs considerably more expensive than regular spend outputs.
For myself, I remain open to the possibility of adding a UTXO set size
corrective factor to a chiefly validation-cost metric. It would be nice to
reward users for cleaning up scattered small output, reward miners for
including dust-be-gone outputs, and make spam attacks more costly. But
doing so requires setting aside some unused validation resources in order
to reward miners who clean up the UTXO, which means it widens the gap
between average and worst case block validation times. Also, worry over the
size of the UTXO database is only a concern for how Bitcoin Core is
currently structured -- with e.g. UTXO or STXO commitments it could be the
case that in the future full nodes do not store the UTXO and instead carry
proofs of their inputs as prunable witness data. If we choose a net-UTXO
metric however, we will be stuck with it for some time.
I will be submitting a talk proposal for Scaling Bitcoin on this topic, but
I would like to get some feedback from the developer community first.
Anyone have any thoughts to add?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151104/036ee438/attachment.html>

2023-06-07 19:41:26 CEST

- reply

📅 Original date posted:2015-09-27
📝 Original message:Agree with all CLTV and nVersionBits points. We should deploy a lock-time
soft-fork ASAP, using the tried and true IsSuperMajoirty test.
However your information regarding BIPs 68 (sequence numbers), 112
(checksequenceverify) and 113 (median time past) is outdated. Debate
regarding semantics has been settled, and there are working implementations
ready for merge on github. See pull requests #6312, #6564, and #6566. I
don’t know what the hold up has been regarding further reviews and merging,
but it is ready.
If you believe there are reasons #6312, #6564, or #6566 should not be
merged, please speak up. Otherwise it appears there is consensus on these
changes. They are related, and there is no reason not to include them in
the soft-fork, delaying applications using these features by 6-12 months.
On Sun, Sep 27, 2015 at 11:50 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Summary
> -------
>
> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
> the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
> pull-req for git HEAD for the soft-fork deployment has been open since
> June 28th, #6351 - the opcode implementation itself was merged two
> months ago.
>
> We should release a v0.10.3 and v0.11.1 with CLTV and get the ball
> rolling on miner adoption. We have consensus that we need CLTV, we have
> a well tested implementation, and we have a well-tested deployment
> mechanism. We also don't need to wait for other soft-fork proposals to
> catch up - starting the CLTV deployment process isn't going to delay
> future soft-forks, or for that matter, hard-forks.
>
> I think it's possible to safely get CLTV live on mainnet before the end
> of the year. It's time we get this over with and done.
>
>
> Detailed Rational
> -----------------
>
> 1) There is a clear need for CLTV
>
> Escrow and payment channels both benefit greatly from CLTV. In
> particular, payment channel implementations are made significantly
> simpler with CLTV, as well as more secure by removing the malleability
> vulnerability.
>
> Why are payment channels important? There's a lot of BTC out there
> vulnerable to theft that doesn't have to be. For example, just the other
> day I was talking with Nick Sullivan about ChangeTip's vulnerability to
> theft, as well as regulatory uncertainty about whether or not they're a
> custodian of their users' funds. With payment channels ChangeTip would
> only be able to spend as much of a deposit as a user had spent, keeping
> the rest safe from theft. Similarly, in the other direction - ChangeTip
> to their users - in many cases it is feasible to also use payment
> channels to immediately give users control of their funds as they
> receive them, again protecting users and helping make the case that
> they're not a custodian. In the future I'm sure we'll see fancy
> bi-directional payment channels serving this role, but lets not let
> perfect be the enemy of good.
>
>
> 2) We have consensus on the semantics of the CLTV opcode
>
> Pull-req #6124 - the implementation of the opcode itself - was merged
> nearly three months ago after significant peer review and discussion.
> Part of that review process included myself(1) and mruddy(2) writing
> actual demos of CLTV. The chance of the CLTV semantics changing now is
> near-zero.
>
>
> 3) We have consensus that Bitcoin should adopt CLTV
>
> The broad peer review and discussion that got #6124 merged is a clear
> sign that we expect CLTV to be eventually adopted. The question isn't if
> CLTV should be added to the Bitcoin protocol, but rather when.
>
>
> 4) The CLTV opcode and IsSuperMajority() deployment code has been
> thoroughly tested and reviewed
>
> The opcode implementation is very simple, yet got significant review,
> and it has solid test coverage by a suite of tx-(in)valid.json tests.
> The tests themselves have been reviewed by others, resulting in Esteban
> Ordano's pull-req #6368 by Esteban Ordano which added a few more cases.
>
> As for the deployment code, both the actual IsSuperMajority() deployment
> code and associated unit-tests tests were copied nearly line-by-line
> from the succesful BIP66. I did this deliberately to make all the peer
> review and testing of the deployment mechanism used in BIP66 be equally
> valid for CLTV.
>
>
> 5) We can safely deploy CLTV with IsSuperMajority()
>
> We've done two soft-forks so far with the IsSuperMajority() mechanism,
> BIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself
> worked flawlessly. As is well-known BIP66 in combination with a large %
> of the hashing power running non-validating "SPV" mining operations did
> lead to a temporary fork, however the root cause of this issue is
> unavoidable and not unique to IsSuperMajority() soft-forks.
>
> Pragmatically speaking, now that miners are well aware of the issue it
> will be easy for them to avoid a repeat of that fork by simply adding
> IsSuperMajority() rules to their "SPV" mining code. Equally turning off
> SPV mining (temporarily) is perfectly feasable.
>
>
> 6) We have the necessary consensus to deploy CLTV via IsSuperMajority()
>
> The various "nVersion bits" proposals - which I am a co-author of - have
> the primary advantage of being able to cleanly deal with the case where
> a soft-fork fails to get adopted. However, we do have broad consensus,
> including across all sides of the blocksize debate, that CLTV should be
> adopted. The risk of CLTV failing to get miner adoption, and thus
> blocking other soft-forks, is very low.
>
>
> 7) Using IsSuperMajority() to deploy CLTV doesn't limit or delay other
> upgrades
>
> It _is_ possible for multiple IsSuperMajority() soft-forks to coexist,
> in the sense that if one soft-fork is "in flight" that doesn't prevent
> another soft-fork from also being deployed simultaneously.
>
> In particular, if we deploy CLTV via IsSuperMajority() that does _not_
> impact the adoption schedule for other future soft-forks, including
> soft-forks using a future nVersion bits deployment mechanism.
>
> For instance, suppose we start deployment of CLTV right now with
> nVersion=4 blocks. In three months we have 25% miner support, and start
> deploying CHECKSEQUENCEVERIFY with nVersion=5 blocks. For miners
> supporting only OP_CLTV, the nVersion=5 blocks still trigger OP_CLTV;
> miners creating nVersion=5 blocks are simply stating that they support
> both soft-forks. Equally, if in three months we finish a nVersion bits
> proposal, those miners will be advertising nVersion=(1 << 29) blocks,
> which also advertise OP_CLTV support.
>
>
> 8) BIP101 miners have not proved to be a problem for CLTV deployment
>
> While there was concern that BIP101's use of nVersion would cause
> issues with a IsSuperMajority() softfork, the % of blocks with BIP101
> nVersion's never reached more than 1%, and currently is hovering at
> around 0.1%
>
> As Gavin Andresen has stated that he is happy to add CLTV to BIP101, and
> thus Bitcoin XT, I believe we can expect those miners to safely support
> CLTV well before soft-fork enforcement happens. Secondly, the 95%
> enforcement threshold means we can tolerate a fairly high % of miners
> running pre-CLTV BIP101 implementations without fatal effects in the
> unlikely event that those miners don't upgrade.
>
>
> 9) Doing another IsSuperMajority() soft-fork doesn't "burn a bit"
>
> This is a common myth! All nVersion bits proposals involve permanently
> setting a high-order bit to 1, which results in nVersion >= all prior
> IsSuperMajority() soft-forks. In short, we can do a nearly unlimited
> number of IsSuperMajority() soft-forks without affecting future nVersion
> bits soft-forks at all.
>
>
> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
> soft-fork with CSV using the nVersion bits mechanism.
>
> nVersion bits doesn't even have an implementation yet, nor has solid
> consensus been reached on the exact semantics of how nVersion bits
> should work. The stateful nature of nVersion bits soft-forks requires a
> significant amount of new code compared to IsSuperMajority() soft-forks,
> which in turn will require a significant amount of testing. (again I'll
> point out I'm a co-author to all the nVersion bits proposals)
>
> CSV has an implementation, but there is still debate going on about what
> the exact semantics of it should be. Getting the semantics right is
> especially important as part of CSV includes changing the meaning of
> nSequence, restricting future uses of that field. There have been many
> proposals to use nSequence, e.g. for proof-of-stake blocksize voting,
> and it has the unique capability of being a field that is both unused,
> and signed by scriptSigs. We shouldn't take potentially restricting
> future uses of it lightly.
>
> CSV is also significantly more complex and invasive than CLTV in terms
> of code changes. A large % of the mining power is running forks
> of Bitcoin Core with custom changes - modifying these forks with new
> features is a labor intensive and slow process.
>
> If CLTV is ready now, why delay it - potentially for 6-12 months - for
> other proposals to catch up? Equally if they do catch up, great! As
> explained above an in-flight CLTV soft-fork won't delay future upgrades.
>
>
> 11) Even if CLTV is broken/obsoleted there is very little carrying cost
> to having it
>
> Suppose we decide in two years that CLTV was botched and we need to fix
> it. What's the "carrying cost" of having implemented CLTV in the first
> place?
>
> We'll have used up one of our ten soft-forkable NOPs, but if we ever
> "run out" it's easy to use extension NOPs(3). Similarly, future script
> improvements like OP_MAST - or even a hard-fork - can easily expand the
> range of NOPs to the point where this is a non-issue.
>
> If you don't use OP_CLTV in your scripts there is zero effect on your
> transactions; we're not limiting future improvements to Bitcoin in any
> way other than using up a NOP by implementing CLTV.
>
>
> References
> ----------
>
> 1) https://github.com/petertodd/checklocktimeverify-demos
> 2) https://github.com/mruddy/bip65-demos
> 3) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-101293403
> 4) https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000006a257845da185433cbde54a74be889b1c046a267dcf4ab2
>
> _______________________________________________
> 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/20150927/7fbbbfa6/attachment-0001.html>

2023-06-07 19:40:49 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:I am unlikely to attend at that time, but there is no time that will fit
everybody's schedules. I approve of the idea and look forward to reading
the logs.
On Thu, Sep 17, 2015 at 9:07 PM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> At Monday's code sprint we had a good idea to schedule a regular developer
> meeting in #bitcoin-dev.
>
> Attendance is of course voluntary, but it may be good to have a time that
> many people are expected to be present and current issues can be discussed.
>
> Any preference for days/times?
>
> What about e.g. every week 15:00-16:00 UTC on Thursday?
>
> Wladimir
> _______________________________________________
> 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/20150918/095b3f02/attachment.html>

2023-06-07 19:40:43 CEST

- reply

📅 Original date posted:2015-09-17
📝 Original message:Note that this violates present assumptions about transaction validity,
unless a constraint also exists that any output of such an expiry block is
not spent for at least 100 blocks.
Do you have a clean way of ensuring this?
On Thu, Sep 17, 2015 at 2:41 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Fill-or-kill tx is not a new idea and is discussed in the Scaling Bitcoin
> workshop. In Satoshi's implementation of nLockTime, a huge range of
> timestamp (from 1970 to 2009) is wasted. By exploiting this unused range
> and with compromise in the time resolution, a fill-or-kill system could be
> built with a softfork.
>
> -----------
> Two new parameters, nLockTime2 and nKillTime are defined:
>
> nLockTime2 (Range: 0-1,853,010)
> 0: Tx could be confirmed at or after block 420,000
> 1: Tx could be confirmed at or after block 420,004
> .
> .
> 719,999: Tx could be confirmed at or after block 3,299,996 (about 55 years
> from now)
> 720,000: Tx could be confirmed if the median time-past >= 1,474,562,048
> (2016-09-22)
> 720,001: Tx could be confirmed if the median time-past >= 1,474,564,096
> (2016-09-22)
> .
> .
> 1,853,010 (max): Tx could be confirmed if the median time-past >=
> 3,794,966,528 (2090-04-04)
>
> nKillTime (Range: 0-2047)
> if nLockTime2 < 720,000, the tx could be confirmed at or before block
> (nLockTime2 + nKillTime * 4)
> if nLockTime2 >= 720,000, the tx could be confirmed if the median
> time-past <= (nLockTime2 - 720,001 + nKillTime) * 2048
>
> Finally, nLockTime = 500,000,000 + nKillTime + nLockTime2 * 2048
>
> Setting a bit flag in tx nVersion will activate the new rules.
>
> The resolution is 4 blocks or 2048s (34m)
> The maximum confirmation window is 8188 blocks (56.9 days) or 16,769,024s
> (48.5 days)
>
> For example:
> With nLockTime2 = 20 and nKillTime = 100, a tx could be confirmed only
> between block 420,080 and 420,480
> With nLockTime2 = 730,000 and nKillTime = 1000, a tx could be confirmed
> only between median time-past of 1,495,042,048 and 1,497,090,048
>
> ----------------
> Why is this a softfork?
>
> Remember this formula: nLockTime = 500,000,000 + nKillTime + nLockTime2 *
> 2048
>
> For height based nLockTime2 (<= 719,999)
>
> For nLockTime2 = 0 and nKillTime = 0, nLockTime = 500,000,000, which means
> the tx could be confirmed after 1970-01-01 with the original lock time
> rule. As the new rule does not allow confirmation until block 420,000, it's
> clearly a softfork.
>
> It is not difficult to see that the growth of nLockTime will never catch
> up nLockTime2.
>
> At nLockTime2 = 719,999 and nKillTime = 2047, nLockTime = 1,974,559,999,
> which means 2016-09-22. However, the new rule will not allow confirmation
> until block 3,299,996 which is decades to go
>
>
>
> For time based nLockTime2 (> 720,000)
>
> For nLockTime2 = 720,000 and nKillTime = 0, nLockTime = 1,974,560,000,
> which means the tx could be confirmed after median time-past 1,474,560,000
> (assuming BIP113). However, the new rule will not allow confirmation until
> 1,474,562,048, therefore a soft fork.
>
> For nLockTime2 = 720,000 and nKillTime = 2047, nLockTime = 1,974,562,047,
> which could be confirmed at 1,474,562,047. Again, the new rule will not
> allow confirmation until 1,474,562,048. The 1 second difference makes it a
> soft fork.
>
> Actually, for every nLockTime2 value >= 720,000, the lock time with the
> new rule must be 1-2048 seconds later than the original rule.
>
> For nLockTime2 = 1,853,010 and nKillTime = 2047, nLockTime =
> 4,294,966,527, which is the highest possible value with the 32-bit nLockTime
>
> ----------------
> User's perspective:
>
> A user wants his tx either filled or killed in about 3 hours. He will set
> a time-based nLockTime2 according to the current median time-past, and set
> nKillTime = 5
>
> A user wants his tx get confirmed in the block 630000, the first block
> with reward below 10BTC. He is willing to pay high fee but don't want it
> gets into another block. He will set nLockTime2 = 210,000 and nKillTime = 0
>
> ----------------
> OP_CLTV
>
> Time-based OP_CLTV could be upgraded to support time-based nLockTime2.
> However, height-based OP_CLTV is not compatible with nLockTime2. To spend a
> height-based OP_CLTV output, user must use the original nLockTime.
>
> We may need a new OP_CLTV2 which could verify both nLockTime and nLockTime2
>
> ----------------
> 55 years after?
>
> The height-based nLockTime2 will overflow in 55 years. It is very likely a
> hard fork will happen to implement a better fill-or-kill system. If not, we
> could reboot everything with another tx nVersion for another 55 years.
>
>
> _______________________________________________
> 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/20150917/78f51514/attachment.html>

2023-06-07 19:40:33 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:Replying to this specific email only because it is the most recent in my
mail client.
Does this conversation have to happen on-list? It seems to have wandered
incredibly far off-topic.
On Sun, Sep 20, 2015 at 5:25 AM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Also, in the US, despite overwhelming resistance on a broad scale,
>> legislation continues to be presented which would violate the 2nd amendment
>> right to keep and bear arms.
>
>
> And yet the proposed legislation goes nowhere, and the USA continues to
> stand alone in having the first world's weakest gun control laws.
>
> You are just supporting my point with this example. Obama would like to
> restrict guns, but can't, because they are too popular (in the USA).
>
> The comparison to BitTorrent is likewise weak: governments hardly care
> about piracy. They care enough to pass laws occasionally, but not enough to
> put serious effort into enforcement. Wake me up when the USA establishes a
> Copyright Enforcement Administration with the same budget and powers as the
> DEA.
>
> Internet based black markets exist only because governments tolerate them
> (for now). A ban on Tor, Bitcoin or both would send them back to the
> pre-2011 state where they were virtually non-existent. Governments tolerate
> this sort of abuse only because they believe, I think correctly, that
> Bitcoin can have great benefits for their ordinary voters and for now are
> willing to let the tech industry experiment.
>
> But for that state of affairs to continue, the benefits must actually
> appear. That requires growth.
>
> I think there's a difference between natural growth and the kind of growth
>> that's being proposed by bank-backed start-ups and pro-censorship entities.
>>
>
> What difference? Are you saying the people who come to Bitcoin because of
> a startup are somehow less "natural" than other users?
>
> _______________________________________________
> 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/20150920/65ddbc70/attachment-0001.html>

2023-06-07 19:40:26 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:Correction of a correction, in-line:
On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > - Many interested or at least willing to accept a "short term bump", a
> > hard fork to modify block size limit regime to be cost-based via
> > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year
> > were debated and seemed "in range" with what might work as a short term
> > bump - net after applying the new cost metric.
>
> I would be careful to point out that hard numbers were deliberately NOT
> discussed. Though some general things were thrown out, they were not
> extensively discussed nor agreed to. I personally think 2-4 is "in
> range", though 8 maybe not so much. Of course it depends on exactly how
> the non-blocksize limit accounting/adjusting is done.
>
> Still, the "greatest common denominator" agreement did not seem to be
> agreeing to an increase which continues over time, but which instead
> limits itself to a set, smooth increase for X time and then requires a
> second hardfork if there is agreement on a need for more blocksize at
> that point.
>
Perhaps it is accurate to say that there wasn't consensus at all except
that (1) we think we can work together on resolving this impasse (yay!),
and (2) it is conceivable that changing from block size to some other
metric might provide the basis for a compromise on near-term numbers.
As an example, I do not think the net-UTXO metric provides any benefit with
respect to scalability, and in some ways makes the situation worse (even
though it helpfully solves an unrelated problem of spammy dust outputs).
But there are other possible metrics and I maintain hope that data will
show the benefit of another metric or other metrics combined with net-UTXO
in a way that will allow us to reach consensus.
As a further example, I also am quite concerned about 2-4-8MB with either
block size or net-UTXO as the base metric. As you say, it depends on how
the non-blocksize limit accounting/adjusting is done... But if a metric
were chosen that addressed my concerns (worst case propagation and
validation time), then I could be in favor of an initial bump that allowed
a larger number of typical transactions in a block.
But where I really need to disagree is on the requirement for a 2nd hard
fork. I will go on record as being definitively against this. While being
conservative with respect to exponentials, I would very much like to make
sure that there is a long-term growth curve as part of any proposal. I am
willing to accept a hard-fork if the adopted plan is too conservative, but
I do not want to be kicking the can down the road to a scheduled 2nd hard
fork that absolutely must occur. That, I feel, could be a more dangerous
outcome than an exponential that outlasts conservative historical trends.
I commend Jeff for writing a Chatham-rules summary of the outcome of some
hallway conversations that occurred. On the whole I think his summary does
represent the majority view of the opinions expressed by core developers at
the workshop. I will caution though that on nearly every issue there were
those expressed disagreement but did not fight the issue, and those who
said nothing and left unpolled opinions. Nevertheless this summary is
informative as it feeds forwards into the design of proposals that will be
made prior to the Hong Kong workshop in December, in order that they have a
higher likelihood of success.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/ddd28331/attachment.html>

2023-06-07 19:37:53 CEST

- reply

📅 Original date posted:2015-08-28
📝 Original message:Ah, then my mistake. It seemed so similar to an idea that was proposed
before on this mailing list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
that my mind just filled in the gaps. I concur -- having miners -- or any
group -- vote on block size is not an intrinsically good thing. The the
original proposal due to Greg Maxwell et al was not a mechanism for
"voting" but rather a feedback control that made the maximum block size
that which generated the most fees.
On Fri, Aug 28, 2015 at 5:00 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > It is in their individual interests when the larger block that is allowed
> > for them grants them more fees.
>
> I realize now that this is not what Greg Maxwell proposed (aka
> flexcap): this is just miner's voting on block size but paying with
> higher difficulty when they vote for bigger blocks.
> As I said several times in other places, miners should not decide on
> the consensus rule to limit mining centralization.
> People keep talking about miners voting on the block size or
> "softforking the size down if we went too far". But what if the
> hashing majority is perfectly fine with the mining centralization at
> that point in time?
> Then a softfork won't be useful and we're talking about an "anti-miner
> fork" (see
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158
> and
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175
> ).
>
> I believe miner's voting on the rule to limit mining centralization is
> a terrible idea.
> It sounds as bad as letting pharma companies write the regulations on
> new drugs safety, letting big food chains deciding on minimum food
> controls or car manufacturers deciding on indirect taxes for fuel.
> That's why I dislike both this proposal and BIP100.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150828/439cc876/attachment.html>

2023-06-07 19:37:51 CEST

- reply

📅 Original date posted:2015-08-28
📝 Original message:It is in their individual interests when the larger block that is allowed
for them grants them more fees.
On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size will never increase under this proposal do to a collective
> action problem. If a miner votes for an increase and nobody else does, the
> blocksize will not increase yet he will still have to pay the difficulty
> penalty.
>
> It may be in everyone's collective interest to raise the block size but
> not their individual interest.
> On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> With this proposal, how much would it cost a miner to include an 'extra'
>> 500-byte transaction if the average block size is 900K and it costs the
>> miner 20BTC in electricity/capital/etc to mine a block?
>>
>> If my understanding of the proposal is correct, it is:
>>
>> 500/900000 * 20 = 0.11111 BTC
>>
>> ... Or $2.50 at today's exchange rate.
>>
>> That seems excessive.
>>
>> --
>> Gavin Andresen
>>
>>
>> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > This is the best proposal I've seen yet. Allow me to summarize:
>> >
>> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
>> their block-size votes.
>> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
>> trying to predict future market needs versus future technological
>> capacities.
>> > • It avoids a large step discontinuity in the block-size limit by
>> starting with a 1-MB limit.
>> > • It throttles changes to ±10% every 2016 blocks.
>> > • It imposes a tangible cost (higher difficulty) on miners who vote to
>> raise the block-size limit.
>> > • It avoids incentivizing miners to vote to lower the block-size limit.
>> >
>> > However, this proposal currently fails to answer a very important
>> question:
>> >
>> > • What is the mechanism for activation of the new consensus rule? It is
>> when a certain percentage of the blocks mined in a 2016-block retargeting
>> period contain valid block-size votes?
>> >
>> >
>> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>> >
>> >
>> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
>> >> Pull request: https://github.com/bitcoin/bips/pull/187
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> 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/20150828/78c1fdf0/attachment-0001.html>

2023-06-07 19:36:57 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:We can use nVersion & 0x8 to signal support, while keeping the consensus
rule as nVersion >= 4, right? That way we don't waste a bit after this all
clears up.
On Aug 18, 2015 10:50 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
> complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
> mine blocks with nVersion=0x20000007, which would falsely trigger the
> previously suggested implementation using the IsSuperMajority()
> mechanism and nVersion=4 blocks. Additionally while the
> XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's
> nVersion soft-fork mechanism(3) a key component of it - fork
> deadlines(3) - is not implemented.
>
>
> XT/Not-Bitcoin-XT behavior
> --------------------------
>
> Both implementations produce blocks with nVersion=0x20000007,
> or in binary: 0b001...111
>
> Neither implementation supports a fork deadline; both Not-Bitcoin-XT and
> XT will produce blocks with those bits set indefinitely under any
> circumstance, with the proviso that while XT has a hashing power
> majority, blocks it produces might not be part of the Bitcoin blockchain
> after Jan 11th 2016. (though this can flap back and forth if reorgs
> happen)
>
> Curiously the BIP101 draft was changed(4) at the last minute from using
> the nVersion bits compliant 0x20000004 block nVersion, to using two more
> bits unnecessarily. The rational for doing this is unknown; the git
> commit message associated with the change suggested "compatibility
> concerns", but what the concerns actually were isn't specified. Equally
> even though implementing the fork deadline would be very each in the XT
> implementation, this was not done. (the XT codebase has had almost no
> peer review)
>
>
> Options for CLTV/CSV/etc. deployment
> ------------------------------------
>
> 1) Plain IsSuperMajority() with nVersion=4
>
> This option can be ruled out immediately due to the high risk of
> premature triggering, without genuine 95% miner support.
>
>
> 2) nVersion mask, with IsSuperMajority()
>
> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would
> be masked away, prior to applying standard IsSuperMajority() logic:
>
> block.nVersion & ~0x20000007
>
> This means that CLTV/CSV/etc. miners running Bitcoin Core would create
> blocks with nVersion=8, 0b1000. From the perspective of the
> CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be
> advertising blocks that do not trigger the soft-fork.
>
> For the perpose of soft-fork warnings, the highest known version can
> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks
> as well as a future nVersion bits implementation. Equally,
> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an
> unknown bit set.
>
> When nVersion bits is implemented by the Bitcoin protocol, the plan of
> setting the high bits to 0b001 still works. The three lowest bits will
> be unusable for some time, but will be eventually recoverable as
> XT/Not-Bitcoin-XT mining ceases.
>
> Equally, further IsSuperMajority() softforks can be accomplished with
> the same masking technique.
>
> This option does complicate the XT-coin protocol implementation in the
> future. But that's their problem, and anyway, the maintainers
> (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks
> and/or appear to be in favor of a more centralized mandatory update
> schedule.(6)
>
>
> 3) Full nVersion bits implementation
>
> The most complex option would be to deploy via full nVersion bits
> implementation using flag bit #4 to trigger the fork. Compliant miners
> would advertise 0x20000008 initially, followed by 0x20000000 once the
> fork had triggered. The lowest three bits would be unusable for forks
> for some time, although they could be eventually recovered as
> XT/Not-Bitcoin-XT mining ceases.
>
> The main disadvantage of this option is high initial complexity - the
> reason why IsSuperMajority() was suggested for CLTV/CSV in the first
> place. That said, much of the code required has been implemented in XT
> for the BIP101 hard-fork logic, although as mentioned above, the code
> has had very little peer review.
>
>
> References
> ----------
>
> 1) https://github.com/bitcoinxt/bitcoinxt
>
> 2) https://github.com/xtbit/notbitcoinxt
>
> 3) "Version bits proposal",
> Pieter Wuille, May 26th 2015, Bitcoin-development mailing list,
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html
> ,
> https://gist.github.com/sipa/bf69659f43e763540550
>
> 4)
> https://github.com/bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe
>
> 5) "On consensus and forks - What is the difference between a hard and
> soft fork?",
> Mike Hearn, Aug 12th 2015,
> https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>
> 6) 2013 San Jose Bitcoin conference developer round-table
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> _______________________________________________
> 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/20150818/a6e953ff/attachment-0001.html>

2023-06-07 19:35:21 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:Baseless accusations also have no place on this mailing list. They are
unprofessional, and poisonous to the consensus-building process we all seek
to engage in.
The Lightning Network effort at Blockstream is purposefully structured to
avoid any conflict of interest. ALL code related to lightning is available
on Github. There is absolutely nothing that we are holding back, and the
protocol itself is entirely p2p. There is no privileged entity, Blockstream
or otherwise.
On Sat, Aug 15, 2015 at 4:07 PM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Please take the lightning 101 discussion to another thread.
>
> The main point I was trying to make was that Mike is clearly
> misrepresenting the views of a great number of people who have deep,
> intimate knowledge of how things work and are almost certainly not
> primarily motivated by their own potential for profits.
>
> On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Being an early hub provider would be an obvious place to start
> capitalizing on lightning. Early lightning adopters would be in the best
> position to do this.
>
> Long term, Bitcoin needs to scale the blockchain in a reasonable manner
> and implement things like lightning.
>
> Limiting the blocksize is a blatant conflict of interest because it
> creates artificial demand for lightning that would not otherwise exist if
> the blockchain scaled in a reasonable manner.
>
> On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach 
> wrote:
>
>> I would like very much to know how it is that we're supposed to be making
>> money off of lightning, and therefore how it represents a conflict of
>> interest. Apparently there is tons of money to be made in releasing
>> open-source protocols! I would hate to miss out on that.
>>
>> We are working on lightning because Mike of all people said, essentially,
>> " if you're so fond of micro payment channels, why aren't you working on
>> them?" And he was right! So we looked around and found the best proposal
>> and funded it.
>> On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I know full well who works for Blockstream and I know you're not one of
>>> those folks. The Blockstream core devs are very vocal against a reasonable
>>> blocksize increase (17% growth per year in Pieter's BIP is not what I
>>> consider reasonable because it doesn't come close to keeping with
>>> technological increases). I think we can both agree that more on-chain
>>> space means less demand for lightning, and vice versa, which is a blatant
>>> conflict of interest.
>>>
>>> I'm also trying to figure out how things like lightning are not
>>> competing directly with miners for fees. More off-chain transactions means
>>> less blockchain demand, which would lower on-chain fees. I'm not sure what
>>> is controversial about that statement.
>>>
>>> The lightning network concept is actually a brilliant way to take fees
>>> away from miners without having to make any investment at all in SSH-256
>>> ASIC mining hardware.
>>>
>>> On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo <elombrozo at gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> What are you so afraid of, Eric? If Mike's fork is successful,
>>>> consensus is reached around larger blocks. If it is rejected, the status
>>>> quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS,
>>>> is the only thing that matters, and those that go against network consensus
>>>> will be severely punished with complete loss of income.
>>>>
>>>>
>>>> I fully agree that core developers are not the only people who should
>>>> have a say in this. But again, we’re not talking about merely forking some
>>>> open source project - we’re talking about forking a ledger representing
>>>> real assets that real people are holding…and I think it’s fair to say that
>>>> the risk of permanent ledger forks far outweighs whatever benefits any
>>>> change in the protocol might bring. And this would be true even if there
>>>> were unanimous agreement that the change is good (which there clearly IS
>>>> NOT in this case) but the deployment mechanism could still break things.
>>>>
>>>> If anything we should attempt a hard fork with a less contentious
>>>> change first, just to test deployability.
>>>>
>>>> I'm not sure who appointed the core devs some sort of Bitcoin Gods that
>>>> can hold up any change that they happen to disagree with. It seems like the
>>>> core devs are scared to death that the bitcoin network may change without
>>>> their blessing, so they go on and on about how terrible hard forks are.
>>>> Hard forks are the only way to keep core devs in check.
>>>>
>>>>
>>>> Again, let’s figure out a hard fork mechanism and test it with a far
>>>> less contentious change first
>>>>
>>>> Despite significant past technical bitcoin achievements, two of the
>>>> most vocal opponents to a reasonable blocksize increase work for a company
>>>> (Blockstream) that stands to profit directly from artificially limiting the
>>>> blocksize. The whole situation reeks. Because of such a blatant conflict of
>>>> interest, the ethical thing to do would be for them to either resign from
>>>> Blockstream or immediately withdraw themselves from the blocksize debate.
>>>> This is the type of stuff that I hoped would end with Bitcoin, but alas, I
>>>> guess human nature never changes.
>>>>
>>>>
>>>> For the record, I do not work for Blockstream. Neither do a bunch of
>>>> other people who have published a number of concerns. Very few of the
>>>> concerns I’ve seen from the technical community seem to be motivated
>>>> primarily by profit motives.
>>>>
>>>> It should also be pointed out that *not* making drastic changes is the
>>>> default consensus policy…and the burden of justifying a change falls on
>>>> those who want to make the change. Again, the risk of permanent ledger
>>>> forks far outweighs whatever benefits protocol changes might bring.
>>>>
>>>> Personally, I think miners should give Bitcoin XT a serious look.
>>>> Miners need to realize that they are in direct competition with the
>>>> lightning network and sidechains for fees. Miners, ask yourselves if you
>>>> think you'll earn more fees with 1 MB blocks and more off-chain
>>>> transactions or with 8 MB blocks and more on-chain transactions…
>>>>
>>>>
>>>> Miners are NOT in direct competition with the lightning network and
>>>> sidechains - these claims are patently false. I recommend you take a look
>>>> at these ideas and understand them a little better before trying to make
>>>> any such claims. Again, I do not work for Blockstream…and my agenda in this
>>>> post is not to promote either of these ideas…but with all due respect, I do
>>>> not think you properly understand them at all.
>>>>
>>>> The longer this debate drags on, the more I agree with BIP 100 and Jeff
>>>> Garzik because the core devs are already being influenced by outside forces
>>>> and should not have complete control of the blocksize. It's also
>>>> interesting to note that most of the mining hashpower is already voting for
>>>> 8MB blocks BIP100 style.
>>>>
>>>>
>>>> I don’t think the concern here is so much that some people want to
>>>> increase block size. It’s the *way* in which this change is being pushed
>>>> that is deeply problematic.
>>>>
>>>> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> You deeply disappoint me, Mike.
>>>>>
>>>>> Not only do you misrepresent many cogent, well thought out positions
>>>>> from a great number of people who have published and posted a number of
>>>>> articles detailing an explaining in-depth technical concerns…you also seem
>>>>> to fancy yourself more capable of reading into the intentions of someone
>>>>> who disappeared from the scene years ago, before we even were fully aware
>>>>> of many things we now know that bring the original “plan” into question.
>>>>>
>>>>> I ask of you, as a civilized human being, to stop doing this divisive
>>>>> crap. Despite your protestations to the contrary, YOU are the one who is
>>>>> proposing a radical departure from the direction of the project. Also, as
>>>>> several of us have clearly stated before, equating the fork of an open
>>>>> source project with a fork of a cryptoledger is completely bogus - there’s
>>>>> a lot of other people’s money at stake. This isn’t a democracy - consensus
>>>>> is all or nothing. The fact that a good number of the people most
>>>>> intimately familiar with the inner workings of Satoshi’s invention do not
>>>>> believe doing this is a good idea should give you pause.
>>>>>
>>>>> Please stop using Bitcoin as your own political football…for the sake
>>>>> of Bitcoin…and for your own sake. Despite your obvious technical abilities
>>>>> (and I sincerely do believe you have them) you are discrediting yourself
>>>>> and hurting your own reputation.
>>>>>
>>>>>
>>>>> - Eric
>>>>>
>>>>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
>>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> As promised, we have released Bitcoin XT 0.11A which includes the
>>>>> bigger blocks patch set. You can get it from
>>>>>
>>>>> https://bitcoinxt.software/
>>>>>
>>>>> I feel sad that it's come to this, but there is no other way. The
>>>>> Bitcoin Core project has drifted so far from the principles myself and many
>>>>> others feel are important, that a fork is the only way to fix things.
>>>>>
>>>>> Forking is a natural thing in the open source community, Bitcoin is
>>>>> not the first and won't be the last project to go through this. Often in
>>>>> forks, people say there was insufficient communication. So to ensure
>>>>> everything is crystal clear I've written a blog post and a kind of
>>>>> "manifesto" to describe why this is happening and how XT plans to be
>>>>> different from Core (assuming adoption, of course).
>>>>>
>>>>> The article is here:
>>>>>
>>>>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
>>>>>
>>>>> It makes no attempt to be neutral: this explains things from our point
>>>>> of view.
>>>>>
>>>>> The manifesto is on the website.
>>>>>
>>>>> I say to all developers on this list: if you also feel that Core is no
>>>>> longer serving the interests of Bitcoin users, come join us. We don't bite.
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
> _______________________________________________
> 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/20150815/84aa5436/attachment-0001.html>

2023-06-07 19:35:17 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:I would like very much to know how it is that we're supposed to be making
money off of lightning, and therefore how it represents a conflict of
interest. Apparently there is tons of money to be made in releasing
open-source protocols! I would hate to miss out on that.
We are working on lightning because Mike of all people said, essentially, "
if you're so fond of micro payment channels, why aren't you working on
them?" And he was right! So we looked around and found the best proposal
and funded it.
On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I know full well who works for Blockstream and I know you're not one of
> those folks. The Blockstream core devs are very vocal against a reasonable
> blocksize increase (17% growth per year in Pieter's BIP is not what I
> consider reasonable because it doesn't come close to keeping with
> technological increases). I think we can both agree that more on-chain
> space means less demand for lightning, and vice versa, which is a blatant
> conflict of interest.
>
> I'm also trying to figure out how things like lightning are not competing
> directly with miners for fees. More off-chain transactions means less
> blockchain demand, which would lower on-chain fees. I'm not sure what is
> controversial about that statement.
>
> The lightning network concept is actually a brilliant way to take fees
> away from miners without having to make any investment at all in SSH-256
> ASIC mining hardware.
>
> On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>>
>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> What are you so afraid of, Eric? If Mike's fork is successful, consensus
>> is reached around larger blocks. If it is rejected, the status quo will
>> remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, is the
>> only thing that matters, and those that go against network consensus will
>> be severely punished with complete loss of income.
>>
>>
>> I fully agree that core developers are not the only people who should
>> have a say in this. But again, we’re not talking about merely forking some
>> open source project - we’re talking about forking a ledger representing
>> real assets that real people are holding…and I think it’s fair to say that
>> the risk of permanent ledger forks far outweighs whatever benefits any
>> change in the protocol might bring. And this would be true even if there
>> were unanimous agreement that the change is good (which there clearly IS
>> NOT in this case) but the deployment mechanism could still break things.
>>
>> If anything we should attempt a hard fork with a less contentious change
>> first, just to test deployability.
>>
>> I'm not sure who appointed the core devs some sort of Bitcoin Gods that
>> can hold up any change that they happen to disagree with. It seems like the
>> core devs are scared to death that the bitcoin network may change without
>> their blessing, so they go on and on about how terrible hard forks are.
>> Hard forks are the only way to keep core devs in check.
>>
>>
>> Again, let’s figure out a hard fork mechanism and test it with a far less
>> contentious change first
>>
>> Despite significant past technical bitcoin achievements, two of the most
>> vocal opponents to a reasonable blocksize increase work for a company
>> (Blockstream) that stands to profit directly from artificially limiting the
>> blocksize. The whole situation reeks. Because of such a blatant conflict of
>> interest, the ethical thing to do would be for them to either resign from
>> Blockstream or immediately withdraw themselves from the blocksize debate.
>> This is the type of stuff that I hoped would end with Bitcoin, but alas, I
>> guess human nature never changes.
>>
>>
>> For the record, I do not work for Blockstream. Neither do a bunch of
>> other people who have published a number of concerns. Very few of the
>> concerns I’ve seen from the technical community seem to be motivated
>> primarily by profit motives.
>>
>> It should also be pointed out that *not* making drastic changes is the
>> default consensus policy…and the burden of justifying a change falls on
>> those who want to make the change. Again, the risk of permanent ledger
>> forks far outweighs whatever benefits protocol changes might bring.
>>
>> Personally, I think miners should give Bitcoin XT a serious look. Miners
>> need to realize that they are in direct competition with the lightning
>> network and sidechains for fees. Miners, ask yourselves if you think you'll
>> earn more fees with 1 MB blocks and more off-chain transactions or with 8
>> MB blocks and more on-chain transactions…
>>
>>
>> Miners are NOT in direct competition with the lightning network and
>> sidechains - these claims are patently false. I recommend you take a look
>> at these ideas and understand them a little better before trying to make
>> any such claims. Again, I do not work for Blockstream…and my agenda in this
>> post is not to promote either of these ideas…but with all due respect, I do
>> not think you properly understand them at all.
>>
>> The longer this debate drags on, the more I agree with BIP 100 and Jeff
>> Garzik because the core devs are already being influenced by outside forces
>> and should not have complete control of the blocksize. It's also
>> interesting to note that most of the mining hashpower is already voting for
>> 8MB blocks BIP100 style.
>>
>>
>> I don’t think the concern here is so much that some people want to
>> increase block size. It’s the *way* in which this change is being pushed
>> that is deeply problematic.
>>
>> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> You deeply disappoint me, Mike.
>>>
>>> Not only do you misrepresent many cogent, well thought out positions
>>> from a great number of people who have published and posted a number of
>>> articles detailing an explaining in-depth technical concerns…you also seem
>>> to fancy yourself more capable of reading into the intentions of someone
>>> who disappeared from the scene years ago, before we even were fully aware
>>> of many things we now know that bring the original “plan” into question.
>>>
>>> I ask of you, as a civilized human being, to stop doing this divisive
>>> crap. Despite your protestations to the contrary, YOU are the one who is
>>> proposing a radical departure from the direction of the project. Also, as
>>> several of us have clearly stated before, equating the fork of an open
>>> source project with a fork of a cryptoledger is completely bogus - there’s
>>> a lot of other people’s money at stake. This isn’t a democracy - consensus
>>> is all or nothing. The fact that a good number of the people most
>>> intimately familiar with the inner workings of Satoshi’s invention do not
>>> believe doing this is a good idea should give you pause.
>>>
>>> Please stop using Bitcoin as your own political football…for the sake of
>>> Bitcoin…and for your own sake. Despite your obvious technical abilities
>>> (and I sincerely do believe you have them) you are discrediting yourself
>>> and hurting your own reputation.
>>>
>>>
>>> - Eric
>>>
>>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Hello,
>>>
>>> As promised, we have released Bitcoin XT 0.11A which includes the bigger
>>> blocks patch set. You can get it from
>>>
>>> https://bitcoinxt.software/
>>>
>>> I feel sad that it's come to this, but there is no other way. The
>>> Bitcoin Core project has drifted so far from the principles myself and many
>>> others feel are important, that a fork is the only way to fix things.
>>>
>>> Forking is a natural thing in the open source community, Bitcoin is not
>>> the first and won't be the last project to go through this. Often in forks,
>>> people say there was insufficient communication. So to ensure everything is
>>> crystal clear I've written a blog post and a kind of "manifesto" to
>>> describe why this is happening and how XT plans to be different from Core
>>> (assuming adoption, of course).
>>>
>>> The article is here:
>>>
>>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
>>>
>>> It makes no attempt to be neutral: this explains things from our point
>>> of view.
>>>
>>> The manifesto is on the website.
>>>
>>> I say to all developers on this list: if you also feel that Core is no
>>> longer serving the interests of Bitcoin users, come join us. We don't bite.
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>> _______________________________________________
>> 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/20150815/fe6932ed/attachment-0001.html>

2023-06-07 19:34:59 CEST

- reply

📅 Original date posted:2015-08-25
📝 Original message:To follow up on this, let's say that you want to be able to have up to 1
year relative lock-times. This choice is somewhat arbitrary and what I
would like some input on, but I'll come back to this point.
* 1 bit is necessary to enable/disable relative lock-time.
* 1 bit is necessary to indicate whether seconds vs blocks as the unit of
measurement.
* 1 year of time with 1-second granularity requires 25 bits. However since
blocks occur at approximately 10 minute intervals on average, having a
relative lock-time significantly less than this interval doesn't make much
sense. A granularity of 256 seconds would be greater than the Nyquist
frequency and requires only 17 bits.
* 1 year of blocks with 1-block granularity requires 16 bits.
So time-based relative lock time requires about 19 bits, and block-based
relative lock-time requires about 18 bits. That leaves 13 or 14 bits for
other uses.
Assuming a maximum of 1-year relative lock-times. But what is an
appropriate maximum to choose? The use cases I have considered have only
had lock times on the order of a few days to a month or so. However I would
feel uncomfortable going less than a year for a hard maximum, and am having
trouble thinking of any use case that would require more than a year of
lock-time. Can anyone else think of a use case that requires >1yr relative
lock-time?
TL;DR
On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach 
wrote:
> A power of 2 would be far more efficient here. The key question is how
> long of a relative block time do you need? Figure out what the maximum
> should be ( I don't know what that would be, any ideas?) and then see how
> many bits you have left over.
> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>> > discussion has any thought been given to represent one block with more
>> > than one increment? This would leave additional space for future
>> > signaling, or allow, for example, higher resolution numbers for a
>> > sharechain commitement.
>>
>> No, I don't think anybody thought about this. I just explained this to
>> Pieter using "for example, 10 instead of 1".
>> He suggested 600 increments so that it is more similar to timestamps.
>> _______________________________________________
>> 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/20150825/9e9f488e/attachment.html>

2023-06-07 19:34:59 CEST

- reply

📅 Original date posted:2015-08-23
📝 Original message:A power of 2 would be far more efficient here. The key question is how long
of a relative block time do you need? Figure out what the maximum should be
( I don't know what that would be, any ideas?) and then see how many bits
you have left over.
On Aug 23, 2015 7:23 PM, "Jorge Timón" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
> > discussion has any thought been given to represent one block with more
> > than one increment? This would leave additional space for future
> > signaling, or allow, for example, higher resolution numbers for a
> > sharechain commitement.
>
> No, I don't think anybody thought about this. I just explained this to
> Pieter using "for example, 10 instead of 1".
> He suggested 600 increments so that it is more similar to timestamps.
> _______________________________________________
> 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/20150823/1db30142/attachment-0001.html>

2023-06-07 19:34:57 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:I am indifferent on this issue (the bit inversion), but so far only Jorge
has spoken up. I opted for this detail during implementation in order to
preserve existing semantics, even if those semantics are not commonly used.
This was the conservative choice, driven in part because I didn't want the
proposal to be held up by the other side saying "this is confusing because
it changes how sequence numbers work! it used to count up but now it counts
down!"
I can see both sides and as I said I'm indifferent, so I went with the
conservative choice of not messing with existing semantics. However if
there is strong preferences from _multiple_ people on this matter it is not
too late to change. If anyone feels strongly about this, please speak up.
On Wed, Aug 19, 2015 at 3:37 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I repeated my nit on https://github.com/bitcoin/bips/pull/179
>
>
> On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Please note there is now a PR for this BIP[1] and also a pull request for
> > the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
> >
> > [1] https://github.com/bitcoin/bips/pull/179
> > [2] https://github.com/bitcoin/bitcoin/pull/6564
> >
> >
> > _______________________________________________
> > 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/20150819/fb556776/attachment-0001.html>

2023-06-07 19:34:56 CEST

- reply

📅 Original date posted:2015-08-14
📝 Original message:With the assumed malleability-fix CHECKSIG2 version of lightning, watching
for and responding to bad behavior is fully outsourceable. You can
synchronize channel state (signed refund transactions) with a third party
that watches for replay of old transactions on the mainnet, and starts the
refund process if it observes them, paying the fees necessary to get on the
chain.
With the CLTV/CSV-only form of the hash time-lock contracts that Rusty has
developed, this is indeed something the users' wallets would have to be
online to observe happening and respond to. I presume that we are
eventually going to get a CHECKSIG2 with some kind of malleability-immune
signing scheme in the long term, and that we are not interested in
introducing new consensus behavior to cover that short stopgap.
> I'm not even sure if sufficient coordination is a sufficient solution.
A regrettable choice of words. In this case it is game theoretic
cooperation, not coordination. The users need only expect that each other
would react the same way, being willing to burn money as fees that would
otherwise be stolen. They don't actually have to communicate with each
other in order to cooperate.
You are correct though that hubs-with-hashpower complicate this situation.
Although a hub with hashpower also creates risk in the timestop scenario
too...
On Fri, Aug 14, 2015 at 11:53 AM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
>
>
> On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote:
> > On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > I haven't tested the details of this, but is there another bit
> available
> > for use in the future for the relative blockheight?
> >
> > I strongly believe that Lightning needs mitigations for a systemic
> > supervillan attack which attemps to flood the network with
> transactions,
> > which can hypothetically be mitigated with something like a timestop
> > bit (as originally suggested by gmaxwell).
> >
> >
> > This proposal includes no such provision.
> >
> > Since we talked about it, I spent considerable time thinking about the
> > supposed risk and proposed mitigations. I'm frankly not convinced that
> > it is a risk of high enough credibility to worry about, or if it is that
> > a protocol-level complication is worth doing.
> >
> > The scenario as I understand it is a hub turns evil and tries to cheat
> > every single one of its users out of their bonds. Normally a lightning
> > user is protected form such behavior because they have time to broadcast
> > their own transactions spending part or all of the balance as fees.
>
> My concern is how the hell do you automate this? Having a threat of
> "well, everyone could update their software to a new version which will
> destroy all coins right now" is kinda useless, and trying to come up
> with a reasonable set of metrics as to how much and when you move from
> just paying the fee to destroying coins is really hard, especially if
> you assume the attacker is a miner with, say, enough hashrate (maybe
> rented) to get one or three blocks in the next day (the timeout period).
>
> > Therefore because of the threat of mutually assured destruction, the
> > optimal outcome is to be an honest participant.
> >
> > But, the argument goes, the hub has many channels with many different
> > people closing at the same time. So if the hub tries to cheat all of
> > them at once by DoS'ing the network, it can do so and spend more in fees
> > than any one participant stands to lose. My issue with this is that
> > users don't act alone -- users can be assured that other users will
> > react, and all of them together have enough coins to burn to make the
> > attack unprofitable.
>
> Now users are coordinating quickly in an attack scenario?
>
> > The hub-cheats-many-users case really is the same
> > as the hub-cheats-one-user case if the users act out their role in
> > unison, which they don't have to coordinate to do.
> >
> > Other than that, even if you are still concerned about that scenario,
> > I'm not sure timestop is the appropriate solution. A timestop is a
> > protocol-level complication that is not trivial to implement, indeed I'm
> > not even sure there is a way to implement it at all -- how do you
> > differentiate in consensus code a DoS attack from regular old blocks
> > filling up? And if you could, why add further complication to the
> > consensus protocol?
>
> Yea, implementation is really tricky here. I do not at all think we
> should be thinking about implementing this any time soon, and should
> assume Lightning will have to stand reasonably on its own without it
> first, and only if it gains a lot of traction will there be enough
> motivation for making such a change at the Bitcoin protocol level for
> Lightning.
>
> > A simpler solution to me seems to be outsourcing the response to an
> > attack to a third party
>
> Doesnt that defeat the purpose of Lightning?
>
> > or otherwise engineering ways for users to
> > respond-by-default even if their wallet is offline, or otherwise
> > assuring sufficient coordination in the event of a bad hub.
>
> I'm not even sure if sufficient coordination is a sufficient solution.
> If you assume a hub just shut down, and everyone is trying to flush to
> the chain, with a backlog of a few days worth of transactions (with
> timeouts of a day or so), and users are even paying huge fees (99% of
> what they'd get back), if the former-hub is a miner, it can claim that
> last 1% of many of the transactions that take longer than a day to confirm.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/55d9334f/attachment-0001.html>

2023-06-07 19:34:55 CEST

- reply

📅 Original date posted:2015-08-13
📝 Original message:On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I haven't tested the details of this, but is there another bit available
> for use in the future for the relative blockheight?
>
> I strongly believe that Lightning needs mitigations for a systemic
> supervillan attack which attemps to flood the network with transactions,
> which can hypothetically be mitigated with something like a timestop
> bit (as originally suggested by gmaxwell).
>
This proposal includes no such provision.
Since we talked about it, I spent considerable time thinking about the
supposed risk and proposed mitigations. I'm frankly not convinced that it
is a risk of high enough credibility to worry about, or if it is that a
protocol-level complication is worth doing.
The scenario as I understand it is a hub turns evil and tries to cheat
every single one of its users out of their bonds. Normally a lightning user
is protected form such behavior because they have time to broadcast their
own transactions spending part or all of the balance as fees. Therefore
because of the threat of mutually assured destruction, the optimal outcome
is to be an honest participant.
But, the argument goes, the hub has many channels with many different
people closing at the same time. So if the hub tries to cheat all of them
at once by DoS'ing the network, it can do so and spend more in fees than
any one participant stands to lose. My issue with this is that users don't
act alone -- users can be assured that other users will react, and all of
them together have enough coins to burn to make the attack unprofitable.
The hub-cheats-many-users case really is the same as the
hub-cheats-one-user case if the users act out their role in unison, which
they don't have to coordinate to do.
Other than that, even if you are still concerned about that scenario, I'm
not sure timestop is the appropriate solution. A timestop is a
protocol-level complication that is not trivial to implement, indeed I'm
not even sure there is a way to implement it at all -- how do you
differentiate in consensus code a DoS attack from regular old blocks
filling up? And if you could, why add further complication to the consensus
protocol?
A simpler solution to me seems to be outsourcing the response to an attack
to a third party, or otherwise engineering ways for users to
respond-by-default even if their wallet is offline, or otherwise assuring
sufficient coordination in the event of a bad hub.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150813/a161abd7/attachment.html>

2023-06-07 19:34:53 CEST

- reply

📅 Original date posted:2015-08-13
📝 Original message:As per the rules of BIP 1, I hereby request that the BIP editor please
assign an official number to this work. The idea has been discussed before
on the bitcoin-dev mailing list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html
And a reference implementation is available here:
https://github.com/maaku/bitcoin/tree/checksequenceverify
On Thu, Aug 13, 2015 at 4:06 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have written the following draft BIP for a new opcode
> CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
> relative-locktime to Bitcoin's scripting language.
>
>
> https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
>
> <pre>
> BIP: XX
> Title: CHECKSEQUENCEVERIFY
> Authors: BtcDrak <btcdrak at gmail.com>
> Mark Friedenbach 
> Status: Draft
> Type: Standards Track
> Created: 2015-08-10
> </pre>
>
> ==Abstract==
>
> This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
> scripting system that in combination with BIP 68 allows execution
> pathways of a script to be restricted based on the age of the output
> being spent.
>
>
> ==Summary==
>
> CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
> it compares the top item on the stack to the inverse of the nSequence
> field of the transaction input containing the scriptSig. If the
> inverse of nSequence is less than the sequence threshold (1 << 31),
> the transaction version is greater than or equal to 2, and the top
> item on the stack is less than or equal to the inverted nSequence,
> script evaluation continues as though a NOP was executed. Otherwise
> the script fails immediately.
>
> BIP 68's redefinition of nSequence prevents a non-final transaction
> from being selected for inclusion in a block until the corresponding
> input has reached the specified age, as measured in block heiht or
> block time. By comparing the argument to CHECKSEQUENCEVERIFY against
> the nSequence field, we indirectly verify a desired minimum age of the
> the output being spent; until that relative age has been reached any
> script execution pathway including the CHECKSEQUENCEVERIFY will fail
> to validate, causing the transaction not to be selected for inclusion
> in a block.
>
>
> ==Motivation==
>
> BIP 68 repurposes the transaction nSequence field meaning by giving
> sequence numbers new consensus-enforced semantics as a relative
> lock-time. However, there is no way to build Bitcoin scripts to make
> decisions based on this field.
>
> By making the nSequence field accessible to script, it becomes
> possible to construct code pathways that only become accessible some
> minimum time after proof-of-publication. This enables a wide variety
> of applications in phased protocols such as escrow, payment channels,
> or bidirectional pegs.
>
>
> ==Specification==
>
> Refer to the reference implementation, reproduced below, for the precise
> semantics and detailed rationale for those semantics.
>
>
> case OP_NOP3:
> {
> if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
> // not enabled; treat as a NOP3
> if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
> return set_error(serror,
> SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
> }
> break;
> }
>
> if (stack.size() < 1)
> return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>
> // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
> // accept 5-byte bignums since any value greater than or
> // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
> // anyway. This limitation just happens to coincide with
> // CScriptNum's default 4-byte limit with an explicit sign
> // bit.
> //
> // This means there is a maximum relative lock time of 52
> // years, even though the nSequence field in transactions
> // themselves is uint32_t and could allow a relative lock
> // time of up to 120 years.
> const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);
>
> // In the rare event that the argument may be < 0 due to
> // some arithmetic being done first, you can always use
> // 0 MAX CHECKSEQUENCEVERIFY.
> if (nInvSequence < 0)
> return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
>
> // Actually compare the specified inverse sequence number
> // with the input.
> if (!CheckSequence(nInvSequence))
> return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
>
> break;
> }
>
> bool CheckSequence(const CScriptNum& nInvSequence) const
> {
> int64_t txToInvSequence;
>
> // Fail under all circumstances if the transaction's version
> // number is not set high enough to enable enforced sequence
> // number rules.
> if (txTo->nVersion < 2)
> return false;
>
> // Sequence number must be inverted to convert it into a
> // relative lock-time.
> txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
>
> // Sequence numbers under SEQUENCE_THRESHOLD are not consensus
> // constrained.
> if (txToInvSequence >= SEQUENCE_THRESHOLD)
> return false;
>
> // There are two types of relative lock-time: lock-by-
> // blockheight and lock-by-blocktime, distinguished by
> // whether txToInvSequence < LOCKTIME_THRESHOLD.
> //
> // We want to compare apples to apples, so fail the script
> // unless the type of lock-time being tested is the same as
> // the lock-time in the transaction input.
> if (!(
> (txToInvSequence < LOCKTIME_THRESHOLD && nInvSequence <
> LOCKTIME_THRESHOLD) ||
> (txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >=
> LOCKTIME_THRESHOLD)
> ))
> return false;
>
> // Now that we know we're comparing apples-to-apples, the
> // comparison is a simple numeric one.
> if (nInvSequence > txInvToSequence)
> return false;
>
> return true;
> }
>
>
> https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2
>
>
> ==Example: Escrow with Timeout==
>
> An escrow that times out automatically 30 days after being funded can be
> established in the following way. Alice, Bob and Escrow create a 2-of-3
> address with the following redeemscript.
>
> IF
> 2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3
> CHECKMULTISIGVERIFY
> ELSE
> <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
> <Alice's pubkey> CHECKSIGVERIFY
> ENDIF
>
> At any time funds can be spent using signatures from any two of Alice,
> Bob or the Escrow.
>
> After 30 days Alice can sign alone.
>
> The clock does not start ticking until the payment to the escrow address
> confirms.
>
>
> ==Reference Implementation==
>
> A reference implementation is provided in the following git repository:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify
>
>
> ==Deployment==
>
> We reuse the double-threshold switchover mechanism from BIPs 34 and
> 66, with the same thresholds, but for nVersion = 4. The new rules are
> in effect for every block (at height H) with nVersion = 4 and at least
> 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
> have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
> preceding a block do have nVersion = 4, nVersion = 3 blocks become
> invalid, and all further blocks enforce the new rules.
>
> It is recommended that this soft-fork deployment trigger include other
> related proposals for improving Bitcoin's lock-time capabilities,
> including:
>
> [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]:
> OP_CHECKLOCKTIMEVERIFY,
>
> [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]:
> Consensus-enforced transaction replacement signalled via sequence numbers,
>
> and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP
> XX]:
> Median-Past-Time-Lock.
>
>
> ==Credits==
>
> Mark Friedenbach invented the application of sequence numbers to
> achieve relative lock-time, and wrote the reference implementation of
> CHECKSEQUENCEVERIFY.
>
> The reference implementation and this BIP was based heavily on work
> done by Peter Todd for the closely related BIP 65.
>
> BtcDrak authored this BIP document.
>
>
> ==References==
>
> BIP 68: Consensus-enforced transaction replacement signalled via
> sequence numbers
> https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
>
> BIP 65: OP_CHECKLOCKTIMEVERIFY
> https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
>
> BIP XX: Median past block time for time-lock constraints
> https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki
>
> HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
> revocation hashes
>
> http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
>
>
> ==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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150813/0d50ce22/attachment-0001.html>

2023-06-07 19:34:03 CEST

- reply

📅 Original date posted:2015-08-11
📝 Original message:More people using Bitcoin does not necessarily mean more transactions being
processed by the block chain. Satoshi was forward-thinking enough to
include a powerful script-signature system, something which has never
really existed before. Though suffering from some limitations to be sure,
this smart contract execution framework is expressive enough to enable a
wide variety of new features without changing bitcoin itself.
One of these invented features is micropayment channels -- the ability for
two parties to rapidly exchange funds while only settling the final balance
to the block chain, and to do so in an entirely trustless way. Right now
people don't use scripts to do interesting things like this, but there is
absolutely no reason why they can't. Lightning network is a vision of a
future where everyone uses a higher-layer protocol for their transactions
which only periodically settle on the block chain. It is entirely possible
that you may be able to do all your day-to-day transactions in bitcoin yet
only settle accounts every other week, totaling 13kB per year. A 1MB block
could support that level of usage by 4 million people, which is many orders
of magnitude more than the number of people presently using bitcoin on a
day to day basis.
And that, by the way, is without considering as-yet uninvented applications
of existing or future script which will provide even further improvements
to scale. This is very fertile ground being explored by very few people.
One thing I hope to come out of this block size debate is a lot more people
(like Joseph Poon) looking at how bitcoin script can be used to enable new
and innovative resource-efficient and privacy-enhancing payment protocols.
The network has room to grow. It just requires wallet developers and other
infrastructure folk to step up to the plate and do their part in deploying
this technology.
On Tue, Aug 11, 2015 at 2:14 AM, Angel Leon <gubatron at gmail.com> wrote:
> - policy neutrality.
> - It can't be censored.
> - it can't be shut down
> - and the rules cannot change from underneath you.
>
> except it can be shutdown the minute it actually gets used by its
> inability to scale.
>
> what's the point of having all this if nobody can use it?
> what's the point of going through all that energy and CO2 for a mere
> 24,000 transactions an hour?
>
> It's clear that it's just a matter of time before it collapses.
>
> Here's a simple proposal (concept) that doesn't pretend to set a fixed
> block size limit as you can't ever know the demands the future will bring
> https://gist.github.com/gubatron/143e431ee01158f27db4
>
> We don't need to go as far as countries with hyper inflation trying to use
> the technology to make it collapse, anybody here who has distributed
> commercial/free end user software knows that any small company out there
> installs more copies in a couple weeks than all the bitcoin users we have
> at the moment, all we need is a single company/project with a decent amount
> of users who are now enabled to transact directly on the blockchain to
> screw it all up (perhaps OpenBazaar this winter could make this whole thing
> come down, hopefully they'll take this debate and the current limitations
> before their release, and boy are they coding nonstop on it now that they
> got funded), the last of your fears should be a malicious government trying
> to shut you down, for that to happen you must make an impact first, for now
> this is a silly game in the grand scheme of things.
>
> And you did sound pretty bad, all of his points were very valid and they
> share the concern of many people, many investors, entrepreneurs putting
> shitload of money, time and their lives on a much larger vision than that
> of a network that does a mere 3,500 tx/hour, but some people seem to be
> able to live in impossible or useless ideals.
>
> It's simply irresponsible to not want to give the network a chance to grow
> a bit more. Miners centralizing is inevitable given the POW based
> consensus, hobbists-mining is only there for countries with very cheap
> energy.
>
> If things remain this way, this whole thing will be a massive failure and
> it will probably take another decade before we can open our mouths about
> cryptocurrencies, decentralization and what not, and this stubornness will
> be the one policy that censored everyone, that shutdown everyone, that made
> the immutable rules not matter.
>
> Perhaps it will be Stellar what ends up delivering at this stubborn pace.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> >It follows then, that if we make a decision now which destroys that
>> property, which makes it possible to censor bitcoin, to deny service, or to
>> pressure miners into changing rules contrary to user interests, then
>> Bitcoin is no longer interesting.
>>
>> You asked to be convinced of the need for bigger blocks. I gave that.
>> What makes you think bitcoin will break when more people use it?
>>
>> Sent on the go, excuse the brevity.
>> *From: *Mark Friedenbach
>> *Sent: *Tuesday, 11 August 2015 08:10
>> *To: *Thomas Zander
>> *Cc: *Bitcoin Dev
>> *Subject: *Re: [bitcoin-dev] Fees and the block-finding process
>>
>> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
>>> > This is where things diverge. It's fine to pick a new limit or growth
>>> > trajectory. But defend it with data and reasoned analysis.
>>>
>>> We currently serve about 0,007% of the world population sending maybe one
>>> transaction a month.
>>> This can only go up.
>>>
>>> There are about 20 currencies in the world that are unstable and showing
>>> early
>>> signs of hyperinflation. If even small percentage of these people
>>> cash-out and
>>> get Bitcoins for their savings you'd have the amount of people using
>>> Bitcoin
>>> as savings go from maybe half a million to 10 million in the space of a
>>> couple
>>> of months. Why so fast? Because all the world currencies are linked.
>>> Practically all currencies follow the USD, and while that one may stay
>>> robust
>>> and standing, the linkage has been shown in the past to cause
>>> chain-effects.
>>>
>>> It is impossible to predict how much uptake Bitcoin will take, but we
>>> have
>>> seen big rises in price as Cyprus had a bailin and then when Greece first
>>> showed bad signs again.
>>> Lets do our due diligence and agree that in the current world economy
>>> there
>>> are sure signs that people are considering Bitcoin on a big scale.
>>>
>>> Bigger amount of people holding Bitcoin savings won't make the
>>> transaction
>>> rate go up very much, but if you have feet on the ground you already see
>>> that
>>> people go back to barter in countries like Poland, Ireland, Greece etc.
>>> And Bitcoin will be an alternative to good to ignore. Then transaction
>>> rates
>>> will go up. Dramatically.
>>>
>>> If you are asking for numbers, that is a bit tricky. Again; we are at
>>> 0,007%... Thats like a f-ing rounding error in the world economy. You
>>> can't
>>> reason from that. Its like using a float to do calculations that you
>>> should
>>> have done in a double and getting weird output.
>>>
>>> Bottom line is that a maximum size of 8Mb blocks is not that odd.
>>> Because a 20
>>> times increase is very common in a "company" that is about 6 years old.
>>> For instance Android was about that age when it started to get shipped
>>> by non-
>>> Google companies. There the increase was substantially bigger and the
>>> company
>>> backing it was definitely able to change direction faster than the
>>> Bitcoin
>>> oiltanker can change direction.
>>>
>>> ...
>>>
>>> Another metric to remember; if you follow hackernews (well, the
>>> incubator more
>>> than the linked articles) you'd be exposed to the thinking of these
>>> startups.
>>> Their only criteria is growth. and this is rather substantial growth.
>>> Like
>>> 150% per month. Naturally, most of these build on top of html or other
>>> existing technologies. But the point is that exponential growth is
>>> expected
>>> in any startup. They typically have a much much more agressive timeline,
>>> though. Every month instead of every year.
>>> Having exponential growth in the blockchain is really not odd and even
>>> if we
>>> have LN or sidechains or the next changetip, this space will be used.
>>> And we
>>> will still have scarcity.
>>
>>
>> I'm sorry, I really don't want to sound like a jerk, but not a single
>> word of that mattered. Yes we all want Bitcoin to scale such that every
>> person in the world can use it without difficulty. However if that were all
>> that we cared about then I would be remiss if I did not point out that
>> there are plenty of better, faster, and cheaper solutions to finding global
>> consensus over a payment ledger than Bitcoin. Architectures which are
>> algorithmically superior in their scaling properties. Indeed they are
>> already implemented and you can use them today:
>>
>> https://www.stellar.org/
>> http://opentransactions.org/
>>
>> So why do I work on Bitcoin, and why do I care about the outcome of this
>> debate? Because Bitcoin offers one thing, and one thing only which
>> alternative architectures fundamentally lack: policy neutrality. It can't
>> be censored, it can't be shut down, and the rules cannot change from
>> underneath you. *That* is what Bitcoin offers that can't be replicated at
>> higher scale with a SQL database and an audit log.
>>
>> It follows then, that if we make a decision now which destroys that
>> property, which makes it possible to censor bitcoin, to deny service, or to
>> pressure miners into changing rules contrary to user interests, then
>> Bitcoin is no longer interesting. We might as well get rid of mining at
>> that point and make Bitcoin look like Stellar or Open-Transactions because
>> at least then we'd scale even better and not be pumping millions of tons of
>> CO2 into the atmosphere from running all those ASICs.
>>
>> On the other side, 3Tb harddrives are sold, which take 8Mb blocks without
>>> problems.
>>>
>>
>> Straw man, storage is not an issue.
>>
>>
>>> You can buy broadband in every relevant country that easily supports the
>>> bandwidth we need. (remember we won't jump to 8Mb in a day, it will
>>> likely
>>> take at least 6 months).
>>>
>>
>> Neither one of those assertions is clear. Keep in mind the goal is to
>> have Bitcoin survive active censorship. Presumably that means being able to
>> run a node even in the face of a hostile ISP or government. Furthermore, it
>> means being location independent and being able to move around. In many
>> places the higher the bandwidth requirements the fewer the number of ISPs
>> that are available to service you, and the more visible you are.
>>
>> It may also be necessary to be able to run over Tor. And not just today's
>> Tor which is developed, serviced, and supported by the US government, but a
>> Tor or I2P that future governments have turned hostile towards and actively
>> censor or repress. Or existing authoritative governments, for that matter.
>> How much bandwidth would be available through those connections?
>>
>> It may hopefully never be necessary to operate under such constraints,
>> except by freedom seeking individuals within existing totalitarian regimes.
>> However the credible threat of doing so may be what keeps Bitcoin from
>> being repressed in the first place. Lose the capability to go underground,
>> and it will be pressured into regulation, eventually.
>>
>> To the second point, it has been previously pointed out that large miners
>> stand to gain from larger blocks, for the same basic underlying reasons as
>> selfish mining. The incentive is to increase blocks, and miners are able to
>> do so at will and without cost. I would not be so certain that we wouldn't
>> see large blocks sooner than that.
>>
>>
>>> We should get the inverted bloom filters stuff (or competing products)
>>> working
>>> at least on a one-to-one basis so we can solve the propagation time
>>> problem.
>>> There frankly is a huge amount of optimization that can be done in that
>>> area,
>>> we don't even use locality (pingtime) to optimize distribution.
>>> From my experience you can expect a 2-magnitude speedup in that same 6
>>> month
>>> period by focusing some research there.
>>>
>>
>> This is basically already deployed thanks to Matt's relay network.
>> Further improvements are not going to have dramatic effects.
>>
>>
>>> Remember 8Gb/block still doesn't support VISA/Mastercard.
>>>
>>
>> No, it doesn't. And 8GB/block is ludicrously large -- it would
>> absolutely, without any doubt destroy the very nature of Bitcoin, turning
>> it into a fundamentally uninteresting reincarnation of the existing
>> financial system. And still be unable to compete with VISA/Mastercard.
>>
>> So why then the pressure to go down a route that WILL lead to failure by
>> your own metrics?
>>
>> I humbly suggest that maybe we should play the strengths of Bitcoin
>> instead -- it's trustlessness via policy neutrality.
>>
>> Either that, or go work on Stellar. Because that's where it's headed
>> otherwise.
>>
>>
>> _______________________________________________
>> 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/20150811/ec733b11/attachment-0001.html>

2023-06-07 19:34:00 CEST

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Mon, Aug 10, 2015 at 10:34 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> So, while LN is written, rolled out and tested, we need to respond with
> bigger
> blocks. 8Mb - 8Gb sounds good to me.
>
This is where things diverge. It's fine to pick a new limit or growth
trajectory. But defend it with data and reasoned analysis.
Can you at least understand the conservative position here? "1MB sounds
good to me" is how we got into this mess. We must make sure that we avoid
making the same mistakes again, creating more or worse problems then we are
solving.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/d52c3f82/attachment.html>

2023-06-07 19:34:00 CEST

- reply

📅 Original date posted:2015-08-11
📝 Original message:On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
> > This is where things diverge. It's fine to pick a new limit or growth
> > trajectory. But defend it with data and reasoned analysis.
>
> We currently serve about 0,007% of the world population sending maybe one
> transaction a month.
> This can only go up.
>
> There are about 20 currencies in the world that are unstable and showing
> early
> signs of hyperinflation. If even small percentage of these people cash-out
> and
> get Bitcoins for their savings you'd have the amount of people using
> Bitcoin
> as savings go from maybe half a million to 10 million in the space of a
> couple
> of months. Why so fast? Because all the world currencies are linked.
> Practically all currencies follow the USD, and while that one may stay
> robust
> and standing, the linkage has been shown in the past to cause
> chain-effects.
>
> It is impossible to predict how much uptake Bitcoin will take, but we have
> seen big rises in price as Cyprus had a bailin and then when Greece first
> showed bad signs again.
> Lets do our due diligence and agree that in the current world economy there
> are sure signs that people are considering Bitcoin on a big scale.
>
> Bigger amount of people holding Bitcoin savings won't make the transaction
> rate go up very much, but if you have feet on the ground you already see
> that
> people go back to barter in countries like Poland, Ireland, Greece etc.
> And Bitcoin will be an alternative to good to ignore. Then transaction
> rates
> will go up. Dramatically.
>
> If you are asking for numbers, that is a bit tricky. Again; we are at
> 0,007%... Thats like a f-ing rounding error in the world economy. You can't
> reason from that. Its like using a float to do calculations that you should
> have done in a double and getting weird output.
>
> Bottom line is that a maximum size of 8Mb blocks is not that odd. Because
> a 20
> times increase is very common in a "company" that is about 6 years old.
> For instance Android was about that age when it started to get shipped by
> non-
> Google companies. There the increase was substantially bigger and the
> company
> backing it was definitely able to change direction faster than the Bitcoin
> oiltanker can change direction.
>
> ...
>
> Another metric to remember; if you follow hackernews (well, the incubator
> more
> than the linked articles) you'd be exposed to the thinking of these
> startups.
> Their only criteria is growth. and this is rather substantial growth. Like
> 150% per month. Naturally, most of these build on top of html or other
> existing technologies. But the point is that exponential growth is
> expected
> in any startup. They typically have a much much more agressive timeline,
> though. Every month instead of every year.
> Having exponential growth in the blockchain is really not odd and even if
> we
> have LN or sidechains or the next changetip, this space will be used. And
> we
> will still have scarcity.
I'm sorry, I really don't want to sound like a jerk, but not a single word
of that mattered. Yes we all want Bitcoin to scale such that every person
in the world can use it without difficulty. However if that were all that
we cared about then I would be remiss if I did not point out that there are
plenty of better, faster, and cheaper solutions to finding global consensus
over a payment ledger than Bitcoin. Architectures which are algorithmically
superior in their scaling properties. Indeed they are already implemented
and you can use them today:
https://www.stellar.org/
http://opentransactions.org/
So why do I work on Bitcoin, and why do I care about the outcome of this
debate? Because Bitcoin offers one thing, and one thing only which
alternative architectures fundamentally lack: policy neutrality. It can't
be censored, it can't be shut down, and the rules cannot change from
underneath you. *That* is what Bitcoin offers that can't be replicated at
higher scale with a SQL database and an audit log.
It follows then, that if we make a decision now which destroys that
property, which makes it possible to censor bitcoin, to deny service, or to
pressure miners into changing rules contrary to user interests, then
Bitcoin is no longer interesting. We might as well get rid of mining at
that point and make Bitcoin look like Stellar or Open-Transactions because
at least then we'd scale even better and not be pumping millions of tons of
CO2 into the atmosphere from running all those ASICs.
On the other side, 3Tb harddrives are sold, which take 8Mb blocks without
> problems.
>
Straw man, storage is not an issue.
> You can buy broadband in every relevant country that easily supports the
> bandwidth we need. (remember we won't jump to 8Mb in a day, it will likely
> take at least 6 months).
>
Neither one of those assertions is clear. Keep in mind the goal is to have
Bitcoin survive active censorship. Presumably that means being able to run
a node even in the face of a hostile ISP or government. Furthermore, it
means being location independent and being able to move around. In many
places the higher the bandwidth requirements the fewer the number of ISPs
that are available to service you, and the more visible you are.
It may also be necessary to be able to run over Tor. And not just today's
Tor which is developed, serviced, and supported by the US government, but a
Tor or I2P that future governments have turned hostile towards and actively
censor or repress. Or existing authoritative governments, for that matter.
How much bandwidth would be available through those connections?
It may hopefully never be necessary to operate under such constraints,
except by freedom seeking individuals within existing totalitarian regimes.
However the credible threat of doing so may be what keeps Bitcoin from
being repressed in the first place. Lose the capability to go underground,
and it will be pressured into regulation, eventually.
To the second point, it has been previously pointed out that large miners
stand to gain from larger blocks, for the same basic underlying reasons as
selfish mining. The incentive is to increase blocks, and miners are able to
do so at will and without cost. I would not be so certain that we wouldn't
see large blocks sooner than that.
> We should get the inverted bloom filters stuff (or competing products)
> working
> at least on a one-to-one basis so we can solve the propagation time
> problem.
> There frankly is a huge amount of optimization that can be done in that
> area,
> we don't even use locality (pingtime) to optimize distribution.
> From my experience you can expect a 2-magnitude speedup in that same 6
> month
> period by focusing some research there.
>
This is basically already deployed thanks to Matt's relay network. Further
improvements are not going to have dramatic effects.
> Remember 8Gb/block still doesn't support VISA/Mastercard.
>
No, it doesn't. And 8GB/block is ludicrously large -- it would absolutely,
without any doubt destroy the very nature of Bitcoin, turning it into a
fundamentally uninteresting reincarnation of the existing financial system.
And still be unable to compete with VISA/Mastercard.
So why then the pressure to go down a route that WILL lead to failure by
your own metrics?
I humbly suggest that maybe we should play the strengths of Bitcoin instead
-- it's trustlessness via policy neutrality.
Either that, or go work on Stellar. Because that's where it's headed
otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/97ad8981/attachment-0001.html>

2023-06-07 19:33:43 CEST

- reply

📅 Original date posted:2015-08-11
📝 Original message:Michael, why does it matter that every node in the world process and
validate your morning coffee transaction? Why does it matter to anyone
except you and the coffee vendor?
On Tue, Aug 11, 2015 at 11:46 AM, Michael Naber via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Jorge: Many people would like to participate in a global consensus
> network -- which is a network where all the participating nodes are aware
> of and agree upon every transaction. Constraining Bitcoin capacity below
> the limits of technology will only push users seeking to participate in a
> global consensus network to other solutions which have adequate capacity,
> such as BitcoinXT or others. Note that lightning / hub and spoke do not
> meet requirements for users wishing to participate in global consensus,
> because they are not global consensus networks, since all participating
> nodes are not aware of all transactions.
>
>
>
>
> On Tue, Aug 11, 2015 at 12:47 PM, Jorge Timón <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> On Aug 11, 2015 12:14 AM, "Thomas Zander via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > On Monday 10. August 2015 13.55.03 Jorge Timón via bitcoin-dev wrote:
>> > > Gavin, I interpret the absence of response to these questions as a
>> > > sign that everybody agrees that there's no other reason to increase
>> > > the consensus block size other than to avoid minimum market fees from
>> > > rising (above zero).
>> > > Feel free to correct that notion at any time by answering the
>> > > questions yourself.
>> > > In fact if any other "big block size advocate" thinks there's more
>> > > reason I would like to hear their reasons too.
>> >
>> > See my various emails in the last hour.
>>
>> I've read them. I have read gavin's blog posts as well, several times.
>> I still don't see what else can we fear from not increasing the size
>> apart from fees maybe rising and making some problems that need to be
>> solved rewardless of the size more visible (like a dumb unbounded mempool
>> design).
>>
>> This discussion is frustrating for everyone. I could also say "This have
>> been explained many times" and similar things, but that's not productive.
>> I'm not trying to be obstinate, please, answer what else is to fear or
>> admit that all your feas are just potential consequences of rising fees.
>>
>> With the risk of sounding condescending or aggressive...Really, is not
>> that hard to answer questions directly and succinctly. We should all be
>> friends with clarity. Only fear, uncertainty and doubt are enemies of
>> clarity. But you guys on the "bigger blocks side" don't want to spread fud,
>> do you?
>> Please, prove paranoid people like me wrong on this point, for the good
>> of this discussion. I really don't know how else to ask this without
>> getting a link to something I have already read as a response.
>>
>> _______________________________________________
>> 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/20150811/7494297f/attachment.html>

2023-06-07 19:33:34 CEST

- reply

📅 Original date posted:2015-08-07
📝 Original message:Surely you have some sort of empirical measurement demonstrating the
validity of that statement? That is to say you've established some
technical criteria by which to determine how much centralization pressure
is too much, and shown that Pieter's proposal undercuts expected progress
in that area?
On Fri, Aug 7, 2015 at 12:07 PM, Ryan Butler <rryananizer at gmail.com> wrote:
> Clarification...
>
> These are not mutually exclusive. We can design an increase to blocksize
> that increases available space on chain AND follow technological
> evolution. Peter's latest proposal is way too conservative on that front.
>
> And given Peter's assertion that demand is infinite there will still be a
> an ocean of off chain transactions for the likes of blockstream to address.
> On Aug 7, 2015 1:57 PM, "Ryan Butler" <rryananizer at gmail.com> wrote:
>
>> Who said anything about scaling bitcoin to visa levels now? We're
>> talking about an increase now that scales into the future at a rate that is
>> consistent with technological progress.
>>
>> Peter himself said "So, I think the block size should follow
>> technological evolution...".
>>
>> The blocksize increase proposals have been modeled around this very
>> thing. It's reasonable to increase the blocksize to a point that a
>> reasonable person, with reasonable equipment and internet access can run a
>> node or even a miner with acceptable orphan rates. Most miners are spv
>> mining anyways. The 8 or even 20 MB limits are within those parameters.
>>
>> These are not mutually exclusive. We can design an increase to blocksize
>> that addresses both demand exceeding the available space AND follow
>> technological evolution. Peter's latest proposal is way too conservative
>> on that front.
>> On Aug 7, 2015 1:25 PM, "Mark Friedenbach" wrote:
>>
>>> Please don't put words into Pieter's mouth. I guarantee you everyone
>>> working on Bitcoin in their heart of hearts would prefer everyone in the
>>> world being able to use the Bitcoin ledger for whatever purpose, if there
>>> were no cost.
>>>
>>> But like any real world engineering issue, this is a matter of
>>> tradeoffs. At the extreme it is simply impossible to scale Bitcoin to the
>>> terrabyte sized blocks that would be necessary to service the entire
>>> world's financial transactions. Not without sacrificing entirely the
>>> protection of policy neutrality achieved through decentralization. And as
>>> that is Bitcoin's only advantage over traditional consensus systems, you
>>> would have to wonder what the point of such an endeavor would be.
>>>
>>> So *somewhere* you have to draw the line, and transactions below that
>>> level are simply pushed into higher level or off-chain protocols.
>>>
>>> The issue, as Pieter and Jorge have been pointing out, is that technical
>>> discussion over where that line should be has been missing from this debate.
>>>
>>> On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Interesting position there Peter...you fear more people actually using
>>>> bitcoin. The less on chain transactions the lower the velocity and the
>>>> lower the value of the network. I would be careful what you ask for
>>>> because you end up having nothing left to even root the security of these
>>>> off chain transactions with and then neither will exist.
>>>>
>>>> Nobody ever said you wouldn't run out of capacity at any size. It's
>>>> quite the fallacy to draw the conclusion from that statement that block
>>>> size should remain far below a capacity it can easily maintain which would
>>>> bring more users/velocity/value to the system. The outcomes of both of
>>>> those scenarios are asymmetric. A higher block size can support more users
>>>> and volume.
>>>>
>>>> Raising the blocksize isn't out of fear. It's the realization that we
>>>> are at a point where we can raise it and support more users and
>>>> transactions while keeping the downsides to a minimum (centralization etc).
>>>> On Aug 7, 2015 11:28 AM, "Pieter Wuille via bitcoin-dev" <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <
>>>>> gavinandresen at gmail.com> wrote:
>>>>>
>>>>>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <
>>>>>> pieter.wuille at gmail.com> wrote:
>>>>>>
>>>>>>> I guess my question (and perhaps that's what Jorge is after): do you
>>>>>>> feel that blocks should be increased in response to (or for fear of) such a
>>>>>>> scenario.
>>>>>>>
>>>>>>
>>>>>> I think there are multiple reasons to raise the maximum block size,
>>>>>> and yes, fear of Bad Things Happening as we run up against the 1MB limit is
>>>>>> one of the reasons.
>>>>>>
>>>>>> I take the opinion of smart engineers who actually do resource
>>>>>> planning and have seen what happens when networks run out of capacity very
>>>>>> seriously.
>>>>>>
>>>>>
>>>>> This is a fundamental disagreement then. I believe that the demand is
>>>>> infinite if you don't set a fee minimum (and I don't think we should), and
>>>>> it just takes time for the market to find a way to fill whatever is
>>>>> available - the rest goes into off-chain systems anyway. You will run out
>>>>> of capacity at any size, and acting out of fear of that reality does not
>>>>> improve the system. Whatever size blocks are actually produced, I believe
>>>>> the result will either be something people consider too small to be
>>>>> competitive ("you mean Bitcoin can only do 24 transactions per second?"
>>>>> sounds almost the same as "you mean Bitcoin can only do 3 transactions per
>>>>> second?"), or something that is very centralized in practice, and likely
>>>>> both.
>>>>>
>>>>>
>>>>>> And if so, if that is a reason for increase now, won't it be a reason
>>>>>>> for an increase later as well? It is my impression that your answer is yes,
>>>>>>> that this is why you want to increase the block size quickly and
>>>>>>> significantly, but correct me if I'm wrong.
>>>>>>>
>>>>>>
>>>>>> Sure, it might be a reason for an increase later. Here's my message
>>>>>> to in-the-future Bitcoin engineers: you should consider raising the
>>>>>> maximum block size if needed and you think the benefits of doing so (like
>>>>>> increased adoption or lower transaction fees or increased reliability)
>>>>>> outweigh the costs (like higher operating costs for full-nodes or the
>>>>>> disruption caused by ANY consensus rule change).
>>>>>>
>>>>>
>>>>> In general that sounds reasonable, but it's a dangerous precedent to
>>>>> make technical decisions based on a fear of change of economics...
>>>>>
>>>>> --
>>>>> Pieter
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20150807/c08c7fc7/attachment-0001.html>

2023-06-07 19:33:32 CEST

- reply

📅 Original date posted:2015-08-07
📝 Original message:Please don't put words into Pieter's mouth. I guarantee you everyone
working on Bitcoin in their heart of hearts would prefer everyone in the
world being able to use the Bitcoin ledger for whatever purpose, if there
were no cost.
But like any real world engineering issue, this is a matter of tradeoffs.
At the extreme it is simply impossible to scale Bitcoin to the terrabyte
sized blocks that would be necessary to service the entire world's
financial transactions. Not without sacrificing entirely the protection of
policy neutrality achieved through decentralization. And as that is
Bitcoin's only advantage over traditional consensus systems, you would have
to wonder what the point of such an endeavor would be.
So *somewhere* you have to draw the line, and transactions below that level
are simply pushed into higher level or off-chain protocols.
The issue, as Pieter and Jorge have been pointing out, is that technical
discussion over where that line should be has been missing from this debate.
On Fri, Aug 7, 2015 at 10:47 AM, Ryan Butler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Interesting position there Peter...you fear more people actually using
> bitcoin. The less on chain transactions the lower the velocity and the
> lower the value of the network. I would be careful what you ask for
> because you end up having nothing left to even root the security of these
> off chain transactions with and then neither will exist.
>
> Nobody ever said you wouldn't run out of capacity at any size. It's quite
> the fallacy to draw the conclusion from that statement that block size
> should remain far below a capacity it can easily maintain which would bring
> more users/velocity/value to the system. The outcomes of both of those
> scenarios are asymmetric. A higher block size can support more users and
> volume.
>
> Raising the blocksize isn't out of fear. It's the realization that we are
> at a point where we can raise it and support more users and transactions
> while keeping the downsides to a minimum (centralization etc).
> On Aug 7, 2015 11:28 AM, "Pieter Wuille via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <gavinandresen at gmail.com>
>> wrote:
>>
>>> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille <pieter.wuille at gmail.com>
>>> wrote:
>>>
>>>> I guess my question (and perhaps that's what Jorge is after): do you
>>>> feel that blocks should be increased in response to (or for fear of) such a
>>>> scenario.
>>>>
>>>
>>> I think there are multiple reasons to raise the maximum block size, and
>>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>>> of the reasons.
>>>
>>> I take the opinion of smart engineers who actually do resource planning
>>> and have seen what happens when networks run out of capacity very seriously.
>>>
>>
>> This is a fundamental disagreement then. I believe that the demand is
>> infinite if you don't set a fee minimum (and I don't think we should), and
>> it just takes time for the market to find a way to fill whatever is
>> available - the rest goes into off-chain systems anyway. You will run out
>> of capacity at any size, and acting out of fear of that reality does not
>> improve the system. Whatever size blocks are actually produced, I believe
>> the result will either be something people consider too small to be
>> competitive ("you mean Bitcoin can only do 24 transactions per second?"
>> sounds almost the same as "you mean Bitcoin can only do 3 transactions per
>> second?"), or something that is very centralized in practice, and likely
>> both.
>>
>>
>>> And if so, if that is a reason for increase now, won't it be a reason
>>>> for an increase later as well? It is my impression that your answer is yes,
>>>> that this is why you want to increase the block size quickly and
>>>> significantly, but correct me if I'm wrong.
>>>>
>>>
>>> Sure, it might be a reason for an increase later. Here's my message to
>>> in-the-future Bitcoin engineers: you should consider raising the maximum
>>> block size if needed and you think the benefits of doing so (like increased
>>> adoption or lower transaction fees or increased reliability) outweigh the
>>> costs (like higher operating costs for full-nodes or the disruption caused
>>> by ANY consensus rule change).
>>>
>>
>> In general that sounds reasonable, but it's a dangerous precedent to make
>> technical decisions based on a fear of change of economics...
>>
>> --
>> Pieter
>>
>>
>> _______________________________________________
>> 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/20150807/760afe4f/attachment-0001.html>

2023-06-07 19:33:02 CEST

- reply

📅 Original date posted:2015-08-09
📝 Original message:Tom, you appear to be misunderstanding how lightning network and
micropayment hub-and-spoke models in general work.
> But neither can Bob receive money, unless payment hub has
advanced it to the channel (or (2) below applies). Nothing requires the
payment hub to do this.
On the contrary the funds were advanced by the hub on the creation of the
channel. There is no credit involved. if the funds aren't already available
for Bob to immediately claim his balance, the payment doesn't go through in
the first place.
On Sun, Aug 9, 2015 at 11:46 AM, Tom Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 8/4/2015 4:27 AM, Pieter Wuille via bitcoin-dev wrote:
>
> > Don't turn Bitcoin into something uninteresting, please.
>
> Consider how Bob will receive money using the Lightning Network.
>
> Bob receives a payment by applying a contract to his local payment
> channel, increasing the amount payable to him when the channel is closed.
>
> There are two possible sources of funding for Bob's increased claim.
> They can appear alone, or in combination:
>
>
> Funding Source (1)
> A deposit from Bob's payment hub
>
> Bob can receive funds, if his payment hub has made a deposit to the
> channel. Another name for this is "credit".
>
> This credit has no default risk: Bob cannot just take payment hub's
> deposit. But neither can Bob receive money, unless payment hub has
> advanced it to the channel (or (2) below applies). Nothing requires the
> payment hub to do this.
>
> This is a 3rd-party dependency totally absent with plain old bitcoin.
> It will come with a fee and, in an important way, it is worse than the
> current banking system. If a bank will not even open an account for Bob
> today, why would a payment hub lock up hard bitcoin to allow Bob to be
> paid through a Poon-Dryja channel?
>
>
> Funding Source (2)
> Bob's previous spends
>
> If Bob has previously spent from the channel, decreasing his claim on
> its funds (which he could have deposited himself), that claim can be
> re-increased.
>
> To avoid needing credit (1), Bob has an incentive to consolidate
> spending and income in the same payment channel, just as with today's
> banks. This is at odds with the idea that Bob will have accounts with
> many payment hubs. It is an incentive for centralization.
>
>
> With Lightning Network, Bob will need a powerful middleman to send and
> receive money effectively. *That* is uninteresting to me.
>
>
> _______________________________________________
> 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/20150809/8ce749f3/attachment-0001.html>

2023-06-07 17:49:17 CEST

- reply

2023-06-07 17:49:16 CEST

- reply

2023-06-07 17:47:10 CEST

- reply

2023-06-07 17:47:07 CEST

- reply

2023-06-07 17:46:48 CEST

- reply

2023-06-07 17:46:47 CEST

- reply

2023-06-07 17:46:04 CEST

- reply

2023-06-07 17:45:50 CEST

- reply

2023-06-07 17:45:42 CEST

- reply

2023-06-07 17:45:15 CEST

- reply

2023-06-07 17:44:16 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:The median is used here because that is the consensus rule -- a block
cannot have a timestamp older than the median time of the last 11 blocks.
By linking the changeover to this rule we avoid perverse incentives about
miners lying in their timestamps, or the threshold being crossed, then
reverted, then crossed again, etc.
Maybe a different percentile would have been a better choice, but that ship
sailed in 2009. The rule is what it is right now, and we benefit the most
from using the same rule as consensus for the threshold.
On Jul 30, 2015 9:57 AM, "Gary Mulder via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 30 July 2015 at 16:12, Jorge Timón <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 1) Unlike previous blocksize hardfork proposals, this uses median time
>> instead of block.nTime for activation. I like that more but my
>> preference is still using height for everything. But that discussion
>> is not specific to this proposal, so it's better if we discuss that
>> for all of them here:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html
>
>
> Note that a "median" is a special case of a 50% percentile. If you desire
> to apply a more stringent criteria you can use the 75th or even 90th
> percentile.
>
> https://en.wikipedia.org/wiki/Percentile
>
> Perhaps if a statistician (i.e. not me) could be found to offer her
> services, she could become a resource for helping selecting the most
> appropriate statistical algorithms on request (and implemented Integer math
> as per Gavin, from memory), considering the consequences of learning
> post-fork that a "bad statistical model" was chosen.
>
> e.g. an exponentially weighted moving average is usually much less
> volatile and harder to manipulate than a simple moving average, but still
> can "respond" to short term drivers.
>
> Regards,
> Gary
>
> _______________________________________________
> 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/20150730/39d7af41/attachment.html>

2023-06-07 17:43:41 CEST

- reply

📅 Original date posted:2015-07-28
📝 Original message:Does it matter even in the slightest why the block size limit was put in
place? It does not. Bitcoin is a decentralized payment network, and the
relationship between utility (block size) and decentralization is
empirical. Why the 1MB limit was put in place at the time might be a
historically interesting question, but it bears little relevance to the
present engineering issues.
On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Enter a “temporary” anti-spam measure - a one megabyte block size limit.
> Let’s test this out, then increase it once we see how things work. So far
> so good…
> >
>
> The block size limit was put in place as an anti-DoS measure (monster
> blocks), not "anti-spam". It was never intended to have any economic
> effect, not on spam and not on any future fee market.
>
>
> jp
>
> _______________________________________________
> 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/20150728/106ea598/attachment.html>

2023-06-07 17:40:55 CEST

- reply

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

2023-06-07 17:40:54 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:Think in terms of participants, not addresses. A participant in the
lightning network has a couple of connections to various hubs, from which
the participant is able to send or receive coin. The user is able to send
coins to anyone connected to the lightning network by means of an atomic
transaction through any path of the network. But the only payment from them
that ever hits the chain is their settlement with the hub.
Imagine there was a TCP/IP data chain and corresponding lightning network.
Everyone connected to the network has an "IP" channel with their ISP.
Through this channel they can send data to anywhere on the network, and a
traceroute shows what hops the data would take. But when settlement
actually occurs all the network sees is the net amount of data that has
gone through each segment -- without any context. There's no record
preserved on-chain of who sent data to whom, just that X bytes went through
the pipe on the way to somewhere unspecified.
So it is with lightning payment networks. You open a channel with a hub and
through that channel send coins to anyone accessible to the network.
Channels only close when a participant needs the funds for non-lightning
reasons, or when hubs need to rebalance. And when they do, observers on the
chain learn nothing more than how much net coin moved across that single
link. They learn nothing about where that coin eventually ended up.
So back to your original question, each channel can be considered to have a
pseudonymous identity, and each new channel given a new identity. Channel
closures can even be coinjoin'd when the other party is cooperating. But
ultimately, lightning usefully solves a problem where participants have
semi-long lived payment endpoints.
On Sun, Jun 28, 2015 at 9:32 AM, Raystonn . <raystonn at hotmail.com> wrote:
> Write coalescing works fine when you have multiple writes headed to the
> same (contiguous) location. Will lightning be useful when we have more
> unique transactions being sent to different addresses, and not just
> multiple transactions between the same sender and address? I have doubts.
>
>
> -----Original Message----- From: Adam Back
> Sent: Sunday, June 28, 2015 5:37 AM
> To: Benjamin
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
>
>
> On 28 June 2015 at 12:29, Benjamin <benjamin.l.cordes at gmail.com> wrote:
>
>> I agree that naive scaling will likely lead to bad outcomes. They might
>> have
>> the advantage though, as this would mean not changing Bitcoin.
>>
>
> Sure we can work incrementally and carefully, and this is exactly what
> Bitcoin has been doing, and *must* do for safety and security for the
> last 5 years!
> That doesnt mean that useful serious improvements have not been made.
>
> Level2 and Lightning is not well defined. If you move money to a third
>> party, even if it is within the constrained of a locked contract, then I
>> don't think that will solve the issues.
>>
>
> I think you misunderstand how lightning works. Every lightning
> transaction *is* a valid bitcoin transaction that could be posted to
> the Bitcoin network to reclaim funds if a hub went permanently
> offline. It is just that while the hubs involved remain in service,
> there is no need to do so. This is why it has been described as a
> (write coalescing) write cache layer for Bitcoin.>
>
> I believe people expect lightning to be peer 2 peer like bitcoin.
>
> Adam
> _______________________________________________
> 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/20150628/166bb4cb/attachment-0001.html>

2023-06-07 17:40:51 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:I really suggest you look into the layer2 systems Adam pointed to, as you
appear to be misinformed about their properties. There are many proposals
which really do achieve global consensus using the block chain, just in a
delayed (and cached) fashion that is still 100% safe.
It is possible to go off-chain without losing the trustlessness and
security of the block chain.
On Sat, Jun 27, 2015 at 9:09 AM, Michael Naber <mickeybob at gmail.com> wrote:
> The goal of Bitcoin Core is to meet the demand for global consensus as
> effectively as possible. Please let's keep the conversation on how to best
> meet that goal.
>
> The off-chain solutions you enumerate are are useful solutions in their
> respective domains, but none of them solves the global consensus problem
> with any greater efficiency than Bitcoin does.
>
>
> On Sat, Jun 27, 2015 at 11:33 AM, Adam Back <adam at cypherspace.org> wrote:
>
>> Michael Naber wrote:
>> > Bitcoin Core must remain the lowest-fee, highest-capacity, most secure,
>> distributed, fastest, overall best solution possible to the global
>> consensus problem.
>>
>> Everyone here is excited about the potential of Bitcoin and would
>> aspirationally like it to reach its full potential as fast as
>> possible. But the block-size is not a free variable, half those
>> parameters you listed are in conflict with each other. We're trying
>> to improve both decentralisation and throughput short-term while
>> people work on algorithmic improvements mid-term. If you are
>> interested you can take a look through the proposals:
>>
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html
>>
>> Note that probably 99% of Bitcoin transactions already happen
>> off-chain in exchanges, tipping services, hosted wallets etc. Maybe
>> you're already using them, assuming you are a bitcoin user.
>> They constitute an early stage layer 2, some of them even have on
>> chain netting and scale faster than the block-chain.
>>
>> You can also read about layer 2, the lightning network paper and the
>> duplex micropayment channel paper:
>>
>> http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
>>
>> http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
>>
>> and read the development list and look at the code:
>>
>> http://lists.linuxfoundation.org/pipermail/lightning-dev/
>> https://github.com/ElementsProject/lightning
>>
>> Adam
>>
>>
>> On 27 June 2015 at 16:39, Michael Naber <mickeybob at gmail.com> wrote:
>> > Demand to participate in a low-fee global consensus network will likely
>> > continue to rise. Technology already exists to meet that rising demand
>> using
>> > a blockchain with sufficient block size. Whether that blockchain is
>> Bitcoin
>> > Core with an increased block size, or whether it is a fork, market
>> forces
>> > make it almost certain that demand will be met by a blockchain with
>> adequate
>> > capacity. These forces ensure that not only today’s block size will be
>> > increased, but also that future increases will occur should the demand
>> > arise.
>> >
>> > In order to survive, Bitcoin Core must remain the lowest-fee,
>> > highest-capacity, most secure, distributed, fastest, overall best
>> solution
>> > possible to the global consensus problem. Attempting to artificially
>> > constrain the block size below the limits of technology for any reason
>> is a
>> > conflict with this objective and a threat to the survival of Bitcoin
>> Core.
>> > At the same time, scheduling large future increases or permitting
>> unlimited
>> > dynamic scaling of the block size limit raises concerns over
>> availability of
>> > future computing resources. Instead, we should manually increase the
>> block
>> > size limit as demand occurs, except in the special case that increasing
>> the
>> > limit would cause an undue burden upon users wishing to validate the
>> > integrity of the blockchain.
>> >
>> > Compromise: Can we agree that raising the block size to a static 8MB now
>> > with a plan to increase it further should demand necessitate except in
>> the
>> > special case above is a reasonable path forward?
>> >
>> > _______________________________________________
>> > 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/20150627/d47f275d/attachment.html>

2023-06-07 17:40:35 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:This is a hard fork. It is not about miners, at all. 2013 showed that when
there is true consensus mining can be coordinated on the order of hours or
days. This is about pushing through a coercive change to the
decentralization tradeoffs of bitcoin without unanimous consent.
On Jun 26, 2015 12:03 PM, "Tier Nolan" <tier.nolan at gmail.com> wrote:
> On Fri, Jun 26, 2015 at 7:47 PM, Patrick Strateman <
> patrick.strateman at gmail.com> wrote:
>
>> For a proposed hard fork to reach a level of consensus necessary to be
>> safe requires that there be a clear and self evident course of action.
>>
>
> Safety increases with more lead-in time. If the reference client was
> updated so that the hard fork happened in two years, it would be pretty
> safe. Miners would have time to update.
>
> If miners (or the community) objected, it is sort of like a game of
> chicken.
>
> This is one of the problems with not making decisions in advance, the
> resulting hard fork is inherently safer.
>
> _______________________________________________
> 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/20150626/f4b14ff9/attachment.html>

2023-06-07 17:40:30 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:Jeff, block size limits large enough to prevent fee pressure is absolutely,
unequivocally unsustainable. We are already running against technological
limits in the tradeoff between decentralization and utility. Increases of
the block size limit in advance of fee pressure only delay the problem --
it does not and cannot solve it!
We must be careful to use the block size limit now to get infrastructure to
support a world with full blocks -- it's not that hard -- while still
having a little room to grow fast if things unexpectedly break.
On Fri, Jun 26, 2015 at 11:23 AM, Jeff Garzik <jgarzik at gmail.com> wrote:
> Failure to plan now for a hard fork increase 6(?) months in the future
> produces that lumpy, unpredictable market behavior.
>
> The market has baked in the years-long behavior of low fees. From the
> market PoV, inaction does lead to precisely that, a sudden change over the
> span of a few months.
>
> At a higher level, people look at bitcoin and see people delaying,
> waiting, dawdling until the barn is actually on fire before taking action
> to put out the fire.
>
> They see a system that is not responsive to higher level externalities of
> people & businesses making plans for the future. Based on current proposal
> of change-through-inaction, businesses will simply shelve plans to use
> bitcoin and not bother putting those new users on the network.
>
> If you wait until the need to increase block size is acute, it is already
> too late. (1) Businesses have permanently shelved plans to use bitcoin and
> (2) change at that point produces _larger_ disruption to the fee market.
>
> Hard forks require planning many months in advance. Gavin's timing is
> sound, even though the Gavin/Hearn Bitcoin-XT antics were sub-optimal.
>
>
>
>
>
>
>
> On Fri, Jun 26, 2015 at 11:12 AM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>
>> I am not saying that economic change is what we want. Only that it is
>> inevitable, independent of whether larger blocks happen or not.
>>
>> I am saying that acting because of fear of economic change is a bad
>> reason. The reason for increase should be because of the higher utility. We
>> need it at some point, but there should be no rush.
>>
>> I do understand that we want to avoid a *sudden* change in economic
>> policy, but I'm generally not too worried. Either fees increase and they
>> get paid, and we're good. But more likely is that some uses just move
>> off-chain because the block chain does not offer what they need. That's
>> sad, but it is inevitable at any size: some uses fit, some don't.
>>
>> --
>> Pieter
>> On Jun 26, 2015 7:57 PM, "Jeff Garzik" <jgarzik at gmail.com> wrote:
>>
>>> It is not "fear" of fee pressure.
>>>
>>> 1) Blocks are mostly not-full on average.
>>>
>>> 2) Absent long blocks and stress tests, there is little fee pressure
>>> above the anti-spam relay fee metric, because of #1.
>>>
>>> 3) As such, inducing fee pressure is a delta, a change from years-long
>>> bitcoin economic policy. Each time we approach the soft limit, Bitcoin
>>> Core increases the soft limit to prevent "full" blocks. Mike Hearn et. al.
>>> lobbies miners to upgrade.
>>>
>>> (note - this is not an endorsement of these actions - it is a neutral
>>> observation)
>>>
>>> 4) Inaction leads to consistent fee pressure as the months tick on and
>>> system volume grows; thus, inaction leads to economic policy change.
>>>
>>> 5) Economic policy change leads to market and software disruption. The
>>> market and software - notably wallets - is not prepared for this.
>>>
>>> 6) If you want to change economic policy, that's fine. But be honest
>>> and admit you are arguing for a change, a delta from current market
>>> expectations and behavior.
>>>
>>> 7) It is critical to first deal with what _is_, not what you wish the
>>> world to be. You want a fee market to develop. There is nothing wrong
>>> with that desire. It remains a delta from where we are today, and that is
>>> critically relevant in a $3b+ market.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jun 26, 2015 at 7:09 AM, Pieter Wuille <pieter.wuille at gmail.com>
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> here I'm going to try to address a part of the block size debate which
>>>> has been troubling me since the beginning: the reason why people seem to
>>>> want it.
>>>>
>>>> People say that larger blocks are necessary. In the long term, I agree
>>>> - in the sense that systems that do not evolve tend to be replaced by other
>>>> systems. This evolution can come in terms of layers on top of Bitcoin's
>>>> blockchain, in terms of the technology underlying various aspects of the
>>>> blockchain itself, and also in the scale that this technology supports.
>>>>
>>>> I do, however, fundamentally disagree that a fear for a change in
>>>> economics should be considered to necessitate larger blocks. If it is, and
>>>> there is consensus that we should adapt to it, then there is effectively no
>>>> limit going forward. This is similar to how Congress voting to increase the
>>>> copyright term retroactively from time to time is really no different from
>>>> having an infinite copyright term in the first place. This scares me.
>>>>
>>>> Here is how Gavin summarizes the future without increasing block sizes
>>>> in PR 6341:
>>>>
>>>> > 1. Transaction confirmation times for transactions with a given fee
>>>> will rise; very-low-fee transactions will fail to get confirmed at all.
>>>> > 2. Average transaction fee paid will rise
>>>> > 3. People or applications unwilling or unable to pay the rising fees
>>>> will stop submitting transactions
>>>> > 4. People and businesses will shelve plans to use Bitcoin, stunting
>>>> growth and adoption
>>>>
>>>> Is it fair to summarize this as "Some use cases won't fit any more,
>>>> people will decide to no longer use the blockchain for these purposes, and
>>>> the fees will adapt."?
>>>>
>>>> I think that is already happening, and will happen at any scale. I
>>>> believe demand for payments in general is nearly infinite, and only a small
>>>> portion of it will eventually fit on a block chain (independent of whether
>>>> its size is limited by consensus rules or economic or technological means).
>>>> Furthermore, systems that compete with Bitcoin in this space already offer
>>>> orders of magnitude more capacity than we can reasonably achieve with any
>>>> blockchain technology at this point.
>>>>
>>>> I don't know what subset of use cases Bitcoin will cater to in the long
>>>> term. They have already changed - you see way less betting transactions
>>>> these days than a few years ago for example - and they will keep changing,
>>>> independent of what effective block sizes we end up with. I don't think we
>>>> should be afraid of this change or try to stop it.
>>>>
>>>> If you look at graphs of block sizes over time (for example,
>>>> http://rusty.ozlabs.org/?p=498), it seems to me that there is very
>>>> little "organic" growth, and a lot of sudden changes (which could
>>>> correspond to changing defaults in miner software, introduction of popular
>>>> sites/services, changes in the economy). I think these can be seen as the
>>>> economy changing to full up the available space, and I believe these will
>>>> keep happening at any size effectively available.
>>>>
>>>> None of this is a reason why the size can't increase. However, in my
>>>> opinion, we should do it because we believe it increases utility and
>>>> understand the risks; not because we're afraid of what might happen if we
>>>> don't hurry up. And from that point of view, it seems silly to make a huge
>>>> increase at once...
>>>>
>>>> --
>>>> Pieter
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20150626/2b2df840/attachment-0001.html>

2023-06-07 17:40:08 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:You don't need to ask permission for testnet. Here is one with 100MB blocks:
https://github.com/pstratem/bitcoin/tree/testnet4
On Jun 24, 2015 11:06 PM, "Pindar Wong" <pindar.wong at gmail.com> wrote:
> In the process of 'mining consensus', perhaps before voting there should
> be robust system testing and telemetry.
>
> May I ask a questions w.r.t. Process BIPs, what is the process for
> establishing a new testnet (e.g. for testing with 8MB blocks)?
>
> p.
>
>
> On Thu, Jun 25, 2015 at 1:41 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
>> These are the kind of silly responses you often get when this subject
>> comes up. Mr. Garzik knows how to ignore messages he doesn't want so I see
>> no need for him to use the list to attack people he doesn't agree with
>> and/or try to interfere with discussions of others on the list.
>> He turns it into a personality discussion rather than a discussion of
>> Systems Engineering. He also tries to intimate anyone who brings up the
>> discussion and "punish" them as a lesson to anyone else who may raise the
>> issue.
>>
>> It is interesting that people like that are attracted to a decentralized
>> system. The reply is simply an attempt at protecting turf which is why
>> Mr. Garzik's vague replies are never taken seriously on the subject of
>> decision-making process for the software.
>>
>> Russ
>>
>>
>>
>> On 6/25/2015 1:07 AM, Jeff Garzik wrote:
>>
>> Ladies & gents, please do not feed the troll. This has been explained to
>> Milly multiple times in the past, on previous mailing list & github with no
>> impact.
>>
>>
>> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info>
>> wrote:
>>
>>> I'm sorry but that is the kind of defensive, cultish response everyone
>>> gets when they ask that question. If you had a well constructed documented
>>> process then you would be able to point to it ... but you can't. While
>>> there are a few bits and pieces scattered about in different places there
>>> is no coherent plan or process.
>>>
>>> It is easy to make statements like "consensus must be unanimous" but the
>>> issue is that you never have true 100% consensus yet you have to move
>>> forward in some fashion and everyone has to run software with the same
>>> consensus rules. The issue is how you move forward is the question that
>>> nobody wants to answer because (a) it is a hard question to answer and (b)
>>> developers see it as a threat to their authority/position. If people just
>>> keep shutting down the discussion with a bunch of cultish stock answers
>>> then you are never going to move forward with developing some kind of
>>> process.
>>>
>>> From what I can see much of the discussion is personality-driven and not
>>> based on Computer Science or and defined process. The issue is that a
>>> personality has changed so the process is perceived to be different and
>>> some people want to hard fork. Previously, the cultish answer is that
>>> Bitcoin development is decentralized because people can fork the code. Now
>>> that some developers want to fork the code suddenly it is a big problem.
>>> Is forking the code part of the consensus process or is it the work of the
>>> devil? The fact that there is so much diverse opinion on this shows a
>>> defined process has never been fully vetted or understood.
>>>
>>> I have worked on these processes for many years for projects orders of
>>> magnitudes larger than Bitcoin. I can absolutely assure you the current
>>> mishmash does not scale and huge amounts of time are wasted. That should
>>> be readily apparent from the recent discussions and the recent concern it
>>> has caused from people outside the developer's inner circle.
>>>
>>> Lack of defined process = high risk and wasted effort.
>>>
>>> Russ
>>>
>>>
>>>
>>>
>>>
>>> On 6/24/2015 9:50 PM, Mark Friedenbach wrote:
>>>
>>> I'm sorry but this is absolutely not the case, Milly. The reason that
>>> people get defensive is that we have a carefully constructed process that
>>> does work (thank you very much!) and is well documented. We talk about it
>>> quite often in fact as it is a defining characteristic of how bitcoin is
>>> developed which differs in some ways from how other open source software is
>>> developed -- although it remains the same in most other ways.
>>>
>>> Changes to the non-consensus sections of Bitcoin Core tend to get
>>> merged when there are a few reviews, tests, and ACKs from recognized
>>> developers, there are no outstanding objections, and the maintainer doing
>>> the merge makes a subjective judgement that the code is ready.
>>>
>>> Consensus-changes, on the other hand, get merged into Bitcoin Core only
>>> after the above criteria are met AND an extremely long discussion period
>>> that has given all the relevant stakeholders a chance to comment, and no
>>> significant objections remain. Consensus-code changes are unanimous. They
>>> must be.
>>>
>>> The sort of process that exists in standards bodies for example, with
>>> working groups and formal voting procedures, has no place where changes
>>> define the nature and validity of other people's money. Who has the right
>>> to reach into your pocket and define how you can or cannot spend your
>>> coins? The premise of bitcoin is that no one has that right, yet that is
>>> very much what we do when consensus code changes are made. That is why when
>>> we make a change to the rules governing the nature of bitcoin, we must make
>>> sure that everyone is made aware of the change and consents to it.
>>>
>>> Everyone. Does this work? Does this scale? So far, it does.
>>> Uncontroversial changes, such as BIP 66, are deployed without issue. Every
>>> indication is that BIP 66 will complete deployment in the very near future,
>>> and we intend to repeat this process for more interesting changes such as
>>> BIP65: CHECKLOCKTIMEVERIFY.
>>>
>>> This isn't about no one stepping forward to be the "decider." This is
>>> about no one having the right to decide these things on the behalf of
>>> others. If a contentious change is proposed and not accepted by the process
>>> of consensus, that is because the process is doing its job at rejecting
>>> controversial changes. It has nothing to do with personality, and
>>> everything to do with the nature of bitcoin itself.
>>>
>>>
>>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin < <milly at bitcoins.info>
>>> milly at bitcoins.info> wrote:
>>>
>>>> I have seen this question asked many times. Most developers become
>>>> defensive and they usually give a very vague 1-sentence answer when this
>>>> question is asked. It seems to be it is based on personalities rather than
>>>> any kind of definable process. To have that discussion the personalities
>>>> must be separated out and answers like "such-and-such wouldn't do that"
>>>> don't really do much to advance the discussion. Also, the incentive for
>>>> new developers to come in is that they will be paid by companies who want
>>>> to influence the code and this should be considered (some developers take
>>>> this statement as an insult when it is just a statement of the incentive
>>>> process).
>>>>
>>>> The other problem you are having is the lead developer does not want to
>>>> be a "decider" when, in fact, he is a very significant decider. While the
>>>> users have the ultimate choice in a practical sense the chief developer is
>>>> the "decider." Now people don't want to get him upset so nobody wants to
>>>> push the issue or fully define the process. Now you are left with a
>>>> broken, unwritten/unspoken process. While this type of thing may work with
>>>> a small group of developers businesses/investors looking in from the
>>>> outside will see this as a risk.
>>>>
>>>> Until you get passed all the personality-based arguments you are going
>>>> to have a tough time defining a real process.
>>>>
>>>> Russ
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>>>
>>>>> I would like to start a civil discussion on an undefined, or at least
>>>>> unwritten, portion of the BIP process. Who should get to vote on approval
>>>>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>>>>> these voters sufficient for approval? If not, then what is?
>>>>>
>>>>> Raystonn
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://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
>>
>>
>
> _______________________________________________
> 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/20150624/1e70f0ed/attachment-0001.html>

2023-06-07 17:40:04 CEST

- reply

📅 Original date posted:2015-06-24
📝 Original message:I'm sorry but this is absolutely not the case, Milly. The reason that
people get defensive is that we have a carefully constructed process that
does work (thank you very much!) and is well documented. We talk about it
quite often in fact as it is a defining characteristic of how bitcoin is
developed which differs in some ways from how other open source software is
developed -- although it remains the same in most other ways.
Changes to the non-consensus sections of Bitcoin Core tend to get merged
when there are a few reviews, tests, and ACKs from recognized developers,
there are no outstanding objections, and the maintainer doing the merge
makes a subjective judgement that the code is ready.
Consensus-changes, on the other hand, get merged into Bitcoin Core only
after the above criteria are met AND an extremely long discussion period
that has given all the relevant stakeholders a chance to comment, and no
significant objections remain. Consensus-code changes are unanimous. They
must be.
The sort of process that exists in standards bodies for example, with
working groups and formal voting procedures, has no place where changes
define the nature and validity of other people's money. Who has the right
to reach into your pocket and define how you can or cannot spend your
coins? The premise of bitcoin is that no one has that right, yet that is
very much what we do when consensus code changes are made. That is why when
we make a change to the rules governing the nature of bitcoin, we must make
sure that everyone is made aware of the change and consents to it.
Everyone. Does this work? Does this scale? So far, it does. Uncontroversial
changes, such as BIP 66, are deployed without issue. Every indication is
that BIP 66 will complete deployment in the very near future, and we intend
to repeat this process for more interesting changes such as BIP65:
CHECKLOCKTIMEVERIFY.
This isn't about no one stepping forward to be the "decider." This is about
no one having the right to decide these things on the behalf of others. If
a contentious change is proposed and not accepted by the process of
consensus, that is because the process is doing its job at rejecting
controversial changes. It has nothing to do with personality, and
everything to do with the nature of bitcoin itself.
On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
> I have seen this question asked many times. Most developers become
> defensive and they usually give a very vague 1-sentence answer when this
> question is asked. It seems to be it is based on personalities rather than
> any kind of definable process. To have that discussion the personalities
> must be separated out and answers like "such-and-such wouldn't do that"
> don't really do much to advance the discussion. Also, the incentive for
> new developers to come in is that they will be paid by companies who want
> to influence the code and this should be considered (some developers take
> this statement as an insult when it is just a statement of the incentive
> process).
>
> The other problem you are having is the lead developer does not want to be
> a "decider" when, in fact, he is a very significant decider. While the
> users have the ultimate choice in a practical sense the chief developer is
> the "decider." Now people don't want to get him upset so nobody wants to
> push the issue or fully define the process. Now you are left with a
> broken, unwritten/unspoken process. While this type of thing may work with
> a small group of developers businesses/investors looking in from the
> outside will see this as a risk.
>
> Until you get passed all the personality-based arguments you are going to
> have a tough time defining a real process.
>
> Russ
>
>
>
>
>
>
> On 6/24/2015 7:41 PM, Raystonn wrote:
>
>> I would like to start a civil discussion on an undefined, or at least
>> unwritten, portion of the BIP process. Who should get to vote on approval
>> to commit a BIP implementation into Bitcoin Core? Is a simple majority of
>> these voters sufficient for approval? If not, then what is?
>>
>> Raystonn
>> _______________________________________________
>> 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/20150624/5488f38b/attachment-0001.html>

2023-06-07 17:39:44 CEST

- reply

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

2023-06-07 17:38:59 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson <andreas at petersson.at>
wrote:
> I have some experience here. If you are seriously suggesting these
> measures, you might as well kill retail transactions altogether.
>
> In practice, if a retail place starts to accept bitcoin they have a
> similar situation as with cash, only that the fraud potential is much
> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
>
> 0-conf concerns were never a problem in practice. except for 2-way atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them means
> excluding 99.9% of the potential users. so you might as well not do it.
>
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
>
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
>
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to sign
> > a double-spend.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/c2719e0f/attachment.html>

2023-06-07 17:38:41 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn <mike at plan99.net> wrote:
> The first issue is how are decisions made in Bitcoin Core? I struggle to
> explain this to others because I don't understand it myself. Is it a vote
> of people with commit access? Is it a 100% agreement of "core developers"
> and if so, who are these people? Is it "whoever reverts the change last"?
> Could I write down in a document a precise description of how decisions are
> made? No, and that's been a fairly frustrating problem for a long time.
>
There is a quote from United States Supreme Court Justice Potter Stewart to
describe his threshold test for obscenity which is relevant here: "I know
it when I see it."
It is hard certainly, and perhaps even impossible to write down a system of
rules that is used to resolve every dispute among core developers. But that
doesn't mean it isn't obvious to all the participants what is going on. If
a contentious change is proposed, and if after sufficient debate there are
still members of the technical community with reasoned, comprehensible
objections who are not merely being obstinate in the views -- a neutral
observer would agree that their concerns have not been met -- then there is
a lack of consensus.
If there was some sort of formal process however, the system wouldn't work.
Rules can be gamed, and if you add rules to a process then that process can
be gamed. Instead we all have a reasonable understanding of what "technical
consensus" is, and we all know it when we see it. Where we do not see it,
we do not proceed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/1adcf256/attachment.html>

2023-06-07 17:38:35 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> The whole point is getting out in front of the need, to prevent
> significant negative impact to users when blocks are consistently full.
>
> To do that, you need to (a) plan forward, in order to (b) set a hard fork
> date in the future.
>
Or alternatively, fix the reasons why users would have negative experiences
with full blocks, chiefly:
* Get safe forms of replace-by-fee and child-pays-for-parent finished and
in 0.12.
* Develop cross-platform libraries for managing micropayment channels,
and get wallet authors to adopt
* Use fidelity bonds, solvency proofs, and other tricks to minimize the
risk of already deployed off-chain solutions as an interim measure until:
* Deploy soft-fork changes for truly scalable solutions like Lightning
Network.
Not raising the block size limit does not mean doing nothing to solve the
problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/b7699ac6/attachment.html>

2023-06-07 17:38:13 CEST

- reply

📅 Original date posted:2015-06-15
📝 Original message:On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine <voisine at gmail.com> wrote:
> Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
> maintainers simply refuse to lift the 1Mb limit? No one wants to go that
> route. An alternate hard-fork proposal like BIP100 that gets consensus, or
> a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
> hell even some major changes to the non-consunsus code to make it
> adequately handle the situation when blocks fill up, and allow wallet
> software to continue working with a send-and-forget use pattern, any of
> these would be enough to avoid the need for an XT only hard-fork.
>
> So far BIP100 is the only one that seems to actually be getting any sort
> of momentum toward consensus, and it was proposed... 2 days ago? When the
> XT fork was proposed as a last resort, it was when the opponents were (to
> my understanding) suggesting we just let blocks fill up, and hopefully
> things would just work out on their own.
>
We are not reaching consensus about any proposal, Garzik's or otherwise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/8ccbaeef/attachment.html>

2023-06-07 17:37:27 CEST

- reply

📅 Original date posted:2015-06-12
📝 Original message:Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks, or conforming incentives among voters by opting
to be with the (slight) majority in order to minimize fees.
Wouldn't it in fact be simpler to use the dynamic block size adjustment
algorithm presented to the list a few weeks back, where the miner opts for
a larger block by sacrificing fees? In that way the users "vote" for larger
blocks by including sufficient fees to offset subsidy, but as it is an
economic incentives miners gain nothing by inflating the fees in their own
blocks.
On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete at petertodd.org> wrote:
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
>
> https://www.mail-archive.com/[email protected]/msg02323.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150612/89a6898b/attachment.html>

2023-06-07 17:36:42 CEST

- reply

📅 Original date posted:2015-06-06
📝 Original message:Certainly, but I would drop discussion of IsStandard or consensus rules.
On Jun 6, 2015 1:24 AM, "Wladimir J. van der Laan" <laanwj at gmail.com> wrote:
> On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:
> > Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
> > assurance contracts among other things. Sometimes the ordering is set by
> > the signing logic itself...
>
> But in that case (unconstrained) randomization can't be used either. This
> is posed as an alternative to randomization. So in that regard, the
> proposal still makes sense.
> I think this move to verifyable, deterministic methods where possible is
> good.
>
> Wladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150606/11ad8bc7/attachment.html>

2023-06-07 17:36:41 CEST

- reply

📅 Original date posted:2015-06-06
📝 Original message:Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
assurance contracts among other things. Sometimes the ordering is set by
the signing logic itself...
On Jun 5, 2015 9:43 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell <rusty at rustcorp.com.au>
> Discussions-To: "Bitcoin Dev" <bitcoin-development at lists.sourceforge.net>
> Status: Draft
> Type: Standards Track
> Created: 2015-06-06
>
> Abstract
>
> This BIP provides a canonical ordering of inputs and outputs when
> creating transactions.
>
> Motivation
>
> Most bitcoin wallet implementations randomize the outputs of
> transactions they create to avoid trivial linkage analysis (especially
> change outputs), however implementations have made mistakes in this area
> in the past.
>
> Using a canonical ordering has the same effect, but is simpler, more
> obvious if incorrect, and can eventually be enforced by IsStandard() and
> even a soft-fork to enforce it.
>
> Specification
>
> Inputs should be ordered like so:
> index (lower value first)
> txid (little endian order, lower byte first)
>
> Outputs should be ordered like so:
> amount (lower value first)
> script (starting from first byte, lower byte first, shorter wins)
>
> Rationale
>
> Any single wallet is already free to implement this, but if other
> wallets do not it would reduce privacy by making those transactions
> stand out. Thus a BIP is appropriate, especially if this were to
> become an IsStandard() rule once widely adopted.
>
> Because integers are fast to compare, they're sorted first, before the
> lexographical ordering.
>
> The other input fields do not influence the sort order, as any valid
> transactions cannot have two inputs with the same index and txid.
>
> Reference Implementation
>
> https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150605/12c1d6ed/attachment.html>

2023-06-07 17:36:26 CEST

- reply

📅 Original date posted:2015-06-01
📝 Original message:I have written a reference implementation and BIP draft for a soft-fork
change to the consensus-enforced behaviour of sequence numbers for the
purpose of supporting transaction replacement via per-input relative
lock-times. This proposal was previously discussed on the mailing list in
the following thread:
http://sourceforge.net/p/bitcoin/mailman/message/34146752/
In short summary, this proposal seeks to enable safe transaction
replacement by re-purposing the nSequence field of a transaction input to
be a consensus-enforced relative lock-time.
The advantages of this approach is that it makes use of the full range of
the 32-bit sequence number which until now has rarely been used for
anything other than a boolean control over absolute nLockTime, and it does
so in a way that is semantically compatible with the originally envisioned
use of sequence numbers for fast mempool transaction replacement.
The disadvantages are that external constraints often prevent the full
range of sequence numbers from being used when interpreted as a relative
lock-time, and re-purposing nSequence as a relative lock-time precludes its
use in other contexts. The latter point has been partially addressed by
having the relative lock-time semantics be enforced only if the
most-significant bit of nSequence is set. This preserves 31 bits for
alternative use when relative lock-times are not required.
The BIP draft can be found at the following gist:
https://gist.github.com/maaku/be15629fe64618b14f5a
The reference implementation is available at the following git repository:
https://github.com/maaku/bitcoin/tree/sequencenumbers
I request that the BIP editor please assign a BIP number for this work.
Sincerely,
Mark Friedenbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/14698846/attachment.html>

2023-06-07 17:34:33 CEST

- reply

📅 Original date posted:2015-05-26
📝 Original message:Please let's at least have some civility and decorum on this list.
On Tue, May 26, 2015 at 1:30 PM, <joliver at airmail.cc> wrote:
> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
> and you have big banks as clients. Shit like replace-by-fee and leading
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
>
> Peter Todd - 8930511 Canada Ltd.
> 1214-1423 Mississauga Valley Blvd.
> Mississauga ON L5A 4A5
> Canada
>
>
> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
>
> On 2015-05-26 00:10, Peter Todd wrote:
> > On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
> >> CPFP also solves it just fine.
> >
> > CPFP is a significantly more expensive way of paying fees than RBF,
> > particularly for the use-case of defragmenting outputs, with cost
> > savings ranging from 30% to 90%
> >
> >
> > Case 1: CPFP vs. RBF for increasing the fee on a single tx
> > ----------------------------------------------------------
> >
> > Creating an spending a P2PKH output uses 34 bytes of txout, and 148
> > bytes of txin, 182 bytes total.
> >
> > Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
> > Alice. This results in a 1in/2out transaction t1 that's 226 bytes in
> > size.
> > I forget to click on the "priority fee" option, so it goes out with the
> > minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
> > creating a new transaction t2 that's 192 bytes in size. I want to pay
> > 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
> > transaction fees.
> >
> > On the other hand, had I use RBF, my wallet would have simply
> > rebroadcast t1 with the change address decreased. The rules require you
> > to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the
> > new
> > fee level, or 218uBTC of fees in total.
> >
> > Cost savings: 48%
> >
> >
> > Case 2: Paying multiple recipients in succession
> > ------------------------------------------------
> >
> > Suppose that after I pay Alice, I also decide to pay Bob for his hard
> > work demonstrating cryptographic protocols. I need to create a new
> > transaction t2 spending t1's change address. Normally t2 would be
> > another 226 bytes in size, resulting in 226uBTC additional fees.
> >
> > With RBF on the other hand I can simply double-spend t1 with a
> > transaction paying both Alice and Bob. This new transaction is 260
> > bytes
> > in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
> > consumed broadcasting it, resulting in an additional 36uBTC of fees.
> >
> > Cost savings: 84%
> >
> >
> > Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
> > ----------------------------------------------------------------
> >
> > The above situation gets even worse with multisig. t1 in the multisig
> > case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
> > in fees. With RBF we rewrite t1 with an additional output, resulting in
> > a 399 byte transaction, with just 36uBTC in additional fees.
> >
> > Cost savings: 90%
> >
> >
> > Case 4: Dust defragmentation
> > ----------------------------
> >
> > My wallet has a two transaction outputs that it wants to combine into
> > one for the purpose of UTXO defragmentation. It broadcasts transaction
> > t1 with two inputs and one output, size 340 bytes, paying zero fees.
> >
> > Prior to the transaction confirming I find I need to spend those funds
> > for a priority transaction at the 1mBTC/KB fee level. This transaction,
> > t2a, has one input and two outputs, 226 bytes in size. However it needs
> > to pay fees for both transactions at once, resulting in a combined
> > total
> > fee of 556uBTC. If this situation happens frequently, defragmenting
> > UTXOs is likely to cost more in additional fees than it saves.
> >
> > With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
> > bytes in size, paying 374uBTC. Even better, if one of the two inputs is
> > sufficiently large to cover my costs I can doublespend t1 with a
> > 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
> >
> > Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
> > costs you more than you save
> >
> >
> ------------------------------------------------------------------------------
> > One dashboard for servers and applications across
> > Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable
> > Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150526/38c108d3/attachment.html>

2023-06-07 17:34:00 CEST

- reply

📅 Original date posted:2015-05-10
📝 Original message:Micropayment channels are not pie in the sky proposals. They work today on
Bitcoin as it is deployed without any changes. People just need to start
using them.
On May 10, 2015 11:03, "Owen Gunden" <ogunden at phauna.org> wrote:
> On 05/08/2015 11:36 PM, Gregory Maxwell wrote:
> > Another related point which has been tendered before but seems to have
> > been ignored is that changing how the size limit is computed can help
> > better align incentives and thus reduce risk. E.g. a major cost to the
> > network is the UTXO impact of transactions, but since the limit is blind
> > to UTXO impact a miner would gain less income if substantially factoring
> > UTXO impact into its fee calculations; and without fee impact users have
> > little reason to optimize their UTXO behavior.
>
> Along the lines of aligning incentives with a diversity of costs to a
> variety of network participants, I am curious about reactions to Justus'
> general approach:
>
>
> http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
>
> I realize it relies on pie-in-the-sky ideas like micropayment channels,
> but I wonder if it's a worthy long-term ideal direction for this stuff.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150510/531fe7c2/attachment.html>

2023-06-07 17:33:59 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:In a fee-dominated future, replace-by-fee is not an opt-in feature. When
you create a transaction, the wallet presents a range of fees that it
expects you might pay. It then signs copies of the transaction with spaced
fees from this interval and broadcasts the lowest fee first. In the user
interface, the transaction is shown with its transacted amount and the
approved fee range. All of the inputs used are placed on hold until the
transaction gets a confirmation. As time goes by and it looks like the
transaction is not getting accepted, successively higher fee versions are
released. You can opt-out and send a no-fee or base-fee-only transaction,
but that should not be the default.
On the receiving end, local policy controls how much fee should be spent
trying to obtain confirmations before alerting the user, if there are fees
available in the hot wallet to do this. The receiving wallet then adds its
own fees via a spend if it thinks insufficient fees were provided to get a
confirmation. Again, this should all be automated so long as there is a hot
wallet on the receiving end.
Is this more complicated than now, where blocks are not full and clients
generally don't have to worry about their transactions eventually
confirming? Yes, it is significantly more complicated. But such
complication is unavoidable. It is a simple fact that the block size cannot
increase so much as to cover every single use by every single person in the
world, so there is no getting around the reality that we will have to
transition into an economy where at least one side has to pay up for a
transaction to get confirmation, at all. We are going to have to deal with
this issue whether it is now at 1MB or later at 20MB. And frankly, it'll be
much easier to do now.
On Fri, May 8, 2015 at 4:15 PM, Aaron Voisine <voisine at gmail.com> wrote:
> That's fair, and we've implemented child-pays-for-parent for spending
> unconfirmed inputs in breadwallet. But what should the behavior be when
> those options aren't understood/implemented/used?
>
> My argument is that the less risky, more conservative default fallback
> behavior should be either non-propagation or delayed confirmation, which is
> generally what we have now, until we hit the block size limit. We still
> have lots of safe, non-controversial, easy to experiment with options to
> add fee pressure, causing users to economize on block space without
> resorting to dropping transactions after a prolonged delay.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach 
> wrote:
>
>> On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <voisine at gmail.com> wrote:
>>
>>> This is a clever way to tie block size to fees.
>>>
>>> I would just like to point out though that it still fundamentally is
>>> using hard block size limits to enforce scarcity. Transactions with below
>>> market fees will hang in limbo for days and fail, instead of failing
>>> immediately by not propagating, or seeing degraded, long confirmation times
>>> followed by eventual success.
>>>
>>
>> There are already solutions to this which are waiting to be deployed as
>> default policy to bitcoind, and need to be implemented in other clients:
>> replace-by-fee and child-pays-for-parent.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/5302db5a/attachment.html>

2023-06-07 17:33:58 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <voisine at gmail.com> wrote:
> This is a clever way to tie block size to fees.
>
> I would just like to point out though that it still fundamentally is using
> hard block size limits to enforce scarcity. Transactions with below market
> fees will hang in limbo for days and fail, instead of failing immediately
> by not propagating, or seeing degraded, long confirmation times followed by
> eventual success.
>
There are already solutions to this which are waiting to be deployed as
default policy to bitcoind, and need to be implemented in other clients:
replace-by-fee and child-pays-for-parent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/a030d88b/attachment.html>

2023-06-07 17:33:57 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:It is my professional opinion that raising the block size by merely
adjusting a constant without any sort of feedback mechanism would be a
dangerous and foolhardy thing to do. We are custodians of a multi-billion
dollar asset, and it falls upon us to weigh the consequences of our own
actions against the combined value of the entire bitcoin ecosystem. Ideally
we would take no action for which we are not absolutely certain of the
ramifications, with the information that can be made available to us. But
of course that is not always possible: there are unknown-unknowns, time
pressures, and known-unknowns where information has too high a marginal
cost. So where certainty is unobtainable, we must instead hedge against
unwanted outcomes.
The proposal to raise the block size now by redefining a constant carries
with it risk associated with infrastructure scaling, centralization
pressures, and delaying the necessary development of a constraint-based fee
economy. It also simply kicks the can down the road in settling these
issues because a larger but realistic hard limit must still exist, meaning
a future hard fork may still be required.
But whatever new hard limit is chosen, there is also a real possibility
that it may be too high. The standard response is that it is a soft-fork
change to impose a lower block size limit, which miners could do with a
minimal amount of coordination. This is however undermined by the
unfortunate reality that so many mining operations are absentee-run
businesses, or run by individuals without a strong background in bitcoin
protocol policy, or with interests which are not well aligned with other
users or holders of bitcoin. We cannot rely on miners being vigilant about
issues that develop, as they develop, or able to respond in the appropriate
fashion that someone with full domain knowledge and an objective
perspective would.
The alternative then is to have some sort of dynamic block size limit
controller, and ideally one which applies a cost to raising the block size
in some way the preserves the decentralization and/or long-term stability
features that we care about. I will now describe one such proposal:
* For each block, the miner is allowed to select a different difficulty
(nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
and this miner-selected difficulty is used for the proof of work check. In
addition to adjusting the hashcash target, selecting a different difficulty
also raises or lowers the maximum block size for that block by a function
of the difference in difficulty. So increasing the difficulty of the block
by an additional 25% raises the block limit for that block from 100% of the
current limit to 125%, and lowering the difficulty by 10% would also lower
the maximum block size for that block from 100% to 90% of the current
limit. For simplicity I will assume a linear identity transform as the
function, but a quadratic or other function with compounding marginal cost
may be preferred.
* The default maximum block size limit is then adjusted at regular
intervals. For simplicity I will assume an adjustment at the end of each
2016 block interval, at the same time that difficulty is adjusted, but
there is no reason these have to be aligned. The adjustment algorithm
itself is either the selection of the median, or perhaps some sort of
weighted average that respects the "middle majority." There would of course
be limits on how quickly the block size limit can adjusted in any one
period, just as there are min/max limits on the difficulty adjustment.
* To prevent perverse mining incentives, the original difficulty without
adjustment is used in the aggregate work calculations for selecting the
most-work chain, and the allowable miner-selected adjustment to difficulty
would have to be tightly constrained.
These rules create an incentive environment where raising the block size
has a real cost associated with it: a more difficult hashcash target for
the same subsidy reward. For rational miners that cost must be
counter-balanced by additional fees provided in the larger block. This
allows block size to increase, but only within the confines of a
self-supporting fee economy.
When the subsidy goes away or is reduced to an insignificant fraction of
the block reward, this incentive structure goes away. Hopefully at that
time we would have sufficient information to soft-fork set a hard block
size maximum. But in the mean time, the block size limit controller
constrains the maximum allowed block size to be within a range supported by
fees on the network, providing an emergency relief valve that we can be
assured will only be used at significant cost.
Mark Friedenbach
* There has over time been various discussions on the bitcointalk forums
about dynamically adjusting block size limits. The true origin of the idea
is unclear at this time (citations would be appreciated!) but a form of it
was implemented in Bytecoin / Monero using subsidy burning to increase the
block size. That approach has various limitations. These were corrected in
Greg Maxwell's suggestion to adjust the difficulty/nBits field directly,
which also has the added benefit of providing incentive for bidirectional
movement during the subsidy period. The description in this email and any
errors are my own.
On Fri, May 8, 2015 at 12:20 AM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> Between all the flames on this list, several ideas were raised that did
> not get much attention. I hereby resubmit these ideas for consideration and
> discussion.
>
> - Perhaps the hard block size limit should be a function of the actual
> block sizes over some trailing sampling period. For example, take the
> median block size among the most recent 2016 blocks and multiply it by 1.5.
> This allows Bitcoin to scale up gradually and organically, rather than
> having human beings guessing at what is an appropriate limit.
>
> - Perhaps the hard block size limit should be determined by a vote of the
> miners. Each miner could embed a desired block size limit in the coinbase
> transactions of the blocks it publishes. The effective hard block size
> limit would be that size having the greatest number of votes within a
> sliding window of most recent blocks.
>
> - Perhaps the hard block size limit should be a function of block-chain
> length, so that it can scale up smoothly rather than jumping immediately to
> 20 MB. This function could be linear (anticipating a breakdown of Moore's
> Law) or quadratic.
>
> I would be in support of any of the above, but I do not support Mike
> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the
> road without actually solving the problem, and it does so in a
> controversial (step function) way.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/ba1d33d5/attachment.html>

2023-06-07 17:32:30 CEST

- reply

📅 Original date posted:2015-04-16
📝 Original message:At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r" <s7r at sky-ip.org> wrote:
> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
>
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
>
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
>
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
>
>
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r" <s7r at sky-ip.org <mailto:s7r at sky-ip.org>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from all the
> >> transactions in the latest 1000 blocks are version 'n' mark all previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet software to
> > be changed.
> >
> > --
> > Pieter
> >
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> 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/20150416/17968d0a/attachment.html>

2023-06-07 17:21:54 CEST

- reply

📅 Original date posted:2014-05-21
📝 Original message:On 05/21/2014 10:10 AM, Wladimir wrote:
> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris at beams.io> wrote:
>> I'm personally happy to comply with this for any future commits, but wonder
>> if you've considered the arguments against commit signing [1]? Note
>> especially the reference therein to Linus' original negative opinion on
>> signed commits [2].
>
> Yes, I've read it. But would his alternative, signing tags, really
> help us more here?
Honest question: what would signed commits do to help us here anyway?
What's the problem being solved?
Unfortunately git places signatures in the history itself, so it's not
like we could use easily use signatures to indicate acceptance after
code review, like we could if we were using monotone for example. Git
just wasn't designed for a commit-signing workflow.

2023-06-07 17:18:15 CEST

- reply

📅 Original date posted:2014-04-09
📝 Original message:On 04/09/2014 09:09 AM, Tamas Blummer wrote:
> Yes, SPV is a sufficient API to a trusted node to build sophisticated
> features not offered by the core.
> SPV clients of the border router will build their own archive and
> indices based on their interest of the chain therefore the
> border router core does not need to store (and process) anything not
> needed for consensus, its memory
> or disk footprint would be as low as an optimal storage of UTXO.
Storing zero full blocks does nothing to aid the network.

2023-06-07 17:17:41 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:On 04/07/2014 12:20 PM, Tamas Blummer wrote:
> Validation has to be sequantial, but that step can be deferred until the
> blocks before a point are loaded and continous.
And how do you find those blocks?
I have a suggestion: have nodes advertise which range of full blocks
they possess, then you can perform synchronization from the adversed ranges!

2023-06-07 17:17:40 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:On 04/07/2014 12:00 PM, Tamas Blummer wrote:
> Once a single transaction in pruned in a block, the block is no longer
> eligible to be served to other nodes.
> Which transactions are pruned can be rather custom e.g. even depending
> on the wallet(s) of the node,
> therefore I guess it is more handy to return some bitmap of pruned/full
> blocks than ranges.
The point is that the node has decided not to prune transactions from
that block, so that it is capable of returning full blocks within that
range.

2023-06-07 17:17:38 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:Right now running a full-node on my home DSL connection (<1Mbps) makes
other internet activity periodically unresponsive. I think we've already
hit a point where resource requirements are pushing out casual users,
although of course we can't be certain that accounts for all lost nodes.
On 04/07/2014 08:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier <justusranvier at gmail.com> wrote:
>> 1. The resource requirements of a full node are moving beyond the
>> capabilities of casual users. This isn't inherently a problem - after
>> all most people don't grow their own food, tailor their own clothes, or
>> keep blacksmith tools handy in to forge their own horseshoes either.
>
> Right now running a full node consumes about $1 in disk space
> non-reoccurring and costs a couple cents in power per month.
>
> This isn't to say things are all ducky. But if you're going to say the
> resource requirements are beyond the capabilities of casual users I'm
> afraid I'm going to have to say: citation needed.
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> .
>

2023-06-07 17:17:38 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
> That is an implementation issue— mostly one that arises as an indirect
> consequence of not having headers first and the parallel fetch, not a
> requirements issue.
Oh, absolutely. But the question "why are people not running full
nodes?" has to do with the current implementation, not abstract
capabilities of a future version of the bitcoind code base.

2023-06-07 17:17:30 CEST

- reply

📅 Original date posted:2014-04-10
📝 Original message:On 04/10/2014 05:19 AM, Flavien Charlon wrote:
> By the way, padding doesn't solve the issue entirely (issuing 10 billion
> shares sill takes you 100 BTC, even with padding and 1 satoshi = 1
> share), so I am going for the solution where the asset quantity of every
> output is explicitly encoded in the OP_RETURN output. That way, whether
> you are issuing 1 share or 100 trillions, you never need to pay more
> than 540 satoshis.
At this point, I don't think what you are doing is even colored coins
anymore. You might want to look into Counterparty or Mastercoin.

2023-06-07 17:17:27 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:Flavien, capital is wealth or resources available for the stated purpose
of the company. These bitcoins represent nothing more than a speculative
floor owned by the investors, not the company.
On 04/07/2014 07:00 AM, Flavien Charlon wrote:
> Jorge, they'd have to be. Otherwise, assuming the price of the share
> goes low enough, you could buy a share of the company, melt the gold
> plate, and sell it for a profit. If the gold is part of the capital of
> the company, the cheapest a share can be is the price of the gold on
> which the stock certificate is printed.
>
> This is why I think the importance of padding with colored coins is
> overblown.
>
>
> On Mon, Apr 7, 2014 at 1:12 PM, Jorge Timón <jtimon at monetize.io
> <mailto:jtimon at monetize.io>> wrote:
>
> On 4/7/14, Flavien Charlon <flavien.charlon at coinprism.com
> <mailto:flavien.charlon at coinprism.com>> wrote:
> > Also those 54 BTC (actually 5.4 BTC if the dust is now 540
> satoshis) become
> > part of the capital of the company, and can always be recovered by
> > uncoloring the shares. It's an investment, not an expense, so I
> think it is
> > acceptable.
>
> This doesn't make much sense to me.
> If you print shares on gold plates instead of paper, is that gold
> "part of the capital of the company"? I don't think so.
>
>

2023-06-07 17:17:26 CEST

- reply

📅 Original date posted:2014-04-06
📝 Original message:On 04/06/2014 01:59 PM, Flavien Charlon wrote:
> Do you think this is the right approach?
No, I'm afraid it has significant flaws. The two chief flaws are (1)
there is absolutely no reason to include asset tagging information if it
is not validated - that just bloats the block chain, and (2) you
shouldn't be using fixed increments for share sizes either. It's not
future-proof as the minimum output size changes based on the minimum fee
(currently 540 satoshis, not 5,400, and it will float in the near
future). And needing a capital of 54 btc for a million shares is totally
unacceptable.
Flavien, I know that I've seen you on the Bitcoin-X mailing list, where
these issues have been mostly worked out:
https://groups.google.com/forum/#!forum/bitcoinx
Have you seen the padded order-based coloring scheme worked out here?
https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro
Kind regards,
Mark Friedenbach

2023-06-07 17:17:13 CEST

- reply

📅 Original date posted:2014-04-22
📝 Original message:Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
Unfortunately few of the alts ever figured this out.
On 04/22/2014 01:39 AM, Tamas Blummer wrote:
> Extra encoding for testnet is quite useless complexity in face of many
> alt chains.
> BIPS should be chain agnostic.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com

2023-06-07 17:17:13 CEST

- reply

📅 Original date posted:2014-04-22
📝 Original message:What I was saying is that while it may or may not make sense to have
separate prefixes for testnet, it makes no sense to have per-alt prefixes.
On 04/22/2014 08:49 AM, Tamas Blummer wrote:
> I use several test chains while testing my software, the official test
> net, a standalone net in house and even chains only created on the fly
> for unit tests. I found no use of distinguishing serialization of keys
> while using any of them.
>
> If you have some deep insights about why this is needed share it, as I
> am not goint to guess your valuable thoughts.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 22.04.2014, at 17:32, Mark Friedenbach <mailto:mark at monetize.io>> wrote:
>
>> Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
>> Unfortunately few of the alts ever figured this out.
>

2023-06-07 17:15:59 CEST

- reply

📅 Original date posted:2014-03-24
📝 Original message:On 03/24/2014 01:34 PM, Troy Benjegerdes wrote:
> I'm here because I want to sell corn for bitcoin, and I believe it will be
> more profitable for me to do that with a bitcoin-blockchain-based system
> in which I have the capability to audit the code that executes the trade.
A discussion over such a system would be on-topic. Indeed I have made my
own proposals for systems with that capability in the past:
http://sourceforge.net/p/bitcoin/mailman/message/31322676/
There's no reason to invoke alts however. There are ways where this can
be done within the bitcoin ecosystem, using bitcoins:
http://sourceforge.net/p/bitcoin/mailman/message/32108143/
> I think that's fair, so long as we limit bitcoin-development discussion to
> issues that are relevant to the owners of the hashrate and companies that
> pay developer salaries.
>
> What I'm asking for is some honesty that Bitcoin is a centralized system
> and to stop arguing technical points on the altar of distributed/decentralized
> whatever. It's pretty clear if you want decentralized you should go with
> altchains.
Bitcoin is not a centralized system, and neither is its development. I
don't even know how to respond to that. Bringing up altchains is a total
red herring.
This is *bitcoin*-development. Please don't make it have to become a
moderated mailing list.