Mark Friedenbach [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-06-18 to 2022-10-19
💬 Posted a total of 295 messages
📚 Participated in the following categories: Bitcoin-development, RFC, BIP proposal, BIP draft, bitcoin-dev, BIP-draft, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u

Profile Code

nprofile1qqspccwejk2fe0a0znmkw7zwze4aapju0wrc84a280c2r5q5kuxqq6gprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqed53kn

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u

Show more details

Last Notes

2023-06-09 12:48:35

- 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 12:45:08

- 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-09 12:43:55

- reply

📅 Original date posted:2015-08-10
📝 Original message:
I believe there may be a misconception in your understanding. Lightning as
implemented by Rusty uses the sequence number field of the transaction
format, but not as an increment-on-each-transaction sequence number in the
traditional sense. Rather, BIP 68 (
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) specifies a
new consensus rule by which the sequence number field can mandate a
required minimum age for each input, thereby achieving a relative
lock-time. Lightning uses these relative lock-times.
A sequence number of MAX_INT is allowed to confirm on the block chain in
the same block or later as its parent. A sequence number one less than that
cannot confirm any earlier than one block AFTER its parent. A sequence
number two less than MAX_INT requires two blocks to elapse, etc.
So let's say that you want a certain script pathway to only take effect 30
days after confirmation of the parent. You achieve this by checking in the
script that the sequence number of the spending transaction (the child) is
equal to MAX_INT - 4320 (= 144 * 30). In the case of a bidirectional
payment channel, this is a value that is ratcheted up (bringing the
confirmation delay down) each time the payment channel switches direction.
So for example, you might increment sequence number / decrement the time to
confirmation by 144 blocks (1 day) each time the payment channel switches
direction, regardless of the number of off-chain transactions that have
elapsed in-between.
On Mon, Aug 10, 2015 at 8:03 AM, Jeremy Rubin <jr at mit.edu> wrote:
> Hi! A couple questions about the use of sequence numbers in lightning.
> Please forgive me if these are somewhat rudimentary.
>
> 1) Can someone better outline what the race conditions are? It seems
> certain things time out w.r.t. the bitcoin blockchain height, which seems
> negative with respect to censorship vulnerability. How is this addressed?
> Section 9.5 of the paper seems unsatisfactory.
>
> 2) Using sequence numbers to select the right transaction to include is
> good, but it would seem to leak information about how many LN transactions
> took place, which could then make it meterable by external parties. (eg, a
> miner could make the fee for settling proportional to it). Perhaps
> incrementing by a random amount would alleviate the ability to reliably
> meter. Maybe it is good that this can be metered?
>
> Cheers,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
> _______________________________________________
> 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/20150810/6e33ee28/attachment.html>

2023-06-09 12:43:41

- reply

📅 Original date posted:2015-07-18
📝 Original message:
On Sat, Jul 18, 2015 at 9:19 AM, Nick ODell <nickodell at gmail.com> wrote:
> There doesn't seem to be any deployment timeline.
>
Welcome to bitcoin development.
At the moment we have only the capability to push out one soft fork vote at
a time. The uncontroversial aspects of BIP62 were rushed out as BIP66 in
response to an undisclosed vulnerability, as mentioned. I believe there is
consensus now that BIP65: CHECKLOCKTIMEVERIFY has higher deployment
priority, so it will be next. There is no deployment timeline for BIP62
because it is a low priority in this soft-fork logjam.
As to BIP62 being out of date, can you point to specific things? They'll
get fixed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150718/2d3ce21e/attachment.html>

2023-06-09 12:43:40

- reply

📅 Original date posted:2015-07-18
📝 Original message:
BIP62 is not in any way abandoned. It just takes time to implement such
broad changes and to be assured of their safety. BIP66 rushed a subset of
features that were necessary to close we pretty serious vulnerabilities
(details of that are forthcoming soon now that it has been deployed).
On Jul 18, 2015 08:15, "Nick ODell" <nickodell at gmail.com> wrote:
> I'm pretty sure that BIP62 is abandonded. At least, the PR based on it
> was never merged. BIP66 implements some of it, and rules 2-7 have been
> nonstandard for a while, but I don't think that rules 2-7 are enforced
> against new blocks.
>
> On Fri, Jul 17, 2015 at 2:19 AM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> > Hi all,
> >
> > http://ozlabs.org/~rusty/ln-deploy-draft-01.pdf
> >
> > I haven't had time to proofread this properly, nor check the
> > script examples. But wanted to post it before the weekend so you all
> > have something to chew on :)
> >
> > Cheers,
> > Rusty.
> > _______________________________________________
> > 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/20150718/d047d7b3/attachment.html>

2023-06-07 18:10:06

- 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 18:09:39

- reply

📅 Original date posted:2018-01-09
📝 Original message: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.
We've been down the route of templating new features, and have made mistakes. P2SH is a canonical example, which BIP 117 is fixing. P2SH only provides 80 bits of security to a multi-party construction. Had we been designing BIP 16 now we probably would have used double-SHA256 instead of RIPEMD160. I will also assert that had we been using single-use tail-call semantics *instead* of BIP 16, recognition of this limitation would have resulted in us immediately defining a longer '3...' address which used HASH256 instead, and we would have immediately benefited from the fix. Instead we had to wait years until segwit gave us the opportunity to fix it at the same time.
To take another example, in some ideal sense we probably shouldn't even be developing a programmable signature script framework. We should instead template a generic lightning-derived layer-2 protocol and use that for everything, including both payments (supporting cut-through) and payment channels for smart contracts. This may not be the majority technical opinion yet, but as someone working in this space I believe that's where we are headed: a single layer-2 protocol that's generic enough to use for all payment caching and smart contracts, while achieving a full anonymity set for all contracts, as closures look identical on the wire. Even if that's where things are headed, I hope it is clear that we are not yet at such a stage to standardize what that looks like. We still need many years of use of specialized lightning protocols and work to be done to make them more generic and applicable to other protocols.
I believe the situation to be similar with MAST. Even if we have a better idea of what the MAST constructions will look like, *nobody* uses MAST in production yet, and there are bound to be implementation issues in rolling it out, or unique variants we do not have the foresight to see now. As a concrete example, BIP 116 has been modified since the initial proposal to allow multiple branches to be proven at once from a single Merkle tree root. To be honest, I don't know exactly how this will be used. We were able to come up with a couple of examples to justify inclusion of the feature, but I anticipate that someone down the line will come up with an even more creative use. Maybe a payment channel that uses a single tree to simultaneously commit to both the policy script and a sequence number. Or something like that. If we provide a templated, special-cased MAST now before it sees wide use then we will be locking in the protocol that we anticipate people using without having any production experience or ecosystem-wide review. Frankly that strikes me as a poor engineering decision.
Finally, even if we had perfect foresight into how a feature will be used, which we don't, it is still the case that we would want to enable permission-less innovation with the generic construct, even if using it comes with a 40-byte or so witness hit. I make the argument for this in the "intuitive explanation of MAST" email I sent to this list back in September of last year. I will reproduce the argument below:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015028.html
The driving motivation for the tail-call and MBV proposals, and the reason they are presented and considered together is to enable Merklized Abstract Syntax Trees. However neither BIP actually defines a MAST template, except as an example use case of the primitive features. This is very much on purpose: it is the opinion of this author that new bitcoin consensus features should follow the UNIX philosophy as expressed by Peter Salus and Mike Gancarz and paraphrased by yours truly:
* Write features that do one thing and do it well.
* Write features to work together.
* Simple is beautiful.
By using modularity and composition of powerful but simple tools like MERKLEBRANCHVERIFY and single tail-call recursion to construct MAST we enable a complex and desirable feature while minimizing changes to the consensus code, review burden, and acquired technical debt.
The reusability of the underlying primitives also means that they can be combined with other modular features to support use cases other than vanilla MAST, or reused in series to work around various limits that might otherwise be imposed on a templated form of MAST. At the moment the chief utility of these proposals is the straightforward MAST script written above, but as primitives they do allow a few other use cases and also combine well with features in the pipeline or on
the drawing board. For example, in addition to MAST you can:
1. Use MERKLEBRANCHVERIFY alone to support honeypot bounties, as
discussed in the BIP.
2. Use a series of MERKLEBRANCHVERIFY opcodes to verify a branch with
split proofs to stay under script and witness push limitations.
3. Combine MERKLEBRANCHVERIFY with key aggregation to get
Wuille-Maxwell tree signatures which support arbitrary signing
policies using a single, aggregatable signature.
4. Combine tail-call execution semantics with CHECKSIGFROMSTACK to get
delegation and signature-time commitment to subscript policy.
5. Combine MERKLEBRANCHVERIFY with a Merkle proof prefix check opcode
and Lamport signature support to get reusable Lamport keys.
I believe these benefits and possible future expansions to be strong arguments in favor of extending bitcoin in the form of small, modular, incremental, and reusable changes that can be combined and used even in ways unforeseen even by their creators, creating a platform for unrestricted innovation.
The alternative approach of rigid templates achieves the stated goals, perhaps even with slightly better encoding efficiency, but at the cost of requiring workaround for each future innovation. P2SH is just such an example -- we couldn't even upgrade to 128-bit security without designing an entirely different implementation because of the limitations of template pattern matching.
> On Jan 9, 2018, at 11:21 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
>
> On Jan 9, 2018 13:41, "Mark Friedenbach via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> The use of the alt stack is a hack for segwit script version 0 which has the clean stack rule. Anticipated future improvements here are to switch to a witness script version, and a new segwit output version which supports native MAST to save an additional 40 or so witness bytes. Either approach would allow getting rid of the alt stack hack. They are not part of the proposal now because it is better to do things incrementally, and because we anticipate usage of MAST to better inform these less generic changes.
>
> If the goal is to introduce a native MAST output type later, what is gained by first having the tailcall semantics?
>
> As far as I can see, this proposal does not have any benefits over Johnson Lau's MAST idea [1]:
> * It is more compact, already giving us the space savings a native MAST version of the tail call semantics would bring.
> * It does not need to work around limitations of push size limits or cleanstack rules.
> * The implementation (of code I've seen) is easier to reason about, as it's just another case in VerifyScript (which you'd need for a native MAST output later too) without introducing jumps or loops inside EvalScript.
> * It can express the same, as even though the MBV opcode supports proving multiple elements simultaneously, I don't see a way to use that in the tail call. Every scenario that consists of some logic before deciding what the tail call is going to be can be rewritten to have that logic inside each of the branches, I believe.
> * It does not interfere with static analysis (see further).
> * Tail call semantics may be easier to extend in the future to enable semantics that are not compactly representable in either proposal right now, by allowing a single top-level script may invoke multiple subscripts, or recursion. However, those sound even riskier and harder to analyse to me, and I don't think there is sufficient evidence they're needed.
>
> Native MAST outputs would need a new witness script version, which your current proposal does indeed not need. However, I believe a new script version will be desirable for other reasons regardless (returning invalid opcodes to the pool of NOPs available for softforks, for example).
>
> I will make a strong assertion: static analyzing the number of opcodes and sigops gets us absolutely nothing. It is cargo cult safety engineering. No need to perpetuate it when it is now in the way.
>
> I'm not sure I agree here. While I'd like to see the separate execution limits go away, removing them entirely and complicating future ability to introduce unified costing towards weight of execution cost seems the wrong way to go.
>
> My reasoning is this: perhaps you can currently make an argument that the current weight limit is sufficient in preventing overly expensive block validation costs, due to a minimal ratio between script sizes and their execution cost. But such an argument needs to rely on assumptions about sighash caching and low per-opcode CPU time, which may change in the future. In my view, tail call semantics gratuitously remove or complicate the ability to reason about the executed code.
>
> One suggestion to reduce the impact of this is limiting the per-script execution to something proportional to the script size. However, I don't think that addresses all potential concerns about static analysis (for example, it doesn't easily let you prove all possible execution paths to a participant in a smart contract).
>
> Another idea that has been suggested on this list is to mark pushes of potentially executable code on the stack/witness explicitly. This would retain all ability to analyse, while still leaving the flexibility of future extensions to tail call execution. If tail call semantics are adopted, I strongly prefer an approach like that to blindly throwing out all limits and analysis.
>
> [1] https://github.com/jl2012/bips/blob/mast/bip-mast.mediawiki <https://github.com/jl2012/bips/blob/mast/bip-mast.mediawiki>
>
> Cheers,
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180110/030d4279/attachment-0001.html>

2023-06-07 18:09:38

- reply

📅 Original date posted:2018-01-09
📝 Original message:The use of the alt stack is a hack for segwit script version 0 which has the clean stack rule. Anticipated future improvements here are to switch to a witness script version, and a new segwit output version which supports native MAST to save an additional 40 or so witness bytes. Either approach would allow getting rid of the alt stack hack. They are not part of the proposal now because it is better to do things incrementally, and because we anticipate usage of MAST to better inform these less generic changes.
Your suggestion of “single blob on the stack” seems to be exactly this proposal afaict? Note the witness data needs to be passed separately because signatures can’t be included in that single blob if that blob is hashed and compared against something in the scriptPubKey.
The sigop and opcode limit drop can be justified with some back of the envelope calculations. Non-scriptPubKey scripts are fundamentally limited by blocksize/weight and the most damage you can do, as an adversary, is limited by space. The most expensive thing you can do check a signature. Our assumptions about block size safety are basically due to how much computation you can stuff in a block with checksigs — all the analysis there applies.
My suggestion is to limit the number of checksigs allowed in a script to size(script+witness)/64, but I wanted this to come up in review rather than complicate the code right off the bat.
I will make a strong assertion: static analyzing the number of opcodes and sigops gets us absolutely nothing. It is cargo cult safety engineering. No need to perpetuate it when it is now in the way.
Sent from my iPhone
> On Jan 9, 2018, at 8:22 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> I've just re-read BIP 117, and I'm concerned about its flexibility. It
> seems to be doing too much.
>
> The use of altstack is awkward, and makes me query this entire approach.
> I understand that CLEANSTACK painted us into a corner here :(
>
> The simplest implementation of tail recursion would be a single blob: if
> a single element is left on the altstack, pop and execute it. That
> seems trivial to specify. The treatment of concatenation seems like
> trying to run before we can walk.
>
> Note that if we restrict this for a specific tx version, we can gain
> experience first and get fancier later.
>
> BIP 117 also drops SIGOP and opcode limits. This requires more
> justification, in particular, measurements and bounds on execution
> times. If this analysis has been done, I'm not aware of it.
>
> We could restore statically analyzability by rules like so:
> 1. Only applied for tx version 3 segwit txs.
> 2. For version 3, top element of stack is counted for limits (perhaps
> with discount).
> 3. The blob popped off for tail recursion must be identical to that top
> element of the stack (ie. the one counted above).
>
> Again, future tx versions could drop such restrictions.
>
> Cheers,
> Rusty.

2023-06-07 18:06:37

- 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 18:06:35

- reply

📅 Original date posted:2017-09-29
📝 Original message:Only if your keys are online and the transaction is self-signed. It wouldn’t let you pre-sign a transaction for a third party to broadcast and have it clear at just the market rate in the future. Like a payment channel refund, for example.
> On Sep 28, 2017, at 7:17 PM, Nathan Wilcox via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
>> On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev wrote:
>> > I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a list of options with feerates and expected confirmation times from which to select. Indeed, in a world where users pay a lower fee if they paid more than necessary fee estimation could be more willing to overshoot and the UX around RBF and CPFP could be simplified greatly, but I'm not actually convinced that it would result in higher overall mining revenue.
>>
>> Note too that the fee users are willing to pay often changes over time.
>>
>> My OpenTimestamps service is a perfect example: getting a timestamp confirmed
>> within 10 minutes of the previous one has little value to me, but if the
>> previous completed timestamp was 24 hours ago I'm willing to pay significantly
>> more money because the time delay is getting significant enough to affect the
>> trustworthyness of the entire service. So the fee selection mechanism is
>> nothing more than a RBF-using loop that bumps the fee every time a block gets
>> mined w/o confirming my latest transaction.
>>
>> This kind of time sensitivity is probably true of a majority of Bitcoin
>> use-cases, with the caveat that often the slope will be negative eventually:
>> after a point in time completing the transaction has no value.
>>
>
> Wouldn't this RBF loop behave pretty much the same in the Monopolistic Price Mechanism? (I haven't grokked RSOP yet.)
>
> In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees and Monopolistic Price fees over time to express the time curve preference?
>
>
>> --
>> 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
>>
>
> _______________________________________________
> 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/20170928/acc90653/attachment.html>

2023-06-07 18:06:35

- 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 18:05:36

- reply

📅 Original date posted:2017-09-12
📝 Original message:On Sep 12, 2017, at 1:55 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
> This is ugly and actually broken, as different script path may
> require different number of stack items, so you don't know how many
> OP_TOALTSTACK do you need. Easier to just use a new witness version
DEPTH makes this relatively easy to do. Just repeat the following for
the maximum number of stack elements that might be used:
DEPTH 1SUB IF SWAP TOALTSTACK ENDIF
There are probably more compact alternatives.
Using a new script version is easier, but not faster. There's a number
of things that might be fixed in a v1 upgrade, and various design
decisions to sort out regarding specification of a witness version
(version in the witness rather than the scriptPubKey).
Tree signatures and MAST are immediately useful to many services,
however, and I would hate to delay usage by six months to a year or
more by serializing dependencies instead of doing them in parallel.
> Otherwise, one could attack relay and mining nodes by sending many
> small size txs with many sigops, forcing them to validate, and
> discard due to insufficient fees.
>
> Technically it might be ok if we commit the total validation cost
> (sigop + hashop + whatever) as the first witness stack item
That is what I'm suggesting. And yes, there are changes that would
have to be made to the p2p layer and transaction processing to handle
this safely. I'm arguing that the cost of doing so is worth it, and a
better path forward.
> Without the limit I think we would be DoS-ed to dead
4MB of secp256k1 signatures takes 10s to validate on my 5 year old
laptop (125,000 signatures, ignoring public keys and other things that
would consume space). That's much less than bad blocks that can be
constructed using other vulnerabilities.
> So to make it functionally comparable with your proposal, the
> IsMSV0Stack() function is not needed. The new 249-254 lines in
> interpreter.cpp could be removed. The new 1480-1519 lines could be
> replaced by a few lines copied from the existing P2WSH code. I can
> make a minimal version if you want to see how it looks like
That's alright, I don't think it's necessary to purposefully restrict
one to compare them head to head with the same features. They are
different proposals with different pros and cons.
Kind regards,
Mark Friedenbach

2023-06-07 18:05:35

- 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 18:05:34

- 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 18:04:56

- 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 18:01:49

- reply

📅 Original date posted:2017-05-30
📝 Original message:The 1MB classic block size is not redundant after segwit activation.
Segwit prevents the quadratic hashing problems, but only for segwit
outputs. The 1MB classic block size prevents quadratic hashing
problems from being any worse than they are today.
Mark
On Tue, May 30, 2017 at 6:27 AM, Jorge Timón via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Why not simply remove the (redundant after sw activation) 1 mb size
> limit check and increasing the weight limit without changing the
> discount or having 2 limits?
>
>
> On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing.
>>
>> I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM
>> growth, of which bandwidth seems the most constraining.
>>
>> - Erik
>>
>>
>> On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> In light of some recent discussions, I wrote up this BIP for a real 2 MB
>>> block
>>> size hardfork following Segwit BIP148 activation. This is not part of any
>>> agreement I am party to, nor anything of that sort. Just something to
>>> throw
>>> out there as a possible (and realistic) option.
>>>
>>> Note that I cannot recommend this to be adopted, since frankly 1 MB blocks
>>> really are still too large, and this blunt-style hardfork quite risky even
>>> with consensus. But if the community wishes to adopt (by unanimous
>>> consensus)
>>> a 2 MB block size hardfork, this is probably the best way to do it right
>>> now.
>>> The only possible way to improve on this IMO would be to integrate it into
>>> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size
>>> HF
>>> improvements).
>>>
>>> I have left Author blank, as I do not intend to personally champion this.
>>> Before it may be assigned a BIP number, someone else will need to step up
>>> to
>>> take on that role. Motivation and Rationale are blank because I do not
>>> personally think there is any legitimate rationale for such a hardfork at
>>> this
>>> time; if someone adopts this BIP, they should complete these sections. (I
>>> can
>>> push a git branch with the BIP text if someone wants to fork it.)
>>>
>>> <pre>
>>> BIP: ?
>>> Layer: Consensus (hard fork)
>>> Title: Post-segwit 2 MB block size hardfork
>>> Author: FIXME
>>> Comments-Summary: No comments yet.
>>> Comments-URI: ?
>>> Status: Draft
>>> Type: Standards Track
>>> Created: 2017-05-22
>>> License: BSD-2-Clause
>>> </pre>
>>>
>>> ==Abstract==
>>>
>>> Legacy Bitcoin transactions are given the witness discount, and a block
>>> size
>>> limit of 2 MB is imposed.
>>>
>>> ==Copyright==
>>>
>>> This BIP is licensed under the BSD 2-clause license.
>>>
>>> ==Specification==
>>>
>>> Upon activation, a block size limit of 2000000 bytes is enforced.
>>> The block weight limit remains at 4000000 WU.
>>>
>>> The calculation of block weight is modified:
>>> all witness data, including both scriptSig (used by pre-segwit inputs) and
>>> segwit witness data, is measured as 1 weight-unit (WU), while all other
>>> data
>>> in the block is measured as 4 WU.
>>>
>>> The witness commitment in the generation transaction is no longer
>>> required,
>>> and instead the txid merkle root in the block header is replaced with a
>>> hash
>>> of:
>>>
>>> 1. The witness reserved value.
>>> 2. The witness merkle root hash.
>>> 3. The transaction ID merkle root hash.
>>>
>>> The maximum size of a transaction stripped of witness data is limited to 1
>>> MB.
>>>
>>> ===Deployment===
>>>
>>> This BIP is deployed by flag day, in the block where the median-past time
>>> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).
>>>
>>> It is assumed that when this flag day has been reached, Segwit has been
>>> activated via BIP141 and/or BIP148.
>>>
>>> ==Motivation==
>>>
>>> FIXME
>>>
>>> ==Rationale==
>>>
>>> FIXME
>>>
>>> ==Backwards compatibility==
>>>
>>> This is a hardfork, and as such not backward compatible.
>>> It should not be deployed without consent of the entire Bitcoin community.
>>> Activation is scheduled for 18 months from the creation date of this BIP,
>>> intended to give 6 months to establish consensus, and 12 months for
>>> deployment.
>>>
>>> ==Reference implementation==
>>>
>>> FIXME
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

2023-06-07 18:00:12

- reply

📅 Original date posted:2017-04-15
📝 Original message:Greg,
If I understand correctly, the crux of your argument against BIP148 is that
it requires the segwit BIP9 activation flag to be set in every block after
Aug 1st, until segwit activates. This will cause miners which have not
upgrade and indicated support for BIP141 (the segwit BIP) to find their
blocks ignored by UASF nodes, at least for the month or two it takes to
activate segwit.
Isn't this however the entire point of BIP148? I understand if you object
to this, but let's be clear that this is a design requirement of the
proposal, not a technical oversight. The alternative you present (new BIP
bit) has the clear downside of not triggering BIP141 activation, and
therefore not enabling the new consensus rules on already deployed full
nodes. BIP148 is making an explicit choice to favor dragging along those
users which have upgraded to BIP141 support over those miners who have
failed to upgrade.
On an aside, I'm somewhat disappointed that you have decided to make a
public statement against the UASF proposal. Not because we disagree -- that
is fine -- but because any UASF must be a grassroots effort and
endorsements (or denouncements) detract from that.
Mark Friedenbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170415/af2462dc/attachment-0001.html>

2023-06-07 17:48:01

- reply

📅 Original date posted:2016-01-19
📝 Original message:Wouldn't this be entirely on topic for #bitcoin-dev? It's probably better
not to fragment the communication channels and associated infrastructure
(logs, bots, etc.)
On Tue, Jan 19, 2016 at 3:54 AM, Eric Lombrozo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello, folks.
>
> I wanted to let all of you know a new IRC channel has been created called
> #segwit-dev where we welcome all discussion pertaining to integrating and
> supporting segregated witness transactions in wallets as well as comments
> or suggestions for improvement to the spec. Please come join us. :)
>
>
> ——
> Eric
> _______________________________________________
> 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/20160119/8e206798/attachment.html>

2023-06-07 17:45:49

- reply

📅 Original date posted:2015-12-21
📝 Original message:I am fully in support of the plan laid out in "Capacity increases for the
bitcoin system".
This plan provides real benefit to the ecosystem in solving a number of
longstanding problems in bitcoin. It improves the scalability of bitcoin
considerably.
Furthermore it is time that we stop bikeshedding, start implementing, and
move forward, lest we lose more developers to the toxic atmosphere this
hard-fork debacle has created.
On Mon, Dec 21, 2015 at 12:33 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote:
> > On Mon, Dec 07, 2015 at 10:02:17PM +0000, Gregory Maxwell via
> bitcoin-dev wrote:
> >> TL;DR: I propose we work immediately towards the segwit 4MB block
> >> soft-fork which increases capacity and scalability, and recent speedups
> >> and incoming relay improvements make segwit a reasonable risk. BIP9
> >> and segwit will also make further improvements easier and faster to
> >> deploy. We’ll continue to set the stage for non-bandwidth-increase-based
> >> scaling, while building additional tools that would make bandwidth
> >> increases safer long term. Further work will prepare Bitcoin for further
> >> increases, which will become possible when justified, while also
> providing
> >> the groundwork to make them justifiable.
> >
> > Sounds good to me.
>
> Better late than never, let me comment on why I believe pursuing this plan
> is important.
>
> For months, the block size debate, and the apparent need for agreement on
> a hardfork has distracted from needed engineering work, fed the external
> impression that nothing is being done, and generally created a toxic
> environment to work in. It has affected my own productivity and health, and
> I do not think I am alone.
>
> I believe that soft-fork segwit can help us out of this deadlock and get
> us going again. It does not require the pervasive assumption that the
> entire world will simultaneously switch to new consensus rules like a
> hardfork does, while at the same time:
> * Give a short-term capacity bump
> * Show the world that scalability is being worked on
> * Actually improve scalability (as opposed to just scale) by reducing
> bandwidth/storage and indirectly improving the effectiveness of systems
> like Lightning.
> * Solve several unrelated problems at the same time (fraud proofs, script
> extensibility, malleability, ...).
>
> So I'd like to ask the community that we work towards this plan, as it
> allows to make progress without being forced to make a possibly divisive
> choice for one hardfork or another yet.
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151221/fa4c9349/attachment.html>

2023-06-07 17:45:08

- reply

📅 Original date posted:2015-11-25
📝 Original message:Looks like I'm the long dissenting voice here? As the originator of the
name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was
appropriately chosen and why the proposed alternatives don't stand up.
First, the names are purposefully chosen to illustrate what they do:
What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.
What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.
Second, the semantics are not limited to relative lock-time / maturity
only. They both leave open ranges with possible, but currently undefined
future consensus-enforced behavior. We don't know what sort of future
behavior these values might trigger, but the associated opcodes are generic
enough to handle them:
CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even
though such constraints have no meaning in Bitcoin.
CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand,
while checking only 17 of the available 39 bits of both the operand and the
nSequence. Indeed the most recent semantic change of CSV was justified in
part because it relaxes all constraints over the values of these bits
freeing them for other purposes in transaction validation and/or future
extensions of the opcode semantics.
Third, single-byte opcode space is limited. There are less than 10 such
opcodes left. Maybe space won't be so precious in a post-segwitness world,
but I don't want to presume that just yet.
As for the alternatives, they capture only the initial use case of
nSequence. My objection would relax if nSequence were renamed, but I think
that would be too disruptive and unnecessary. In any case, the imagined use
cases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways
of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY
was a hypothicated opcode that directly checked the minimum age of inputs
of a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other
hand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a
hypothicated opcode that would check a ficticious nRelativeLockTime field,
which does not exist. Again my objection would go away if we renamed
nSequence, but I actually think the nSequence name is better...
On Tue, Nov 24, 2015 at 2:30 AM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> BIP68 introduces relative lock-time semantics to part of the nSequence
> field leaving the majority of bits undefined for other future applications.
>
> BIP112 introduces opcode CHECKSEQUENCEVERIFY (OP_CSV) that is specifically
> limited to verifying transaction inputs according to BIP68's relative
> lock-time[1], yet the _name_ OP_CSV is much boarder than that. We spent
> months limiting the number of bits used in BIP68 so they would be available
> for future use cases, thus we have acknowledged there will be completely
> different usecases that take advantage of unused nSequence bits.
>
> For this reason I believe the BIP112 should be renamed specifically for
> it's usecase, which is verifying the time/maturity of transaction inputs
> relative to their inclusion in a block.
>
> Suggestions:-
>
> CHECKMATURITYVERIFY
> RELATIVELOCKTIMEVERIFY
> RCHECKLOCKTIMEVERIFY
> RCLTV
>
> We could of course softfork additional meaning into OP_CSV each time we
> add new sequence number usecases, but that would become obscure and
> confusing. We have already shown there is no shortage of opcodes so it
> makes no sense to cram everything into one generic opcode.
>
> TL;DR: let's give BIP112 opcode a name that reflects it's actual usecase
> rather than focusing on the bitcoin internals.
>
> [1]
> https://github.com/bitcoin/bitcoin/pull/6564/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1223
>
> _______________________________________________
> 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/20151125/25ab2f56/attachment-0001.html>

2023-06-07 17:42:30

- reply

📅 Original date posted:2015-10-15
📝 Original message:Adam, there is really no justification I can see to lower the interblock
interval on the Bitcoin blockchain, primarily due to the effects of network
latency. Lowering the interblock interval and raising the block size are
not equal alternatives - you can always get more throughput in bitcoin by
raising the block size than by lowering the interblock time. And that's
without considering the effect shorter intervals would have on e.g. SPV
client bandwidth or sidechain connectivity proofs. So I find it very
unlikely that such granularity would ever be needed on the Bitcoin block
chain, although if were to happen then extra bits from nSequence could be
used in a soft-fork compatible way.
However it is true that various sidechains such as Liquid will have a much
shorter interblock interval than 10min, as well as customer demand for
protocols with shorter timeouts. It would be nice if such systems did not
HAVE to resort to complex bit shifting to support more precision, and if
protocols written for bitcoin could be reused on such systems with minimal
or no modification.
To that end, it might be preferable to move the flag bit indicating use of
seconds from bit 16 to bit 23 and (by convention only) reserve bits 17..22
to provide higher granularity in a sidechain environment. This keeps the
size of a stack push to 3 bytes while also keeping sufficient room for
high-order bits of relative lock-time in a sidechain that supports shorter
block intervals.
Another alternative is to put the units flag in the least significant bit,
which has the advantage of allowing both units of lock-time to make use of
1-2 byte pushes, but the disadvantage of making lock times of 64..127
2-bytes instead of 1-byte.
Thoughts?
On Thu, Oct 15, 2015 at 9:37 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Does that pre-judge that block interval would never change from
> 10mins? Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> > /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> > * applied to extract that lock-time from the sequence field. */
> > static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
> >
> > /* In order to use the same number of bits to encode roughly the
> > * same wall-clock duration, and because blocks are naturally
> > * limited to occur every 600s on average, the minimum granularity
> > * for time-based relative lock-time is fixed at 512 seconds.
> > * Converting from CTxIn::nSequence to seconds is performed by
> > * multiplying by 512 = 2^9, or equivalently shifting up by
> > * 9 bits. */
> > static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> Peter Todd <pete at petertodd.org> writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> >>> >> writes:
> >>> >> > However I don't think we've done a good job showing why we need to
> >>> >> > implement this feature via nSequence.
> >>> >>
> >>> >> It could be implemented in other ways, but nSequence is the neatest
> >>> >> and
> >>> >> most straightforward I've seen.
> >>> >>
> >>> >> - I'm not aware of any other (even vague) proposal for its use?
> >>> >> Enlighten?
> >>> >
> >>> > There's three that immediately come to mind:
> >>> >
> >>> > Gregory Maxwell has proposed it as a way of discouraging miners from
> >>> > reorging chains, by including some of the low-order bits of a
> previous
> >>> > block header in nSequence.
> >>> >
> >>> > A few people have proposed implementing proof-of-stake blocksize
> voting
> >>> > with nSequence.
> >>>
> >>> Excellent, thanks! It's good to have such ideas as a compass. PoS
> >>> voting seems like it won't be a problem in 5 bits.
> >>>
> >>> The "prevbits" idea would want more bits; naively 64 would be good, but
> >>> I think there are some tricks we can use to make 32 work OK. We would
> >>> have to then split between nLocktime (if available) and multiple
> >>> nSequence fields, and it would weaken it for some txs.
> >>>
> >>> There is one easy solution: change the BIP wording from:
> >>>
> >>> -For transactions with an nVersion of 2 or greater,
> >>> +For transactions with an nVersion of 2,
> >>>
> >>> And on every tx bump, we decide whether to keep this scheme (mempool
> >>> would enforce it always).
> >>>
> >>> Cheers,
> >>> Rusty.
> >>> _______________________________________________
> >>> 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/20151015/d0e24a27/attachment.html>

2023-06-07 17:34:17

- reply

📅 Original date posted:2015-08-07
📝 Original message:Actually I gave a cached answer earlier which on further review may need
updating. (Bad Mark!)
I presume by "what's more likely to matter is seconds" you are referencing
point of sale. As you mention yourself, lightning network or green address
style payment escrow obviates the need for short inter-block times.
But with lightning there is a danger of channels being exhausted in the
time between blocks, causing the need for new channels to be established.
So lightning does in fact benefit from moderately shorter inter-block
times, although how much of an issue this will be is anyone's guess now.
Still the first two points about larger SPV proofs and selfish mining still
hold true, which sets the bar particularly high for justifying more
frequent blocks.
On Fri, Aug 7, 2015 at 3:46 PM, Natanael <natanael.l at gmail.com> wrote:
> Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>:
> >
> > Mark,
> > It took you 3 minutes to respond to my e-mail. And I responded to you 4
> minutes later. If you had responded to me in 10 minutes, I would be of out
> the office and we wouldn't have this dialogue. So 5 minutes is a lot of
> time.
> >
> > Obviously this is not a technical response to the technical issues you
> argue. But "minutes" is a time scale we humans use to measure time very
> often.
>
> But what's more likely to matter is seconds. What you need then is some
> variant of multisignature notaries (Greenaddress.it, lightning network),
> where the combination of economic incentives and legal liability gives you
> the assurance of doublespend protection from the time of publication of the
> transaction to the first block confirmation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150807/dd0d22a0/attachment-0001.html>

2023-06-07 17:34:16

- reply

📅 Original date posted:2015-08-07
📝 Original message:Because halving the block interval comes with costs to SPV proofs (which
double the number of headers) and mining centralization (doubles the
selfish mining effect of latency) for the questionable benefit of a block
expectation time that is still measured in minutes, not seconds.
Doubling the block size is safer than halving the block interval, for the
same effect in aggregate transactions per second.
On Fri, Aug 7, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What would you do?
>
> a. Double the block size
> b. Reduce the block rate to a half (average 5 minute blocks)
>
> Suppose this is a one time hard fork. There no drastic technical problems
> with any of them: "SPV" mining and the relay network has shown that block
> propagation is not an issue for such as small change. Mining centralization
> won't radically change for a 2x adjustment.
>
> So what would be best for Bitcoin?
>
> I suspect some (if not most of you) would choose b. Because reducing the
> block interval saves us real time. Waiting 30 minutes for a 3-block
> confirmation is... such a long time! Time that we value. Time that
> sometimes we waste waiting. Time that makes a difference for us. Doubling
> the block size does not change the user perception of Bitcoin in any way.
>
> Then why most discussions go around doubling the block size?
>
> Each change require less than 20 lines of code (*) in the reference code,
> and minimum change in other wallets.
>
> Currently there is no idle mining hardware for hire, so the security of
> six 10-minute block confirmation is equivalent to the security of six
> 5-minute block confirmations, as described in Satoshi's paper (if there
> were 51% spare mining hardware for hire, then obviously hiring that
> hardware for 30 minutes would cost less than hiring it for 1 hour).
>
> Why we discuss a 2x block size increase and not a 1/2 block interval
> reduction? Aren't we Bitcoin users after all?
>
> Best regards,
> Sergio.
>
> (*) b requires increasing the transaction version number, to support the
> old nLockTime rate.
>
>
>
> _______________________________________________
> 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/5b262b5c/attachment.html>

2023-06-07 15:46:17

- reply

2023-06-07 15:46:16

- reply

2023-06-07 15:45:42

- 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" <mark at friedenbach.org> 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 15:40:55

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

2023-06-07 15:40:35

- 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 15:40:20

- reply

📅 Original date posted:2015-06-28
📝 Original message:Milly you are absolutely wrong as has been pointed out by numerous people
numerous times. Your idea of how bitcoin development decision making works
is demonstrably false. Please stop filling our inboxes with trolling
accusations, or else this will have to become a moderated list. And no one
wants that.
On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly at bitcoins.info> wrote:
> I really don't know who has power to do what behind the scenes. From
> what i understand, if push comes to shove, it is under the ultimate control
> of one person who can revoke commit privileges. Maybe I am wrong about
> that but the point is most people don't know for sure.
>
> You are correct about the people having the choice to download but the
> influence of the official release is way beyond the influence of any forked
> release. What that means in the real world is an open question and would
> be different depending upon the specific circumstances and difficult to
> predict. It is significant power to have control over the official release
> at the present time. If they did not have significant power people would
> not spend significant efforts lobbying them to make changes. Any new
> developers hired by companies will do so because they can influence over
> the official release since that is the only incentive.
>
> It seems to me that this block size fork is only the beginning of the
> issues that will arise over the coming years. Whatever powers the core
> maintainers have it is going to be exploited one way or another as time
> goes on. Maybe there are enough feedback mechanisms to protect against
> that, I don't really know.
>
> Russ
>
>
>
>
>
> On 6/28/2015 3:05 PM, Patrick Murck wrote:
>
> Wladimir has no more or less “power” to push change to the Bitcoin Core
> codebase than any other person with commit privileges to the GitHub repo.
> If I’m not mistaken there are 7 people with commit privileges and five of
> them are active. If Wladimir committed a change it could be reverted by any
> of the others. This is by design and ensures that changes will have reached
> some level of technical consensus before they are merged, among other
> things.
>
> Furthermore even assuming the Core Maintainer commits a change to
> Bitcoin Core (that isn’t reverted and that gets packaged up into the next
> code release) that still doesn’t push a change to the bitcoin network.
> There is no auto-update on Bitcoin Core so individuals and companies
> running Bitcoin Core software have to choose to upgrade. Further still,
> developers that maintain alternative implementations would have to decide
> to merge those changes to the codebase they are indepently maintaining (and
> their users would need to update, etc.).
>
> I understand why it might *seem* to be the case that the Core Maintainer
> is empowered to make changes to "teh Bitcoin" but the reality is that the
> Core Maintainer role is really about cat herding and project management of
> Bitcoin Core the open-source software project and not the bitcoin network.
> We’re lucky Wladimir has agreed to take on so much of the scut work to keep
> the project moving forward.
>
> The process might get ugly and inefficient but that’s the cost of having
> no wizard behind the curtain.
>
> -pm
>
> --
> Patrick Murck
>
> On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly at bitcoins.info) wrote:
>
> The core maintainer has always been in control of the consensus rules.
> Satoshi came up with the rules and put them in there. Since then any
> changes to any part of the code go through the core maintainer. It
> looks to me as if people are saying it somehow changed along the way
> because they don't want to hurt people's feeling, upset up, get them to
> quit, etc. Sure there are checks and balances and people don't have to
> use the main code base but if they change the consensus rules they are
> incompatible.
>
> The notion that because people can download different rules and run them
> is interesting from a theoretical perspective but that is constrained by
> the network effect. I can say the US government is not the "decider" of
> laws because I can vote them out, recall them, challenge things in
> court, or secede and start my own country. You can also say the
> judge/jury in a criminal court case is not a "decider" because the
> president can always issue a pardon. But those points are generally not
> useful in a practical sense.
>
> The issue about the developers is the tremendous influence they have to
> veto any changes. I don't have veto power yet I have more bitcoins than
> garzik says he has. The whole Bitcoin software development system is
> subject to attack from just a couple of people who have this veto
> power. With all the crying and moaning about centralization on this
> list I would think that would be a concern.
>
> Russ
>
>
>
> On 6/28/2015 11:35 AM, Jorge Timón wrote:
> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly at bitcoins.info>
> <milly at bitcoins.info> wrote:
> >> I never said something was approved by garzik added something after it
> was
> >> opposed. What I said was a proposal was made and 4 people commented on
> the
> >> Github. He then tweeted there was near universal approval before most
> >> people even heard about the subject. It was not controversial but i was
> >> pointing out the arrogance of some of the developers. He considers the
> >> entire universe of Bitcoin stakeholders to be a very small group of
> >> insiders, not the entire universe of Bitcoin users. Another thing I have
> >> seen on Github for bitcoin.org is how some the maintainers change the
> rules
> >> on the fly. Sometimes they say a proposal had no objections so it is
> >> approved. Other times they say a proposal has no support so it is
> rejected.
> > Ok, I misunderstood.
> > Well, the fact is that the number of capable reviewers is quite small.
> > If more companies hired and trained more developers to become bitcoin
> > core developers that situation could change, but that's where we are
> > now.
> >
> >> You are also trying to say that the core developers actually have little
> >> influence and are not "deciders" because anyone can fork the code. That
> has
> >> already been discussed at length and such an argument is faulty because
> >> there is a constraint that your software is incompatible with everyone
> else.
> > Only if you change the consensus rules (which are, in fact, a
> > relatively small part of the code).
> > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
> > with the replace by fee policy, libbitcoin also changes many
> > non-consensus things, there's code written in other languages...
> > There's multiple counter-examples to your claim of that argument being
> faulty.
> > Seriously, forking the project is just one click. You should try it
> > out like at least 9627 other people have done.
> > >From there, you can pay your own developers (if you don't know how to
> > code yourself) and maybe they're also fine being insulted by you as
> > part of the job.
> > What you still can't do is unilaterally change the consensus rules of
> > a running p2p consensus system, because you cannot force the current
> > users to run any software they don't want to run.
> >
> >> The issue is that there is no way right now to change the consensus
> rules
> >> except to go through the core maintainer unless you get everybody on the
> >> network to switch to your fork. People who keep repeating that the
> software
> >> development is "decentralized because you fork the code" without
> explaining
> >> the constraints are just cultists.
> > Please, stop the cultist crap. Maybe insulting people like that is how
> > you got people to call you a troll.
> > But, yes, you are right: there's no known mechanism for safely
> > deploying controversial changes to the consensus rules
> >
> >> The discussion has nothing to do with who has the position now and I
> never
> >> said he has "control over the consensus rules." The maintainer has a
> very
> >> large influence way beyond anyone else. As for your claim that I want
> >> someone hurt because I am explaining the process, that is ridiculous. If
> >> the Core maintainers did not have significant influence to change the
> >> consensus rules then everybody would not be spending all this time
> lobbying
> >> them to have them changed.
> > Well, if you don't think he has control over the consensus rules we're
> > advancing.
> > I think that was implied from some of your previous claims. He is no
> > "decider" on consensus changes.
> > Insisting on it can indeed get him hurt, so I'm happy that you're
> > taking that back (or clarifying that really wasn't your position).
> > Influence is very relative and not only core devs have "influence".
> > Maybe Andreas Antonopolous has more "influence" than I have because he
> > is a more public figure?
> > Well, that's fine I think. I don't see the point in discussing who has
> > how much influence.
> >
> >> The outside influences and stake of the developer is a relevant topic.
> The
> >> same types of things are discussed on this list all the time in the
> context
> >> of miners, users, merchants, and exchanges. Again, the developers try to
> >> place themselves on some kind of pedestal where they are the protectors
> and
> >> pure and everyone else (miners, users, merchants) are abusers, spammers,
> >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made an
> >> issue of how many bitcoins he holds and he made that issue in the same
> place
> >> where he announces many of the technical issues. It is very relevant
> that
> >> he has a minimal stake in Bitcoin holdings yet he goes around making
> major
> >> decisions about Bitcoin and trying to dictate who is allowed to
> participate
> >> in discussions. If a core developer has minimal stake in Bitcoin yet has
> >> major veto power over code change that is a problem.
> > Please, don't generalize. I don't think I put myself in any kind of
> pedestal.
> > That is insulting to me and many others (you may not even know and
> > you're insulting them).
> > And I think my Bitcoin holdings are completely irrelevant when judging
> > my contributions to the software: either they're good or not, and who
> > I am or how many Bitcoins I have at any given time shouldn't matter.
> > Again, nobody forces you to use our software, as said there's
> > alternatives (including forking the project right now).
> >
> >> You are correct that you cannot give power to any person over the
> Internet
> >> which is why some kind of process needs to be developed that does not
> >> involve trying to convince one person to make the changes or a system
> that
> >> depends on unwritten, ever-changing rules maintained by a handful of
> people.
> > Well, for now the process we have is seeking consensus, and although
> > our definition of "uncontroversial" is very vague, I think it is quite
> > obvious when a proposed change is not "uncontroversial" (like in the
> > block size debate).
> > It seems to me that any other "formal process" would imply
> > centralization in the decision making of the consensus rules (and from
> > there you only have to corrupt that centralized organization to
> > destroy Bitcoin).
> >
>
>
> _______________________________________________
> 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/2b0a55ee/attachment-0001.html>

2023-06-07 15:38:41

- 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 15:36:44

- reply

📅 Original date posted:2015-06-14
📝 Original message:There's another important use case which you mentioned Greg, that also
requires special exemption: compact commitments via mid-state compression.
The use case is an OP_RETURN output sorted last, whose last N bytes are a
commitment of some kind. A proof of the commitment can then use mid state
compression to elide the beginning of the transaction.
How do you make a special exemption for this category of outputs? I can't
think of a very clean way of doing so that doesn't require an ugly
advertising of sort-order exemptions.
The fact that we have two different existing use cases which conflict with
soft-fork enforcement, I'm quiet concerned that there are either other
things we aren't thinking of or haven't invented yet which would be
affected.
On Sun, Jun 14, 2015 at 7:33 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> > The softfork argument I find the most compelling, though it's tempting
> > to argue that every ordering use (including SIGHASH_SINGLE) is likely
> > a mistake.
>
> Oh.
>
> Hm.
>
> It is the case that the generalized sighash flag design I was thinking
> about was actually completely neutral about ordering, and yet still
> replaced SINGLE.
>
> I need to think a bit on that.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150614/cd07104d/attachment.html>

2023-06-07 15:36:26

- reply

📅 Original date posted:2015-06-02
📝 Original message:You are correct! I am maintaining a 'checksequenceverify' branch in my git
repository as well, an OP_RCLTV using sequence numbers:
https://github.com/maaku/bitcoin/tree/checksequenceverify
Most of the interesting use cases for relative lock-time require an RCLTV
opcode. What is interesting about this architecture is that it possible to
cleanly separate the relative lock-time (sequence numbers) from the RCLTV
opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
CLTV, the CSV opcode only checks transaction data and requires no
contextual knowledge about block headers, a weakness of the other RCLTV
proposals that violate the clean separation between libscript and
libconsensus. In a similar way, this BIP proposal only touches the
transaction validation logic without any impact to script.
I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
opcode and its enabling applications. But, well, one thing at a time.
On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <stephencalebmorse at gmail.com>
wrote:
> Hi Mark,
>
> Overall, I like this idea in every way except for one: unless I am missing
> something, we may still need an OP_RCLTV even with this being
> implemented.
>
> In use cases such as micropayment channels where the funds are locked up
> by multiple parties, the enforcement of the relative locktime can be done
> by the first-signing party. So, while your solution would probably work in
> cases like this, where multiple signing parties are involved, there may be
> other, seen or unforeseen, use cases that require putting the relative
> locktime right into the spending contract (the scriptPubKey itself). When
> there is only one signer, there's nothing that enforces using an nSequence
> and nVersion=2 that would prevent spending the output until a certain time.
>
> I hope this is received as constructive criticism, I do think this is an
> innovative idea. In my view, though, it seems to be less fully-featured
> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
> obviously that it saves transaction space by repurposing unused space, and
> would likely work for most cases where an OP_RCLTV would be needed.
>
> Best,
> Stephen
>
> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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/20150601/b2e1f6dc/attachment.html>

2023-06-07 15:33:58

- 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 15:24:03

- reply

📅 Original date posted:2014-07-17
📝 Original message:Can someone explain to these guys and the public why promising to limit
yourselves to *only* a 50% chance of successfully double-spending a 6
confirm transaction is still not acceptable?
q=0.4
z=0 P=1
z=1 P=0.828861
z=2 P=0.736403
z=3 P=0.664168
z=4 P=0.603401
z=5 P=0.550625
z=6 P=0.50398
z=7 P=0.462301
z=8 P=0.424782
z=9 P=0.390828
z=10 P=0.359976
z=11 P=0.331858
z=12 P=0.306167
z=13 P=0.282649
z=14 P=0.261083
z=15 P=0.24128
z=16 P=0.223076
z=17 P=0.206324
z=18 P=0.190896
z=19 P=0.176676
On 07/17/2014 06:59 AM, Melvin Carvalho wrote:
> I noticed this article today.
>
> GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit
>
> http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/
>
> Here's a quote from Satoshi when the mining arms race began:
>
> "We should have a gentleman’s agreement to postpone the GPU arms race as
> long as we can for the good of the network. It’s much easer to get new
> users up to speed if they don’t have to worry about GPU drivers and
> compatibility. It’s nice how anyone with just a CPU can compete fairly
> equally right now."
>
> Maybe outdated now, but I thought it was interesting.
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 15:11:43

- reply

📅 Original date posted:2014-01-15
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".
Say it like it is. This is the only suggestion so far that I really like.
No amount of finger wagging got people to stop using the block chain
for data storage, but news of the OP_RETURN change to relay rules in
0.9 got people to at least be less damaging in how they do it.
Having an officially named "reusable address" format won't stop people
from doing dumb things (e.g. vanity addresses), but at least maybe
they'll stop using traditional addresses for it.
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJS1yafAAoJEAdzVfsmodw40ccQAI0EFAyODzx7yXvlq9idctSd
xisH4xsOMlsW4lV7xReMnhQsCZ5A+qTMcCd7n7a0bveAxWg1srqBDONLXtHZfwiN
Px/TfoJKPt1oIHnCoyN8G6pcuHhbUbL3lV19sH02dGnM9Ystf9F4oeqwDTITYb5i
huqShMfaTdLEig76zPCLQcOT88deIWZgIxc3R4Do4aCDoyh//2LVZKfzQyEJzVms
njgxcVLVRlomofPW+a+60zm/iLsrbmDjwvWSH8IB4d5ik1aO3732pWgNz3X4HSLk
1s9hVEnpN3GLIWmCcPkbrE9RZtcitghjwrt/xOMKQaqprUuFW4COc0fsfzdLIRtP
bhrA/dnhVSxiUnjc7gLJBnB9+udVKdk2aTdJvSMB1PvhW9QKPjU/H4AW/yQYmism
rSr9imurbi3WosTewtwdcQD47SNS4ALMh//3MeHWOBUMEHP7Tki6i8qR+/xOK+vx
zMc4dnnTQsbgu9bKhrU7ia4eoe/UDvPoLck5cb2+PwYTInfdYBWn1ivbHO7S5ppP
R+/Tc8h3TyLLcPQmH0tpSX+C/YwvctiGsd+iXBRfSTe7o+0wLn8NcDNGi7QI0ipQ
iCHJup9K0FJqf9OuH9qYeaWht7cyuRJ5H4P/HNESGZaPSdTHDpStSmAzdtbBZOkI
qrFg7irL2+CxXwI4H6vC
=XEtz
-----END PGP SIGNATURE-----

2023-06-07 15:11:30

- reply

📅 Original date posted:2014-01-06
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/06/2014 10:13 AM, Peter Todd wrote:
> On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
>> I have written a Python-levelDB implementation of this UTXO
>> hashtree, which is currently being tested, and will be added to
>> Electrum servers.
>
> Along the lines of my recent post on blockchain data:
>
> Is it going to be possible to do partial prefix queries on that
> tree?
There's really two tree structures being talked about here. Correct me
if I'm wrong Thomas, but last time I looked at your code it was still
implementing a 256-way PATRICIA trie, correct? This structure lends
itself to indexing either scriptPubKey or H(scriptPubKey) with
approximately the same performance characteristics, and in the
"Ultimate blockchain compression" thread there is much debate about
which to use.
In the process of experimentation I've since moved from a 256-way
PATRICIA trie to a bitwise, non-level-compressed trie structure - what
I call proof-updatable trees in the BIP. These have the advantage of
allowing stateless application of one proof to another, and as
consequence enable mining & mempool operations without access to the
UTXO set, so long as proofs are initially provided in the transaction
& block wire format.
The "disadvantage" is that performance is closely tied to key length,
making H(scriptPubKey) the much more desirable option. I'm sure you
see that as an advantage, however :)
> Also have you considered creating per-block indexes of all
> scriptPubKeys, spent or unspent, queryable via the same partial
> prefix method?
This would be quite easy to do, separate from the UTXO structure but
using the same trie format.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSy0iFAAoJEAdzVfsmodw434MQAIA/fDYT7SfMtfLEgDQKhXCn
slRqFEx/HXjvgHHSYnbr9V+8LrGzNvT2ImebbV9ge8VlziAFNGIUq2EYhFs4kHWu
GVm9aL8Jj/27SvM0tRwr9n2XIifKOh2sVINAjbv+UwPv/O+cULU95/b53DEF6aqI
OWxioOR50TPe4t9AevAGVypNLm1DsyDdymhO9xyBN92xGTNj5QKL5hHG3kcsLIl1
7KaxO0w4UC2sdSGj9FeyH1b0zYg8FlzjJHc1CUshHwUwyYo8LRJtRypL5lrayERg
Er/kIGEDovcenNBW8G79l+8VKPfB/lMTssT2pDiQL+1e1fg46CIQxHSyap2JSFTE
jgleRk/+1NK/ZjOQ8dEBPZK3TE1WY3qlm/ekjG/8W5kXqcxzFBoAkeBNXuJ/8UMi
mKe+DTmbp0xnvLO1p+hpugXKfrQSpcFL+ZvJHlFS1lz7O1N3WvuDCNP9El+L6ueM
nFzjr1NTnX0z4vYtscI7qBKVqUrB7Z84c3O/lSYpw4Jilxl4trzV4cn7+AF7KWGM
ktR9JJeIoNcJ2Zx4EpRp6OSwhtLkWZyLpPnidQ2p6ev2ytXpTpGsW/i5XS2w57UD
2IG5E0Q7Xzvd58lI/YollWQcagVOZdyzYXa+wVZoFQ6gLF47andpUmtUJOhI7gxv
T/rWhPhkTMUn8TdvUcV/
=N9zM
-----END PGP SIGNATURE-----

2023-06-07 10:46:33

- reply

📅 Original date posted:2012-12-04
📝 Original message:Alan's UTxO meta-chain proposal becomes vastly easier to do now that
ultraprune is merged. That would allow the Satoshi client to know it's
wallet balance and operate with a >=SPV level of security during the
initial block download, and keep them on the path of becoming a full node.
If users can see their balances, send and receive transactions, and
otherwise go about their business (except for mining) during the initial
block download, would that not address your concerns?
IMHO the only time bitcoin.org should recommend a SPV-only client is when
it is dynamically when it is being accessed from a mobile device, but
that's a separate issue.
Mark
On Tue, Dec 4, 2012 at 9:46 AM, Mike Hearn <mike at plan99.net> wrote:
> At the moment if you visit bitcoin.org then you're recommended to
> download the full client. I think we all agree that at some point we
> need to start presenting users with something more like this:
>
>
> To get started, download wallet apps A or B.
>
> If you'd like to contribute your computing resources to the Bitcoin
> network and have a fast computer with an unfiltered internet
> connection, download:
>
> - for desktop machines, Bitcoin-Qt
> - for servers, bitcoind
>
>
>
> Obviously not that exact wording.
>
> I personally feel it's a bit early for this, but it's true that users
> are being turned away by the fact that they're pointed to Bitcoin-Qt
> by default, so having some kind of roadmap or plan for changing that
> would be good.
>
> I think MultiBit is maturing into a client that I'd feel comfortable
> recommending to end users who take the fast-start path, though it
> still has a few serious lacks (encrypted wallets aren't released yet,
> bloom filters will help performance a lot, needs to catch up with some
> newer features). But there doesn't have to be a one true client.
>
> The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> not convinced this is the best use of time, but if somebody steps up
> to do it, that could also work. MultiBit has some unique features that
> are quite useful like integrating charting and exchange rate feeds.
>
> What does everyone think on this?
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> 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/20121204/f061420b/attachment.html>