Re: [bitcoin-dev] Bitcoin covenants are inevitable

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

Re: [bitcoin-dev] Bitcoin covenants are inevitable

"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: >

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

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

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

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

Re: [bitcoin-dev] Speedy covenants (OP_CAT2)

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,

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

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

[bitcoin-dev] Speedy covenants (OP_CAT2)

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

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

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

Re: [bitcoin-dev] What to do when contentious soft fork activations are attempted

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

Re: [bitcoin-dev] What to expect in the next few weeks

"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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

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! > >

Re: [bitcoin-dev] Speedy Trial

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: > &

Re: [bitcoin-dev] Speedy Trial

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*

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

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

Re: [bitcoin-dev] Speedy Trial

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'

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

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: >

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

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

Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

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

Re: [bitcoin-dev] Meeting Summary & Logs for CTV Meeting #5

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

Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)

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

Re: [bitcoin-dev] On the regularity of soft forks

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

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

"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

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

"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

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

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. > >

Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades

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

Re: [bitcoin-dev] Improvement on Blockbuilding

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

Re: [bitcoin-dev] Consensus protocol immutability is a feature

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: > >

Re: [bitcoin-dev] Reducing block reward via soft fork

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

Re: [bitcoin-dev] Consensus protocol immutability is a feature

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.

Re: [bitcoin-dev] Consensus protocol immutability is a feature

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

Re: [bitcoin-dev] Reminder on the Purpose of BIPs

> 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

Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev

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

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

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

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

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).

Re: [bitcoin-dev] Modern Soft Fork Activation

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

Re: [bitcoin-dev] Modern Soft Fork Activation

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

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

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

Re: [bitcoin-dev] Bitcoin Core 0.17.0 released

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

Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

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: >

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

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

Re: [bitcoin-dev] Making OP_TRUE standard?

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

Re: [bitcoin-dev] Making OP_TRUE standard?

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, <

Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?

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

Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?

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.

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

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"

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

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

[bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

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

Re: [bitcoin-dev] Solving the Scalability Problem Part II - Adam Shem-Tov

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

Re: [bitcoin-dev] A Segwit2x BIP

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

Re: [bitcoin-dev] A Segwit2x BIP

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

Re: [bitcoin-dev] Height based vs block time based thresholds

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 > >

Re: [bitcoin-dev] Height based vs block time based thresholds

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,

Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated

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,

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

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

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

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

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

> 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

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

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

Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

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

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

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.

Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148

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 >>

[bitcoin-dev] Suggested changes to bip8

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

Re: [bitcoin-dev] I do not support the BIP 148 UASF

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

Re: [bitcoin-dev] Some real-world results about the current Segwit Discount

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

Re: [bitcoin-dev] A Small Modification to Segwit

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

Re: [bitcoin-dev] A Small Modification to Segwit

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

Re: [bitcoin-dev] A Small Modification to Segwit

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

Re: [bitcoin-dev] A Small Modification to Segwit

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 >

Re: [bitcoin-dev] A Small Modification to Segwit

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

Re: [bitcoin-dev] A Small Modification to Segwit

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,

Re: [bitcoin-dev] A Small Modification to Segwit

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

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

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.

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

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

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

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,

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

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 "

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

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. > > &

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

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

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

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

Re: [bitcoin-dev] Fraud proofs for block size/weight

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

Re: [bitcoin-dev] Quadratic hashing solution for a post-segwit hard fork

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

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

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

Re: [bitcoin-dev] Planned Obsolescence

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

Re: [bitcoin-dev] New BIP: Hardfork warning system

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

Re: [bitcoin-dev] New BIP: Hardfork warning system

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

Re: [bitcoin-dev] [BIP Proposal] Buried Deployments

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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

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

[bitcoin-dev] Libconsensus completion plan document (with pictures)

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

Re: [bitcoin-dev] BIP Number Request: Addresses over Audio

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   2   3   >