Btc Drak [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-10-15 to 2018-03-07
💬 Posted a total of 115 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP-draft, xxxx, BIP/Draft, BIP Proposal, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed

Profile Code

nprofile1qqs0mucsyn9q2dlds2xcjhwus5jl3tcz8uxujddgxfag5jtdp4aflqcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds5uuez8

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed

Show more details

Last Notes

2023-06-07 20:04:04

- reply

📅 Original date posted:2017-07-08
📝 Original message:I am utterly appalled by this proposal both technically, ethically, and by
the process which it has adopted. Hard forks require consensus from the
entire ecosystem in order to prevent a fork, funds loss, confusion and harm
to the robust guarantees of the Bitcoin system has thus far displayed.
I know this is a draft, but you are seeking reviews of a proposal that has
just a few weeks remaining before deployment (where "technical review" is
pointless because the is not actually open
<https://pastebin.com/kktB1kaw> unless
you are an approved member
<https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
making it totally unworkable and irresponsible. For example, exactly how
are other implementations supposed to adopt the BIP in such a short
timeframe? For all the talk of how important "alternative implementations"
are, how does this rash and rushed action promote an ecosystem of multiple
implementors? By encouraging fast upgrades, you are actually centralizing
the ecosystem even further.
The linked coded doesn't uniquely identify itself on the network by
user-agent, something all distinct implementations have done to date.
The draft BIP text looks like an afterthought and doesn't actually specify
the proposal in enough detail to implement from the text. By contrast for
example, BIP141 has a level of detail which allowed others to implement
segwit without looking at any reference code (which consequently results to
more confidence and testing of the specification all round). The Bitcoin
system has a market cap of over $40bn supported by a robust and reliable
network and your proposal is an offence to all Bitcoin has achieved because
due to it's the strong foundations.
I cannot not support this proposal in the current form and timeline, nor do
I support the coercion that has been used behind closed doors to try and
gain more support (not limited to, but including approaching company
investors to twist arms and veiled threats of blacklisting companies from
further funding/collaboration).
I think the best you can hope for this hard fork proposal is for it to be
quietly ignored.
On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
>
> This BIP and code satisfies the requests of a large part of the Bitcoin
> community for a moderate increase in the Bitcoin non-witness block space
> coupled with the activation of Segwit.
>
> You can find the BIP draft in the following link:
>
> https://github.com/SergioDemianLerner/BIPs/blob/
> master/BIP-draft-sergiolerner-segwit2x.mediawiki
>
> Reference source was kindly provided by the Segwit2x group.
>
> Best regards,
> Sergio.
>
> _______________________________________________
> 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/20170708/b3a2925a/attachment.html>

2023-06-07 19:56:57

- reply

📅 Original date posted:2017-03-05
📝 Original message:Nodes are by design not supposed to be identifiable in any way, including
persisting identities across IPs changes or when connecting over different
networks (e.g. clearnet/tor). Anything that makes Bitcoin less private is a
step backwards. Also absolute node count is pretty meaningless since only
fully validating nodes that participate in economic activity really matter.
As a side note, this should probably have started out as a bitcoin-discuss
post.
On Sat, Mar 4, 2017 at 4:04 PM, John Hardy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The discussion of UASF got me thinking about whether such a method might
> lead to sybil attacks, with new nodes created purely to inflate the node
> count for a particular implementation in an attempt at social engineering.
>
> I had an idea for an anonymous, opt-in, unique node identification
> mechanism to help counter this.
>
> This would give every node the opportunity to create a node
> ‘address’/unique identifier. This could even come in the form of a Bitcoin
> address.
>
> The node on first installation generates and backs up a private key. The
> corresponding public key becomes that node’s unique identifier. If the node
> switches to a new software version or a new IP, the identifier can remain
> constant if the node operator chooses.
>
> Asking a node for its identifier can be done by sending a message the
> command ‘identify’ and a challenge. The node can then respond with its
> unique identifier and a signature for the challenge to prove it. The node
> can also include what software it is running and sign this information so
> it can be verified as legitimate by third parties.
>
> Why would we do this?
>
> Well, it adds a small but very useful piece of data when compiling lists
> of active nodes.
>
> Any register of active nodes can have a record of when a node identifier
> was “first seen”, and how many IPs the same identifier has broadcast from.
> Also, crucially, we could see what software the node operator has been seen
> running historically.
>
> This information would make it easy to identify patterns. For example if a
> huge new group of nodes appeared on the network with no history for their
> identifier they could likely be dismissed as sybil attacks. If a huge
> number of nodes that had been reporting as Bitcoin Core for an extended
> period of time started switching to a rival implementation, this would add
> credibility but not certainty (keys could be traded), that the shift was
> more organic.
>
> This would be trivial to implement, is (to me?) non-controversial, and
> would give a way for a node to link itself to a pseudo-anonymous identity,
> but with the freedom to opt-out at any time.
>
> Keen to hear any thoughts?
>
> Thanks,
>
> John Hardy
>
> john at seebitcoin.com
>
>
> _______________________________________________
> 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/20170305/efa7c897/attachment.html>

2023-06-07 19:56:08

- reply

📅 Original date posted:2017-02-10
📝 Original message:Agreed, this thread is venturing somewhat out of scope for the list. Please
can we redirect philosophical discussion to another forum/list such as
bitcoin-discuss, which can be found at
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
Repost of the bitcoin-dev posting guidelines are:
- Posts must concern development of bitcoin protocol.
- Posts should be technical or academic in nature.
- Generally encouraged: patches, notification of pull requests, BIP
proposals, academic paper announcements. And discussions that follow.
- Generally discouraged: shower thoughts, wild speculation, jokes, +1s,
non-technical bitcoin issues, rehashing settled topics without new data,
moderation concerns.
- Detailed patch discussion generally better on a GitHub PR.
- Meta-discussion is better on bitcoin-discuss.
On Wed, Feb 8, 2017 at 8:13 PM, alp alp via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> >Only the majority needs to consent, though what is considered a majority
> varies depending on the context (95%, 75%, 51%). Nowhere does it say
> "everyone needs to agree".
>
> There's a pretty huge gap between 90% and nearly 100%. 90% excluding 10%
> only 7 times results in only 48% of the original base.
>
> >If a small dissenting minority can block all forward progress then
> bitcoin is no longer interesting.
>
> Your definition of forward may be different than other users.
>
> >Is that really the bitcoin that you want to be a part of?
>
> Yes, I chose Bitcoin because it relies on a strictly held consensus
> mechanism and not one that changes on the whims of the majority. We have
> tens of dozens of political currencies for that.
>
> >When the 1MB cap was implemented it was stated specifically that we
> could increase it when we needed it. The white paper even talks about
> scaling to huge capacity. Not sure where you got the idea that we all
> agreed to stay at 1MB forever, I certainly didn't. It was never stated or
> implied that we could change the coin cap later(please cite if I'm
> mistaken).
>
> The community has not agreed that it is needed at this time. Perhaps they
> will change their mind at some point in the future. We have also learned a
> great deal since the publication of the initial whitepaper, such as the
> unstable state without a backlog or subsidy. Fortunately, participation in
> this system is voluntary, and you are free to leave at any time.
>
> This seems to be venturing quite off topic, and perhaps would be better
> suited for the bitcoin-discuss list.
>
> On Wed, Feb 8, 2017 at 1:56 PM, Andrew Johnson <andrew.johnson83 at gmail.com
> > wrote:
>
>> If a small dissenting minority can block all forward progress then
>> bitcoin is no longer interesting. What an incredibly simple attack
>> vector...
>>
>> No need to break any cryptography, find a bug to exploit, build tens of
>> millions of dollars in mining hardware, spend lots of bitcoin on fees to
>> flood the network, or be clever or expend any valuable resources in any
>> way, shape, or form.
>>
>> Just convince(or pay, if you do want to expend some resources) a few
>> people(or make up a few online personas) to staunchly refuse to accept
>> anything at all and the entire system is stuck in 2013(when we first
>> started widely discussing a blocksize increase seriously).
>>
>> Is that really the bitcoin that you want to be a part of?
>>
>> When the 1MB cap was implemented it was stated specifically that we could
>> increase it when we needed it. The white paper even talks about scaling to
>> huge capacity. Not sure where you got the idea that we all agreed to stay
>> at 1MB forever, I certainly didn't. It was never stated or implied that we
>> could change the coin cap later(please cite if I'm mistaken).
>>
>>
>> On Feb 8, 2017 12:16 PM, "alp alp" <alp.bitcoin at gmail.com> wrote:
>>
>> Doing nothing is the rules we all agreed to. If those rules are to be
>> changed,nearly everyone will need to consent. The same rule applies to the
>> cap, we all agreed to 21m, and if someone wants to change that, nearly
>> everyone would need to agree.
>>
>>
>> On Feb 8, 2017 10:28 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
>> wrote:
>>
>> It is when you're talking about making a choice and 6.3x more people
>> prefer something else. Doing nothing is a choice as well.
>>
>> Put another way, if 10% supported increasing the 21M coin cap and 63%
>> were against, would you seriously consider doing it?
>>
>> On Feb 8, 2017 9:57 AM, "alp alp" <alp.bitcoin at gmail.com> wrote:
>>
>>> 10% is not a tiny minority.
>>>
>>> On Feb 8, 2017 9:51 AM, "Andrew Johnson" <andrew.johnson83 at gmail.com>
>>> wrote:
>>>
>>>> You're never going to reach 100% agreement, and stifling the network
>>>> literally forever to please a tiny minority is daft.
>>>>
>>>> On Feb 8, 2017 8:52 AM, "alp alp via bitcoin-dev" <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> 10% say literally never. That seems like a significant
>>>> disenfranchisement and lack of consensus.
>>>>
>>>> On Mon, Feb 6, 2017 at 2:25 PM, t. khan via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> On Mon, Feb 6, 2017 at 2:53 PM, Luke Dashjr <luke at dashjr.org> wrote:
>>>>>
>>>>>> On Monday, February 06, 2017 6:19:43 PM you wrote:
>>>>>> > >My BIP draft didn't make progress because the community opposes
>>>>>> any block
>>>>>> > >size increase hardfork ever.
>>>>>> >
>>>>>> > Luke, how do you know the community opposes that? Specifically, how
>>>>>> did you
>>>>>> > come to this conclusion?
>>>>>>
>>>>>> http://www.strawpoll.me/12228388/r
>>>>>
>>>>>
>>>>> That poll shows 63% of votes want a larger than 1 MB block by this
>>>>> summer. How do you go from that to "the community opposes any block
>>>>> increase ever"? It shows the exact opposite of that.
>>>>>
>>>>>
>>>>>> > >Your version doesn't address the current block size
>>>>>> > >issues (ie, the blocks being too large).
>>>>>> >
>>>>>> > Why do you think blocks are "too large"? Please cite some evidence.
>>>>>> I've
>>>>>> > asked this before and you ignored it, but an answer would be
>>>>>> helpful to the
>>>>>> > discussion.
>>>>>>
>>>>>> Full node count is far below the safe minimum of 85% of economic
>>>>>> activity.
>>>>>>
>>>>>
>>>>> Is this causing a problem now? If so, what?
>>>>>
>>>>>
>>>>>> Typically reasons given for people not using full nodes themselves
>>>>>> come down
>>>>>> to the high resource requirements caused by the block size.
>>>>>
>>>>>
>>>>> The reason people stop running nodes is because there's no incentive
>>>>> to counteract the resource costs. Attempting to solve this by making blocks
>>>>> *smaller* is like curing a disease by killing the patient. (Incentivizing
>>>>> full node operation would fix that problem.)
>>>>>
>>>>> - t.k.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20170210/f18dc28a/attachment.html>

2023-06-07 19:54:17

- reply

📅 Original date posted:2016-11-15
📝 Original message:I think this is already covered in the BIP text:-
"As of November 2016, the most recent of these changes (BIP 65,
enforced since December 2015) has nearly 50,000 blocks built on top of
it. The occurrence of such a reorg that would cause the activating
block to be disconnected would raise fundamental concerns about the
security assumptions of Bitcoin, a far bigger issue than any
non-backwards compatible change.
So while this proposal could theoretically result in a consensus
split, it is extremely unlikely, and in particular any such
circumstances would be sufficiently damaging to the Bitcoin network to
dwarf any concerns about the effects of this proposed change."
On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> NACK
>
> Horrible precedent (hardcoding rule changes based on the assumption that
> large forks indicate a catastrophic failure), extremely poor process
> (already shipped, now the discussion), and not even a material performance
> optimization (the checks are avoidable once activated until a sufficiently
> deep reorg deactivates them).
>
> e
>
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Recently Bitcoin Core merged a simplification to the consensus rules
> surrounding deployment of BIPs 34, 66, and 65
> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a
> minor one, I thought it was worth documenting the rationale in a BIP for
> posterity.
>
> Here's the abstract:
>
> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> signaling in block version numbers. Now that the chain has long since passed
> the blocks at which those consensus rules have triggered, we can (as a
> simplification and optimization) replace the trigger mechanism by caching
> the block heights at which those consensus rules became enforced.
>
> The full draft can be found here:
>
> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:54:07

- reply

📅 Original date posted:2016-10-16
📝 Original message:I can see how it looks but actually most of the underlying libraries have
already been adapted or are almost finished being adapted for segwit. Since
segwit is not live on mainnet, most are not released (either still in PR
form or merged to a development branch). As a software developer, I think
you can appreciate that libraries cant actually release a segwit supported
versions until segwit is released as final in 0.13.1. Obviously consumers
of the libraries cant update for segwit until the libraries are released -
you get the idea. I wouldn't be too concerned about the adoption chart,
it's just very difficult to reflect the actual state of affairs. For
example Trezor is marked as wip, but they have had an updated, but
unreleased firmware version for many months[1]. We are in the process of
planning a migration guide and updating the existing development notes[2].
Additionally, many companies are already planning to update their services
for segwit.
Regarding BIP9, it's purpose is to co-ordinate *miner upgrade* and
activation. The starttime delay is simply designed to avoid miners
signalling before the soft fork has been made available for general
release; so the starttime prevents unreleased software from setting the
version bit prematurely. The whole BIP9 state machine allows predictable
activation. Non mining full nodes are under no constraints to upgrade on a
specific schedule, which is by design of soft forks. Signalling will not
begin until the first diff retarget period after the starttime of 15th Nov.
Practically it means there will be a minimum of 4-6 weeks at the very least
before activation can happen.
[1] https://github.com/bitcoin-core/bitcoincore.org/pull/30#issu
ecomment-217329474
[2] https://bitcoincore.org/en/segwit_wallet_dev/
On Sun, Oct 16, 2016 at 7:20 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
> wrote:
> > Would I want anyone to lose money due to faulty wallets? Of course not.
> > By the same token, devs have had almost a year to tinker with SegWit and
> > make sure the wallet isn't so poorly written that it'll flame out when
> > SegWit comes along. It's not like this is some untested, mostly unknown
> > feature that's being slipped out at the last minute
>
> There have been objections to the way that SegWit has been implemented for
> a
> long time, some wallets are taking a "wait and see" approach. If you look
> at the page you linked[1], that is a very very sad state of affairs. The
> vast majority is not ready. Would be interesting to get a more up-to-date
> view.
> Wallets probably won't want to invest resources adding support for a
> feature
> that will never be activated. The fact that we have a much safer
> alternative
> in the form of Flexible Transactions may mean it will not get activated. We
> won't know until its actually locked in.
> Wallets may not act until its actually locked in either. And I think we
> should respect that.
>
> Even if all wallets support it (and thats a big if), they need to be rolled
> out and people need to actually download those updates.
> This takes time, 2 months after the lock-in of SegWit would be the minimum
> safe time for people to actually upgrade.
>
> 1) https://bitcoincore.org/en/segwit_adoption/
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161016/db56653c/attachment-0001.html>

2023-06-07 19:54:06

- reply

📅 Original date posted:2016-10-17
📝 Original message:This thread has strayed extensively off topic from the OP which asked a
simple question about BIP141 signalling start params.
Please move to another thread, or take more general discussion to
bitcoin-discuss.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161017/c9f09fb1/attachment.html>

2023-06-07 19:48:36

- reply

📅 Original date posted:2016-02-05
📝 Original message:On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
> https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
> Increase block size limit to 2,000,000 bytes.
> After 75% hashpower support then 28-day grace period.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
>
> Blog post walking through the code:
> http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
>
It's great to finally see a BIP, although seems strange to ask for feedback
after releasing binaries.
In any case, the issue isn't about "whether or not it is a good idea to
roll out a hard fork", the question has always been about how to do safe
hard fork deployment and what the technological requirements are for doing
so. Your BIP/blogs do not actually address any of this. 75% miner
signalling with a 28 day flag day thereafter gives virtually no time for
the entire ecosystem to migrate and is widely considered unsafe. It's
plainly obvious that an entire ecosystem of 5000 full nodes cannot be
prepared in a month.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160205/0c3d2ed8/attachment-0001.html>

2023-06-07 19:45:06

- reply

📅 Original date posted:2015-11-24
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151124/a775f63a/attachment.html>

2023-06-07 19:42:41

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 6:26 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> History has shown that for many decision making processes this doesn't
> work,
> and this argument has been made to Core.
> Until today this was essentially a rule that hurt the things that Mike was
> really passionate about.
> Today this hurts the things that some other devs are passionate about.
>
If you are referring to some of Mike's PRs that were either refused or
reverted, it was because they where substantial technical objections to
them. This isn't even in the same ballpark.
Surely you see the absurdity of arguing against soft forks after we
successfully used them already for BIP34 and BIP66?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/bc7c4a65/attachment.html>

2023-06-07 19:42:41

- reply

📅 Original date posted:2015-10-05
📝 Original message:You are absolutely right and this is something I have often unsuccessfully
tried to explain as "disruption strategies". The problem is that most
people in the technical community assume good faith at all times, which
plays right into the frame required for disruption.
However, I would like to challenge your assumption of point 1 that that by
Mike making a rabble, it somehow makes CLTV deployment controversial. His
arguments have been refuted.
Mike has not presented anything convincing and history actually shows that
ISM works, and we have learned how to make it even more streamlined. We
know ISM has consensus because miners have accepted ISM for past softfork
rollouts.
Simply making a noise does not make something controversial. When it is
controversial, it is obvious and plain to see.
On Mon, Oct 5, 2015 at 4:56 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not Mike's
> main intention. At least I perceive (and maybe others too) something else
> is happening.
>
> Let me try to clarify: the discussion has nothing to do with technical
> arguments. I generally like more hard forks than soft forks (but I won't
> explain why because this is not a technical thread), but for CLTV this is
> quite irrelevant (but I won't explain why..), and I want CLTV to be
> deployed asap.
>
> Mike's intention is to criticize the informal governance model of Bitcoin
> Core development and he has strategically pushed the discussion to a
> dead-end where the group either:
>
> 1) ignores him, which is against the established criteria that all
> technical objections coming from anyone must be addressed until that person
> agrees, so that a change can be uncontroversial. If the group moves forward
> with the change, then the "uncontroversial" criteria is violated and then
> credibility is lost. So a new governance model would be required for which
> the change is within the established rules.
>
> 2) respond to his technical objections one after the other, on never
> ending threads, bringing the project to a standstill.
>
> As I don't want 2) to happen, then 1) must happen, which is what Mike
> wants. I have nothing for or against Mike personally. I just think Mike
> Hearn has won this battle. But having a more formal decision making process
> may not be too bad for Bitcoin, maybe it can actually be good.
>
> Best regards
> from a non-developer to my dearest developer friends,
> Sergio.
>
>
> _______________________________________________
> 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/20151005/a541ef59/attachment.html>

2023-06-07 19:42:39

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 5:56 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> CLTV deployment is clearly controversial. Many developers other than me
> have noted that hard forks are cleaner, and have other desirable
> properties. I'm not the only one who sees a big question mark over soft
> forks.
>
No, that is not correct and you are distorting facts to fit your argument.
We have discussed the tradeoffs of each method in general, but that does
not make hard forks or soft forks controversial in an of itself.
There is technical consensus to roll out CLTV by ISM, and if somehow you
are right, it will come out during deployment in much the same way as your
recent attempt at rolling out a controversial hardfork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/45f8c2cb/attachment.html>

2023-06-07 19:42:39

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 6:33 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I also agree with Mike that Core's requirement for unanimous consensus
> results in development grid lock and should be revisited.
>
There is no development gridlock. Look at the IRC logs for core-dev; look
at the pull requests; look a the merge history: Development is vibrant.
Developers are very active. You are manufacturing a crisis convenient to
your narrative, but it is far from the actual reality on the ground.
Please desist from this intellectual dishonesty and toxicity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/4d591b1b/attachment.html>

2023-06-07 19:42:29

- reply

📅 Original date posted:2015-10-15
📝 Original message: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151015/04dcdf41/attachment.html>

2023-06-07 19:42:27

- reply

📅 Original date posted:2015-10-05
📝 Original message:Regarding the keeping nSequence for future expansion I believe this has
been covered in the specification section of BIP68[1]: For transaction
version >= 2, if the MSB of nSequence is unset, the field is interpreted as
relative locktime, otherwise no special consensus meaning is attached (and
thus free for repurposing in the future). Effectively if the MSB is set,
the remaining 31 bits (out of 32) are free.
Also please note the BIP112 text has been updated with several more
usecases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151006/47ce0e5c/attachment.html>

2023-06-07 19:41:30

- reply

📅 Original date posted:2015-09-28
📝 Original message:On Mon, Sep 28, 2015 at 12:40 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> There is no consensus. Now pick. Lose the requirement that everyone agree
> for consensus changes, and tell people you've done it. Change the spec. Or
> do nothing.
>
Of course there is good technical consensus for CLTV by IsSuperMajority()
in the same way as BIP66 was rolled out. I believe the only open question
is whether we have to account for XT's use of versionbits (because the
standard has not been finalised). One can take the view that it is a non
issue given the almost negligible number of BIP101 blocks, but it certainly
goes away if XT also merges BIP65/CLTV.
As for risks, I think we learned a lot from BIP66:
1. miners are now aware of the risks of SPV mining near activation and are
financially incentivised not to during that period.
2. As for SPV wallets need to handle awareness of the new blocks. BitcoinJ
can play a pivotal role: as far as I am aware if we'd thought about adding
handling to BitcoinJ before activation rather than after activation[1][2],
the SPV issues would have been mitigated for the vast majority who rely on
the library. To me, this particular issue highlights our collective failure
to communicate the necessity for additional SPV handling requirements and
other preparation the ecosystem should engage in during a soft fork. This
is something we should definitely add to the release notes for the next
soft fork and advertise widely. Certainly it MUST be well documented in the
BIP65 deployment section, which it is currently not.
Lastly your objections came across very strongly (at least to my
understanding) so I am curious: Peter stated Gavin is OK with adding CLTV
support to XT, and assuming that is the case, will you object to merging it
or similarly object to adding the necessary block handling to BitcoinJ?
[1]
https://github.com/bitcoinj/bitcoinj/commit/6f03669fbd6c368961a25dfd772751d1ca2a1b5b
[2]
https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11cef2dc0caa8263daa641fe118
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2d9c5e1d/attachment.html>

2023-06-07 19:41:26

- reply

📅 Original date posted:2015-09-27
📝 Original message:On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
> soft-fork with CSV using the nVersion bits mechanism.
>
> nVersion bits doesn't even have an implementation yet, nor has solid
> consensus been reached on the exact semantics of how nVersion bits
> should work.
Small correction, the suggestion is to aim to roll out CLTV+CSV together by
0.12 release, using IsSuperMajority() (or versionbits if it is ready by
then). If CSV is not ready by then, we'd just roll out CLTV.
However, the CSV related pull requests are ready for final review and if
that can happen soon I don't see why we wouldn't roll CLTV+CSV out together
before 0.12. A considerable amount of time, discussion and iterations have
occurred for the related PRs and I believe they are at the point of
consensus modulo final review before merging.
References:
Mempool-only sequence number constraint verification
https://github.com/bitcoin/bitcoin/pull/6312
Mempool-only CHECKSEQUENCEVERIFY
https://github.com/bitcoin/bitcoin/pull/6564
Mempool-only Median time-past as endpoint for lock-time calculations
https://github.com/bitcoin/bitcoin/pull/6566
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150927/81513026/attachment.html>

2023-06-07 19:41:09

- reply

📅 Original date posted:2015-09-23
📝 Original message:For anyone who missed the discussions of weak blocks, here are the Scaling
Bitcoin's transcripts:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
(under Network Propagation).
On Wed, Sep 23, 2015 at 4:43 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've been thinking about 'weak blocks' and SPV mining, and it seems to me
> weak blocks will make things better, not worse, if we improve the mining
> code a little bit.
>
> First: the idea of 'weak blocks' (hat tip to Rusty for the term) is for
> miners to pre-announce blocks that they're working on, before they've
> solved the proof-of-work puzzle. To prevent DoS attacks, assume that some
> amount of proof-of-work is done (hence the term 'weak block') to rate-limit
> how many 'weak block' messages are relayed across the network.
>
>
> Today, miners are incentivized to start mining an empty block as soon as
> they see a block with valid proof-of-work, because they want to spend as
> little time as possible mining a not-best chain.
>
> Imagine miners always pre-announce the blocks they're working on to their
> peers, and peers validate those 'weak blocks' as quickly as they are able.
>
> Because weak blocks are pre-validated, when a full-difficulty block based
> on a previously announced weak block is found, block propagation should be
> insanely fast-- basically, as fast as a single packet can be relayed across
> the network the whole network could be mining on the new block.
>
> I don't see any barrier to making accepting the full-difficulty block and
> CreateNewBlock() insanely fast, and if those operations take just a
> microsecond or three, miners will have an incentive to create blocks with
> fee-paying transactions that weren't in the last block, rather than mining
> empty blocks.
>
> .................
>
> A miner could try to avoid validation work by just taking a weak block
> announced by somebody else, replacing the coinbase and re-computing the
> merkle root, and then mining. They will be at a slight disadvantage to
> fully validating miners, though, because they WOULD have to mine empty
> blocks between the time a full block is found and a fully-validating miner
> announced their next weak block.
>
> .................
>
> Weak block announcements are great for the network; they give transaction
> creators a pretty good idea of whether or not their transactions are likely
> to be confirmed in the next block. And if we're smart about implementing
> them, they shouldn't increase bandwidth or CPU usage significantly, because
> all the weak blocks at a given point in time are likely to contain the same
> transactions.
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> 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/20150923/1d2d6730/attachment.html>

2023-06-07 19:41:02

- reply

📅 Original date posted:2015-09-23
📝 Original message:On Wed, Sep 23, 2015 at 12:01 PM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Will there be any agenda published before the meetings? If I'm really
> interested in the topics, I'll have some reasons to get up in the middle of
> the night.
>
The #bitcoin-dev IRC channel is logged at http://bitcoinstats.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/39e8b81b/attachment.html>

2023-06-07 19:40:52

- reply

📅 Original date posted:2015-09-18
📝 Original message:Urgh... Can we hardfork time? It's clearly in need of an upgrade...
On Fri, Sep 18, 2015 at 9:31 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Google Calendar is localized, but has an option to change the timezone
> > of an event, it just doesnt have UTC in its options. So, yes, we should
> > use something that observes DST in roughly the same way as everyone else
> > - CEST/PDT/EST/etc.
>
> uh. There is fairly little global consistency in DST usage. Lots of
> places do dst on different dates.
>
> So if it's in some DST timezone it's likely to move twice each change
> for some subset of the people who do it.
>
> E.g. europe and US end DST one week apart.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/09bbdbe3/attachment.html>

2023-06-07 19:40:51

- reply

📅 Original date posted:2015-09-18
📝 Original message:Google calendar is localised, so it doesn't matter. The problem with
quoting UTC anyway it the meeting times are going to change for those that
observe DST. It would be much better to quote an actual timezone of an
actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
example. Otherwise when the clocks change, what was a convenient meeting
time will become inconvenient for some.
On Fri, Sep 18, 2015 at 9:14 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Generally in favor, but for practical purposes can we select a timezone
> that is available in Google Calendar? It appears it does not directly
> support UTC...
>
> On 09/18/15 01:07, Wladimir J. van der Laan via bitcoin-dev wrote:
> > Hello,
> >
> > At Monday's code sprint we had a good idea to schedule a regular
> developer meeting in #bitcoin-dev.
> >
> > Attendance is of course voluntary, but it may be good to have a time
> that many people are expected to be present and current issues can be
> discussed.
> >
> > Any preference for days/times?
> >
> > What about e.g. every week 15:00-16:00 UTC on Thursday?
> >
> > Wladimir
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/c4455a41/attachment.html>

2023-06-07 19:40:45

- reply

📅 Original date posted:2015-09-18
📝 Original message:On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Btc Drak 於 2015-09-17 15:12 寫到:
>
>> Forgive me if I have missed the exact use-case, but this seems overly
>> complex. Surely fill-or-kill refers to getting a transaction confirmed
>> within a few confirms or to drop the tx from the mempool so it wont be
>> considered for inclusion anymore. As such, you could just repurpose a
>> small range of nLocktime such that a TX will be accepted into mempool
>> for a specific period before expiring.
>>
>
> What I'm describing is to implement fill-or-kill as consensus rule.
> Certainly, we could implement it at the P2P network level: everything is
> the same as I described, but the nLockTime2 and nKillTime are for reference
> only and tx validity depends only on the nLockTime. Benevolent miners
> should drop the tx after the suggested kill time but there is no guarantee
>
Sure, you can make the scheme I describe consensus based by adding the rule
tx is not valid to mine after expiry: this still keeps the simplicity I
described.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/d28eff3f/attachment-0001.html>

2023-06-07 19:40:40

- reply

📅 Original date posted:2015-09-16
📝 Original message:Where do we stand now on which sequencenumbers variation to use? We really
should make a decision now.
On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> So I've created 2 new repositories with changed rules regarding
> sequencenumbers:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers2
>
> This repository inverts (un-inverts?) the sequence number. nSequence=1
> means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1
> second relative lock-height. nSequence>=0x80000000 (most significant bit
> set) is not interpreted as a relative lock-time.
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers3
>
> This repository not only inverts the sequence number, but also interprets
> it as a fixed-point number. This allows up to 5 year relative lock times
> using blocks as units, and saves 12 low-order bits for future use. Or, up
> to about 2 year relative lock times using seconds as units, and saves 4
> bits for future use without second-level granularity. More bits could be
> recovered from time-based locktimes by choosing a higher granularity (a
> soft-fork change if done correctly).
>
> On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach 
> wrote:
>
>> To follow up on this, let's say that you want to be able to have up to 1
>> year relative lock-times. This choice is somewhat arbitrary and what I
>> would like some input on, but I'll come back to this point.
>>
>> * 1 bit is necessary to enable/disable relative lock-time.
>>
>> * 1 bit is necessary to indicate whether seconds vs blocks as the unit
>> of measurement.
>>
>> * 1 year of time with 1-second granularity requires 25 bits. However
>> since blocks occur at approximately 10 minute intervals on average, having
>> a relative lock-time significantly less than this interval doesn't make
>> much sense. A granularity of 256 seconds would be greater than the Nyquist
>> frequency and requires only 17 bits.
>>
>> * 1 year of blocks with 1-block granularity requires 16 bits.
>>
>> So time-based relative lock time requires about 19 bits, and block-based
>> relative lock-time requires about 18 bits. That leaves 13 or 14 bits for
>> other uses.
>>
>> Assuming a maximum of 1-year relative lock-times. But what is an
>> appropriate maximum to choose? The use cases I have considered have only
>> had lock times on the order of a few days to a month or so. However I would
>> feel uncomfortable going less than a year for a hard maximum, and am having
>> trouble thinking of any use case that would require more than a year of
>> lock-time. Can anyone else think of a use case that requires >1yr relative
>> lock-time?
>>
>> TL;DR
>>
>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach 
>> wrote:
>>
>>> A power of 2 would be far more efficient here. The key question is how
>>> long of a relative block time do you need? Figure out what the maximum
>>> should be ( I don't know what that would be, any ideas?) and then see how
>>> many bits you have left over.
>>> On Aug 23, 2015 7:23 PM, "Jorge Timón" <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the
>>>> > discussion has any thought been given to represent one block with more
>>>> > than one increment? This would leave additional space for future
>>>> > signaling, or allow, for example, higher resolution numbers for a
>>>> > sharechain commitement.
>>>>
>>>> No, I don't think anybody thought about this. I just explained this to
>>>> Pieter using "for example, 10 instead of 1".
>>>> He suggested 600 increments so that it is more similar to timestamps.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>
>
> _______________________________________________
> 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/20150916/bfdc2567/attachment-0001.html>

2023-06-07 19:40:18

- reply

📅 Original date posted:2015-09-15
📝 Original message:On Tue, Sep 15, 2015 at 4:26 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> The problem comes with the impact of an unfocused stream of refactors to
> key code.
>
> For example, there is much less long term developer impact if refactoring
> were _accelerated_, scheduled to be performed in a one-week sprint. There
> is a lot of breakage, yes, but after that week the average level of
> downstream patch breakage is significantly lower. A "rip the band-aid off
> quickly rather than slowly" approach.
>
My sentiments exactly...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150915/578098d2/attachment.html>

2023-06-07 19:40:15

- reply

📅 Original date posted:2015-09-15
📝 Original message:I also share a lot of Jeff's concerns about refactoring and have voiced
them several times on IRC and in private to Jorge, Wladamir and Greg. I
meant to do a write up but never got around to it. Jeff has quite
eloquently stated the various problems. I would like to share my thoughts
on the matter because we really do need to come up with a plan on how this
issue is dealt with.
Obviously, Bitcoin Core is quite tightly coupled at the moment and
definitely needs extensive modularisation. Such work will inevitably
require lots of bulk code moves and then finer refactoring. However, it
requires proper planning because there are lots of effects and consequences
for other people contributing to Core and also downstream projects relying
on Core:
1. Refactoring often causes other pull requests to diverge and require
rebasing. Continual refactoring can put PRs in "rebase hell" and puts a big
stress on contributors (many of whom are part time).
2. Version to version, Bitcoin Core changes significantly in structure. 0.9
to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This makes makes
it hard to follow release to release and the net result is less people
upgrade (especially think of miners trying to keep their patch sets working
while trying not to disrupt or risk their mining operations).
3. Continual refactoring increases risk: we're human, and mistakes will
slip through peer review. This is especially concerning with consensus
critical code and this makes it difficult to merge such refactoring often,
which of course exacerbates the problem.
The net negative consequence is it is harder to contribute to Core, harder
for the Core maintainers to merge and harder for downstream/dependent
projects/implementations to keep up.
Suggested Way Forward
---------------------------------
With the understanding that refactored code by definition must not change
behaviour. There are three major kinds of refactoring:
1. code moves (e.g. separating concerns into different files);
2. code style;
3. structural optimisation and consolidation (reducing LOC, separating
concerns, encapsulation etc).
Code moves(1) and CS(2) are easy to peer review and merge quickly. The
third kind(3) requires deeper analysis to ensure that while the code
changed, the behaviour (including any bugs) did not.
We must resist all temptation to fix bugs or tack on minor fixes and tweaks
during refactoring: pull requests should only be refactoring only, with no
net change to behaviour. Keeping discipline makes it much easier to verify
and peer review and this faster to merge.
With respect to Code moves and CS, I believe we should have a "refactoring
fortnight" where we so the bulk of code move-only refactoring plus CS where
necessary. This is by fat the most disruptive kind of change because it
widely affects other PRs mergeability. We should aim to get most of this
done in one go, so that it's not happening in dribs and drabs over months
and many releases. Once done, it gives everyone a good idea to the overall
new structure and where one can expect to find things in the future. The
idea here is to help orientation and not have to continuously hunt for
where things have moved to.
To be clear, I am strongly suggesting code move-only refactoring PRs not be
mixed with anything else. Same for CS changes. This makes the PRs extremely
easy to vet and thus quick to merge.
Towards this end, maybe there should be an IRC meeting to agree the initial
moves, then someone who has the stomach for it can get on and do it -
during that time, we do not merge anything else. We need to bite the bullet
and break the back out of code moves.
With regards to CS, I think we do need to get CS right, because a continual
dribble of CS changes also makes diffs between releases less easy to
follow. Much of CS checking can be automated by the continuous integration
so authors can get it right easily. It can be just like a Travis check.
With respect to the 3rd kind of refactoring, we need to set some standards
and goals and aim for some kind of consistency. Refactoring needs to fulfil
certain goals and criterion otherwise contributors will always find a
reason to fiddle over and over forever. Obvious targets here can be things
like proper encapsulation and separation of concerns.
Overall, refactoring should be merged quickly, but only on a schedule so it
doesn't cause major disruption to others.
Obviously the third kind of refactoring more complex and time consuming and
will need to occur over time, but it should happen in defined steps. As
Jeff said, one week a month, or maybe one month a release. In any case,
refactoring changes should be quickly accepted or rejected by the project
maintainer and not left hanging.
Finally, refactoring should *always* be uncontroversial because essentially
functionality is not changing. If functionality changes (e.g. you try to
sneak in a big fix or feature tweak "because it's small") the PR should be
rejected outright. Additionally, if we break down refactoring into the
three kinds stated above, peer review will be much more straightforward.
On Tue, Sep 15, 2015 at 5:10 AM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> [collating a private mail and a github issue comment, moving it to a
> better forum]
>
> On libconsensus
> ---------------
> In general there exists the reasonable goal to move consensus state
> and code to a specific, separate lib.
>
> To someone not closely reviewing the seemingly endless stream of
> libconsensus refactoring PRs, the 10,000 foot view is that there is a
> rather random stream of refactors that proceed in fits and starts
> without apparent plan or end other than a one sentence "isolate
> consensus state and code" summary.
>
> I am hoping that
> * There is some plan
> * We will not see a five year stream of random consensus code movement
> patches causing lots of downstream developer headaches.
>
> I read every code change in every pull request that comes into
> github/bitcoin/bitcoin with three exceptions:
> * consensus code movement changes - too big, too chaotic, too
> frequent, too unfocused, laziness guarantees others will inevitably
> ACK it without me.
> * some non-code changes (docs)
> * ignore 80% of the Qt changes
>
> As with any sort of refactoring, they are easy to prove correct, easy
> to reason, and therefore quick and easy to ACK and merge.
>
> Refactors however have a very real negative impact.
> bitcoin/bitcoin.git is not only the source tree in the universe.
> Software engineers at home, at startups, and at major companies are
> maintaining branches of their own.
>
> It is very very easy to fall into a trap where a project is merging
> lots of cosmetic changes and not seeing the downstream ripple effects.
> Several people complained to me at the conference about all the code
> movement changes breaking their own work, causing them to stay on
> older versions of bitcoin due to the effort required to rebase to each
> new release version - and I share those complaints.
>
> Complex code changes with longer development cycles than simple code
> movement patches keep breaking. It is very frustrating, and causes
> folks to get trapped between a rock and a hard place:
> - Trying to push non-trivial changes upstream is difficult, for normal
> and reasonable reasons (big important changes need review etc.).
> - Maintaining non-trivial changes out of tree is also painful, for the
> aforementioned reasons.
>
> Reasonable work languishes in constant-rebase hell, and incentivizes
> against keeping up with the latest tree.
>
>
> Aside from the refactor, libconsensus appears to be engineering in the
> dark. Where is any sort of plan? I have low standards - a photo of a
> whiteboard or youtube clip will do.
>
> The general goal is good. But we must not stray into unfocused
> engineering for a non-existent future library user.
>
> The higher priority must be given to having a source code base that
> maximizes the collective developers' ability to maintain The Router --
> the core bitcoin full node P2P engine.
>
> I recommend time-based bursts of code movement changes. See below;
> for example, just submit & merge code movement changes on the first
> week of every 2nd month. Code movement changes are easy to create
> from scratch once a concrete goal is known. The coding part is
> trivial and takes no time.
>
> As we saw in the Linux kernel - battle lessons hard learned - code
> movement and refactors have often unseen negative impact on downstream
> developers working on more complicated changes that have more positive
> impact to our developers and users.
>
>
> On Bitcoin development release cycles & process
> ------------------------------------------------------------------
>
> As I've outlined in the past, the Linux kernel maintenance phases
> address some of these problems. The merge window into git master
> opens for 1 week, a very chaotic week full of merging (and rebasing),
> and then the merge window closes. Several weeks follow as the "dust
> settles" -- testing, bug fixing, moving in parallel OOB with
> not-yet-ready development. Release candidates follow, then the
> release, then the cycle repeats.
>
> IMO a merge window approach fixes some of the issues with refactoring,
> as well as introduces some useful -developer discipline- into the
> development process. Bitcoin Core still needs rapid iteration --
> another failing of the current project -- and so something of a more
> rapid pace is needed:
> - 1st week of each month, merge changes. Lots of rebasing during this
> week.
> - remaining days of the month, test, bug fix
> - release at end of month
>
> If changes are not ready for merging, then so be it, they wait until
> next month's release. Some releases have major features, some
> releases are completely boring and offer little of note. That is the
> nature of time-based development iteration. It's like dollar cost
> averaging, a bit.
>
>
> And frankly, I would like to close all github pull requests that are
> not ready to merge That Week. I'm as guilty of this as any, but that
> stuff just languishes. Excluding a certain category of obvious-crap,
> pull requests tend to default to a state of either (a) rapid merging,
> (b) months-long issues/projects, (c) limbo.
>
> Under a more time-based approach, a better pull request process would be to
> * Only open pull requests if it's a bug fix, or the merge window is
> open and the change is ready to be merged in the developer's opinion.
> * Developers CC bitcoin-dev list to discuss Bitcoin Core-bound projects
> * Developers maintain and publish projects via their own git trees
> * Pull requests should be closed if unmerged after 7 days, unless it
> is an important bug fix etc.
>
> The problem with projects like libconsensus is that they can get
> unfocused and open ended. Code movement changes in particular are
> cheap to generate. It is low developer cost for the developer to
> iterate all the way to the end state, see what that looks like, and
> see if people like it. That end state is not something you would
> merge all in one go. I would likely stash that tree, and then start
> again, seek the most optimal and least disruptive set of refactors,
> and generate and merge those into bitcoin/bitcoin.git in a time-based,
> paced manner. Announce the pace ahead of time - "cosmetic stuff that
> breaks your patches will be merged 1st week of every second month"
>
> To underscore, the higher priority must be given to having a source
> code base and disciplined development process that maximizes the
> collective developers' ability to maintain The Router that maintains
> most of our network.
>
> Modularity, refactoring, cleaning up grotty code generates a deep
> seated happiness in many engineers. Field experience however shows
> refactoring is a never ending process which sometimes gets in the way
> of More Important Work.
> _______________________________________________
> 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/20150915/93989145/attachment-0001.html>

2023-06-07 19:40:03

- reply

📅 Original date posted:2015-09-16
📝 Original message:Rusty,
I think you've covered all the issues discussed now. +1 for submitting to
BIPs repo to get an official number.
Are you planning to write the implementation?
On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Those who've seen the original versionbits bip, this adds:
> 1) Percentage checking only on retarget period boundaries.
> 2) 1 retarget period between 95% and activation.
> 3) A stronger suggestion for timeout value selection.
>
> https://gist.github.com/rustyrussell/47eb08093373f71f87de
>
> And pasted below, de-formatted a little.
>
> Thanks,
> Rusty.
>
> BIP: ??
> Title: Version bits with timeout and delay
> Author: Pieter Wuille <pieter.wuille at gmail.com>, Peter Todd <
> pete at petertodd.org>, Greg Maxwell <greg at xiph.org>, Rusty Russell <
> rusty at rustcorp.com.au>
> Status: Draft
> Type: Informational Track
> Created: 2015-10-04
>
> ==Abstract==
>
> This document specifies a proposed change to the semantics of the
> 'version' field in Bitcoin blocks, allowing multiple backward-compatible
> changes (further called called "soft forks") being deployed in parallel. It
> relies on interpreting the version field as a bit vector, where each bit
> can be used to track an independent change. These are tallied each retarget
> period. Once the consensus change succeeds or times out, there is a
> "fallow" pause after which the bit can be reused for later changes.
>
> ==Motivation==
>
> BIP 34 introduced a mechanism for doing soft-forking changes without
> predefined flag timestamp (or flag block height), instead relying on
> measuring miner support indicated by a higher version number in block
> headers. As it relies on comparing version numbers as integers however, it
> only supports one single change being rolled out at once, requiring
> coordination between proposals, and does not allow for permanent rejection:
> as long as one soft fork is not fully rolled out, no future one can be
> scheduled.
>
> In addition, BIP 34 made the integer comparison (nVersion >= 2) a
> consensus rule after its 95% threshold was reached, removing 2^31 +2 values
> from the set of valid version numbers (all negative numbers, as nVersion is
> interpreted as a signed integer, as well as 0 and 1). This indicates
> another downside this approach: every upgrade permanently restricts the set
> of allowed nVersion field values. This approach was later reused in BIP 66,
> which further removed nVersion = 2 as valid option. As will be shown
> further, this is unnecessary.
>
> ==Specification==
>
> ===Mechanism===
>
> '''Bit flags'''
> We are permitting several independent soft forks to be deployed in
> parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is
> not currently in use for any other ongoing soft fork. Miners signal intent
> to enforce the new rules associated with the proposed soft fork by setting
> bit 1B in nVersion to 1 in their blocks.
>
> '''High bits'''
> The highest 3 bits are set to 001, so the range of actually possible
> nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two
> future upgrades for different mechanisms (top bits 010 and 011), while
> complying to the constraints set by BIP34 and BIP66. Having more than 29
> available bits for parallel soft forks does not add anything anyway, as the
> (nVersion >= 3) requirement already makes that impossible.
>
> '''States'''
> With every softfork proposal we associate a state BState, which begins
> at ''defined'', and can be ''locked-in'', ''activated'',
> or ''failed''. Transitions are considered after each
> retarget period.
>
> '''Soft Fork Support'''
> Software which supports the change should begin by setting B in all blocks
> mined until it is resolved.
>
> if (BState == defined) {
> SetBInBlock();
> }
>
> '''Success: Lock-in Threshold'''
> If bit B is set in 1916 (1512 on testnet) or more of the 2016 blocks
> within a retarget period, it is considered ''locked-in''. Miners should
> stop setting bit B.
>
> if (NextBlockHeight % 2016 == 0) {
> if (BState == defined && Previous2016BlocksCountB() >= 1916) {
> BState = locked-in;
> BActiveHeight = NextBlockHeight + 2016;
> }
> }
>
> '''Success: Activation Delay'''
> The consensus rules related to ''locked-in'' soft fork will be enforced in
> the second retarget period; ie. there is a one retarget period in
> which the remaining 5% can upgrade. At the that activation block and
> after, the bit B may be reused for a different soft fork.
>
> if (BState == locked-in && NextBlockHeight == BActiveHeight) {
> BState = activated;
> ApplyRulesForBFromNextBlock();
> /* B can be reused, immediately */
> }
>
> '''Failure: Timeout'''
> A soft fork proposal should include a ''timeout''. This is measured
> as the beginning of a calendar year as per this table (suggested
> three years from drafting the soft fork proposal):
>
> Timeout Year >= Seconds Timeout Year >= Seconds
> 2018 1514764800 2026 1767225600
> 2019 1546300800 2027 1798761600
> 2020 1577836800 2028 1830297600
> 2021 1609459200 2029 1861920000
> 2022 1640995200 2030 1893456000
> 2023 1672531200 2031 1924992000
> 2024 1704067200 2032 1956528000
> 2025 1735689600 2033 1988150400
>
> If the soft fork still not ''locked-in'' and the
> GetMedianTimePast() of a block following a retarget period is at or
> past this timeout, miners should cease setting this bit.
>
> if (NextBlockHeight % 2016 == 0) {
> if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
> BState = failed;
> }
> }
>
> After another retarget period (to allow detection of buggy miners),
> the bit may be reused.
>
> '''Warning system'''
> To support upgrade warnings, an extra "unknown upgrade" is tracked, using
> the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask
> will be non-zero whenever an unexpected bit is set in nVersion. Whenever
> lock-in for the unknown upgrade is detected, the software should warn
> loudly about the upcoming soft fork. It should warn even more loudly after
> the next retarget period.
>
> '''Forks'''
> It should be noted that the states are maintained along block chain
> branches, but may need recomputation when a reorganization happens.
>
> ===Support for future changes===
>
> The mechanism described above is very generic, and variations are possible
> for future soft forks. Here are some ideas that can be taken into account.
>
> '''Modified thresholds'''
> The 95% threshold (based on in BIP 34) does not have to be maintained for
> eternity, but changes should take the effect on the warning system into
> account. In particular, having a lock-in threshold that is incompatible
> with the one used for the warning system may have long-term effects, as the
> warning system cannot rely on a permanently detectable condition anymore.
>
> '''Conflicting soft forks'''
> At some point, two mutually exclusive soft forks may be proposed. The
> naive way to deal with this is to never create software that implements
> both, but that is a making a bet that at least one side is guaranteed to
> lose. Better would be to encode "soft fork X cannot be locked-in" as
> consensus rule for the conflicting soft fork - allowing software that
> supports both, but can never trigger conflicting changes.
>
> '''Multi-stage soft forks'''
> Soft forks right now are typically treated as booleans: they go from an
> inactive to an active state in blocks. Perhaps at some point there is
> demand for a change that has a larger number of stages, with additional
> validation rules that get enabled one by one. The above mechanism can be
> adapted to support this, by interpreting a combination of bits as an
> integer, rather than as isolated bits. The warning system is compatible
> with this, as (nVersion & ~nExpectedVersion) will always be non-zero for
> increasing integers.
>
> == Rationale ==
>
> The failure timeout allows eventual reuse of bits even if a soft fork was
> never activated, so it's clear that the new use of the bit refers to a
> new BIP. It's deliberately very course grained, to take into account
> reasonable development and deployment delays. There are unlikely to be
> enough failed proposals to cause a bit shortage.
>
> The fallow period at the conclusion of a soft fork attempt allows some
> detection of buggy clients, and allows time for warnings and software
> upgrades for successful soft forks.
> _______________________________________________
> 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/20150916/c96d62e3/attachment-0001.html>

2023-06-07 19:39:45

- reply

📅 Original date posted:2015-09-07
📝 Original message:I mailed the solution privately, but for the record he was using the
wrong build option which should have been --with-gui=no
On Mon, Sep 7, 2015 at 9:58 AM, Sriram Karra via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Your problem is it cannot find your Boost libs. Why exactly are you trying
> to build with a custom lib directory?
>
>
>
> On Sat, Sep 5, 2015 at 11:24 PM, LinuXperia via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi.
>>
>> I am trying to compile bitcoin core on my ubuntu Linux machine as follow:
>>
>> ./autogen.sh
>>
>> ./configure
>> CPPFLAGS="-I/media/linuxperia/mydata/Projects/bitcoi/depends/x86_64-unknown-linux-gnu/include/
>> -O2"
>> LDFLAGS="-L/media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/lib/"
>> --without-gui
>>
>> make
>>
>> but i am getting always this Build Error message here!
>> What i am doing wrong ?
>> How can i fix this build problem so i am able to run the Bitcoin-core Node
>> on my Machine ?
>>
>> Thanks in advance for your helpful solution tips!
>>
>> CXXLD bitcoind
>> libbitcoin_server.a(libbitcoin_server_a-init.o): In function
>> `boost::filesystem::path::path<boost::filesystem::directory_entry>(boost::filesystem::directory_entry
>> const&,
>> boost::enable_if<boost::filesystem::path_traits::is_pathable<boost::decay<boost::filesystem::directory_entry>::type>,
>> void>::type*)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/filesystem/path.hpp:140:
>> undefined reference to
>> `boost::filesystem::path_traits::dispatch(boost::filesystem::directory_entry
>> const&, std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >&)'
>> libbitcoin_util.a(libbitcoin_util_a-util.o): In function `GetNumCores()':
>> /media/linuxperia/mydata/Projects/bitcoin/src/util.cpp:825: undefined
>> reference to `boost::thread::physical_concurrency()'
>> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
>> `boost::program_options::detail::basic_config_file_iterator<char>::getline(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >&)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/program_options/detail/config_file.hpp:161:
>> undefined reference to
>> `boost::program_options::to_internal(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&)'
>> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
>> `boost::program_options::detail::basic_config_file_iterator<char>::basic_config_file_iterator(std::istream&,
>> std::set<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, std::less<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > >,
>> std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > > > const&, bool)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/program_options/detail/config_file.hpp:145:
>> undefined reference to
>> `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> >,
>> std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > > > const&, bool)'
>> libbitcoin_wallet.a(libbitcoin_wallet_a-walletdb.o): In function
>> `boost::filesystem::copy_file(boost::filesystem::path const&,
>> boost::filesystem::path const&, boost::filesystem::copy_option::enum_type)':
>>
>> /media/linuxperia/mydata/Projects/bitcoin/depends/x86_64-unknown-linux-gnu/include/boost/filesystem/operations.hpp:497:
>> undefined reference to
>> `boost::filesystem::detail::copy_file(boost::filesystem::path const&,
>> boost::filesystem::path const&, boost::filesystem::detail::copy_option,
>> boost::system::error_code*)'
>> collect2: error: ld returned 1 exit status
>> Makefile:2620: recipe for target 'bitcoind' failed
>> make[2]: *** [bitcoind] Error 1
>> make[2]: Leaving directory '/media/linuxperia/mydata/Projects/bitcoin/src'
>> Makefile:6559: recipe for target 'all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory '/media/linuxperia/mydata/Projects/bitcoin/src'
>> Makefile:626: recipe for target 'all-recursive' failed
>> make: *** [all-recursive] Error 1
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:39:39

- reply

📅 Original date posted:2015-09-07
📝 Original message:Sorry not to reply earlier. I have a rather long post. I've split it
into two sections, one explaining the background and secondly talking
very specifically about your proposal and possible areas to look at.
I think there's a key misunderstanding about BIPs and "who decides
what in Bitcoin". A BIP usually defines some problem and a solutions
or helps communicate proposals to the technical community. They are
sort of mini white papers on specific topics often with reference
implementations attached. They may be consensus critical, or not. The
process for getting a BIP published is fairly loose in that it really
just requires some discussion and relevance to Bitcoin regardless of
whether the proposal is something that would be accepted or used by
others in the ecosystem. The BIP editor is obviously going to filter
out obvious nonesense and that shouldn't be controversial but obvious
when you see it.
You need to separate out the idea of BIPs as is, and implementations
of BIPs in Bitcoin software (like Bitcoin Core).
Take BIP64 for example. It's a proposal that adds a service to nodes
allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
as a project has not implemented it but was instead implemented in XT
and is utilised by Lighthouse. So the BIP specification is there in
the BIPs repository. As far as the bitcoin ecosystem goes, only
Bitcoin XT and lighthouse utilise it so far.
BIP101 is another example, but one of a consensus critical proposal
that would change the Bitcoin protocol (i.e. requires a hard fork). It
was adopted by only the XT project and so far no other software. At
the time of writing miners have chosen not to run implementations of
BIP101.
You can see the BIPs authoring and publishing process is a separate
issue entirely to the implementation and acceptance by the Bitcoin
ecosystem.
For non-consensus critical proposals like BIP64, or maybe one relating
to privacy (how to order transaction output for example), you could
judge acceptance of the proposal by the number of software projects
that implement the proposal, and the number of users it impacts. If a
proposal is utilised by many projects, but not the few projects that
have the majority of users, one could not claim wide acceptance.
For consensus critical proposals like BIP66 (Strict DER encoding) this
BIP was implemented in at least two bitcoin software implementations.
Over 95% of miners adopted the proposal over a 4.5 month period. The
BIP became de facto accepted, and in fact, once 95% lock-in was
achieved, the BIP became Final by rights that the consensus rules for
the Bitcoin network had changed.
In the case of consensus critical proposals like that, you can only
write proposals, implement it in software and hope they are adopted.
Now where does the confusion arise? Well, Bitcoin Core is the de facto
reference implementation by virtue of having the largest technical
contributor base and the widest userbase of any Bitcoin full node
implementation. This is where I believe, the community get stuck in
their assumptions and is so obvious it may have been overlooked.
Consensus rule changes to Bitcoin Core are always documented as BIPs
so the exact details can be picked up by other software implementers
(if they so desire). Take CHECKLOCKTIMEVERIFY a new widely anticipated
opcode. The proposal implemented in Bitcoin Core and eventually
merged. Peter also authored BIP65 (required because without it, his
proposal could not be considered for Bitcoin Core).
It is not that BIP65 was somehow "accepted", in fact, as it stands,
BIP65 is still just a draft because while there is a BIP and a
reference implementation in Bitcoin Core, the consensus changes to the
Bitcoin protocol have not been proposed to the community (through a
soft fork), and thus acceptance is still only a possibility (although
acceptance is extremely likely because service providers are literally
chomping at the bit waiting for deployment).
Also I would like to note that it's only an internal rule of Bitcoin
Core that consensus rule changes require a formal BIP. It is not a
requirement laid down from the BIP gods. BIPs simply serve as a way to
communicate ideas and proposals. The community at large will decide if
a BIP becomes widely adopted or not. Of course, Bitcoin Core has a
major influence on this because they have the largest user base. It is
relevant to say the large userbase is not just a historical artefact
by virtue of being the first Bitcoin implementation. Bitcoin Core is
widely trusted by commercial users because of the high developer
count, wide technical expertise and relative security given knowing
that they will be supported with security and maintenance releases.
YOUR PROPOSAL
Getting back to your specific proposal. It seems to focus more on
getting BIPs accepted in the sense of published and missed the wider
picture. As I have detailed, getting published isnt a problem. Anyone
can make a proposal, so long as it's not obviously off topic or
nonsensical, there is no grounds to refuse to publish it.
Any part of your proposal which seems to infer governance of Bitcoin
is misplaced because it's not the place of BIPs. The Bitcoin Core
project is not the BIPs project and their rules are their own. They
are one implementation, and very influential one yes, but, not the one
true implementation to rule them all.
Where I do think the BIP-1 text falls down is with the workflow of
ACCEPTED/REJECTED because it does not really define who is accepting
and rejecting what and misses much of the reality of the process in
the real world. Given the purpose of BIPs is a formal way to
communicate technical proposals to the bitcoin community (i.e.
implementers and protocol consumers) the work flow needs to be
adjusted.
Anyone can submit a proposal and the state of the proposal can be
DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
it's a work in progress, but the proposal is "complete" when the
proposer is happy with the final text. Downstream implementers should
not attempt to write code (in my opinion) until the proposal has been
finalised by the authors. Only the author has the right to say when
their proposal is finished.
The states of Accepted / Rejected are easy for consensus critical
changes, especially once versionbits softforking is enacted and
proposals will have a timeout associated. Certainly for deployed
proposals you could say the proposal is "active" or better still
"pending approval". However "accepted" and "rejected" is difficult for
say privacy standards because how can you gauge or measure it. As I
said earlier, you might have a lot of small projects implementing some
privacy standards, but if the major wallets dont, and thus the
majority of users, how would you gauge it?
Something is a standard only when it becomes a standard by virtue of
having become a standard :)
"Replaced" is an easy state, when another proposal supercedes and
replaces an older one. Again the wording could be better here.
"deprecated" would also be appropriate in some circumstances.
I'm not making a concrete proposal, I'm just highlighting where BIP-1
sort of falls apart because of an incongruence with the workflow
states and what actually happens in real life.
Local to the BIPs project, I do think the BIPs editor, and guidelines
try to filter proposals by raising the bar: i.e. requiring proposal to
be polished through peer review before they are formally published as
draft BIPs. Though this process an author would a) get most of his
details right first time, and b) have some relative confidence his/her
idea was useful and withdraw any obvious bad proposals themselves. An
author may still decide, despite many objections from their peers they
want to proceed with publishing and nothing should stop them providing
it's relevant to the Bitcoin space. Peer review pressure is likely to
act as the best filtering mechanism in this case anyway (no-one would
want to be seen as an ass right?). Personally speaking, I felt quite
nervous proposing my own blocksize ideas. I sought opinions in private
first and had it been widely decried would probably not have pursued
it any further.
So in summary, I think some aspects of BIP-1 could do with polishing
as I have detailed, specially around the "workflow states" but not to
introduce any committees to the process, but where possible to extract
state from the real state of the BIP in the real world. In fact, this
is my direct argument against any forms of committee, in that the
state of a BIP is determined by factors outside of any particular
individual's or groups' purview.
On Fri, Sep 4, 2015 at 9:13 PM, Andy Chase <theandychase at gmail.com> wrote:
> Thanks for your thoughts.
>
> My proposal isn't perfect for sure. There's likely much better ways to do
> it. But to be clear what I'm trying to solve is basically this:
>
> Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
> users? Let's set up a system where everyone has a say and clear acceptance
> can be reached.
>
> ---
>
> My motivation for writing this proposal is stated right at the start:
>> "The current process for accepting a BIP is not clearly defined. While
>> BIP-0001 defines the process for writing and submitting a Bitcoin
>> Improvement Proposal to the community it does not specify the precise method
>> for which BIPs are considered accepted or rejected."
>
> BIPs are considered "accepted" right now based on an undefined system, quite
> honestly. Btc Drak: What's the system for accepting a BIP? Words like
> "consensus" come up but they aren't defined. My goal is to define a system
> that makes finding "consensus" (I like the word "acceptance" better) in a
> clear and fair way.
>
> I.e. what's broken?
>
> * Being sure that a proposal is widely accepted or rejected
> * Preventing deadlock (i.e. one person's weak objections preventing
> acceptance)
> * Receiving feedback from important segments like user groups,
> merchants/exchanges, etc. in a systematic and clear way instead of going and
> forth or having "oracles" on technical advisory boards.
>
>> Yes the process is loose, but is it broken?
>
> Yes/No. Work gets done with the current process. Work can get done with this
> process. The goal is for this process is to be safer/clearer/better defined
> way.
>
>> There have been a flood of
>> BIPs added recently with zero bureaucracy or friction.
>
> As we move forward, we want to balance the powers in such a way that we may
> want to pause a bit before we accept each proposal. 2 weeks for comments + 2
> weeks for opinions will slow things down, but it shouldn't stall meaningful
> work. I used 4 weeks for the process with the understanding that most
> proposals are clear and easily acceptable. Controversial proposals will
> likely need more time and thus will likely have be submitted at least twice
> to discover a clear response.
>
> "Accepting" a BIP means just that: It's accepted. What's acceptance mean?
> This proposal provides an answer.
>
> Client implementations, users, miners, and merchants can feel safe
> implementing and using a feature that has clear acceptance. This process
> isn't meant to force anything on client implementors, users, miners, or
> merchants.
>
> On Fri, Sep 4, 2015 at 12:20 PM, Btc Drak <btcdrak at gmail.com> wrote:
>>
>> I'm rather perplexed about this proposal. What exactly is wrong with
>> the existing BIPs process? I mean, it seems to me anyone can publish a
>> BIP pretty easily in the BIPs repository. There doesnt seems to be any
>> real barrier to entry whatsoever. I know there have been all manner of
>> aspersions, but having just written two BIPs there was no friction at
>> all.
>>
>> Whether the ecosystem adopts a BIP is another question of course, but
>> that's out of scope of the BIPs project anyhow. Take BIP101
>> controversial as it gets, but it's there. Whether Bitcoin implementers
>> implement it is another kettle of fish and a matter for each project
>> to decide. It's absolutely NOT the realm of the BIPs project itself.
>> Bitcoin Core does not make any consensus critical changes with a BIP.
>> Where one seeks to establish certain standards, say for privacy, a BIP
>> would be appropriate so the ecosystem can harmonise methodology across
>> the board.
>>
>> The status of a BIP is not really determined by anyone, it's by
>> adoption - that's where consensus happens. There's a little legroom
>> around this but I'm not entirely sure what you are trying to solve.
>> Yes the process is loose, but is it broken? There have been a flood of
>> BIPs added recently with zero bureaucracy or friction.
>>
>> BIP0001 is the BIP that defines the BIP process. Interestingly enough
>> the only BIP that might be controversial is in fact a BIP to change
>> the way BIPs are handled!
>>
>> So I'd really prefer to start this conversation with a breakdown of
>> what you think is broken first before tackling what may or may not
>> need fixing. I would be very cautious bringing "administrative"
>> burdens to the process or evicting common sense from the proceedings.
>> Much of the debates around consensus building seem to negate the
>> importance of common sense and the simple fact that "it's obvious when
>> you see it".
>>
>> I'm sure there can be improvements, but for me personally, I need to
>> see what is broken before I can make any judgement on a potential way
>> forward, and if it's not broken, we should leave it alone.
>>
>>
>> On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > As posted:
>> >
>> > **Enforcement/Organization** I agree with your comments. I don't believe
>> > in
>> > setting up an organization to manage this process (would be too much
>> > power
>> > and not really needed because the internet is pretty good at information
>> > sharing). Therefore, I designed it around the assumption that
>> > participation
>> > is voluntary. This means that it's hard to enforce rules like forcing
>> > groups
>> > to see the other side. Groupthink/Echo chambers is real and is bad but
>> > it's
>> > hard to change human nature.
>> >
>> > In regards to enforcement, I believe that the best approach would be to
>> > motivate committees to produce the best opinion they can (and also proof
>> > of
>> > stake, another weak point in this proposal), as the better they can do
>> > this
>> > the more likely the community will accept their opinion as valid and
>> > important.
>> >
>> > Indeed, I believe that without an organization managing the process,
>> > it's up
>> > to each individual reader of each BIP/Opinions set to make the decision
>> > on
>> > whether or not there is clear and true community acceptance.
>> >
>> > ----
>> >
>> > **Committee versus another approach**
>> >
>> > Pros of using Committees:
>> >
>> > * Committees are used today in many fields with a range of success. Lots
>> > of
>> > previous work to work off of here, history is established.
>> > * Many segments already have committee-like structures (Merchants
>> > produce
>> > shared signed documents, miners often represent themselves, User groups
>> > have
>> > representatives like voting on subreddit moderators, Core Devs have Core
>> > Devs)
>> > * Committees can filter a range of opinions down to a yes/no
>> > * Committees have real people that can be talked to, contacted, etc.
>> > * Much easier to proof stake in a range (People generally accept the
>> > Bitcoin
>> > Core has 70-90% of the market share) vs someone trying to proof they
>> > make up
>> > (.000001% of the Bitcoin user-base)
>> > * Committees have some stability, encourages experience and expertise
>> > (Committee members can be knowledgeable in their area and adequately
>> > understand BIPs)
>> >
>> > Cons:
>> >
>> > * Fear of committees working in the dark, censoring opinions (i.e. "Dark
>> > smokey room of fat cats") (Possible solution: make committee power fluid
>> > i.e. easily abandon-able: miners can change pools, users can change
>> > client
>> > forks, change merchants, users can re-group, encourage transparency)
>> > * More centralized, centralization of power (generally bad) (Possible
>> > solution: encourage smaller committees)
>> > * Centralization pressure (groups may seek to consolidate to gain power)
>> > (Possible solution: Segmentation)
>> > * Encourages groupthink, political maneuvers, turns good people into
>> > politicians, mud-tossing
>> >
>> > **Another possible approach: micro votes**
>> >
>> > Pros:
>> >
>> > * Each user can represent themselves, no censorship
>> > * People feel more involved and empowered
>> >
>> > Cons:
>> >
>> > * How to prove and prevent manipulation?
>> > * Only motivated people will contribute. Motivated people may be
>> > motivated
>> > for bad reasons.
>> >
>> >
>> > On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>> >>
>> >> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> > I wrote the BIP mostly to stir the pot on ideas of governance
>> >>
>> >> Some quick comments:
>> >>
>> >> I have some objects that I am not ready to put into words, but I do
>> >> think there are easily some major objections to committee design. If I
>> >> vanish and never respond with my objections, perhaps there's an IETF
>> >> RFC about this already....
>> >>
>> >> Something that may mitigate my possible objections would be some
>> >> mandatory requirement about ecosystem echo-chambers making many
>> >> attempts and efforts at steelman representations of alternative
>> >> viewpoints. Understanding objections at a fundamental level, enough to
>> >> make strong steelman statements, is very important to ensure that the
>> >> competing opinions are not censored from consideration. Pathological
>> >> integration and internalization of these steelman arguments can be
>> >> very useful, even if the process looks unusual.
>> >>
>> >> Your process does not have to replace any particular BIP process
>> >> as-is, but rather could be an alternative that proceeds on its own
>> >> perhaps indefinitely without replacement. I don't think too many BIP
>> >> processes are necessarily incompatible except by namespace collision.
>> >>
>> >>
>> >> https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
>> >>
>> >> - Bryan
>> >> http://heybryan.org/
>> >> 1 512 203 0507
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>
>

2023-06-07 19:39:36

- reply

📅 Original date posted:2015-09-04
📝 Original message:I'm rather perplexed about this proposal. What exactly is wrong with
the existing BIPs process? I mean, it seems to me anyone can publish a
BIP pretty easily in the BIPs repository. There doesnt seems to be any
real barrier to entry whatsoever. I know there have been all manner of
aspersions, but having just written two BIPs there was no friction at
all.
Whether the ecosystem adopts a BIP is another question of course, but
that's out of scope of the BIPs project anyhow. Take BIP101
controversial as it gets, but it's there. Whether Bitcoin implementers
implement it is another kettle of fish and a matter for each project
to decide. It's absolutely NOT the realm of the BIPs project itself.
Bitcoin Core does not make any consensus critical changes with a BIP.
Where one seeks to establish certain standards, say for privacy, a BIP
would be appropriate so the ecosystem can harmonise methodology across
the board.
The status of a BIP is not really determined by anyone, it's by
adoption - that's where consensus happens. There's a little legroom
around this but I'm not entirely sure what you are trying to solve.
Yes the process is loose, but is it broken? There have been a flood of
BIPs added recently with zero bureaucracy or friction.
BIP0001 is the BIP that defines the BIP process. Interestingly enough
the only BIP that might be controversial is in fact a BIP to change
the way BIPs are handled!
So I'd really prefer to start this conversation with a breakdown of
what you think is broken first before tackling what may or may not
need fixing. I would be very cautious bringing "administrative"
burdens to the process or evicting common sense from the proceedings.
Much of the debates around consensus building seem to negate the
importance of common sense and the simple fact that "it's obvious when
you see it".
I'm sure there can be improvements, but for me personally, I need to
see what is broken before I can make any judgement on a potential way
forward, and if it's not broken, we should leave it alone.
On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> As posted:
>
> **Enforcement/Organization** I agree with your comments. I don't believe in
> setting up an organization to manage this process (would be too much power
> and not really needed because the internet is pretty good at information
> sharing). Therefore, I designed it around the assumption that participation
> is voluntary. This means that it's hard to enforce rules like forcing groups
> to see the other side. Groupthink/Echo chambers is real and is bad but it's
> hard to change human nature.
>
> In regards to enforcement, I believe that the best approach would be to
> motivate committees to produce the best opinion they can (and also proof of
> stake, another weak point in this proposal), as the better they can do this
> the more likely the community will accept their opinion as valid and
> important.
>
> Indeed, I believe that without an organization managing the process, it's up
> to each individual reader of each BIP/Opinions set to make the decision on
> whether or not there is clear and true community acceptance.
>
> ----
>
> **Committee versus another approach**
>
> Pros of using Committees:
>
> * Committees are used today in many fields with a range of success. Lots of
> previous work to work off of here, history is established.
> * Many segments already have committee-like structures (Merchants produce
> shared signed documents, miners often represent themselves, User groups have
> representatives like voting on subreddit moderators, Core Devs have Core
> Devs)
> * Committees can filter a range of opinions down to a yes/no
> * Committees have real people that can be talked to, contacted, etc.
> * Much easier to proof stake in a range (People generally accept the Bitcoin
> Core has 70-90% of the market share) vs someone trying to proof they make up
> (.000001% of the Bitcoin user-base)
> * Committees have some stability, encourages experience and expertise
> (Committee members can be knowledgeable in their area and adequately
> understand BIPs)
>
> Cons:
>
> * Fear of committees working in the dark, censoring opinions (i.e. "Dark
> smokey room of fat cats") (Possible solution: make committee power fluid
> i.e. easily abandon-able: miners can change pools, users can change client
> forks, change merchants, users can re-group, encourage transparency)
> * More centralized, centralization of power (generally bad) (Possible
> solution: encourage smaller committees)
> * Centralization pressure (groups may seek to consolidate to gain power)
> (Possible solution: Segmentation)
> * Encourages groupthink, political maneuvers, turns good people into
> politicians, mud-tossing
>
> **Another possible approach: micro votes**
>
> Pros:
>
> * Each user can represent themselves, no censorship
> * People feel more involved and empowered
>
> Cons:
>
> * How to prove and prevent manipulation?
> * Only motivated people will contribute. Motivated people may be motivated
> for bad reasons.
>
>
> On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure at gmail.com> wrote:
>>
>> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > I wrote the BIP mostly to stir the pot on ideas of governance
>>
>> Some quick comments:
>>
>> I have some objects that I am not ready to put into words, but I do
>> think there are easily some major objections to committee design. If I
>> vanish and never respond with my objections, perhaps there's an IETF
>> RFC about this already....
>>
>> Something that may mitigate my possible objections would be some
>> mandatory requirement about ecosystem echo-chambers making many
>> attempts and efforts at steelman representations of alternative
>> viewpoints. Understanding objections at a fundamental level, enough to
>> make strong steelman statements, is very important to ensure that the
>> competing opinions are not censored from consideration. Pathological
>> integration and internalization of these steelman arguments can be
>> very useful, even if the process looks unusual.
>>
>> Your process does not have to replace any particular BIP process
>> as-is, but rather could be an alternative that proceeds on its own
>> perhaps indefinitely without replacement. I don't think too many BIP
>> processes are necessarily incompatible except by namespace collision.
>>
>> https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:39:29

- reply

📅 Original date posted:2015-09-03
📝 Original message:It's a good idea. It would remove friction from the process and
assignment is auditable to boot, something I've had difficulty with in
the past. Almost every time I see a BIP number I would wonder, is that
self-assigned (and thus invalid) or has it been assigned by the BIP
editor.
On Fri, Sep 4, 2015 at 12:18 AM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The process in BIP01 was written when we used a different solution for
> storing and presenting BIPs.
>
> I'm thinking of suggesting that the number request process be changed
> to opening a pull req with BIP text with no number (e.g. just using
> the authors name and an index as the number) as the mechenism to
> request number assignment.
>
> Is there any reason that anyone would find this objectionable?
>
> (Please do not respond to this message with anything but a strictly
> directed answer to that question, start a new thread for a different
> subject. Thanks!)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:39:22

- reply

📅 Original date posted:2015-09-04
📝 Original message:If you read between the lines of what was recently changed and why
(reducing to 2MB), it seems reasonable to assume BIP101's allowance
opens up some of the attack vector again.
On Fri, Sep 4, 2015 at 4:37 PM, Simon Liu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Maybe grab some code from BIP101 ? It permits block messages > 2MB,
> while retaining the current limit of 2 MB imposed on other network
> messages. The 32 MB limit was patched a few months ago.
>
> Links to code:
>
> https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
>
>
>
> On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
>> The 32Mb limit is
>> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
>>
>> It's to keep the message size small enough that messages can be
>> serialized in memory.
>>
>> Jeff if you decide to lift the 32MB limit (you really should, unless
>> your plan is to potentially hard force another Blocksize discussion
>> again which might be okay). I suggest having the 32MB ceiling auto-raise
>> according to a exponential factor (1.5?) starting 1 year from now.
>>
>> Basically hard limit ceiling 2016-2017: 32 MB
>> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
>>
>> The factor could be 2 like BIP-101 but I imagine you will want to be
>> more conservative. The delay time could also be longer if you think it
>> will take longer to fix the message size issue across all implementations.
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:39:21

- reply

📅 Original date posted:2015-09-03
📝 Original message:Just use a 4-byte unsigned integer where the integer is the size in
bytes. It's concise and less complex (and less complex to implement).
There's no need for human readable strings here.
On Thu, Sep 3, 2015 at 5:35 PM, Jeff Garzik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Take a look at the latest update:
>
> - swiped Tier Nolan verbiage, which I agree was usefully more clear
> - added 'M' suffix and removed 'V' from coinbase scriptSig
>
>
> On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 1. I think there is no need to have resolution at byte level, while
>> resolution at MB level is not enough. kB would be a better choice.
>>
>> 2. In my specification a v4 block without a vote is invalid, so there is
>> no need to consider absent or invalid votes
>>
>> 3. We should allow miners to explicitly vote for the status quo, so they
>> don't need to change the coinbase vote every time the size is changed. They
>> may indicate it by /BV/ in the coinbase, and we should look for the first
>> "/BVd*/" instead of "/BVd+/"
>>
>> 4. Alternatively, miners may vote in different styles: /BV1234567/,
>> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB,
>> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
>>
>> Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到:
>>>
>>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> *
>>>>
>>>> hardLimit floats within the range 1-32M, inclusive.
>>>
>>>
>>> Does the 32MB limit actually still exist anywhere in the code? In
>>> effect, it is re-instating a legacy limitation.
>>>
>>> The message size limit is to minimize the storage required per peer.
>>> If a 32MB block size is required, then each network input buffer must
>>> be at least 32MB. This makes it harder for a node to support a large
>>> number of peers.
>>>
>>> There is no reason why a single message is used for each block. Using
>>> the merkleblock message (or a different dedicated message), it would
>>> be possible to send messages which only contain part of a block and
>>> have a limited maximum size.
>>>
>>> This would allow receiving parts of a block from multiple sources.
>>>
>>> This is a separate issue but should be considered if moving past 32MB
>>> block sizes (or maybe as a later protocol change).
>>>
>>>> * Changing hardLimit is accomplished by encoding a proposed value
>>>> within a block's coinbase scriptSig.
>>>>
>>>> * Votes refer to a byte value, encoded within the pattern "/BVd+/"
>>>> Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
>>>> more than one match with with pattern, the first match is counted.
>>>
>>>
>>> Is there a need for byte resolution? Using MB resolution would use up
>>> much fewer bytes in the coinbase.
>>>
>>> Even with the +/- 20% rule, miners could vote for the nearest MB.
>>> Once the block size exceeds 5MB, then there is enough resolution
>>> anyway.
>>>
>>>> * Absent/invalid votes and votes below minimum cap (1M) are
>>>>
>>>> counted as 1M votes. Votes above the maximum cap (32M) are counted
>>>> as 32M votes.
>>>
>>>
>>> I think abstains should count for the status quo. Votes which are out
>>> of range should be clamped.
>>>
>>> Having said that, if core supports the change, then most miners will
>>> probably vote one way or another.
>>>
>>>> New hardLimit is the median of the followings:
>>>> min(current hardLimit * 1.2, 20-percentile)
>>>> max(current hardLimit / 1.2, 80-percentile)
>>>> current hardLimit
>>>
>>>
>>> I think this is unclear, though mathematically exact.
>>>
>>> Sort the votes for the last 12,000 blocks from lowest to highest.
>>>
>>> Blocks which don't have a vote are considered a vote for the status
>>> quo.
>>>
>>> Votes are limited to +/- 20% of the current value. Votes that are out
>>> of range are considered to vote for the nearest in range value.
>>>
>>> The raise value is defined as the vote for the 2400th highest block
>>> (20th percentile).
>>>
>>> The lower value is defined as the vote for the 9600th highest block
>>> (80th percentile).
>>>
>>> If the raise value is higher than the status quo, then the new limit
>>> is set to the raise value.
>>>
>>> If the lower value is lower than the status quo, then the new limit is
>>> set to the lower value.
>>>
>>> Otherwise, the size limit is unchanged.
>>>
>>> _______________________________________________
>>> 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 19:39:19

- reply

📅 Original date posted:2015-09-03
📝 Original message:On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> A discussion of rolling out BIP 100 will not be avoided :)
>
> It is a hard fork; it would be silly to elide discussion of these key
> issues.
>
> I don't get the community's recent interest in avoiding certain topics.
It's not a matter of avoiding the subject, it's a whole separate
discussion and in the interests of efficient discussion, it is best
done separately. There's a whole BIP dedicated to the discussion of
consensus forks which you should probably give some input in also,
BIP99 [1]
Once we come to an agreement and can say "here's what we're doing
about blocksize, it will be X, or we'll raise by this algo", then we
can discuss the best way to implement the hard fork.
[1] https://github.com/bitcoin/bips/pull/181
>
>
>
> On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak at gmail.com> wrote:
>>
>> We should avoid discussing actual hard fork/softfork deployment
>> methodologies when discussing blocksize proposals because deployment
>> is a separate issue. As a recent case in point, look at how BIP65
>> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
>> That lead to a focused discussion of the functionality and relatively
>> quick inclusion.
>>
>> Deployment really is a separate issue than the mechanics of how BIP100
>> will function after activation.
>>
>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Some comments:
>> >
>> > The 75% rule is meaningless here. Since this is a pure relaxation of
>> > rules,
>> > there is no such thing as "invalid version 4 blocks"
>> >
>> > The implication threshold is unclear. Is it 95% or 80%?
>> >
>> > Softfork requires a very high threshold (95%) to "attack" the original
>> > fork.
>> > This makes sure that unupgraded client will only see the new fork.
>> > In the case of hardfork, however, the new fork is unable to attack the
>> > original fork, and unupgraded client will never see the new fork. The
>> > initiation of a hardfork should be based on its acceptance by the
>> > economic
>> > majority, not miner support. 95% is an overkill and may probably never
>> > accomplished. I strongly prefer a 80% threshold rather than 95%.
>> >
>> > As I've pointed out, using 20-percentile rather than median creates an
>> > incentive to 51% attack the uncooperative minority.
>> >
>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>> >
>> > Having said that, I don't have a strong feeling about the use of
>> > 20-percentile as threshold to increase the block size. That means the
>> > block
>> > size is increased only when most miners agree, which sounds ok to me.
>> >
>> > However, using 20-percentile as threshold to DECREASE the block size
>> > could
>> > be very dangerous. Consider that the block size has been stable at 8MB
>> > for a
>> > few years. Everyone are happy with that. An attacker would just need to
>> > acquire 21% of mining power to break the status quo and send us all the
>> > way
>> > to 1MB. The only way to stop such attempt is to 51% attack the attacker.
>> > That'd be really ugly.
>> >
>> > For technical and ethical reasons, I believe the thresholds for increase
>> > and
>> > decrease must be symmetrical: increase the block size when the
>> > x-percentile
>> > is bigger than the current size, decrease the block size when the
>> > (100-x)-percentile is smaller than the current size. The overall effect
>> > is:
>> > the block size remains unchanged unless 80% of miners agree to.
>> >
>> > Please consider the use of "hardfork bit" to signify the hardfork:
>> >
>> >
>> > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>> >
>> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>> >
>> > Or, alternatively, please combine the hardfork with a softfork. I'm
>> > rewriting the specification as follow (changes underlined):
>> >
>> > Replace static 1M block size hard limit with a floating limit
>> > ("hardLimit").
>> >
>> > hardLimit floats within the range 1-32M, inclusive.
>> >
>> > Initial value of hardLimit is 1M, preserving current system.
>> >
>> > Changing hardLimit is accomplished by encoding a proposed value within a
>> > block's coinbase scriptSig.
>> >
>> > Votes refer to a byte value, encoded within the pattern "/BV\d+/"
>> > Example:
>> > /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than
>> > one
>> > match with with pattern, the first match is counted.
>> > Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
>> > votes. Votes above the maximum cap (32M) are counted as 32M votes.
>> > A new hardLimit is calculated at each difficult adjustment period (2016
>> > blocks), and applies to the next 2016 blocks.
>> > Calculate hardLimit by examining the coinbase scriptSig votes of the
>> > previous 12,000 blocks, and taking the 20th percentile and 80th
>> > percentile.
>> > New hardLimit is the median of the followings:
>> >
>> > min(current hardLimit * 1.2, 20-percentile)
>> > max(current hardLimit / 1.2, 80-percentile)
>> > current hardLimit
>> >
>> > version 4 block: the coinbase of a version 4 block must match this
>> > pattern:
>> > "/BV\d+/"
>> > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
>> > reject invalid version 4 blocks. (testnet4: 501 of last 1000)
>> > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are
>> > version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of
>> > last
>> > 1000)
>> > Block version number is calculated after masking out high 16 bits (final
>> > bit
>> > count TBD by versionBits outcome).
>> >
>> > Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
>> >> BIP 100 initial public draft:
>> >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>> >>
>> >> Emphasis on "initial" This is a starting point for the usual open
>> >> source feedback/iteration cycle, not an endpoint that Must Be This
>> >> Way.
>> >>
>> >>
>> >>
>> >> Links:
>> >> ------
>> >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev at lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>
>

2023-06-07 19:39:17

- reply

📅 Original date posted:2015-09-03
📝 Original message:We should avoid discussing actual hard fork/softfork deployment
methodologies when discussing blocksize proposals because deployment
is a separate issue. As a recent case in point, look at how BIP65
(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
That lead to a focused discussion of the functionality and relatively
quick inclusion.
Deployment really is a separate issue than the mechanics of how BIP100
will function after activation.
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Some comments:
>
> The 75% rule is meaningless here. Since this is a pure relaxation of rules,
> there is no such thing as "invalid version 4 blocks"
>
> The implication threshold is unclear. Is it 95% or 80%?
>
> Softfork requires a very high threshold (95%) to "attack" the original fork.
> This makes sure that unupgraded client will only see the new fork.
> In the case of hardfork, however, the new fork is unable to attack the
> original fork, and unupgraded client will never see the new fork. The
> initiation of a hardfork should be based on its acceptance by the economic
> majority, not miner support. 95% is an overkill and may probably never
> accomplished. I strongly prefer a 80% threshold rather than 95%.
>
> As I've pointed out, using 20-percentile rather than median creates an
> incentive to 51% attack the uncooperative minority.
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>
> Having said that, I don't have a strong feeling about the use of
> 20-percentile as threshold to increase the block size. That means the block
> size is increased only when most miners agree, which sounds ok to me.
>
> However, using 20-percentile as threshold to DECREASE the block size could
> be very dangerous. Consider that the block size has been stable at 8MB for a
> few years. Everyone are happy with that. An attacker would just need to
> acquire 21% of mining power to break the status quo and send us all the way
> to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increase and
> decrease must be symmetrical: increase the block size when the x-percentile
> is bigger than the current size, decrease the block size when the
> (100-x)-percentile is smaller than the current size. The overall effect is:
> the block size remains unchanged unless 80% of miners agree to.
>
> Please consider the use of "hardfork bit" to signify the hardfork:
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>
> Or, alternatively, please combine the hardfork with a softfork. I'm
> rewriting the specification as follow (changes underlined):
>
> Replace static 1M block size hard limit with a floating limit ("hardLimit").
>
> hardLimit floats within the range 1-32M, inclusive.
>
> Initial value of hardLimit is 1M, preserving current system.
>
> Changing hardLimit is accomplished by encoding a proposed value within a
> block's coinbase scriptSig.
>
> Votes refer to a byte value, encoded within the pattern "/BV\d+/" Example:
> /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than one
> match with with pattern, the first match is counted.
> Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
> votes. Votes above the maximum cap (32M) are counted as 32M votes.
> A new hardLimit is calculated at each difficult adjustment period (2016
> blocks), and applies to the next 2016 blocks.
> Calculate hardLimit by examining the coinbase scriptSig votes of the
> previous 12,000 blocks, and taking the 20th percentile and 80th percentile.
> New hardLimit is the median of the followings:
>
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit
>
> version 4 block: the coinbase of a version 4 block must match this pattern:
> "/BV\d+/"
> 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
> reject invalid version 4 blocks. (testnet4: 501 of last 1000)
> 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are
> version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of last
> 1000)
> Block version number is calculated after masking out high 16 bits (final bit
> count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
>> BIP 100 initial public draft:
>> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>>
>> Emphasis on "initial" This is a starting point for the usual open
>> source feedback/iteration cycle, not an endpoint that Must Be This
>> Way.
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:39:04

- reply

📅 Original date posted:2015-09-01
📝 Original message:I have read the proposal. I think you missed my point: every existing
transaction author would be required to agree to your proposals for
them to be legal, and that's clearly impossible. You'd also need every
single miner who published a block. You're much better taking the line
that actually, the data is public domain and unrestricted based on
various assumptions.
You make some assumptions that transaction authors use Bitcoin Core to
"contract with the network", but in fact transactions are written and
broadcast by a number of means, arguably very few are created by
Bitcoin Core these days. How exactly do you expect to get a legally
binding agreement from all future transaction authors agreeing to your
terms? How would you prove Alice agreed 10 years later? If it was a
proprietary system like Paypal who can force you to agree or close
your account, the Bitcoin protocol is permissionless and anyone can
author a transaction using any means they like, not just Bitcoin Core.
So again I come back to the point your proposal would have to get
permission from all existing authors, and all future authors to work.
Overall I think the proposal is trying to fix something that doesn't
need fixing and get into a quagmire in the process. In fact, I see it
as an impossible task.
On Tue, Sep 1, 2015 at 11:11 PM, Ahmed Zsales <ahmedzsales18 at gmail.com> wrote:
> To avoid repetition, we have actually covered the general points and
> questions you have raised in the draft BIP, which includes a draft licence
> to assist discussions:
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>
> Regards,
>
> Ahmed
>
> On Tue, Sep 1, 2015 at 11:02 PM, Btc Drak <btcdrak at gmail.com> wrote:
>>
>> I think it gets worse. Who are the copyright owners (if this actually
>> applies). You've got people publishing transaction messages, you've
>> got miners reproducing them and publishing blocks. Who are all the
>> parties involved? Then to take pedantry to the next level, does a
>> miner have permission to republish messages? How do you know? What if
>> the messages are reproducing others copyright/licensed material? It's
>> not possible to license someone else's work. There are plenty rabbit
>> holes to go down with this train of thought.
>>
>> On Tue, Sep 1, 2015 at 8:36 PM, Ahmed Zsales via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > That is a very good point.
>> >
>> > We considered whether data existing before a licence change would be
>> > covered, but we hadn't factored the potential need for gaining
>> > permissions
>> > for a change to be considered effective.
>> >
>> > We have proposed that miners be the main beneficiaries of licensing and
>> > there is a consideration on whether they should vote to adopt the new
>> > terms.
>> > While not the preferred route, that would overcome any issues to what is
>> > an
>> > otherwise honest 'error and omission.' There doesn't seem to be anyone
>> > who
>> > could claim to have suffered any economic losses so this may not be an
>> > issue. It merits further investigation.
>> >
>> > The block chain is in perpetual change, so the sooner a change is agreed
>> > upon, if at all, the more data it will cover without any reservations.
>> > At
>> > any rate, we believe the changes would be considered effective on a
>> > retrospective basis.
>> >
>> >
>> > On Tue, Sep 1, 2015 at 7:12 PM, Btc Drak <btcdrak at gmail.com> wrote:
>> >>
>> >> Without commenting on your proposal at all, the general problem with
>> >> licensing after the fact is you require the permission of every
>> >> copyright holder in order to make the change.
>> >>
>> >>
>> >>
>> >> On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >> > Hello,
>> >> >
>> >> > We believe the network requires a block chain licence to supplement
>> >> > the
>> >> > existing MIT Licence which we believe only covers the core reference
>> >> > client
>> >> > software.
>> >> >
>> >> > Replacing or amending the existing MIT Licence is beyond the scope of
>> >> > this
>> >> > draft BIP.
>> >> >
>> >> > Rationale and details of our draft BIP for discussion and evaluation
>> >> > are
>> >> > here:
>> >> >
>> >> >
>> >> >
>> >> > https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>> >> >
>> >> > Regards,
>> >> >
>> >> > Ahmed
>> >> >
>> >> > _______________________________________________
>> >> > bitcoin-dev mailing list
>> >> > bitcoin-dev at lists.linuxfoundation.org
>> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >
>> >
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>
>

2023-06-07 19:39:01

- reply

📅 Original date posted:2015-09-01
📝 Original message:Without commenting on your proposal at all, the general problem with
licensing after the fact is you require the permission of every
copyright holder in order to make the change.
On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> We believe the network requires a block chain licence to supplement the
> existing MIT Licence which we believe only covers the core reference client
> software.
>
> Replacing or amending the existing MIT Licence is beyond the scope of this
> draft BIP.
>
> Rationale and details of our draft BIP for discussion and evaluation are
> here:
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>
> Regards,
>
> Ahmed
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:38:27

- reply

📅 Original date posted:2015-08-29
📝 Original message:What about supporting different networks? What if I want to look up
testnet for example?
blockchain://mainnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://testnet/txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
or
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a?network=testnet
On Sat, Aug 29, 2015 at 5:31 PM, Richard Moore via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I like the idea of having a standard for this, that all explorers (and even
> core, eventually) would understand.
>
> I would recommend 2 changes though. First, using a real URI scheme,
> blockchain:// so that we can just use normal URL parsing libraries. The
> bitcoin: thing leads to additional code to mutate it into a proper URI
> before passing it to URL parsing. And I think it would be fine to include
> the type looking up. For example:
>
> blockchain://blockhash/00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain://txid/3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
> blockchain://block/189000
> blockchain://address/1RicMooMWxqKczuRCa5D2dnJaUEn9ZJyn
>
> I think this would help the URI be more human understandable as well as give
> the explorers the ability to optimize a bit what they are looking for when
> hitting various databases.
>
> A possible future path could also include blockchain://tx/123000/4 for block
> height, tx index... Another possibility could be blockchain://version which
> would return a list of supported paths, version of the BIP supported, etc.
>
> The BIP should also specify little endian searching. I'm not sure, but would
> it also make sense for this BIP to include what the return results should
> look like? Maybe another, related BIP.
>
> RicMoo
>
> Sent from my self-aware iPhone
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software Inc.
> phone: (778) 882-6125
> email: ricmoo at geneticmistakes.com
> www: http://GeneticMistakes.com
>
> On Aug 29, 2015, at 7:48 AM, Marco Pontello via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi!
> My first post here, hope I'm following the right conventions.
> I had this humble idea for a while, so I thought to go ahead and propose
> it.
>
> BIP: XX
> Title: URI scheme for Blockchain exploration
> Author: Marco Pontello
> Status: Draft
> Type: Standards Track
> Created: 29 August 2015
>
> Abstract
> ========
> This BIP propose a simple URI scheme for looking up blocks, transactions,
> addresses on a Blockchain explorer.
>
> Motivation
> ==========
> The purpose of this URI scheme is to enable users to handle all the
> requests for details about blocks, transactions, etc. with their preferred
> tool (being that a web service or a local application).
>
> Currently a Bitcoin client usually point to an arbitrary blockchain
> explorer when the user look for the details of a transaction (es. Bitcoin
> Wallet use BitEasy, Mycelium or Electrum use Blockchain.info, etc.).
> Other times resorting to cut&paste is needed.
> The same happens with posts and messages that reference some particular
> txs or blocks, if they provide links at all.
>
> Specification
> =============
> The URI follow this simple form:
>
> blockchain: <hash/string>
>
> Examples:
>
> blockchain:00000000000000001003e880d500968d51157f210c632e08a652af3576600198
> blockchain:001949
> blockchain:3b95a766d7a99b87188d6875c8484cb2b310b78459b7816d4dfc3f0f7e04281a
>
> Rationale
> =========
> I thought about using some more complex scheme, or adding qualifiers to
> distinguish blocks from txs, but in the end I think that keeping it simple
> should be practical enough. Blockchain explorers can apply the same
> disambiguation rules they are already using to process the usual search
> box.
>
> From the point of view of a wallet developer (or other tool that need to
> show any kind of Blockchain references), using this scheme mean that he
> can simply make it a blockchain: link and be done with it, without having
> to worry about any specific Blockchain explorer or provide a means for the
> user to select one.
>
> Blockchain explorers in turn will simply offer to handle the blockchain:
> URI, the first time the user visit their website, or launch/install the
> application, or even set themselves if there isn't already one.
>
> Users get the convenience of using always their preferred explorer, which
> can be especially handy on mobile devices, where juggling with cut&paste
> is far from ideal.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:37:58

- reply

📅 Original date posted:2015-08-28
📝 Original message:On Fri, Aug 28, 2015 at 11:24 PM, Gavin <gavinandresen at gmail.com> wrote:
> With this proposal, how much would it cost a miner to include an 'extra' 500-byte transaction if the average block size is 900K and it costs the miner 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is correct, it is:
>
> 500/900000 * 20 = 0.11111 BTC
Typo, 0.01111
> ... Or $2.50 at today's exchange rate.
>
> That seems excessive.
I am not sure how it is relevant to this proposal because miners are
not paying to include an extra transaction. The BIP details how miners
can vote for a larger block size limit during a window of 2016 blocks.
The block size limit does not increase during this phase. The block
size limit is adjusted at the end of the sample window and the new
size is valid until the next retargetting.
If this wasn't clear, please let me know if I need to clarify any
specifics in the wording of the proposal.

2023-06-07 19:37:58

- reply

📅 Original date posted:2015-08-28
📝 Original message:On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> However, this proposal currently fails to answer a very important question:
>
> • What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
I chose not to address hard fork methodology at this stage because I
wanted to focus on the main algorithm. There are a number of options
open to us for deployment including a simple fixed activation (which I
think is feasible because there is a a lot of awareness and the
industry shows they are willing to rally around a single proposal). If
there are any strong preferences, I can add a deployment section
although I think it's less interesting until we forge a clear way
forward with what blocksize proposal to use.

2023-06-07 19:37:58

- reply

📅 Original date posted:2015-08-28
📝 Original message:On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size will never increase under this proposal do to a collective action
> problem. If a miner votes for an increase and nobody else does, the
> blocksize will not increase yet he will still have to pay the difficulty
> penalty.
>
> It may be in everyone's collective interest to raise the block size but not
> their individual interest.
It is clear from recent events that miners are willing to collaborate
together for the greater good of their industry. Miners have also
publicly shown support for raising the blocksize collaboratively.
Obviously, as transaction volume grows they want to collect as many
transaction fees as possible so if there isnt enough space in blocks,
they're going to vote for increases because it's in their collective
financial interests. The proposal specifically encourages
collaboration and hinders antisocial behaviour, and it specifically
encourages the blocksize to be raised according to demand without
neutering the fee market.

2023-06-07 19:37:54

- reply

📅 Original date posted:2015-08-29
📝 Original message:On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Ah, then my mistake. It seemed so similar to an idea that was proposed
> before on this mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>
> that my mind just filled in the gaps. I concur -- having miners -- or any
> group -- vote on block size is not an intrinsically good thing. The the
> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
> but rather a feedback control that made the maximum block size that which
> generated the most fees.
Mark and Jorge,
I am very glad you have brought up this particular objection because
it's something I thought about but was unclear if it was an opinion
that would be shared by others. I chose to omit it from the proposal
to see if it would come up during peer review.
I feel that giving miners a blank cheque to increase blocksize, by any
means, goes against a key design of bitcoin's security model. Full
nodes keep miners honest by ensuring by validating their blocks. Under
any voting-only scheme there is no way for full nodes to keep miners
in cheque because miner have free reign to increase the blocksize.
This problem can be solved by introducing a hard cap on blocksize. By
introducing an upper limit miners now have the freedom to increase
blocksize but only within defined parameters. Remember my proposal
allows blocksize to increase and decrease in such a way that miners
must collectively agree if they want the size to increase.
I believe the idea of a hard upper limit has become rather politicised
but is essential to the security model of bitcoin.
With respect to the flexicap idea where miners can create a larger
block by paying extra difficulty, I believe that proposal has a
critical flaw because, as Gavin pointed out, it makes it very
expensive (and risky) to include a few extra transactions. I believe
it suffers from tragedy of the commons because there is no incentive
for the mining community to reach consensus. Each and every block is
going to be a gamble, "should we include a few extra transactions at
the risk of losing the block?". Under my proposal miners can
collectively agree to change the blocksize. Let's say they want a 10%
increase, they can collude together to make that increase and once
reached, it remains until they want to change it again. Yet, the upper
hard limit keeps the ultimate control of the maximum block size
squarely in the hands of full nodes.
Whilst the exact number may be up for discussion, I would propose an
initial upper limit of 8MB, so under my proposal the blocksize would
be flexible between 1MB and 8MB.
An alternative methodology to voting in the coinbase would be to
change the vote to be the blocksize itself
1. miners pay extra difficulty to create a larger block.
2. every 2016 blocks the average or median of the last 2016 blocks is
calculated and becomes the new maximum blocksize limit.
This would retain incentive to collude to increase blocksize, as well
as the property of costing to increase while being free to propose
decrease.
It would still require an upper blocksize limit in order for full
nodes to retain control. Without an upper limit, any proposal is going
to break the security model as full nodes give up some oversight
control over miners.
Another way of looking at these ideas is we're raising blocksize hard
limit (to 8MB or whatever is decided), but making a soft of "softer"
or inner limit part of consensus. Such a concept is not really
departing from the current idea of a soft limit except to make it
consensus enforced. Obviously it's not identical, but I think you can
see the similarities.
Does that make sense?

2023-06-07 19:37:50

- reply

📅 Original date posted:2015-08-28
📝 Original message:I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.
I also request the BIP maintainer for a BIP number assignment
[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2] https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/
Pull request: https://github.com/bitcoin/bips/pull/187
<pre>
BIP: XX
Title: Consensus based block size retargeting algorithm
Author: BtcDrak <btcdrak at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-08-21
</pre>
==Abstract==
A method of altering the maximum allowed block size of the Bitcoin protocol
using a consensus based approach.
==Motivation==
There is a belief that Bitcoin cannot easily respond to raising the
blocksize limit if popularity was to suddenly increase due to a mass adoption
curve, because co-ordinating a hard fork takes considerable time, and being
unable to respond in a timely manner would irreparably harm the credibility of
bitcoin.
Additionally, predetermined block size increases are problematic because they
attempt to predict the future, and if too large could have unintended
consequences like damaging the possibility for a fee market to develop
as block subsidy decreases substantially over the next 9 years; introducing
or exacerbating mining attack vectors; or somehow affect the network in unknown
or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
extensive.
Dynamic block size adjustments also suffer from the potential to be gamed by the
larger hash power.
Free voting as suggested by BIP100 allows miners to sell their votes out of band
at no risk, and enable the sponsor the ability to manipulate the blocksize.
It also provides a cost free method or the larger pools to vote in ways to
manipulate the blocksize such to disadvantage or attack smaller pools.
==Rationale==
By introducing a cost to increase the block size ensures the mining community
will collude to increase it only when there is a clear necessity, and reduce it
when it is unnecessary. Larger miners cannot force their wishes so easily
because not only will they have to pay extra a difficulty target, then can be
downvoted at no cost by the objecting hash power.
Using difficulty as a penalty is better than a fixed cost in bitcoins because it
is less predictable.
==Specification==
The initial block size limit shall be 1MB.
Each time a miner creates a block, they may vote to increase or decrease the
blocksize by a maximum of 10% of the current block size limit. These votes will
be used to recalculate the new block size limit every 2016 blocks.
Votes are cast using the block's coinbase field.
The first 4 bytes of the coinbase field shall be repurposed for voting as an
unsigned long integer which will be the block size in bytes.
If a miner votes for an increase, the block hash must meet a difficulty target
which is proportionally larger than the standard difficulty target based on the
percentage increase they voted for.
Votes proposing decreasing the block size limit do not need to meet a higher
difficulty target.
Miners can vote for no change by voting for the current block size.
For blocks to be valid the blockhash must meet the required difficulty target
for the vote otherwise the block is invalid and will be rejected.
Every 2016 blocks, the block size limit will be recalculated by the median of
all votes in the last 2016 blocks. This will redefine the block size limit for
the next 2016 blocks.
Blocks that are larger than the calculated base block size limit are invalid and
will be rejected.
The base block size limit may not reduce below 1MB.
==Acknowledgements==
This proposal is based on ideas and concepts derived from the writings of
Meni Rosenfeld and Gregory Maxwell.
==Copyright==
This work is placed in the public domain.

2023-06-07 19:37:48

- reply

📅 Original date posted:2015-08-21
📝 Original message:I wanted to offer a potential way to adjust the block size limit in a
democratic way without making it easy to game. This is meant only as a
starting point for a general idea. Thresholds and exact figures and
the details of the algorithm are up for debate, and possibly some
formula based determination.
The living document is currently a gist available at
https://gist.github.com/btcdrak/1c3a323100a912b605b5
<pre>
BIP: XX
Title: Consensus based block size retargeting algorithm
Author: BtcDrak <btcdrak at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-08-21
</pre>
==Abstract==
A method of altering the maximum allowed block size of the Bitcoin
protocol using a consensus based approach.
==Motivation==
There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase due to a
mass adoption curve, because co-ordinating a hard fork takes
considerable time, and being unable to respond in a timely manner
would irreparably harm the credibility of bitcoin.
Additionally, predetermined block size increases are problematic
because they attempt to predict the future, and if too large could
have unintended consequences like damaging the possibility for a fee
market to develop as block subsidy decreases substantially over the
next 9 years; introducing or exacerbating mining attack vectors; or
somehow affect the network in unknown or unpredicted ways. Since fixed
changes are hard to deploy, the damage could be extensive.
Dynamic block size adjustments also suffer from the potential to be
gamed by the larger hash power.
==Rationale==
By introducing a cost to increase the block size ensures the mining
community will collude to increase it only when there is a clear
necessity, and reduce it when it is unnecessary. Rogue miners cannot
force their wishes so easily because not only will they have to pay
extra a difficulty target, then can be downvoted at no cost by the
objecting hash power.
==Specification==
The initial "base block size limit" shall be 1MB.
Miners can vote for a block size increase by signalling the proposed
percentage increase of the "base block size limit" in the coinbase
field. For the vote to be considered valid the block they mine must
meets a difficulty target which is proportionally larger than the
standard difficulty target based on the percentage increase they voted
for. If a miner does not vote, or the vote is invalid, it shall be
counted as a vote for no change.
Miners may vote the size down by signalling in the coinbase field
without paying a difficulty penalty.
Every 2016 blocks, the maximum allowed block size will be recalculated
by the average of all votes in the last 2016 blocks, i.e. sum each
vote from each block and divide by 2016 then multiply by the base
block size limit. This will redefine the base block size limit for the
next 2016 blocks.
Blocks that are larger than the calculated base block size limit are
invalid and MUST be rejected.
The maximum change up or down each retargeting period shall be limited
to 10% of the base block size limit.
The maximum block size may not increase above 8MB.
Votes shall be cast by adding the following human readable multiplier
to the coinbase string “/BXn.nnn/” where valid votes would exist
between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
increase). “/BX1.000/” would be a vote for no change. Invalid votes
will be counted as a vote for no change: “/BX1.000/”.
==Acknowledgements==
This proposal is based on ideas and concepts derived from the writings
of Meni Rosenfeld and Gregory Maxwell.
==Copyright==
This work is placed in the public domain.

2023-06-07 19:37:45

- reply

📅 Original date posted:2015-08-31
📝 Original message:On Mon, Aug 31, 2015 at 10:49 AM, NxtChg <nxtchg at hush.com> wrote:
>>While this topic is very interesting, I do not see how it is
>>relevant to a mailing list dedicated to technical and academic debate.
>>Please can you take this discussion elsewhere.
>
> Wow. I have Deja Vu. Where have I heard recently that discussing Bitcoin split is off topic and must be stopped?.. Hm...
>
> This is the biggest issue with Bitcoin right now and you want us to move to some obscure place?
>
> Where? Reddit? Where we can't be heard? Create another list with top XT people then.
This is a technical list dedicated to technical discussions revolving
around the bitcoin protocol and related technologies. What I am saying
is your discussion topic is not relevant to the long established theme
of this list. Please have a bit of decorum and respect for people who
joined this list so they could participate in and review
technical/academic topics.
Clearly there *should* be a general bitcoin discussion list somewhere,
I don't disagree (and I have repeatedly asked for one to be created),
but regardless, this list isn't it. The flood of off topic and
non-technical posts make it almost impossible to follow any technical
proposals.

2023-06-07 19:37:44

- reply

📅 Original date posted:2015-08-31
📝 Original message:While this topic is very interesting, I do not see how it is relevant
to a mailing list dedicated to technical and academic debate. Please
can you take this discussion elsewhere.
On Mon, Aug 31, 2015 at 10:35 AM, Zach G via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> When I say de-centralized I mean it, all the things you listed are
> centralized. Reddit is actually a purely centralized system and just as
> unhealthy as the current bitcoin forum. We have the technology, I'm simply
> putting together the pieces that other people have already built. This forum
> will literally be uncontrollable in raw form, once it's unleashed it can't
> be stopped. It will exist on thousands of computers so it cannot be
> destroyed, it will not be centrally hosted.
>
> I expect users to create their own external software to parse the data, so
> people can centralize as much or as little as they want in their own
> 'sub-forums' built on this system. I will be releasing some very rudimentary
> external software/website to go along with this de-centralized system just
> so people can post and read what's posted, and will worry about the finer
> details at a later time.
>
> There will be various leaders who utilize this program and organize quality
> forums, but fundamentally the raw de-centralized system cannot be
> controlled, so people posting to it will always have a venue to speak
> without being censored.
>
> I actually started this project to create a journal of uncensored scientific
> research, but it didn't take long to realize this sort've thing is useful
> for pretty much everyone, so I'm rushing the basic release out. Then I will
> work on making my science journal 'sub-forum' software and everyone else can
> do whatever they want.
>
>
> -----Original Message-----
> From: NxtChg <nxtchg at hush.com>
> To: hurricanewarn1 <hurricanewarn1 at aol.com>; bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org>
> Sent: Mon, Aug 31, 2015 4:45 am
> Subject: Re: [bitcoin-dev] Censorship
>
>
>>I am creating a de-centralized forum, and I mean truly decentralized as I
>> nor
> anyone else will be able to control it.
>
> Zander is working on the same thing:
> https://www.reddit.com/r/AetheralResearch/
>
> But it's actually quite difficult
> to make it truly censorship-resistant: both in solving the theymos factor
> and
> spam/abuse/overloading as an attack.
>
>
>>There is no doubt that the
> centralization and censorship of the Bitcoin community is massively
> inhibiting
> the advance of Bitcoin
>>and also the growth of the Bitcoin economy. We are
> scaring away intellectuals, businessman, and newbies that are just getting
> started.
>
> We have /r/bitcoinxt and so far it has been great. But we also need
> a regular forum.
>
> Roger Ver controls bitcoin.com, as I understand?
> https://bitcoin.com/forum/ would be nice.
>
> And it must be a real community,
> not "say whatever you want because free speech". We've seen how that turned
> out
> to be.
>
> Something like battle.net or Steam forums: heavily moderated, not for
> opinions, but for spam/noise/insults.
>
> Again, this needs leadership. Anyone
> can install a forum software, what is needed is an "official seal of
> approval"
> and regular presence of top XT people there.
>
> And a will to setup proper
> moderation. Then people will move.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:37:05

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
> discussion?
Well -dev or both, I dont particularly see a difference at the moment,
and establishing two lists isnt really going to make a difference so
long as Bitcoin Core is the reference client, which it is by defacto.
The risk of having too many lists is interested stakeholders will miss
a discussions. Normal protocol and core discussions are usually pretty
low volume in any case.
> As Jorge notes, a general discussion list has existed for a long time with
> little use.
I would suggest it's only because there havent been any rules for -dev
that would force general discussion over to the bitcoin list. On IRC
we regularly tell people in #bitcoin-dev they are OT and ask them to
move to #bitcoin and as a result, -dev remains quite clear of chit
chat, #bitcoin has a steady stream of general chatter.
We could reduce the OT/noise of bitcoin-dev list considerably by
offloading the non-technical/academic debate to the bitcoin list. It
just needs a bit of shepherding. I am more than happy to help out.
Especially if the list already exists, we should consider making a
decision now.
Who are the moderators for that list? Do we really want to use
sourceforge or are there alternatives, like another list on
linuxfoundation?
ping @Warren.

2023-06-07 19:37:04

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
> But technical people run away from noise while non-technical people
> chase them wherever their voices sounds more loud.
>
Regarding disruptors, if there are clear rules about what is acceptable on
-dev, one can simply moderate out offenders. It's absolutely necessary we
have a forum where we can share and discuss purely academic and technical
matters. No-one can accuse censorship because all moderation would say
would be to "take it to the other list". It's essential for all people who
are developing and maintaining Bitcoin protocol software, or services that
rely on it. The mailing list used to be very low volume.
While we are at it, we should also think about a bitcoin-announce read only
list which consumers of Bitcoin Core can subscribe for announcements about
new versions of Bitcoin Core, and any critical warnings. Miners and service
providers would particularly benefit from this. The list is moderated so
only say Bitcoin Core commit engineers are allowed to post.
> One thing that I would like though, is separating Bitcoin
> Core-specific development from general bips and consensus discussions.
>
The potential downside is too much separation becomes confusing although I
would not oppose such a change. My own suggestion would be try just a -dev
and -discuss list and see how that goes first. It used to work well.
Whatever the case I am very confident we need a general discussion mailing
list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/4f650849/attachment.html>

2023-06-07 19:36:59

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 2:24 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> What problem am I missing if we just mask of the offending bits. For my own project which uses auxpow (and thus has weird nVersion), I also used the bitmasking method to get rid of auxpow version bits before making the standard integer comparisons to deploy BIP66 using IsSuperMajority():
>>
>> if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...)) { //...}
>
> What if version number 257 is used in the future? That would appear to be a version 1 block and fail the test.
To clarify this is the code example for how the same problem occurs
with auxpow bits when running a an IsSuperMajority() softfork and how
it's solved in that instance.
In our case for Bitcoin Core, option 2 we use nVersion=8, apply a
bitmask of 0xdffffff8 thus:
if ((block.nVersion & ~0x20000007) >= 4 &&
CBlockIndex::IsSuperMajority(...)) { //...}
With nVersion=8, but using comparison >=4 allows us to recover the
bit later, assuming we want it (otherwise we use version >=8).
This should, unless I am missing something, be forward compatible with
future softforks. My understanding was if "versionbits softfork" code
is not ready by the time we're ready for the deployment,
IsSuperMajority() would be acceptable; and this is how we could deploy
it in the wake of the XT developers' carelessness.

2023-06-07 19:36:59

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 11:31 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I don't think just using version=4 for cltv and friends would be a
> problem if it wasn't for the XT/nonXT issue.
What problem am I missing if we just mask of the offending bits. For my own
project which uses auxpow (and thus has weird nVersion), I also used the
bitmasking method to get rid of auxpow version bits before making the
standard integer comparisons to deploy BIP66 using IsSuperMajority():
if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...))
{ //...}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/aeca027e/attachment.html>

2023-06-07 19:36:58

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Seems like 3 is something we want to do no matter what and therefore
> is the "most future-proof" solution.
> I wonder if I can help with that (and I know there's more people that
> would be interested).
> Where's the current "non-full" nVersion bits implementation?
> Why implement a "non-full" version instead of going with the full
> implementation directly?
There is a simple answer to this, convenience: versionbits has not been
implemented yet, and I believe the BIP is still in review stage. As it
seems likely the remaining locktime pull requests will be ready by or
before the next major release, we need a deployment method if versionbits
is not ready (which is unlikely because no-one appears to be working on it
at the moment). Pieter indicated he is OK with another IsSuperMajority()
rollout in the interim. Personally, I dont think we should let perfection
be the enemy of progress here because at the end of the day, the deployment
method is less important than the actual featureset being proposed.
That said, the features in the next soft fork proposal are all related and
best deployed as one featureset softfork, but moving forward, versionbits
seems essential to be able to roll out multiple features in parallel
without waiting for activation and enforcement each time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/abd890c2/attachment.html>

2023-06-07 19:36:52

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I like the intend of this attempt to bring more clarity to the blocksize
> debate, however it would be more help to make this a information site about
> the current outstanding BIPs and summarize their differences rather than
> voting mechanism.
> (ofcourse the author of the BIPs would "vote" for their own proposals.)
>
> It would be good to include supporting and counter statements regards to
> these BIPs on the site.
> in addition to highlight certain things like pools in china have voiced
> their opinion that increase should happen, and 8mb is something they are
> comfortable with, which is not directly related to a single BIP, but never
> the less relevant in this discussion.
I was rather surprised by the tweet from AntPool[1] today saying that
they support big blocks and would be prepared to upgrade to XT. Pools
have stated that they are willing to increase to a maximum of 8MB, but
upgrading to XT puts them on a schedule towards 8GB which is clearly
not what they have agreed to.
Do you have any insights into what's going on there?
Also do you have any insight into what Chinese pools would accept as a
compromise in terms of raising the blocksize limit?
Drak
[1] https://twitter.com/JihanWu/status/633288343338381314

2023-06-07 19:36:51

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> What might be valuable is to ask devs to explain what their threat models are, what should be at the root of their thinking about the blocksize.
That's exactly what the "Technical Opinion" column is for.

2023-06-07 19:36:50

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Fri, Aug 21, 2015 at 6:10 AM, Nicolas Dorier via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Decision making is not the goal of this site, it is only a way to see
> various pros and cons of various devs on various proposals in a single
> place.
> This is for the community to have a coherent view about what you are talking
> about now spread into reddit/mailing/forums.
>
> If you did not analyzed a proposal yet, you don't have to fill out your
> opinion veto or approval.
> It is only to show what you would you "approve" and what you would "veto",
> after your analysis.
> Then point out all the discussions in the opinion section that lead you to
> your conclusion.
>
> You can change edit your position as you progress into your analysis and as
> new BIP get redacted.
> I'm eager to include the new proposals.
The most important part that developers should complete is the
"Technical Opinion" column section where they can explain their
general worldview, what their concerns are, how those concerns would
be alleviated. If one is undecided or does not have enough information
regarding each BIP then dont fill it out. That also helps signal the
level of consensus for a proposal.
As it stands at the moment, it's almost impossible to direct someone
at the opinion of a specific developer other than hunting down a few
gems scattered to the four corners of the universe. I tried recently
and it was simply impossible. At least with this system, specific BIPs
aside, we can easily see the view of each developer. I think most of
us can comment on BIP101 since the BIP appears non-negotiable.
The XT faction are easily winning the media war by obscuring rational
debate by high signal to noise ratio. Nicolas' solution means the most
important views expressed by each heavyweight will not get lost and
serve as a good reference point for everyone, including the media.
The site could be extended to include major stakeholders too like
major service providers (think exchanges, wallet providers etc) and
mining pools.

2023-06-07 19:36:49

- reply

📅 Original date posted:2015-08-21
📝 Original message:I was looking at this site recently and it's not very clear that by
clicking the name you get their opinion. I would make that a separate
column stated, Technical Opinion.
I think you need to include more of the developers/technical people,
Adam Back, Mark Friedenback, Jorge Timons, (all of who are core
developers). You need
Peter Todd is a core dev btw, as is thebluematt.
You need other experts, I would include Nick Szabo, Meni Rosenfeld,
Charlie Lee might be a good one. You should get the pools on there
too.
You're missing Mike Hearn of course.
My key is 0xE5D138F5E73A1AF2
On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I created a small website which show a chart of your approvals about various
> BIPs (which you must fill by yourself with a signed pgp message)
>
> For each BIP, you can fill if you approve or not, and give comments. (HTML
> accepted, so you can link stuff you your posts)
>
> It would help the community a lot, so I hope you will do it !
> I'm open to add other important devs, big miners, or other proposal that I
> missed.
>
> Please, respond on BTC Talk or github. (I don't read the mailing anymore
> because of the spam :( )
>
> Link : http://bipsxdevs.azurewebsites.net/
> BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164
> Github : https://github.com/NicolasDorier/BIPxDevs
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:36:36

- reply

📅 Original date posted:2015-08-27
📝 Original message:This BIP was assigned number 113.
I have updated the text accordingly and added credits to Gregory Maxwell.
Please see the changes in the pull request:
https://github.com/bitcoin/bips/pull/182
On Sat, Aug 22, 2015 at 1:57 AM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote:
>>
>> I submitted the pull-request for the median-past timelock BIP just now
>>
>> https://github.com/bitcoin/bips/pull/182
>>
>> Any luck finding the link to this discussion? It would be nice to
>> include this for posterity.
>
> Found it! From #bitcoin-wizards, 2013-07-16:
>
> 23:57 < petertodd> See, it'd be possible for nLockTime w/ time-based locks to create some really ugly incentives for miners to mine blocks at thelimit of the 2hr window - a timestamping chain could provide a way for nodes to at least detect that their clocks are off, especially given how peers can mess with them.
> 23:58 < petertodd> It's still dodgy though... I was thinking if nLockTime-by-time inclusion was based on the previous block timestamp it'd be ok, but that still leaves large miners with incentives to screw with the 2hr window, never mind how it can reduce competition if there exists clock skew in the mining nodes.
> --- Log closed Wed Jul 17 00:00:57 2013
> --- Log opened Wed Jul 17 00:00:57 2013
> 00:01 < petertodd> (remember that if this is a timestamping facility any node wanting to know the current time simply gets a nonce timestamped, and then they know what time it is!)
> 00:11 < Luke-Jr> I don't see how nLockTime can discourage forward-dating blocks
> 00:11 < Luke-Jr> and there is no 2hr window backward..
> 00:12 < Luke-Jr> well, I guess if miners are behaving there is <.<
> 00:19 < petertodd> The problem is a block being created with nTime > actual time, and the incentive is to get a head start on other miners to put, say, a high-fee nLockTime in the block you are creating.
> 00:21 < Luke-Jr> petertodd: but nLockTime only sets a minimum time, it cannot set a maximum
> 00:22 < petertodd> but that's it, if I have a 1BTC fee tx, with nLockTime expiring in two hours, why not take the increased orphan chance and set nTime on my block to two hours ahead/
> 00:22 < petertodd> ?
> 00:22 < petertodd> yet if we allow that incentive, it's very bad for consensus
> 00:23 < gmaxwell> ha. We can fix.
> 00:23 < gmaxwell> it's a soft forking fix.
> 00:23 < gmaxwell> use the last blocks ntime, not this one.
> 00:23 < Luke-Jr> is sipa's secp256k1 branch reasonably stable?
> 00:23 < petertodd> gmaxwell: that's what I said...
> 00:24 < gmaxwell> petertodd: sorry I just read the last couple lines.
> 00:24 < Luke-Jr> petertodd: AFAIK we already don't relay transactions with time in the future?
> 00:24 < gmaxwell> petertodd: well I agree. (or not even the last block— it could use the minimum time)
> 00:24 < petertodd> gmaxwell: The problem is, that's only a fix if mining power is well distributed, it actually makes things worse because if there is a lot of profit to be gained the miners with a lot of hashing power still have the incentive, and it's to a much greater degree. (their orphan rate is less)
> 00:24 < Luke-Jr> gmaxwell: the minimum time will be earlier than the last block's :p
> 00:25 < gmaxwell> Luke-Jr: sure, but that doesn't change it really. Presumably if people start locking in the future miners will run nodes that take what they get and selfishly horde them, creating incentives for all miners to run good collection networks.
> 00:25 < petertodd> Luke-Jr: sure, but there are lots of ways to learn that a tx exists
> 00:26 < gmaxwell> petertodd: one of the reasons that the min is important there is because (1) it's hard to advance, and (2) when you advance it you raise the difficulty.
> 00:26 < petertodd> gmaxwell: I was working on figuring out the expected return - the math is really ugly
> 00:27 < gmaxwell> petertodd: a worst case expected return may be easier.
> 00:27 < petertodd> gmaxwell: Worst case is easy - your block is orphaned.
> 00:28 < petertodd> gmaxwell: See the issue is that once I find a block, the other side needs to find two blocks to beat me. As time goes on more of the other sides hashing power will accept my from the future block as valid, so then you get the next level where the remainder needs three blocks and so on.
> 00:28 < petertodd> gmaxwell: Pretty sure it can't be done as a closed-form equation.
> 00:30 < petertodd> gmaxwell: I don't think minimum time works either, because you still get to manipulate it by creating blocks in the future, although the ability too is definitely less. If I could show you'd need >50% hashing power to do anything interesting I'd be set.
> 00:31 < Luke-Jr> petertodd: hmm, is block-uneconomic-utxo-creation basically just an older revision of what Gavin did in 0.8.2?
> 00:31 < gmaxwell> petertodd: moving the minimum time forward needs the coperation of >50% of the hashpower over the small median window.
> 00:32 < petertodd> Luke-Jr: It's what Gavin did but non-hardcoded. I'd emphasize the better, not the older. :P
> 00:32 < Luke-Jr> petertodd: will you be rebasing it despite its closed status?
> 00:32 < Luke-Jr> actually, what about Gavin's is hardcoded? <.<
> 00:33 < petertodd> gmaxwell: Yeah, but you have to assume a steady stream of these incentives.
> 00:33 < gmaxwell> petertodd: right, so you have some force that turns all miners into a conspiracy.
> 00:34 < petertodd> gmaxwell: exactly
> 00:34 < petertodd> gmaxwell: nLockTime by time should have never been added in the first place, but it's such a nice idea on the face of it
> 00:35 -!- realazthat is now known as rudeasthat
> 00:35 -!- rudeasthat is now known as rudest
> 00:35 < Luke-Jr> softfork so nLockTime requires data on what block a transaction was created at, and enforces the 10 min per block <.<
> 00:36 -!- rudest is now known as heh
> 00:36 < petertodd> Luke-Jr: ?
> 00:36 -!- heh is now known as realz
> 00:36 < Luke-Jr> petertodd: for example, if you nLockTime for 1 day from now, it also enforces 144 blocks passing too
> 00:37 < Luke-Jr> so block count must be >now+144 AND time must be >now+24h
> 00:37 < Luke-Jr> not perfect, but might help
> 00:37 < petertodd> Still doesn't help in the usual case where mean interval is < 10 minutes, because you're back to only caring about time.
> 00:38 < Luke-Jr> usual now, but not eventually
> 00:38 < petertodd> Right, you've solved half the problem, when measured over the entire lifespan of Bitcoin, and only approximately half. :P
> 00:39 < Luke-Jr> theory is so much nicer than practice <.<
> 00:39 < gmaxwell> I'm forgetting why this is a problem again? If miners mine blocks early, people will just artifically inflate their times or switch to height locking.
> 00:39 < petertodd> The problem is you're incentivising miners to make the 2hr window for block acceptance effectively shorter.
> 00:39 < petertodd> Thus requiring accurate clocks for consensus.
> 00:39 < gmaxwell> if miners do this consistently they'll drive difficulty up too which wouldn't be in their interest.
> 00:39 < Luke-Jr> ^
> 00:40 < petertodd> gmaxwell: It's only a fixed 2hr offset, that just drives difficulty up by 0.5%
> 00:40 < Luke-Jr> and on top of that, you'd just end up treating nTime with a minus-2-hours :p
> 00:41 < Luke-Jr> if everyone does it, it's predictable.
> 00:41 < petertodd> More to the point for any individual miner the marginal difference if they do it is effectively zero.
> 00:41 < gmaxwell> consider, why why cant the 2 hour window be 24 hours?
> 00:41 < petertodd> Luke-Jr: But that's the problem, if everyone does it, and people respond, then you can extend the interval even further!
> 00:41 < Luke-Jr> petertodd: how?
> 00:41 < petertodd> gmaxwell: It should have been more like 24 hours in the first place...
> 00:42 < Luke-Jr> you don't change the 2h rule
> 00:42 < Luke-Jr> you just assume miner times will always be up against it
> 00:42 < gmaxwell> Luke-Jr: move your clock/window forward so you dont reject stupid blocks.
> 00:42 < petertodd> Luke-Jr: Again, the issue is the effect on *consusus*. I don't care when the tx gets mined, I care that miners are incentivised to break consunsus for anyone without NTP.
> 00:43 < petertodd> The problem is no matter *what* the window is, there is an incentive to mine as close to the window as possible to accept a tx sooner than your competitors.
> 00:43 < petertodd> It could be a week and people would still have an incentive to set nTime + 1 week - 1 second
> 00:44 < Luke-Jr> if nTime is future, wait until that time before relaying it? <.<
> 00:44 -!- realz is now known as pleasedont
> 00:44 < gmaxwell> and once people did that, you'd want to start accepting blocks that where nTime + 1 week because god knows you don't want to reject a block if your clock was 2 seconds slow and most hashpower accepted it.
> 00:44 < petertodd> About the only thing that might change that is if the rule was nLockTime > nTime of last block, and then after that being allowed to include a tx was based on H(txhash, last hash) or similar
> 00:45 < petertodd> gmaxwell: exactly, the fundemental issue is there is no good incentive to set nTime accurately other than miners rejecting your blocks, and nLockTime sabotages that
> 00:45 -!- pleasedont is now known as realzies
> 00:45 < petertodd> gmaxwell: (timestamping could do, but the cause->effect is less obvious)
> 00:45 < Luke-Jr> I guess I just incentivized always setting nTime to the minimum then
> 00:45 < Luke-Jr> [04:32:26] <Luke-Jr> petertodd: will you be rebasing it despite its closed status? (block-uneconomic-utxo-creation)
> 00:46 < petertodd> Luke-Jr: again, relaying does nothing - consider the case of nLockTime'd fidelity bonds where it's guaranteed 100% of the hashing power know (why I wrote the spec as by-block-height in the first place)
> 00:46 < petertodd> Luke-Jr: sure
> 00:46 < Luke-Jr> petertodd: I mean delaying relaying the BLOCK
> 00:46 < Luke-Jr> ie, increasing the risk of it being stale
> 00:47 < petertodd> Luke-Jr: then you have your mining pool connect directly to other mining pools playing the same game
> 00:47 < petertodd> you have to assume perfect information knowledge in this stuff, at least if you're writing worst-case academic papers
> 00:48 < gmaxwell> petertodd: so ... prior block vs minimum time.
> 00:48 < petertodd> see, that's why I was talking about timestamping, because it provides a way for all users to set their clocks to what the majority of hashing power thinks nTime is, sidestepping the problem
> 00:48 < gmaxwell> petertodd: what are your arguments there?
> 00:48 < petertodd> gmaxwell: minimum time is definitely stronger because it involves more hashing power
> 00:49 < petertodd> gmaxwell: users would prefer minimum time - easier to understand why the tx isn't getting mined
> 00:49 < gmaxwell> sidestepping the problem < that doesn't sidestep the problem, it would allow the majority of hashpower to mine difficulty down to 1; also moots nlocktime as _time_ being more reliable than a height.
> 00:49 < gmaxwell> petertodd: plus, you can just add a constant offset to your nlocktime to adjust for the expected minimum lag.
> 00:51 < petertodd> gmaxwell: yes, it creates a new problem, but it did sidestep the existing one :P
> 00:51 < gmaxwell> petertodd: yea, lol, creates an inflation attack. Keep it up and you'll be qualified to create an altcoin. :P
> 00:52 < gmaxwell> (sorry, hah, I'm not poking fun at you, I'm poking fun at all the altcoins that "solved the Foo problem" where foo is something no one else thinks is a problem and they totally broke security as a side effect)
> 00:52 < petertodd> gmaxwell: yup, now you see how it only sidesteps the problem truly when there is enough hashing power setting their clocks back, IE 50% honest, which is better
> 00:53 < petertodd> gmaxwell: without the timestamping, nodes have the consensus failures, which can be attacked, likely it trades off one risk for a more existential risk
> 00:53 < petertodd> gmaxwell: and it's a good excuse for timestamping, lol
> 00:54 < gmaxwell> I thin the min solves the consensus failure so long as hashpower is well distributed.
> 00:54 < petertodd> yeah, I'm thinking min is probably the best we can do
>
> https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-16.log
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:36:18

- reply

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Nobody is going to click that...
I guess I am nobody. Here's a copy of the text:-
*Dynamically Controlled Bitcoin Block Size Max Cap
<http://upalc.com/maxblocksize.php>*
*Assumption*: This article is for those, who already understand the bitcoin
protocol and aware of the block size controversy. Details of the problem
statement can be found in BIP 100
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
Satoshi's opinion regarding block size can be found here
<https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will be
directly going into the solution without explaining the problem in details.
*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do
just another calculation here. Nodes will also calculate what % of blocks
in the last difficulty period is higher than 90% of the maximum block size,
which is 1 MB for now. If it is found that more than 90% blocks in the last
difficulty period is higher than 90% of the maximum block size, then double
the maximum block size. If not, then calculate what % of blocks in the last
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.
Please note that, while calculating the % of blocks, it is better to take
into account the first 2000 of the 2016, than the whole of 2016. This helps
to avoid the calculation mistake if some of the last few blocks get
orphaned.
*Reasoning*: This solution is derived directly from the indication of the
problem. If transaction volume increases, then we will naturally see bigger
blocks. On the contrary, if there are not enough transaction volume, but
maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.
*Other Solutions of this Problem*:-
Making Decentralized Economic Policy
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
Jeff Garzik
Elastic block cap with rollover penalties
<https://bitcointalk.org/index.php?topic=1078521> – by Meni Rosenfeld
Increase maximum block size
<https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by Gavin
Andresen
Block size following technological growth
<https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
<https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
Thaddeus Dryja
Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.
> On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> 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/20150817/9a6dca23/attachment.html>

2023-06-07 19:35:51

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> ignored the warnings. Many also warned that 75% was an optimally BAD
> trigger ratio (and that in a hard fork it is not a miner vote really
> as in soft-forks). Gavin & Mike ignored that warning to. I know they
> heard those warnings because I told them 1:1 in person or via email
> and had on going conversations. Others did too.
I would like to add for the record, I also warned Gavin of this in his
PR to Bitcoin Core, and also suggested a timeout which if
activation/enforcement did not occur within, hard fork deployment
would be cancelled. His response was to delete these from the PR
claiming thresholds were not relevant conversation in his PR and
belonged elsewhere (even though they had already been discussed
elsewhere).

2023-06-07 19:35:51

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd <pete at petertodd.org> wrote:
> Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
> other users' comments on their own pull-reqs...
>
> IMO that's an abuse of the pull-req process, and in turn, Gavin
> Andresens's commit access rights for the Bitcoin Core repo.
For the avoidance of doubt here's the archive link of my comment
https://archive.is/omvSY#40% (call me paranoid)
and here's where he tells me he's censored my posts https://archive.is/vym6N#40%
> I think this should weigh in favor of Gavin Andresen not having commit
> privileges for the Bitcoin Core repository.
It's time.

2023-06-07 19:35:39

- reply

📅 Original date posted:2015-08-17
📝 Original message:For the record I would like to share my technical analysis of the Satoshi
email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few days
ago.
1. The email is the one used by Satoshi to announce Bitcoin in the first
place.
http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
2. The email was not spoofed, it actually originated from vistomail's
server. The email headers show the email originated from 190.97.163.93 and
the SPF records show this as an authorised sender for the email. This does
not prove the account wasn't hacked of course, or that the account might
have expired and be re-registered by someone else (vistomail is a paid for
email provider).
3. While the email is not signed, and there are a number of PGP keys listed
on key servers for him (to vary addresses), he didnt sign any emails with
any PGP keys.
It is therefore not possible to outright dismiss the email's authenticity
as the email originates from an authentic source. The only questions is
whether the webmail service was hacked or commandeered somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/14bc2afd/attachment.html>

2023-06-07 19:35:01

- reply

📅 Original date posted:2015-08-25
📝 Original message:This BIP has been assigned BIP112 by the BIP repository maintainer. I
have updated the pull request accordingly.
Regarding the suggestion to cannibalise version, by your own
disadvantage list, we would lose fine grained control over txins which
neuters the usefulness considerably. Also using version is also ugly
because there isn't a semantic association with what we are trying to
do, whereas, sequence is associated with transaction finality and is
thus the more appropriate and logical field to use.

2023-06-07 19:34:56

- reply

📅 Original date posted:2015-08-17
📝 Original message:Please note there is now a PR for this BIP[1] and also a pull request for
the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
[1] https://github.com/bitcoin/bips/pull/179
[2] https://github.com/bitcoin/bitcoin/pull/6564
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/364f36b8/attachment.html>

2023-06-07 19:34:53

- reply

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

2023-06-07 19:33:41

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Mon, Aug 10, 2015 at 12:55 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Gavin, I interpret the absence of response to these questions as a
> sign that everybody agrees that there's no other reason to increase
> the consensus block size other than to avoid minimum market fees from
> rising (above zero).
> Feel free to correct that notion at any time by answering the
> questions yourself.
> In fact if any other "big block size advocate" thinks there's more
> reason I would like to hear their reasons too.
Additionally, correct me if I am wrong, but the net effect from preventing
fees rising from zero would be to guarantee miners have no alternative
income from fees as block subsidy dries up and thus harm the incentives to
secure the chain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/1476e03a/attachment.html>

2023-06-07 19:33:10

- reply

📅 Original date posted:2015-08-09
📝 Original message:I thought it's worth mentioning there is a specific Lightning Network
development mailing list at
http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
some pretty interesting explanations in the archives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/73ecb74d/attachment-0001.html>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-08-19
📝 Original message:I see no problem with Satoshi returning to participate in peer review.
Bitcoin development has long since migrated from a single authority figure
to a system of technical peer review consensus. What is more of a problem
is this list has degenerated to a generalised discussion forum where any
academic or technical debate is drowned out by noise.
I joined this list so I keep be abreast of bitcoin's technical development
and proposals. I am sure many ecosystem stakeholders and participants also
once used this list to keep abreast of technical developments and academic
research. It would be splendid indeed if we could return to some semblance
of decorum that once existed.
Do you think we could have a "bitcoin-discuss" list where specifically
non-technical discussion can happen leaving this list for more academic and
technical debate together with setting a clear mandate about what is on
topic for this list?
On Tue, Aug 18, 2015 at 12:52 PM, Micha Bailey via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My interpretation is that he's saying Satoshi wouldn't be welcome to
> return as Satoshi, because whatever he did/said would inevitably end up
> being treated with authority, which shouldn't be the case.
>
>
> On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I honestly don't understand your position, but I get the sense that you
>> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
>> active in development again?
>>
>> Warren
>> On Aug 17, 2015 1:38 PM, "Oliver Egginger" <bitcoin at olivere.de> wrote:
>>
>>> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
>>> > This bitcoin-dev list restarted with an empty subscriber list on June
>>> > 21st, 2015. So whoever posted from satoshi at vistomail.com
>>> > <mailto:satoshi at vistomail.com> subscribed and verified the address
>>> > recently. Do you propose that we manually approve new subscribers to
>>> > prevent these kind of "abuses" as you put it?
>>>
>>> I would simply block the creators old email addresses. Easy with
>>> Mailman. I thought that would be a good and easy approach, but maybe I'm
>>> wrong.
>>>
>>> Some believes it is possible that the email could be genuine. Some say
>>> that only the content is important. I have closely followed. An
>>> interesting discussion. Thank you all so far.
>>>
>>> But let's say the poster would be the real Satoshi. Would we discuss his
>>> posting if he would not claim to be Satoshi? There are a lot of smart
>>> people on this list, which publish occasionally quite useful ideas. But
>>> much of this is hardly the subject of greater discussion. Especially not
>>> when it comes to the blocksize. On this subject almost everything has
>>> been already said. But not yet by everyone. Especially not by Satoshi.
>>>
>>> Satoshi would have a decisive influence on the community. I'm sure. To
>>> say it does not matter who's talking is maybe genteelly but a little bit
>>> remote from everyday life. Or not? Satoshi is the creator. What he says
>>> is in the newspaper and is perceived by all. If he says it's okay to do
>>> nothing as long as we stand together, then people have the courage to do
>>> maybe something dangerous or something wrong. Then people only follow
>>> their hearts. Otherwise they follow their fear. It is a paradox of the
>>> human nature that some type of Dictatorship can make you free. I say
>>> some type, not any type. Enough said.
>>>
>>> - oliver
>>>
>>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/f49ea8d0/attachment.html>

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-06-21
📝 Original message:Thanks for all your hard work setting this up, and to everyone else
involved.
Drak
On Sun, Jun 21, 2015 at 10:29 PM, Warren Togami Jr. <wtogami at gmail.com>
wrote:
> Hi folks,
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> The move is now complete. The previous archive has been fully imported
> and new posts here will now be saved.
>
> *Greylisting Notice*
> Your first post to this list may be delayed by 5+ minutes due to
> Greylisting <https://en.wikipedia.org/wiki/Greylisting>. Subsequent posts
> should go through without delay. Contact Freenode #bitcoin-dev if you have
> any questions or concerns.
>
> *TODO*
>
> - LF will be upgrading Mailman soon to better handle posts from DKIM
> enforced domains.
> - There will be a few more config tweaks like auto-rejecting
> non-subscribed posts. Nobody has time to moderate this list, and mail
> silently disappearing into the moderation hold blackhole is worse than an
> instant reject message telling people to subscribe. Unfortunately, it is
> too dangerous to auto-reject spam ... those messages need to go into a
> blackhole to prevent bounce abuse.
>
> Warren Togami
>
>
>
> _______________________________________________
> 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/20150621/0a8bbc88/attachment.html>

2023-06-07 17:39:12

- reply

📅 Original date posted:2015-06-21
📝 Original message:Eric,
BitPay clearly do understand the risks of 0-conf. In case you were not
aware BitPay does not particularly "accept zero confirm transactions". When
a payment is seen on the network the payment screen reports the invoice has
been paid, but that's front-end user facing. On the back end it's marked as
paid but the API exposes the the confirmation status allowing the merchant
to make business decisions about when to progress to fulfilment. A good
example of this is Neteller (a sort of paypal variant) which allows one to
fund the account with fiat using Bitcoin, via Bitpay. When you pay the
bitpay invoice, your account is marked as payment pending until there are
some confirmations.
Coinbase does not expose the confirmation status and from what I understand
(not checked myself) they guarantee payment to merchants for 0-confirm,
regardless of whether they confirm or not.
I want to address something stated by Justus, that signing a payment
message and broadcasting somehow solidifies intent and going back on that
would be fraud. This seriously conflates cryptographic certainty with human
behaviour. For one, humans make mistakes all the time. We get tired, we get
distracted, we make copy paste errors. It's entirely possible on sends a
payment only to find it's been sent to the wrong address or the wrong
amount has been sent or the fee is wrong. Software may also misbehave
(Electrum for example has a weird UI glitch with fees where the specified
fee can be overwritten). r/bitcoin it littered with sad examples. What
ECDSA signing tells is that it was signed by your private key, but nothing
else. It does not say if *you* signed it, or that the message you signed
was correct.
On Sun, Jun 21, 2015 at 8:42 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>> but we NEED to be applying some kind of pressure on the merchant end to
>> upgrade their stuff to be more resilient
>>
>
> Can you be specific? What precise technical steps would you have BitPay
> and Coinbase do? We upgrade our stuff to... what exactly?
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>
>
> As for software tools to accomplish these things, we can talk about that
> offline :)
>
>
> - Eric Lombrozo
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150621/4abdd8ca/attachment.html>

2023-06-07 17:37:08

- reply

📅 Original date posted:2015-06-08
📝 Original message:On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . <raystonn at hotmail.com> wrote:
> No, with no blocksize limit, a spammer would would flood the network with
> transactions until they ran out of money.
I think you are forgetting even if you remove the blocksize limit, there is
still a hard message size limit imposed by the p2p protocol. Block would
de-facto be limited to this size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150608/961926e8/attachment.html>

2023-06-07 17:33:26

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 5:11 PM, Mike Hearn <mike at plan99.net> wrote:
> Right now there is this nice warm fuzzy notion that decisions in Bitcoin
>> Core are made by consensus. "Controversial" changes are avoided. I am
>> trying to show you that this is just marketing.
>
>
Consensus is arrived when the people who are most active at the time
(active in contributing to discussions, code review, giving opinions etc.)
agreed to ACK. There are a regular staple of active contributors. Bitcoin
development is clearly a meritocracy. The more people participate and
contribute the more weight their opinions hold.
> Nobody can define what these terms even mean. It would be more accurate to
>> say decisions are vetoed by whoever shows up and complains enough,
>> regardless of technical merit. After all, my own getutxo change was merged
>> after a lot of technical debate (and trolling) ..... then unmerged a day
>> later because "it's a shitstorm".
>
>
I am not sure that is fair, your PR was reverted because someone found a
huge exploit in your PR enough to invalidate all your arguments used to get
it merged in the first place.
> So if Gavin showed up and complained a lot about side chains or whatever,
> what you're saying is, oh that's different. We'd ignore him. But when
> someone else complains about a change they don't like, that's OK.
>
> Heck, I could easily come up with a dozen reasons to object to almost any
> change, if I felt like it. Would I then be considered not a part of the
> consensus because that'd be convenient?
>
I don't think it's as simple as that. Objections for the sake of
objections, or unsound technical objections are going to be seen for what
they are. This is a project with of some of the brightest people in the
world in this field. Sure people can be disruptive but their reputation
stand the test of time.
The consensus system might not be perfect, but it almost feels like you
want to declare a state of emergency and suspend all the normal review
process for this proposed hard fork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/6d310e9c/attachment.html>

2023-06-07 17:33:26

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 3:05 PM, Mike Hearn <mike at plan99.net> wrote:
>
> Maybe you dislike that idea. It's so .... centralised. So let's say Gavin
> commits his patch, because his authority is equal to all other committers.
> Someone else rolls it back. Gavin sets up a cron job to keep committing the
> patch. Game over.
>
> You cannot have committers fighting over what goes in and what doesn't.
> That's madness. There must be a single decision maker for any given
> codebase.
>
You are conflating consensus with commit access. People with commit access
are maintainers who are *able to merge* pull requests. However, the rules
for bitcoin development are that only patches with consensus get merged. If
any of the maintainers just pushed a change without going through the whole
code review and consensus process there would be uproar, plain and simple.
Please don't conflate commit access with permission to merge because it's
just not the case. No-one can sidestep the requirement to get consensus,
not even the 5 maintainers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/3061743b/attachment.html>

2023-06-07 17:33:16

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 7:40 PM, Gavin Costin <slashdevnull at hotmail.com>
wrote:
> Can anyone opposed to this proposal articulate in plain english the worst
> case scenario(s) if it goes ahead?
>
> Some people in the conversation appear to be uncomfortable, perturbed,
> defensive etc about the proposal …. But I am not seeing specifics on why it
> is not a feasible plan.
>
See this response:
http://www.mail-archive.com/[email protected]/msg07462.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/7ec7417f/attachment.html>

2023-06-07 17:33:15

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 6:43 PM, Mike Hearn <mike at plan99.net> wrote:
>
> And I'll ask again. Do you have a *specific, credible alternative*?
> Because so far I'm not seeing one.
>
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do not believe there is
any urgency, nor that there is an immanent problem that has to be solved
before the sky falls in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/ae2e1450/attachment.html>

2023-06-07 17:33:06

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 10:25 AM, Mike Hearn <mike at plan99.net> wrote:
> What I don't see from you yet is a *specific and credible plan* that fits
> within the next 12 months and which allows Bitcoin to keep growing. Not
> some vague handwave like "let's all use the Lightning network" (which does
> not exist), or "let's do more research" (Gavin has done plenty of
> research), or "but what about the risks" (Bitcoin is full of risks). A
> plan, with dates attached, and a strong chance of actually being deployed
> in time.
>
Would you please explain where this 12 months timeframe comes from?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/55cd10b4/attachment.html>

2023-06-07 17:30:14

- reply

📅 Original date posted:2015-02-12
📝 Original message:On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn <mike at plan99.net> wrote:
> Peter argues that this is stable and makes unconfirmed transactions safe
>> because a fraudster can buy something, walk out of the shop, and broadcast
>> a double spend with a higher fee. But then the merchant can re-spend the
>> original payment back to themselves with an *even* higher fee than that.
>> Then the fraudster can re-spend their double spend with an *even* higher
>> fee than that, and so on back and forth, until *all* the money has been
>> spent to miner fees. Thus the merchant loses their goods but the fraudster
>> has still "paid" in some sense because they don't get the money either.
>>
>
> This argument makes no sense for two reasons.
>
> The first is that this setup means miners can steal arbitrary payments if
> they work together with the sender of the money. The model assumes this
> collaboration won't happen, but it will. Because no existing wallet has a
> "double spend this" button, to make the scheme work the dishonest miners
> must create and distribute such a wallet that implements the whole
> scorched-earth protocol. At that point it's easy for miners to reward the
> payment fraudster with some of the stolen money the merchant lost, meaning
> it now makes sense for the fraudster to always do this. The situation isn't
> stable at all.
>
> The second is that it incentivises competitors to engage in payment fraud
> against each other. A big rich coffee shop chain that is facing competition
> from a small, scrappy newcomer can simply walk into the new shop and buy
> things, then trigger the "scorched earth". Even with no miner
> collaboration, this means the big company is down the cost of the product
> *but* so is the little company who lost everything. Whoever can outspend
> the other wins.
>
I think that is a misdirection on your part. The point of replace-by-fee is
to make 0-confirms reliably unreliable. Currently people can "get away"
with 0-confirms but it's only because most people arent actively double
spending, and when they do it is for higher value targets. Double spend
attacks *are* happening a lot more frequently than is being admitted here,
according to Peter from work with various clients.
Like single address reuse, people have gotten used to something which is
bad. Generally accepting 0-conf is also a bad idea(tm) and instant
confirmation solutions should be sought elsewhere. There are already
interesting solutions and concepts: greenaddress for example, and
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than
supporting and promoting risky 0-confirms, we need to spend time on better
alternative solutions that will work for everyone and not during the
honeymoon phase where attackers are fewer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/13ef9edc/attachment.html>

2023-06-07 17:28:04

- reply

📅 Original date posted:2014-12-15
📝 Original message:On Mon, Dec 15, 2014 at 7:35 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> At a macro level, that cycle was repeated many times, leading to the
> opposite end result: a lot of tiny movement/refactor/movement/refactor
> producing the review and patch annoyances described.
>
> It produces a blizzard of new files and new data structures, breaking a
> bunch of out-of-tree patches, complicating review quite a bit. If the vast
> majority of code movement is up front, followed by algebraic
> simplifications, followed by data structure work, further patches are easy
> to review/apply with less impact on unrelated code.
>
> The flow of patches into the tree over time should be examined. Simply
> tagging patches as movement-only does not address the described problem at
> all.
>
I think we can all agree that if the process is made more friendly for
reviewers, everyone wins. It's been hard to even know where everything is
because it moves so often. e.g. In the last couple weeks stuff moved from
core.h to core/block.h to primitive/block.h or something to that effect.
Anyway, Jeff said this quite elegantly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141215/7cf75389/attachment.html>

2023-06-07 17:28:03

- reply

📅 Original date posted:2014-12-15
📝 Original message:This is a pretty good example about refactoring discipline as well as
premature/over optimisation.
We all want to see more modular code, but the first steps should just be to
relocate blocks of code so everything is more logically organised in
smaller files (especially for consensus critical code). Refactoring should
come in a second wave preferably after a stable release. Refactoring should
be in the pure sense, optimising code with absolutely no change in
behaviour.
When it comes to actual API changes, I think we need to be a lot more
careful and should be considered feature requests and get a lot more
scrutiny as we are essentially breaking backwards compatibility. #4890 was
pretty much merged with no discussion or thought yet other really simple
and uncontroversial PRs remain unmerged for months. A key question in the
case of EvalScript() would have been, "why are we passing txTo and nIn
here, and are there any future use cases that might require them? Why
should this be removed from the API and the entire method signature
changed?". BC breaks always need strong justification.
So I've expressed my concern a few times about the speed and frequency of
refactoring and also the way it's being done. I am not alone, as others not
directly connected with the Bitcoin Core project have also expressed
concerns about the number of refactorings "for the sake of refactoring",
especially of consensus critical code. Careful as we may be, we know from
history that small edge case bugs can creep in very easily and cause a lot
of unforeseen problems.
BtcDrak
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd <pete at petertodd.org> wrote:
>
> BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a
> few
> days ago and found a fairly large design change that makes merging it
> currently
> impossible. Pull-req #4890², specifically commit c7829ea7, changed the
> EvalScript() function to take an abstract SignatureChecker object,
> removing the
> txTo and nIn arguments that used to contain the transaction the script was
> in
> and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the
> nLockTime field of the transaction, and it needs nIn to obtain the
> nSequence of
> the txin.
>
> We need to fix this if CHECKLOCKTIMEVERIFY is to be merged.
>
> Secondly, that this change was made, and the manner in which is was made,
> is I
> think indicative of a development process that has been taking significant
> risks with regard to refactoring the consensus critical codebase. I know I
> personally have had a hard time keeping up with the very large volume of
> code
> being moved and changed for the v0.10 release, and I know BtcDrak - who is
> keeping Viacoin up to date with v0.10 - has also had a hard time giving the
> changes reasonable review. The #4890 pull-req in question had no ACKs at
> all,
> and only two untested utACKS, which I find worrying for something that made
> significant consensus critical code changes.
>
> While it would be nice to have a library encapsulating the consensus code,
> this
> shouldn't come at the cost of safety, especially when the actual users of
> that
> library or their needs is still uncertain. This is after all a
> multi-billion
> project where a simple fork will cost miners alone tens of thousands of
> dollars
> an hour; easily much more if it results in users being defrauded. That's
> also
> not taking into account the significant negative PR impact and loss of
> trust. I
> personally would recommend *not* upgrading to v0.10 due to these issues.
>
> A much safer approach would be to keep the code changes required for a
> consensus library to only simple movements of code for this release, accept
> that the interface to that library won't be ideal, and wait until we have
> feedback from multiple opensource projects with publicly evaluatable code
> on
> where to go next with the API.
>
> 1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
> 2) https://github.com/bitcoin/bitcoin/pull/4890
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000001b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141215/d2a843f5/attachment.html>

2023-06-07 17:27:31

- reply

📅 Original date posted:2014-11-18
📝 Original message:On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon <
flavien.charlon at coinprism.com> wrote:
> > My main concern with OP_RETURN is that it seems to encourage people to
> use the blockchain as a convenient transport channel
>
> The number one user of the blockchain as a storage and transport mechanism
> is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them
> from doing so. In fact they use multi-sig outputs which is worse than
> OP_RETURN since it's not always prunable, and yet let them store much more
> than 40 bytes.
>
> For Open Assets <https://github.com/OpenAssets/open-assets-protocol>, we
> need to store a URL in the OP_RETURN output (with optionally a hash) plus
> some bytes of overhead. 40 bytes comes really short for that. The benefit
> of having a URL in there is that any storage mechanism can be used (Web,
> FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
> hardcode the storing mechanism in the protocol (and even then, a hash is
> not enough to address a HTTP or FTP resource). Storing only a hash is fine
> for the most basic timestamping application, but it's hardly enough to
> build something interesting.
>
> I've counted the number of OP_RETURN outputs in the blockchain for the
> month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
> blocks. Assuming they were all 40 bytes (the average is probably less than
> half of that), that means an increase of 14.37 bytes per block. Considering
> a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data
> in average.
>
> Increasing to 80 bytes will have a negligible impact on bandwidth and
> storage requirements, while being extremely useful for many use cases where
> a hash only is not enough.
>
While I am not opposing the proposal, I am not sure about your statistics
because while Counterparty is not currently using OP_RETURN encoding, you
should factor in the number of CP transactions that would have been
OP_RETURNs if they had been permitted (100,000 since inception according
their blog[1] with monthly charts at their block explorer[2]).
Refs:
[1]
http://counterparty.io/news/celebrating-100000-transaction-on-the-counterparty-network/
[2] http://blockscan.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141118/f3def71d/attachment.html>

2023-06-07 17:26:32

- reply

📅 Original date posted:2014-10-19
📝 Original message:On Sun, Oct 19, 2014 at 8:17 AM, xor <xor at freenetproject.org> wrote:
> I joined the list when Bitcoin was already in the 10-billions of market
> capitalization, and it actually really surprised me how low the traffic is
> here
> given the importance of Bitcoin.
>
> So as a random stranger to the project, I would vote against that if I was
> allowed to. There really should be *more* discussion here, and splitting
> the
> list up won't help with that.
I agree. This is also where the best peer review is to be found. Splitting
the list will dilute this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141019/c8e7d3fb/attachment.html>