Who do you mean by "the non technical folks"?
You don't include alicexbt or yourself as a "technical folk", do you?
On Wed, Jun 8, 2022 at 8:38 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Wholeheartedly agree with you alicexbt. There are no technical issues
"Some people say CTV is contentious, but they're spreading misinformation"?
Really? Seriously?
Come on, guys, we can do better than nina jankovich and the "fact checkers".
Please, rise the bar.
On Fri, Jun 3, 2022, 19:44 alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
I think something like visacoin could be kind of feasible without recursive
covenants. But as billy points out, I guess they could kind of do it with
multisig too.
I fail to understand why non recursive covenants are called covenants at
all. Probably I'm missing something, but I guess that's
It is quite ironic that yeah, it is quite ironic that the people who are
constantly basing their arguments on personal attack are also the ones who
complain the most about personal attacks. That's exactly the irony I was
trying to convey.
Just like some people claim that the only people against
I think people may be scared of potential attacks based on covenants. For
example, visacoin.
But there was a thread with ideas of possible attacks based on covenants.
To me the most scary one is visacoin, specially seeing what happened in
canada and other places lately and the general censorship
Thanks a lot for the many clarifications.
Yeah, I forgot it wasn't OP_CAT alone, but in combination with other things.
I guess this wouldn't be a covenants proposal then.
But simplicity would enable covenants too indeed, no?
Or did I get that wrong too?
On Sat, May 7, 2022 at 5:06 AM ZmnSCPxj
On Sat, May 7, 2022 at 5:52 AM wrote:
> > Re-enabling OP_CAT with the exact same OP would be a hardfork, but
> creating a new OP_CAT2 that does the same would be a softfork.
>
> We have TapScript for that. OP_CAT is defined as OP_SUCCESS, it can be
> re-enabled in a soft-fork way. For now,
I sounded sarcastic, but I was trying to be sarcastic with ryan,
not with you.
On Fri, May 6, 2022 at 8:24 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <
> bitcoin-dev@lists.l
OP_CAT was removed. If I remember correctly, some speculated that perhaps
it was removed because it could allow covenants.
I don't remember any technical concern about the OP besides enabling
covenants.
Before it was a common opinion that covenants shouldn't be enabled in
bitcoin because, despite
On Tue, May 3, 2022 at 4:36 PM Ryan Grant wrote:
> On Sun, May 1, 2022 at 8:49 PM Jorge Timón via bitcoin-dev
> wrote:
> > On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >> [...] Andreas is clueless
On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Michael,
>
> Maybe the whole thing worked as designed. Some users identified what was
> going on, well known Bitcoin educators such as Andreas Antonopoulos, Jimmy
> Song etc brought additional
"The only 3 nacks"...I would not call that an accurate "collection of
feedback". Feedback is always more positive when you laregely chose to
ignore any negative feedback, isn't it?
"Largely, the formal critiques of CTV (the 3 NACKs) are based on topics of
whether or not to swing the racquet, not
On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson <
michaelfolk...@protonmail.com> wrote:
> Hi Jorge
>
> > Can we agree now that resisting a bip8 proposal is simpler and cleaner
> than resisting a speedy trial proposal?
>
> Personally I'd rather stick to one challenge at a time :) Currently we are
On Sun, Apr 24, 2022 at 2:56 PM Ryan Grant wrote:
> Michael and Jorge,
>
> It is ethically inappropriate to make personal attacks on the
> trustworthiness of participants on this list, on such vague grounds as
> disliking an activation proposal!
>
>
the real explanation is for you not understanding me, you're not
understanding me and it feels luke a waste of time for both of us.
So, I'm sorry, it's over.
On Mon, Apr 11, 2022, 14:05 Anthony Towns wrote:
> On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev
> wrote:
> &
On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns wrote:
> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
> > You're not even considering user resistance in your cases.
>
> Of course I am. Again:
>
No, you're relying on miners to stop bad proposals.
> > > My claim is that for *any*
I've been calling them "controversial softforks" for long.
I hate to be right some times, but I guess I'm happy that I'm not the only
one who distrusts jeremy rubin anymore.
Can we agree now that resisting a bip8 proposal is simpler and cleaner than
resisting a speedy trial proposal?
I guess now
On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns wrote:
> On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > > In particular, any approach that allows you to block an evil fork,
> > > even when everyone else doesn't agree that it'
On Sat, Mar 26, 2022, 01:45 Anthony Towns wrote:
> On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > Sorry, I won't answer to everything, because it's clear you're not
> listening.
>
> I'm not agreeing with you; that's different to not listen
2:50 AM Anthony Towns wrote:
>
> On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> > On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns wrote:
> > > On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev
> > > wrote:
>
On Tue, Mar 15, 2022 at 6:25 PM Jeremy Rubin via bitcoin-dev
wrote:
>
> Boker tov bitcoin devs,
I don't undesrtand what that means, sorry
>> A mechanism of soft-forking against activation exists. What more do you
>> want?
>
>
> Agreed -- that should be enough.
No, resistance should ideally
On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns wrote:
>
> On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote:
> People opposed to having taproot transactions in their chain had over
> three years to do that coordination before an activation method was
On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
wrote:
>
> > If I find out I'm in the economic minority then I have little choice but
> > to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is
On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón wrote:
> A mechanism of soft-forking against activation exists. What more do you
> want? Are we supposed to write the code on behalf of this hypothetical group
> of users
On Fri, Mar 11, 2022 at 5:32 PM Billy Tetrud via bitcoin-dev
wrote:
>
> I think involving users more in activation is a good avenue of thought for
> improving how bitcoin does soft forks. I also think the idea you brought up
> of some way for people to signal opposition is a good idea. I've
On Fri, Mar 11, 2022, 13:47 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón wrote:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this
On Fri, Mar 11, 2022, 00:12 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> You're right, we s
Thank you for explaining. I agree with luke then, I'm against speedy trial.
I explained why already, I think.
In summary: speedy trial kind of means is miners and not users who decide
the rules.
It gives users less opportunities to react and oppose a malevolent change
in case miners want to impose
I believe jremey has malicious intentions and doesn't listen to
the community, you're still right, we shouldn't get personal. I shoud
assume the same malevolent intentions I assume jeremy has from everyone
else.
Thanks
> Michael
>
> --
> Michael Folkson
> Email: michae
What is ST? If it may be a reason to oppose CTV, why not talk about it more
explicitly so that others can understand the criticisms?
It seems that criticism isn't really that welcomed and is just explained
away.
Perhaps it is just my subjective perception.
Sometimes it feels we're going from
Since this has meetings like taproot, it seems it's going to end up being
added in bitcoin core no matter what.
Should we start the conversation on how to resist it when that happens?
We should talk more about activation mechanisms and how users should be
able to actively resist them more.
On
On Tue, Oct 12, 2021 at 5:34 PM Prayank via bitcoin-dev
wrote:
>
> Hi Michael,
>
> Agree with almost everything.
>
> > Miner signaling is a tool for signaling readiness. It is not voting for the
> > soft fork or expressing support for the soft fork. There should not be any
> > attempt to
"Softforks arentcompatible without miner enforcement"
Compatible with what?
"Softforks without miner support cause splits".
No, what causes splits are 3 things:
1) bugs
2) coordination mistakes
3) people wanting different rules.
Let me give an example. Let's say all users want change A.
Only
"Confirmation" isn't needed for softforks. Miners controlling confirmation
doesn't mean miners control the rules, they never did. Read section 11 of
the bitcoin paper "even with a majority of hashrate one cannot arbitrarily
change rules or forge signatures.
You may say users chosing the rules is
I think the option of "permanent failure because miners veto" should
actually be abandoned.
No, I don't think we should avoid splits when possible, I don't think we
should avoid splits at all costs.
On Sun, Jun 27, 2021, 19:12 Billy Tetrud wrote:
> @Luke
> > They can still slow it down.
>
>
If different users want different incompatible things (enough on each
side), there's no way to avoid the split. We shouldn't try to avoid
such a split.
Users decide the rules, not miners nor developers.
On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
wrote:
>
> Ultimately there is
Sounds really interesting, thanks. Making CPFP reliable would be very nice
in my opinion.
On Sat, May 29, 2021, 14:24 Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Mark and Clara,
>
> Great research, thanks for it!
>
> Few questions out of mind after a first
Sure, many things that were though only possible with hardforks initially
were later shown to be possible with softforks.
That doesn't mean hardforks should be taboo in my opinion though.
On Mon, May 24, 2021, 01:09 vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
Your analysis is correct.
In perfect competition, profits tend to zero, which means the costs of
mining tend to equal the reward.
Since the reward is fees plus subsidy, reducing the subsidy should reduce
mining costs.
I think convincing other users we need such a softfork to reeuce the
subsidy is
Hardforks can be useful too.
But, yes, I agree softforks are preferable whenever possible.
On Sat, May 22, 2021, 20:55 Raystonn . wrote:
> None of these required a hard fork. I should rephrase my previous email
> to clarify the intended topic as hard consensus changes, requiring a hard
> fork.
That is clearly not true. People entretain making changes to the protocol
all the time. Bitcoin is far from perfect and not improving it would be
stupid in my opinion.
Some improvements require changes to the consensus rules.
Recent changes include relative lock time verify or segwit. These are
> Despite the continual harassment, I have even made two efforts to try to
> (fairly) make things faster, and have been obstructed both times by ST
> advocates. It appears they intend to paint me as "deliberately refusing"
> (to
> use your words) in order to try to put Bitcoin and the BIP process
So the only thing that seemed clear, using height as per bip8, it's not
clear anymore.
And, as usual, we're not talking about activation in general but about
taproot activation, segwit activation...
I won't make it to the meeting because I don't think I have much more to
contribute that I haven't
Concept nack.
This has no advantage over bip8(true).
Bip9(false) is just bip9.
Thr only reasonable argument against bip8(true) is "some people may do
bip8(false) instead", which is a stypid argument applyable to any
activation method.
People against taproot should want code to forbid its
Just to clarify, I'm not saying bitcoin core should maintain the
"oppose proposal" part of the software. presumably people opposing the
change don't want much of the recent software changes anyway.
But perhaps it wouldn't be so bad, to oppose other proposals, perhaps.
I don't expect anyone to want
Sorry, I haven't read everything. I just want to say what I think is
the best option and why.
Let's say something like 2 years in which miners can signal activation
after which, the MUST signal it for their blocks to be valid (I think
this is LOT=true, but I don't remember what LOT stands for).
I see how your approach doesn't lose goal 3 while "mine" does.
Regarding goal 4, I don't think any of the approaches loses it. "Use
hashpower enforcement to de-risk the upgrade process, wherever
possible".
Well, in the case of activation while there's "many" non upgrade
miners, they simply can't
Well, bip9 doesn't only fall apart in case of unreasonable objection,
it also fails simply with miners' apathy.
Anyway, your proposed plan should take care of that case too, I think.
Overall sounds good to me.
Regarding bip8-like activation, luke-jr suggested that instead of
simply activating on
The complains I could imagine about this, (apart from being a very
specific use case) are the same complains I heard about op_expiry.
Namely, that in a reorg, the same tx, having been valid in a given
block could potentially become invalid in some other block mining it.
I guess in this case the
It seems we forgot
https://github.com/bitcoin/bitcoin/issues/12391#issuecomment-413653714
since getblockstats is only mentioned in the commits.
On Wed, Oct 3, 2018 at 12:32 PM Wladimir J. van der Laan via
bitcoin-dev wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Bitcoin Core
I only knew about ArtForz's fix, which isn't backwards compatible.
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki#code
On Mon, Aug 20, 2018 at 10:14 PM, Gregory Maxwell via bitcoin-dev
wrote:
>
op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".
I think I'm missing some context, but if you're using op_return purely
for
But in prnciple I don't oppose to making it stardard, just want to
understand what's the point.
On Thu, 10 May 2018, 02:16 Jorge Timón, wrote:
> I fail to see what's the practical difference between sending to op_true
> and giving the coins are fees directly. Perhaps it is ao
I fail to see what's the practical difference between sending to op_true
and giving the coins are fees directly. Perhaps it is ao obvious to you
that you forget to mention it?
If you did I honestlt missed it.
On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
Yes, in fact, you don't need to lose those bits like bitcoin by
imposing that the version is greater than that. But I guess just doing
the same is simpler.
On Thu, Mar 29, 2018 at 7:14 AM, Samad Sajanlal
wrote:
> Excellent - Thanks for your response Jorge. This helps us
Yes, you can activate softforks at a given height.
I don't see any reason why you couldn't rebase to 0.16 directly.
The block version bumping was a mistake in bip34, you don't really
need to bump the version number. In any case, I would recommend
reading bip34 and what it activates in the code.
Gmaxwell I think what's new is that in this case, with a single tx you
would take out all txs with fee below 1 btc. With current rules, you would
only remove enoguh txs for that one to fit, not empty the whole block and
mine only a block with that single tx.
On 30 Sep 2017 5:53 am, "Jorge Timón"
er Todd <p...@petertodd.org> wrote:
> On Tue, Sep 05, 2017 at 11:51:45PM +0200, Jorge Timón via bitcoin-dev wrote:
>> This is not a priority, not very important either.
>> Right now it is possible to create 0-value outputs that are spendable
>> and thus stay in the utxo (poten
This is not a priority, not very important either.
Right now it is possible to create 0-value outputs that are spendable
and thus stay in the utxo (potentially forever). Requiring at least 1
satoshi per output doesn't really do much against a spam attack to the
utxo, but I think it would be
Regarding storage space, have you heard about pruning? Probably you should.
On 27 Aug 2017 12:27 am, "Adam Tamir Shem-Tov via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Thank You Christian for your response.
>
> https://bitcointalk.org/index.php?topic=473.0 : I dont see the
On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote:
> I think anything less than 1 year after release of tested code by some
> implementation would be
On Mon, Jul 10, 2017 at 1:50 PM, Sergio Demian Lerner via bitcoin-dev
wrote:
> Regarding the timeline, its certainly rather short, but also is the UASF BIP
> 148 ultimatum.
This is correct. If you are trying to imply that makes the short
timeline here
What if you want height based but lockinontimeout = false ?
On 7 Jul 2017 8:09 am, "shaolinfry via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I have written a height based reference implementation as well as updated
> the BIP text in the following proposals
>
>
I'm all for using height instead of time. That was my preference for
bip9 all along, but my arguments at the time apparently weren't
convincing.
Regarding luke's proposal, the only advantage I see is that it would
allow nodes that don't know a deployment that gets activated to issue
a warning,
First the implementation, then the technical design (BIP)... will the
analysis come after that?
Will there be any kind of simulations of tje proposed size or will thag
come only after activation on mainnet?
I assume the very last step will be activation on testnet 3 ?
On 27 Jun 2017 8:44 am,
oops s/45%/35%/
On Sun, Jun 11, 2017 at 7:11 PM, Jorge Timón wrote:
> On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
> wrote:
>> Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
>> split, because I
On Sat, Jun 10, 2017 at 8:04 PM, Jacob Eliosoff via bitcoin-dev
wrote:
> Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
> split, because I may have left an overly pessimistic impression -
>
> In short: the timing isn't as dire as I
> I believe that means 80% of hashrate would need to be running BIP91
> (signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
> 27), not "a few days ago" as I claimed. So, tight timing, but not impossible.
This is not needed, if segwit is locked in by aug 1 (with or
On Sun, Jun 11, 2017 at 3:44 PM, Martijn Meijering via bitcoin-dev
wrote:
> Jorge Timón wrote:
> Why not just make sure BIP 149 will never activate unless BIP 141 has
> expired unsuccessfully?
Right, that would be part of it, as well as not removing the
The current proposal assumes that bip149 would only be merged and
released after nov15, so there's not time in one day.
My preference would be a bip149 proposal that could be merged and
released now, but some people complain that would require more
testing, because if you deploy bip149 and then
On Wed, May 31, 2017 at 1:50 AM, James MacWhyte wrote:
>
>>
>> The 1MB classic block size prevents quadratic hashing
>> problems from being any worse than they are today.
>>
>
> Add a transaction-size limit of, say, 10kb and the quadratic hashing problem
> is a non-issue.
adratic hashing
> problems from being any worse than they are today.
>
> Mark
>
> On Tue, May 30, 2017 at 6:27 AM, Jorge Timón via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Why not simply remove the (redundant after sw activation) 1 mb size
>>
Hi, I didn't want to comment on
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html
because it seemed to me that thread was more broad.
I like bip8 very much as an extension to bip9, but I think it could be better.
With bip9, a bip9-ready node that sees a softfork
On Tue, May 23, 2017 at 2:55 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Tuesday 23 May 2017 6:30:01 AM Karl Johan Alm via bitcoin-dev wrote:
>> Essentially, if we make a potentially very harmful option easy to
>> enable for users, we are putting them at
If there's a better factor than 0.25 I would change it now before deploying
segwit instead of leaving it to be changed later with a hf.
On 9 May 2017 10:59 pm, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I agree with you Matt.
> I'm artificially
On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
wrote:
> I've changed the proposal so only 8 bits are given to grinding so something
> like 20 bits are available for signaling.
>
> I have to say I'm at a loss here as to what's next? Should I make
The discussion is going offtopic. Can we please take vague discussions
about changing pow, so called "asic resistance", the environment etc
to bitcoin-disscuss or some other forum?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
On 9 Apr 2017 4:01 pm, "Jimmy Song" wrote:
Jorge,
Why won't the attacker use asicboost too? (Please don't say because of
> patents)
>
>
We're assuming the ASIC optimization in my example is incompatible with
ASICBoost. But if the new optimization were compatible with
Why won't the attacker use asicboost too? (Please don't say because of
patents)
On 9 Apr 2017 12:26 am, "Jimmy Song" wrote:
> Jorge,
>
> Suppose someone figures out an ASIC optimization that's completely
> unrelated that gives X% speed boost over your non-ASICBoosted
>
On 8 Apr 2017 8:31 pm, "praxeology_guy via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
There is the equation:
Power Cost + Captial Rent + Labor ~= block reward + fees
I don't know why many people insist on calling the subsidy the blick
reward. Thw block reward is both the block
To be more specific, why "being higher will secure the Bitcoin network
better against newer optimizations"?
Or, to be more clear, let's forget about future "optimizations", let's
just think of an attacker. Does asicboost being used by all miners
make the system more secure against an attacker? No,
On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Praxeology Guy,
Why would the actual end users of Bitcoin (the long term and short term
> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> policy in order to make their
On Thu, Apr 6, 2017 at 4:39 AM, Bram Cohen via bitcoin-dev
wrote:
>
> Asicboost also has the problem that it isn't treating the hashing as a black
> box, and thus has impacts on what gets mined. In particular it creates an
> incentive to make blocks smaller.
On Thu, Apr 6, 2017 at 2:30 PM, Luv Khemani via bitcoin-dev
wrote:
>
> Just to add on to the ethical issue of blocking this.
>
>
> If blocking the covert form of ASICBOOST is seen as unethical, then the same
> can be said about libsecp256k1, various client
Just saying that we can talk in terms of weight alone after segwit. 8 mb
weight is much more clear than 2 mb size to me. 2 mb size seems to
obfuscate the actual new limit with the proposed hf, which simply 8 mb
weight.
On 2 Apr 2017 12:03 pm, "Natanael" wrote:
> My point,
On Sat, Apr 1, 2017 at 5:34 PM, Natanael <natanae...@gmail.com> wrote:
> Den 1 apr. 2017 16:07 skrev "Jorge Timón" <jti...@jtimon.cc>:
> On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanae...@gmail.com> wrote:
>> Den 1 apr. 2017 14:33 skrev "
On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanae...@gmail.com> wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Timón via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org>:
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
&
Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
MAX_BLOCK2_BASE_SIZE.
Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
mb weight to 8 mb weight.
I would also use the hardfork bit (sign
While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be
controversial among some users (I find that very often it is because they
have been confused about what segwit does or even outright lied about it) I
don't think it's very interesting to discuss further size increases.
I
Great stuff, although the ordering of the sections seems a little bit confusing.
I think it would be clearer to put the "Creation of proofs" section
before "Proof verification", maybe even before "Proof format" if a
high level defintion of "full tx size proof" is provided before.
Also, in "For
Segwit allows old -> old, old -> new, new -> old and of course new -> new
txs.
On 17 Mar 2017 1:47 a.m., "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Yeah, it does make things harder, and it's easy enough to soft fork to
handle arbitrary opt-in protocol
There were talks about implementing spv mode for bitcoin core without using
bloom filters. Less efficient because it downloads full blocks, but better
for privacy. Perhaps other spv implementations should consider doing the
same instead of committing the filters in the block?
Now I feel I was
On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
wrote:
> Older node versions may generate issues because some upgrades will make
> several of the nodes running older protocol versions obsolete and or
> incompatible. There may be other hard
On Fri, Dec 2, 2016 at 5:18 AM, Luke Dashjr <l...@dashjr.org> wrote:
> On Friday, December 02, 2016 1:42:46 AM Jorge Timón via bitcoin-dev wrote:
>> We can already warn users of a hardfork when a block is invalid (at
>> least) because of the highest bit in nVersion
We can already warn users of a hardfork when a block is invalid (at
least) because of the highest bit in nVersion (as you say, because it
is forbidden since bip34 was deployed). It seems the softfork serves
only to warn about soft-hardforks, assuming it chooses to use this
mechanism (which a
On Wed, Nov 16, 2016 at 2:58 PM, Eric Voskuil via bitcoin-dev
wrote:
> This sort of statement represents one consequence of the aforementioned bad
> precedent.
>
> Are checkpoints good now?
Checkpoints are not necessary for consensus and work is being done
On Mon, Oct 17, 2016 at 1:17 PM, Tom Zander via bitcoin-dev
wrote:
> You are asking people to create everyone-can-spend transactions that would
> mean a loss of funds to everyone that used it if we do find a major flaw and
> need to rollback.
Please, nobody
As has been mentioned there have been a lot of time to upgrade
software to support segwit. Furthermore, since it is a softfork, there
will be plenty of time after activation too for those taking a "wait
and see" approach.
You keep insisting on "2 months after activation", but that's not how
BIP9
Hello, since trying to encapsulate consensus code without exposing
anything else (see my post from january
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012235.html
) wasn't succesful in getting review, I decided to turn "phase 2" into
"expose verifyHeader" again. I was
No, anyone with the bip32 public seed can do the same as the receiver as
"watch only". The only difference is rhat the receiver can actually spend
the coins. As gmaxwell explained, if it's expensive for everyone, it will
be also expensive for the receiver (assuming no interaction after the bip32
1 - 100 of 264 matches
Mail list logo