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

2021-10-12 Thread Jorge Timón via bitcoin-dev
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

2021-06-30 Thread Jorge Timón via bitcoin-dev
"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

2021-06-29 Thread Jorge Timón via bitcoin-dev
"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

2021-06-29 Thread Jorge Timón via bitcoin-dev
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

2021-06-27 Thread Jorge Timón via bitcoin-dev
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

2021-05-29 Thread Jorge Timón via bitcoin-dev
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

2021-05-25 Thread Jorge Timón via bitcoin-dev
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

2021-05-25 Thread Jorge Timón via bitcoin-dev
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

2021-05-22 Thread Jorge Timón via bitcoin-dev
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

2021-05-22 Thread Jorge Timón via bitcoin-dev
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

2021-04-27 Thread Jorge Timón via bitcoin-dev
> 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

2021-04-04 Thread Jorge Timón via 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

2021-03-08 Thread Jorge Timón via bitcoin-dev
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)

2021-02-22 Thread Jorge Timón via bitcoin-dev
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)

2021-02-22 Thread Jorge Timón via bitcoin-dev
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

2020-01-10 Thread Jorge Timón via bitcoin-dev
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

2020-01-10 Thread Jorge Timón via bitcoin-dev
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.

2019-05-23 Thread Jorge Timón via bitcoin-dev
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

2018-10-03 Thread Jorge Timón via bitcoin-dev
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.

2018-08-22 Thread Jorge Timón via bitcoin-dev
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

2018-08-15 Thread Jorge Timón via bitcoin-dev
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?

2018-05-10 Thread Jorge Timón via bitcoin-dev
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?

2018-05-10 Thread Jorge Timón via bitcoin-dev
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?

2018-03-30 Thread Jorge Timón 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

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

2018-03-28 Thread Jorge Timón via bitcoin-dev
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

2017-09-29 Thread Jorge Timón via bitcoin-dev
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

2017-09-09 Thread Jorge Timón via bitcoin-dev
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

2017-09-05 Thread Jorge Timón via bitcoin-dev
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

2017-08-27 Thread Jorge Timón via bitcoin-dev
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

2017-07-12 Thread Jorge Timón via bitcoin-dev
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

2017-07-11 Thread Jorge Timón via bitcoin-dev
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

2017-07-07 Thread Jorge Timón via bitcoin-dev
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

2017-07-06 Thread Jorge Timón via bitcoin-dev
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

2017-06-27 Thread Jorge Timón via bitcoin-dev
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

2017-06-11 Thread Jorge Timón via bitcoin-dev
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

2017-06-11 Thread Jorge Timón via bitcoin-dev
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

2017-06-11 Thread Jorge Timón via bitcoin-dev
> 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?

2017-06-11 Thread Jorge Timón via bitcoin-dev
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?

2017-06-11 Thread Jorge Timón via bitcoin-dev
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

2017-05-30 Thread Jorge Timón via bitcoin-dev
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

2017-05-30 Thread Jorge Timón via bitcoin-dev
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

2017-05-25 Thread Jorge Timón via bitcoin-dev
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

2017-05-23 Thread Jorge Timón via bitcoin-dev
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

2017-05-09 Thread Jorge Timón via bitcoin-dev
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

2017-04-11 Thread Jorge Timón via bitcoin-dev
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

2017-04-11 Thread Jorge Timón via bitcoin-dev
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

2017-04-10 Thread Jorge Timón via bitcoin-dev
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

2017-04-09 Thread Jorge Timón via bitcoin-dev
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

2017-04-09 Thread Jorge Timón via bitcoin-dev
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

2017-04-08 Thread Jorge Timón via bitcoin-dev
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

2017-04-08 Thread Jorge Timón via bitcoin-dev
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

2017-04-06 Thread Jorge Timón via bitcoin-dev
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

2017-04-06 Thread Jorge Timón via bitcoin-dev
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

2017-04-02 Thread Jorge Timón via bitcoin-dev
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

2017-04-01 Thread Jorge Timón via bitcoin-dev
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

2017-04-01 Thread Jorge Timón via bitcoin-dev
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

2017-04-01 Thread Jorge Timón via bitcoin-dev
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

2017-03-29 Thread Jorge Timón via bitcoin-dev
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

2017-03-23 Thread Jorge Timón via bitcoin-dev
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

2017-03-17 Thread Jorge Timón via bitcoin-dev
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] Script Abuse Potential?

2017-01-04 Thread Jorge Timón via bitcoin-dev
I would assume that the controversial part of op_cat comes from the fact that it enables covenants. Are there more concerns than that? On 4 Jan 2017 04:14, "Russell O'Connor via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > For the record, the OP_CAT limit of 520 bytes was added

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

2017-01-04 Thread Jorge Timón via bitcoin-dev
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

2016-12-15 Thread Jorge Timón via bitcoin-dev
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

2016-12-01 Thread Jorge Timón via bitcoin-dev
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

2016-12-01 Thread Jorge Timón via bitcoin-dev
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

2016-11-16 Thread Jorge Timón via bitcoin-dev
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)

2016-10-17 Thread Jorge Timón via bitcoin-dev
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)

2016-10-16 Thread Jorge Timón via bitcoin-dev
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)

2016-10-10 Thread Jorge Timón via bitcoin-dev
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

2016-08-12 Thread Jorge Timón via bitcoin-dev
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

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

2016-05-19 Thread Jorge Timón via bitcoin-dev
On May 19, 2016 01:53, "Peter Todd" wrote: tip of the tree. > > > > How expensive it is to update a leaf from this tree from unspent to spent? > > log2(n) operations. Updating a leaf is just as expensive as adding a new one? That's not what I expected. Or is adding a new one

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

2016-05-18 Thread Jorge Timón via bitcoin-dev
On May 17, 2016 15:23, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > # TXO Commitments > > Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a > type of deterministic, indexable, insertion ordered merkle tree, which allows > new items to be

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-12 Thread Jorge Timón via bitcoin-dev
On May 12, 2016 00:43, "Timo Hanke via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > This is what I meant. If existing hardware gets forked-out it will inevitably lead to the creation of an altcoin. Simply because the hardware exists and can't be used for anything else both chains

Re: [bitcoin-dev] Making AsicBoost irrelevant

2016-05-11 Thread Jorge Timón via bitcoin-dev
On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Again: this is unlike the hypothetical persistence of two chains after a hardfork that is only contentious but doesn’t change the mining algorithm, the kind of hardfork you are proposing would

Re: [bitcoin-dev] BIP 2 promotion to Final

2016-03-10 Thread Jorge Timón via bitcoin-dev
On Mar 10, 2016 17:28, "Mustafa Al-Bassam" wrote: > > The fact that it takes very little time and effort to prevent a BIP from reaching final status, means that in an base of millions of users it's guaranteed that some disgruntled or bored person out there will attack it, even

Re: [bitcoin-dev] BIP 2 promotion to Final

2016-03-10 Thread Jorge Timón via bitcoin-dev
On Mar 10, 2016 16:51, "Mustafa Al-Bassam via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think in general this sounds like a good definition for a hard-fork > becoming active. But I can envision a situation where someone will try > to be annoying about it and point to one

Re: [bitcoin-dev] BIP 2 promotion to Final

2016-03-10 Thread Jorge Timón via bitcoin-dev
On Mar 10, 2016 02:04, "Mustafa Al-Bassam via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > >A hard-fork BIP requires adoption from the entire Bitcoin economy, > particularly including those selling desirable goods and services in > exchange for bitcoin payments, as well as

Re: [bitcoin-dev] consensus rule change for TX fee safety

2016-03-03 Thread Jorge Timón via bitcoin-dev
There's an absurd fee (non-consensus) check already. Maybe that check can be improved, but probably the wallet layer is more appropriate for this. On Mar 3, 2016 16:23, "Henning Kopp via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > I think there is no need to do a

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

2016-02-06 Thread Jorge Timón via bitcoin-dev
On Feb 6, 2016 16:37, "Gavin Andresen" wrote: > > Responding to "28 days is not long enough" : Any thoughts on the "95% better than 75%" and "grace period before miner coordination instead of after" comments ? > I suspect there ARE a significant percentage of

Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses

2016-02-02 Thread Jorge Timón via bitcoin-dev
In the section https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki#formally-defining-consensus Can we please find another term for the "consensus" here (which is often confused with "consensus rules", "consensus code" etc)? In BIP99 I used the term "uncontroversial", but

Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?

2016-01-29 Thread Jorge Timón via bitcoin-dev
On Fri, Jan 29, 2016 at 5:39 PM, Gavin Andresen via bitcoin-dev wrote: > On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev > wrote: > It doesn't matter much where in the difficulty period the fork happens;

Re: [bitcoin-dev] Libconsensus phase 2

2016-01-13 Thread Jorge Timón via bitcoin-dev
On Tue, Jan 12, 2016 at 8:17 PM, Eric Voskuil wrote: > Jorge, first, thanks again for your work on this. > > Without creating and using a public blockchain interface in phase 2, how > will you isolate the database dependency from consensus critical code? > Is it that the

[bitcoin-dev] Libconsensus phase 2

2016-01-12 Thread Jorge Timón via bitcoin-dev
After talking to some people about libconsensus in the last Hong Kong conference I realized that my initial plan of exposing one more thing at a time would actually probably slow things down. There's still a promised pdf with pictures that will be released, and actually drafting the UML pictures

Re: [bitcoin-dev] Time to worry about 80-bit collision attacks or not?

2016-01-11 Thread Jorge Timón via bitcoin-dev
On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev wrote: > And to fend off the messag that I bet somebody is composing right now: > > Yes, I know about a "security first" mindset. But as I said earlier in the > thread, there is a tradeoff here

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-26 Thread Jorge Timón via bitcoin-dev
On Dec 26, 2015 5:45 PM, "Pieter Wuille via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > My opinion is that the role of Bitcoin Core maintainers is judging whether consensus for a hard fork exists, and is technically necessary and safe. We don't need a hashpower vote to decide

Re: [bitcoin-dev] We need to fix the block withholding attack

2015-12-26 Thread Jorge Timón via bitcoin-dev
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unfortunately, this also means longer confirmation times, lower throughput, and lower miner revenue. Note, however, that confirmations would (on average) represent more PoW, so fewer

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-21 Thread Jorge Timón via bitcoin-dev
To clarify, although I have defended the deployment of segwit as a hardfork, I have no strong opinion on whether to do that or do it as a softfork first and then do a hardfork to move things out of the coinbase to a better place. I have a strong opinion against never doing the later hardfork

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

2015-12-18 Thread Jorge Timón via bitcoin-dev
Well, if it's not going to be height, I think median time of the previous block is better than the time of the current one, and would also solve Chun Wang's concerns. But as said I prefer to use heights that correspond to diff recalculation (because that's the window that bip9 will use for the

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

2015-12-18 Thread Jorge Timón via bitcoin-dev
I believe the attacks are the same for height or median time of the prev block are equal, only the time of the current block has more edge cases. On Dec 18, 2015 9:15 PM, "Jeff Garzik" wrote: > My preference is height activation + one step per block (i.e. also > height).

Re: [bitcoin-dev] The increase of max block size should be determined by block height instead of block time

2015-12-18 Thread Jorge Timón via bitcoin-dev
On Dec 18, 2015 9:43 PM, "Peter Todd" wrote: > FWIW all these median time based schemes should be using median time past: the point is to use a time that the block creator has no direct control of, while still tying the rule to wall clock time for planning purposes. Well, if

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

2015-12-17 Thread Jorge Timón via bitcoin-dev
Although I agree that how safe a pre-hardfork upgrade period is depends on the complexity of the changes (we should assume everyone may need time to reimplementat it themselves in their own implementations, not just upgrade bitcoin core) and bip102 is indeed a very simple hardfork, I think less

Re: [bitcoin-dev] On the security of softforks

2015-12-17 Thread Jorge Timón via bitcoin-dev
To me it's getting clearer and clearer that th frintier between softforks and hardforks it's softer than we thought. Aoftforks should start having a minimum median time deplayment day (be it height or median time, I don't care, just not header.nTime). TYDGFHdfthfg64565$%^$ On Fri, Dec 18, 2015 at

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

2015-12-17 Thread Jorge Timón via bitcoin-dev
On Thu, Dec 17, 2015 at 8:44 PM, Peter Todd via bitcoin-dev wrote: > If Bitcoin remains decentralized, miners have veto power over any > blocksize increases. You can always soft-fork in a blocksize reduction > in a decentralized blockchain that actually

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

2015-12-12 Thread Jorge Timón via bitcoin-dev
On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback wrote: >>If it's voting for something consensus, you will need something special. If >> it's not consensus (ie external) thw voting doesn't have to hit the chain at >> all. > > I had in mind voting for something that can't be

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-11 Thread Jorge Timón via bitcoin-dev
On Dec 9, 2015 5:40 PM, "Gavin Andresen" wrote: > > On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> I think it would be logical to do as part of a hardfork that moved >> commitments generally; e.g. a

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-09 Thread Jorge Timón via bitcoin-dev
Fair enough. On Dec 9, 2015 4:03 PM, "Gregory Maxwell" wrote: > On Wed, Dec 9, 2015 at 7:54 AM, Jorge Timón wrote: > > From this question one could think that when you said "we can do the > > cleanup hardfork later" earlier you didn't really meant it. And that >

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

2015-12-09 Thread Jorge Timón via bitcoin-dev
On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > This, combined with the ability to make new transactions arbitrarily would allow a function to pay its creator. I don't understand what you mean by "a function" in this context, I assume you

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-08 Thread Jorge Timón via bitcoin-dev
On Dec 8, 2015 7:08 PM, "Wladimir J. van der Laan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > - Gregory linked to an implementation but as he mentions it is not completely > finished yet. ETA for a Segwit testnet is later this month, then you can test as well.

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-08 Thread Jorge Timón via bitcoin-dev
On Wed, Dec 9, 2015 at 7:29 AM, Gregory Maxwell via bitcoin-dev wrote: > What was being discussed was the location of the witness commitment; > which is consensus critical regardless of where it is placed. Should > it be placed in an available location which

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-08 Thread Jorge Timón via bitcoin-dev
On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev wrote: > On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev > wrote: > We already have consensus critical enforcement there, the height, >

  1   2   3   >