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 facilitate miner signaling until there is sufficient community 
> > consensus (the mining community is a subset of the community) on the soft 
> > fork.
>
> This is really important which gets ignored. I wish there was a way to solve 
> this problem in a way that it is not misinterpreted by users.
>
> During signalling for taproot, there were lots of users in different 
> communities that believed miners are voting for taproot and we need some 
> percentage of miners to agree before making any changes in Bitcoin. It was 
> not just non-technical users but few mining pools, exchanges etc. also 
> considered miners signaling as some voting process.
>
> Best I could do at that moment was share this link: 
> https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/
>
> However I am sure there are lot of people who still think miners vote during 
> signaling. Opinions of few developers on MASF vs UASF also adds more 
> confusion to this thing. I could not think of any solution to solve this 
> problem.

Yes, given most of the arguments given against activation at the end
of the period regardless of mining signaling, it seems sadly it's not
just users but developers too. They seem to believe that miners must
chose for users with bip8(false) because (according to them) with
bip8(true) it is developers who decide for users, and they don't want
to decide for users: they want miners to decide for users.
They don't seem to believe users can actually chose for themselves, sadly.
In the next softfork, sadly, probably the same discussions will be
repeated, the same rational arguments will be ignored and activation
will be once again done, in my opinion, the wrong way and most users
(many more, as we grow in numbers) will remain confused in the same
way and confusing the newcomers they explain bitcoin to.



> --
> Prayank
>
> A3B1 E430 2298 178F
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 60% miners want it.
When it activates with LOT=true, will this cause a split?

Well, not necessarily. Since all users will be on the chain with change A,
all miners will quickly abandon that useless chain and start building on
the one that actually pays them.

Do you agree that's what would happen in this example given the assumptions?


On Tue, Jun 29, 2021, 20:44 Eric Voskuil  wrote:

>
> On Jun 29, 2021, at 12:28, Jorge Timón  wrote:
>
> 
> "Confirmation" isn't needed for softforks.
>
>
> All transactions require confirmation. Splitting does not change this.
>
> Softforks are not compatible without miner enforcement. So soft forking
> without it has essentially the same effect as hard forking, the chain
> splits.
>
> Miners controlling confirmation doesn't mean miners control the rules,
> they never did.
>
>
> Please define “control” because these statements hinge on that word.
> Nobody “controls” the rules of others, nor did anyone claim that to be the
> case. Majority hash power does have the ability to determine what gets
> confirmed. That is the central design principle of proof of work. It takes
> that decision out of the hands of politicians and places it at the feet of
> the market.
>
> Read section 11 of the bitcoin paper "even with a majority of hashrate one
> cannot arbitrarily change rules or forge signatures.
>
>
> Never claimed that was the case. One can run any rules that one desires.
>
> You may say users chosing the rules is "politicial". Isn't miners deciding
> them for users more political?
>
>
> No, it’s economic. The largest investment in mining (including highest
> fees paid to incentivize it) determines censorship resistance.
>
> Whatever you call it, it is still how free software works: users decide
> what to run.
>
>
> A *person* can run whatever software they want. Money requires that others
> agree (same rules), and to be money bitcoin requires confirmation.
>
> It is extremely disappointing to see how few developers seem to ubderstand
> this, or even care about users deciding or miners not deciding the rules.
>
>
> It’s poorly understood because there are so many who should know better
> making very misleading statements.
>
> How can we expect users to understand bitcoin when most developers don't
> seem to understand it?
>
>
> Clearly we cannot.
>
> It is really sad.
>
> On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:
>
>>
>> > On Jun 29, 2021, at 10:55, Luke Dashjr  wrote:
>> >
>> > The only alternative to a split in the problematic scenarios are 1)
>> concede
>> > centralised miner control over the network,
>>
>> Miners control confirmation, entirely.
>>
>> This is the nature of bitcoin. And merchants control validation,
>> entirely. Anyone can be a miner or a merchant. Neither is inherently
>> “better” than the other. The largest merchants are likely a handful of
>> exchanges, likely at least as centralized as miners are pooled.
>>
>> Splitting does not change this.
>>
>> > and 2) have inconsistent
>> > enforcement of rules by users who don't agree on what the correct rules
>> are,
>>
>> There are no “correct” rules. Whatever rules one enforces determine what
>> network he chooses to participate in.
>>
>> > again leading to centralised miner control over the network.
>>
>> Leading to? Miners control confirmation, always. Whether that is
>> centralized, just as with merchanting, is up to individuals.
>>
>> > In other words, in this context, accepting a split between disagreeing
>> users
>> > is the ONLY way Bitcoin can possibly continue as a decentralised
>> currency.
>>
>> No, it is not. You are proposing splitting as the method of censorship
>> resistance inherent to Bitcoin. Coordinating this split requires
>> coordinated action. The whole point of bitcoin is coordinate that action
>> based on mining (proof of work). Replacing that with a political process is
>> just a reversion to political money.
>>
>> > Making that split as clean and well-defined as possible not only
>> ensures the
>> > best opportunity for both sides of the disagreement,
>>
>> Trivially accomplished, just change a rule. This isn’t about that. It’s
>> about how one gets others to go along with the new coin, or stay with the
>> old. An entirely political process, which is clearly evident from the
>> campaigns around such attempts.
>>
>> > but also minimises the
>> > risk that the split occurs at all (since the "losing" side needs to
>> concede,
>> > rather than passively continue the disagreement ongoing after the
>> attempted
>> > protocol change).
>>
>> Nobody “needs to” concede once a split has occurred, which is evident in
>> existing splits.
>>
>> e
>>
>> > Luke
>> >
>> >
>> >> On Tuesday 29 June 2021 

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 "politicial". Isn't miners deciding
them for users more political? Whatever you call it, it is still how free
software works: users decide what to run.
It is extremely disappointing to see how few developers seem to ubderstand
this, or even care about users deciding or miners not deciding the rules.
How can we expect users to understand bitcoin when most developers don't
seem to understand it?

It is really sad.

On Tue, Jun 29, 2021, 19:17 Eric Voskuil  wrote:

>
> > On Jun 29, 2021, at 10:55, Luke Dashjr  wrote:
> >
> > The only alternative to a split in the problematic scenarios are 1)
> concede
> > centralised miner control over the network,
>
> Miners control confirmation, entirely.
>
> This is the nature of bitcoin. And merchants control validation, entirely.
> Anyone can be a miner or a merchant. Neither is inherently “better” than
> the other. The largest merchants are likely a handful of exchanges, likely
> at least as centralized as miners are pooled.
>
> Splitting does not change this.
>
> > and 2) have inconsistent
> > enforcement of rules by users who don't agree on what the correct rules
> are,
>
> There are no “correct” rules. Whatever rules one enforces determine what
> network he chooses to participate in.
>
> > again leading to centralised miner control over the network.
>
> Leading to? Miners control confirmation, always. Whether that is
> centralized, just as with merchanting, is up to individuals.
>
> > In other words, in this context, accepting a split between disagreeing
> users
> > is the ONLY way Bitcoin can possibly continue as a decentralised
> currency.
>
> No, it is not. You are proposing splitting as the method of censorship
> resistance inherent to Bitcoin. Coordinating this split requires
> coordinated action. The whole point of bitcoin is coordinate that action
> based on mining (proof of work). Replacing that with a political process is
> just a reversion to political money.
>
> > Making that split as clean and well-defined as possible not only ensures
> the
> > best opportunity for both sides of the disagreement,
>
> Trivially accomplished, just change a rule. This isn’t about that. It’s
> about how one gets others to go along with the new coin, or stay with the
> old. An entirely political process, which is clearly evident from the
> campaigns around such attempts.
>
> > but also minimises the
> > risk that the split occurs at all (since the "losing" side needs to
> concede,
> > rather than passively continue the disagreement ongoing after the
> attempted
> > protocol change).
>
> Nobody “needs to” concede once a split has occurred, which is evident in
> existing splits.
>
> e
>
> > Luke
> >
> >
> >> On Tuesday 29 June 2021 08:44:56 Eric Voskuil wrote:
> >> At least we are now acknowledging that splitting is what it’s about.
> That’s
> >> progress.
> >>
> >> e
> >>
>  On Jun 29, 2021, at 01:32, Jorge Timón  wrote:
> >>>
> >>> 
> >>> 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.
> 
>  Absolutely. However I think that the option of permanent failure is
>  important. It certainly would be ideal to ensure that enough bitcoin
>  users support the upgrade *before* releasing it, however realistically
>  this can never be more than an estimate, and estimates can sometimes
> be
>  wildly wrong. It would be unfortunate if miners had a substantially
>  different estimate of user support than the people putting in the work
>  to release bitcoin upgrades. Even if upgrades are never released
> before
>  it becomes clear that a large supermajority of users want the upgrade,
>  if miners don't agree with the estimate a harmful chain split could
>  occur. And I agree with Eric that the goal here is to prevent a chain
>  split during an upgrade when possible. This includes permanent failure
>  of an upgrade when there is unexpectedly large miner opposition.
> 
>  This of course does not prevent a UASF-style deployment to be done
> after
>  an initial failure to deploy occurs. My proposal is essentially a
>  mechanism to improve upon the speedy-trial idea, allowing for even
>  speedier releases (than speedy trial) without adding additional risk
> of
>  undesired chain splits.
> 
> > [BIP8] already has the trinary state you seem to be describing
> 
>  It sounds like you're saying the trinary state of BIP8 is A. Follow
> 

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.
>
> Absolutely. However I think that the option of permanent failure is
> important. It certainly would be ideal to ensure that enough bitcoin users
> support the upgrade *before* releasing it, however realistically this can
> never be more than an estimate, and estimates can sometimes be wildly
> wrong. It would be unfortunate if miners had a substantially different
> estimate of user support than the people putting in the work to release
> bitcoin upgrades. Even if upgrades are never released before it becomes
> clear that a large supermajority of users want the upgrade, if miners don't
> agree with the estimate a harmful chain split could occur. And I agree with
> Eric that the goal here is to prevent a chain split during an upgrade when
> possible. This includes permanent failure of an upgrade when there is
> unexpectedly large miner opposition.
>
> This of course does not prevent a UASF-style deployment to be done after
> an initial failure to deploy occurs. My proposal is essentially a mechanism
> to improve upon the speedy-trial idea, allowing for even speedier releases
> (than speedy trial) without adding additional risk of undesired chain
> splits.
>
> > [BIP8] already has the trinary state you seem to be describing
>
> It sounds like you're saying the trinary state of BIP8 is A. Follow the
> longest chain, B. Follow the upgrade chain, or C. follow the non-upgraded
> chain. I agree. However the trinary state in my proposal is materially
> different - it is the signaling itself that is trinary, not just which
> chain is being followed. This allows others to know and make programmatic
> decisions (in software) based on that signaling. I'm sure you can agree
> that does not exist in BIP8.
>
> > No additional bit is needed, as softforks are coordinated between users,
> NOT miners
>
> And yet there is miner involvement, as you rightly pointed out. Miners are
> needed to set the nVersion in the header. So when you say "no additional
> bit is needed", could you please be clearer as to what you mean? Do you
> mean that signaling of opposition in a block can be done without any
> "additional bit"? Or are you just saying that it is redundant to consider
> what miners might be opposing an upgrade?
>
> @Jorge
> > If different users want different incompatible things... there's no way
> to avoid the split
>
> I agree. This happened with bcash, and that's fine. It was painful, but
> there were a significant amount of users that disagreed, and they have the
> chain they want now.
>
> But we generally all want to avoid a chain split when possible. Because
> chain splits have a cost, and that cost can be high, its likely that many
> users would rather choose the chain with the most support rather than
> choosing the chain with their preferred rules.
>
> However, the question here is: how do we estimate what fraction of users
> wants which rules? We don't have a divining rod to determine with certainty
> what users want. We can only make polls of various levels of inaccuracy.
> The methods bitcoin has been using is community discussion and social
> consensus estimation as well as miner signaling during the actual
> deployment period. Neither of these are perfect, but they are both
> reasonable enough mechanisms. However, because both of these mechanisms are
> very rough estimates of user sentiment, we need to consider the possibility
> that sometimes the estimate may be substantially inaccurate when we design
> deployment procedures. This inaccuracy is why we need multiple barriers in
> place for an upgrade, and why we need to have higher thresholds of success
> (require larger supermajorities in both consensus and miner signaling).
>
> Developers obviously care about bitcoin and have an incentive (personal
> and probably financial) to do it right. And miners have both an incentive
> to keep the system healthy, as well as an incentive to mine on the chain
> that the economic majority of users is using. But measuring the consensus
> of the bitcoin community can be extraordinarily difficult to do with
> consistent accuracy, and so I think miner signaling as it has been used as
> a second barrier to entry for an upgrade is quite appropriate.
>
> On Sun, Jun 27, 2021 at 2:22 AM Eric Voskuil  wrote:
>
>> I have not objected to anyone splitting. As I said, a split is always
>> possible, and of course has been done on a large scale. It is only the
>> misleading statements about inherent soft fork “compatibility” and the
>> implication that activation without hash power enforcement does not create
>> a split that I object to. People who know better should be honest about it.
>>
>> Far too many people have been led to believe there is 

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 only one answer to this question. Get majority hash power 
> support.
>
> Soft fork enforcement is the same act as any other censorship enforcement, 
> the difference is only a question of what people want. Given that there is no 
> collective “we”, those wants differ. Bitcoin resolves this question of 
> conflicting wants, but it is not a democracy, it’s a market. One votes by 
> trading.
>
> If one wants to enforce a soft fork (or otherwise censor) this is 
> accomplished by mining (or paying others to do so). Anyone can mine, so 
> everyone gets a say. Mining is trading capital now for more later. If enough 
> people want to do that, they can enforce a soft fork. It’s time Bitcoiners 
> stop thinking of miners as other people. Anyone can mine, and that’s your 
> vote.
>
> Otherwise, as mentioned below, anyone can start a new coin. But it’s 
> dishonest to imply that one can do this and all others will surely follow. 
> This cannot be known, it’s merely a gamble. And it’s one that has been shown 
> to not always pay off.
>
> e
>
> > On Jun 26, 2021, at 14:43, Eric Voskuil  wrote:
> >
> > For some definitions of “block”.
> >
> > Without majority hash power support, activation simply means you are off on 
> > a chain split. Anyone can of course split off from a chain by changing a 
> > rule (soft or otherwise) at any time, so this is a bit of an empty claim.
> >
> > Nobody can stop a person from splitting. The relevant question is how to 
> > *prevent* a split. And activation without majority hash power certainly 
> > does not “ensure” this.
> >
> > e
> >
> >> On Jun 26, 2021, at 14:13, Luke Dashjr via bitcoin-dev 
> >>  wrote:
> >>
> >> BIP8 LOT=True just ensures miners cannot block an upgrade entirely. They 
> >> can
> >> still slow it down.
> >>
> >> It also already has the trinary state you seem to be describing (although
> >> perhaps this could be better documented in the BIP): users who oppose the
> >> softfork can and should treat the successful signal (whether MASF or UASF) 
> >> as
> >> invalid, thereby ensuring they do not follow a chain with the rules in 
> >> force.
> >>
> >> No additional bit is needed, as softforks are coordinated between users, 
> >> NOT
> >> miners (who have no particular say in them, aside from their role as also
> >> being users). The miner involvement is only out of necessity (to set the 
> >> bit
> >> in the header, which users coordinate with) and potentially to accelerate
> >> activation by protecting upgrade-lagging users.
> >>
> >> Luke
> >>
> >>
>  On Saturday 26 June 2021 20:21:52 Billy Tetrud via bitcoin-dev wrote:
> >>> Given the recent controversy over upgrade mechanisms for the
> >>> non-controversial taproot upgrade, I have been thinking about ways to 
> >>> solve
> >>> the problems that both sides brought up. In short, BIP8 LOT=true 
> >>> proponents
> >>> make the point that lazy miners failing to upgrade in a timely manner slow
> >>> down releases of bitcoin upgrades, and BIP9 / BIP8 LOT=false
> >>> proponents make the point that LOT=true can lead to undesirable forks that
> >>> might cause a lot of chaos. I believe both points are essentially correct
> >>> and have created a proposal
> >>>  >>> ip-trinary-version-bits.md> for soft fork upgrades that solve both 
> >>> problems.
> >>>
> >>> The proposal uses trinary version signaling rather than binary signaling.
> >>> For any particular prospective soft fork upgrade, this allows for three
> >>> signaling states:
> >>>
> >>> * Actively support the change.
> >>> * Actively oppose the change.
> >>> * Not signaling (neither support or oppose). This is the default state.
> >>>
> >>> Using this additional information, we can release non-contentious upgrades
> >>> much quicker (with a much lower percent of miners signaling support). For
> >>> contentious upgrades, miners who oppose the change are incentivized to
> >>> update their software to a version that can actively signal opposition to
> >>> the change. The more opposition there is, the higher the threshold
> >>> necessary to lock in the upgrade. With the parameters I currently
> >>> recommended in the proposal, this chart shows how much support signaling
> >>> would be necessary given a particular amount of active opposition
> >>> signaling:
> >>>
> >>> [image: thresholdChart.png]
> >>> If literally no one signals opposition, a 60% threshold should be
> >>> relatively safe because it is a supermajority amount that is unlikely to
> >>> change significantly very quickly (ie if 60% of miners support the change
> >>> today, its unlikely that less than a majority of miners would support 

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 read.
>
> > This approach enables block building to consider Child Pays For Parent
> (CPFP) constellations.
>
> I think that's a really interesting point, it's likely that such
> transaction graphs with multiple disjunctive branches become far more
> regular in the future. One can think about OP_CTV's style
> congestion-tree, LN's splicing or chain of coinjoins. If this phenomenon
> happens, can you expect CSB feerate perf to improve ?
>
> > CSB is more complex and requires more computation
>
> Let's say a malicious miner identifies and connects to its competitors'
> mempools then starts to broadcast to them hard-to-traverse CPFP
> constellations. Doing so, this malicious miner would prevent them either
> from assembling block templates at all or slow down their assemblage
> computation enough to gain an advantage in fee collection. Following
> current mempools limits, it would be relevant to know by how much CSB makes
> that kind of DoS possible/efficient.
>
> > From the point of view of global blockspace demand, if miners generally
> became DPFA-sensitive,
> it could encourage creation of additional transactions for the sole
> purpose of bumping stuck ancestors.
>
> As ASB's ancestor set and CSB's candidate set, a fee bidder, we'll have to
> pay the feerate to cover the new transaction fields, high enough to catch
> up with the already-present feerate set ? Likely more feerate efficient to
> RBF the first child, though you have to swallow the replacement feerate
> penalty (default 1 sat/vbyte iirc)
>
> Antoine
>
> Le mar. 25 mai 2021 à 10:34, Murch via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Hi Bitcoin Devs,
>>
>> We are writing to share with you a suggested improvement to the current
>> bitcoin core block building algorithm. In short, currently Bitcoin Core
>> uses a straightforward greedy algorithm which evaluates each
>> transaction’s effective fee rate in the context of its unconfirmed
>> ancestors. This overlooks situations in which multiple descendant
>> transactions could be grouped with their shared ancestors to form a more
>> attractive transaction set for block inclusion.
>>
>> For example, if we have 4 transactions A,B,C, and D, with fee rates and
>> weights as follows
>>
>> Tx Fee Weight
>> A51
>> B   101
>> C   151
>> D   141
>>
>> And dependencies:
>> • B is a descendant of A
>> • C is a descendant of B
>> • D is a descendant of A
>> The current algorithm will consider {A,B,C} best which has an effective
>> fee rate of 10. Our suggested algorithm will also consider {A,B,C,D},
>> which has an effective fee rate of 11.
>>
>> Experimental data shows that our suggested algorithm did better on more
>> than 94% of blocks (99% for times of high congestion). We have also
>> compared the results to CBC and SAT Linear Programming solvers. The LP
>> solvers did slightly better, at the price of longer running times. Greg
>> Maxwell has also studied LP solvers in the past, and his results suggest
>> that better running times are possible.
>>
>> The full details are given in this document, and we are happy to hear
>> any comment, critic or suggestion!
>>
>> Best,
>> Mark and Clara
>>
>> Full details:
>>
>> https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md
>>
>> Research Code:
>> https://github.com/Xekyo/blockbuilding
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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:

> > Because the above block header format is hashed to generate the
> `prevBlockHash` for the *next* block, it is almost impossible to change the
> format without a hardfork.
>
> First, assume that everything should be validated as today to be
> backward-compatible. For that reason, removing SHA-256 is impossible. Then,
> notice that breaking SHA-256 would mean that there would be more and more
> leading zeroes in "prevBlockHash". Breaking SHA-256 fully would mean
> reaching all zeroes hash. So, the old client would see "prevBlockHash" with
> all zeroes.
>
> Soft-fork means that previously valid blocks could be invalid, so rules
> should be more strict. And that means we could have two headers, one for
> SHA-256 and one for SHA-3. Normally, it would mean that our 80-byte headers
> would take 160 bytes instead. But we could compress it a little bit if we
> share some data.
>
> > * `nVersion`: 4 bytes
>
> Version would be some higher number than today and validated as today. It
> could be shared for both headers.
>
> > * `prevBlockHash`: 32 bytes, SHA2 of previous block.
>
> Previous block hash in SHA-256 would have more and more leading zeroes, so
> we could reuse them and fill with SHA-3 truncated to N bits. In this way,
> after fully breaking SHA-256 it would be fully replaced by SHA-3. Until
> then, first N bits could refer to truncated SHA-3 and the rest to SHA-256.
> When passing that to old nodes, that bits could be zeroed, but all new
> nodes should see them and perform SHA-3 validation.
>
> Example:
>
> SHA-2 of some block:
> 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
> SHA-3 of the same data:
> 95587d55da5108290c46bac70b622715ae380ef7a313febcc27aeb1c51a28d90
> 32 bytes stored for that block:
> 95587d550019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
>
> Of course, we should perform SHA-3 on a different data than used for
> SHA-2, at least merkle root should be recalculated, but it is just an
> example showing how single 32-byte string could store data for both hash
> functions.
>
> > * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.
>
> If SHA-256 would be broken, then we could use single coinbase transaction
> to prevent doing transactions in the old way. That transaction would
> contain SHA-3 of the new merkle root, as you mentioned. New nodes could
> treat that transaction as some kind of annex to the block header, but still
> doing SHA-2 is needed for backward compatibility. For that reason, storing
> 32 bytes for SHA-2 and 32 bytes for SHA-3 is needed, unless we have some
> fast way to get hash with all zeroes, then we can save that 32 bytes.
>
> > * `nTime`: 4 bytes, miner-imagined time.
>
> Time should be the same in both headers, so there is no need to duplicate
> it.
>
> > * `nBits`: 4 bytes, encoded difficulty target
>
> Difficulty should be different for SHA-2 and SHA-3. Finally when SHA-256
> would be broken, we could reach 0300 for SHA-256 and store only SHA-3
> difficulty.
>
> > * `nonce`: 4 bytes, random number with no other meaning.
>
> Nonce should be also different for SHA-2 and SHA-3. If SHA-256 would be
> fully broken, it could be set to zero for SHA-2 and stored only for SHA-3.
>
> On 2021-05-23 20:12:00 user ZmnSCPxj  wrote:
> > Good morning vjudeu,
> >
> > > > Perhaps the only things that cannot be usefully changed in a
> softfork is the block header format and how proof-of-work is computed from
> the block header.
> > >
> > > Why not? I can imagine a soft fork where the block header would
> contain SHA-256 and SHA-3 hashes in the same place. The SHA-256 would be
> calculated as-is, but the SHA-3 would be truncated only to cover zero bits
> in SHA-256 hashes. In this way, if SHA-256 would be totally broken, old
> nodes would see zero hashes in the previous block hash and the merkle tree
> hash, but the new nodes would see correct SHA-3 hashes in the same place.
> So, for example if we have 1d00 difficulty, the first 32-bits would be
> zeroes for all old nodes, but all new nodes would see SHA-3 truncated to
> 32-bits in the same place. The difficulty could tell us how many zero bits
> we should truncate our SHA-3 result to. Also, in the same way we could
> introduce SHA-4 in the future as a soft-fork if SHA-3 would be broken and
> we would see many zero bits in our mixed SHA-256 plus SHA-3 consensus.
> >
> > I do not think I follow.
> >
> > The block header has a Merkle tree root that is a SHA-256 of some Merkle
> tree node, is that what you refer to?
> > Do you mean the same Merkle tree node has to hash to some common value
> in both SHA-2 and SHA-3?
> >
> > Or do you refer to the `prevBlockHash`?
> > Do you mean the same `prevBlockHash` 

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 going to be hard though.
Even among developers, these proposals seem to be kind of taboo, because
people tene to perceive them as "attacking miners".
Sadly the notion that miners decide consensus rules is pretty extended even
among developers. The recent bip8(true) vs bip8(false) discussions are
anundant evidence that this is the case. Most devs perceive that not giving
miners veto power over proposals somehow means that then developers become
dictators who can unilaterally decide the rules.
They don't accept the fact that it's users who decide the consensus rules.
For them, if it's not miners who decide, then it must be devs. That's
because they see users as a bunch of uninformed imbeciles who can't
understand anything or decide anything. And yet this arrogant position is
coming from people who seemingly don't understand section 11 of the
whitepaper when it says "even with a hashrate majority, that doesn't allow
one to arbitrarily change the rules or forge signatures" which can be
summarized to "miners DO NOT decide the rules.

Given these deeps misunderstandings, most devs (and who knows how many
users) will consider a softfork to reduce mining subsidy "impossible, since
miners will oppose it".
This incredibly sad situation is where we're at.

I personally would be in favor of a softfork to reduce the subsidy. That
would hopefully pacify some of the people concerned with bitcoin's energy
consumption. Bitcoin ecologists should defend this and not "proof of stake"
and other technical nonsense.







On Mon, May 24, 2021, 21:32 Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Before we can decide on tradeoffs that reduce security in favor of less
> energy usage, or less inflation, or whatever goal you might have for
> reducing (or delaying) coinbase rewards, we need to decide as a community
> how much security bitcoin *needs*.
>
> Do we need to be secure against an attacker with a budget of $1
> billion/year for an attack? $10 billion/year? More?
>
> An upper limit would be the budget of the largest government: the US. The
> US federal budget is almost $5 trillion/year. But they certainly couldn't
> spend all that budget attacking bitcoin. About $3 trillion of that is
> mandatory spending, which couldn't be allocated to such an attack. About
> $1.5 trillion is discretionary, which includes the military budget. It
> seems like an upper limit on the amount that could be siphoned from that
> budget to attack bitcoin would be 5%. That would take massive political
> cooperation and wheeling and dealing. Likely spending that much would not
> be politically feasible, but it seems possible, since a 5% reduction in
> other activities is something other departments would likely be able to
> sustain with just a bit of downsizing. Or that money could simply come from
> more borrowing. 5% of $1.5 trillion is $75 billion. So that seems like a
> pretty solid upper limit on the amount the US could allocate to an attack
> in a year, in that it seems incredibly unlikely that more money than that
> could be allocated. Such an expenditure might be eventually seen as
> justified since the federal reserve has been inflating the supply of
> dollars by 17.5% on average every year, which would be $1 trillion next
> year (and more the next, etc). A similar story is told if you calculate the
> amount of seigniorage banks get access to by their ability to use
> fractional reserve to inflate the supply of M2 money.  It should be
> considered tho that this seigniorage doesn't give its beneficiaries that
> full value, but rather some fraction of that value - say 5% earned by being
> first to buy with that new money and earning interest on it. So 5% of a
> trillion is $50 billion. Still, over just two years, that's enough to pay
> for an attack of at least that size ($75 billion).
>
> The budget for the government of China is about $3.6 trillion, the second
> largest in the world. And since they're an authoritarian country, they can
> basically do whatever they want with that money. It still seems unlikely
> they would spend more than 5% of that budget on doing something like
> attacking bitcoin. However, consider that China's M2 money supply has been
> increasing at a rate of almost $3 trillion per year. Protecting the ability
> to do this is seems like something worth spending some (printed) money on.
> So perhaps at some point, spending 10 or 20% of their budget for a year or
> two to attack bitcoin might seem like a good idea to some mickey mouse in
> the government. That would be $720 billion/year.
>
> So given the amount of seigniorage taken in every year by these central
> banks, it would seem to justify 

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.  "Soft" forks can be useful.
>
> Raystonn
>
> --
> *From:* Jorge Timón 
> *Sent:* Saturday, May 22, 2021 7:55 AM
> *To:* Raystonn . ; Bitcoin Protocol Discussion <
> bitcoin-dev@lists.linuxfoundation.org>
> *Subject:* 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
> important changes that made things like lightning much easier and efficient
> than they could possibly be without them.
> Taproot, which is a recent proposal, could help simplify the lightning
> protocol even further, and make it more efficient and its usage more
> private. And there are more use cases.
>
> There have been consensus rule changes since bitcoin started, and with
> good reason. As a user, you can always oppose new changes. And if enough
> users agree with you, you will be able to maintain your own chain with the
> old rules. At the same time, there's nothing you can do to stop other users
> who want those changes from coordinating with each other to adopt them.
>
> Perhaps you're interested in bip99, which discusses consensus rule changes
> in more detail.
>
>
>
> On Sat, May 22, 2021, 13:09 Raystonn . via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Suggestions to make changes to Bitcoin's consensus protocol will only ever
> be entertained if Bitcoin is completely dead without such a change.  Any
> attempt to change consensus protocol without a clear and convincing
> demonstration to the entire network of participants that Bitcoin will die
> without that change is a waste of your own time.  Bitcoin's resistance to
> consensus changes is a feature that makes it resistant to being coopted and
> corrupted.  I recommend developers focus on making improvements that do not
> attempt to change the consensus protocol.  Otherwise, you are simply
> working on an altcoin, which is off-topic here.
>
> Raystonn
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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
important changes that made things like lightning much easier and efficient
than they could possibly be without them.
Taproot, which is a recent proposal, could help simplify the lightning
protocol even further, and make it more efficient and its usage more
private. And there are more use cases.

There have been consensus rule changes since bitcoin started, and with good
reason. As a user, you can always oppose new changes. And if enough users
agree with you, you will be able to maintain your own chain with the old
rules. At the same time, there's nothing you can do to stop other users who
want those changes from coordinating with each other to adopt them.

Perhaps you're interested in bip99, which discusses consensus rule changes
in more detail.



On Sat, May 22, 2021, 13:09 Raystonn . via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Suggestions to make changes to Bitcoin's consensus protocol will only ever
> be entertained if Bitcoin is completely dead without such a change.  Any
> attempt to change consensus protocol without a clear and convincing
> demonstration to the entire network of participants that Bitcoin will die
> without that change is a waste of your own time.  Bitcoin's resistance to
> consensus changes is a feature that makes it resistant to being coopted and
> corrupted.  I recommend developers focus on making improvements that do not
> attempt to change the consensus protocol.  Otherwise, you are simply
> working on an altcoin, which is off-topic here.
>
> Raystonn
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 under
> their control, and abuse it in the same manner in which they abused
> Bitcoin
> Core's usual standards (by releasing ST without community consensus).
>

I haven'tpaying attention to the BIPs.
But I just want to say I agree it is the case that speed trial didn't have
consensus and had many good and logical arguments against it.
Sadly discussions around taproot activation I've been lacking logic and
having too many irrational arguments appealing to emotions.

I'm really disapointed at the community right now.
I'm sorry for luke and others defending lot=true (the whole point of bip8
anyway), but I feel ignored and frustrated when I try to participate in
these irrational debates.
I miss the rational debates here.

But if we're gping to turn this list into an irrational place, with ad
hominem fallacies and insults, I guess I can say my subjective personal
opinion about other people too.
I think it is you, Matt, who is playing dumb, not Luke.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 said already beyond perhaps: sigh.
My arguments will probably ignored again, so it doesn't matter.


On Sun, Apr 4, 2021, 06:39 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We'll be having another meeting this Tuesday, as per
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018699.html.
> If you can't make it feel free to leave a comment on any agenda item below,
> or if you think there are other things to be discussed.
>
> Agenda:
>
> 1. AJ's update to MTP time.
>
> Please review https://github.com/bitcoin/bitcoin/pull/21377 as AJ updated
> it substantially.
>
> The PR is now purely MTP based, and the state machine has been simplified.
> This approach is intended to be compatible with a mandatory signaling
> period (via a LAST_CHANCE change) and makes it easier to deploy ST on
> signets (irrelevant for Taproot, because it is already active on all
> signets).
>
> 2. Selecting between MTP and Height
>
> In the previous meeting, there was no substantial publicly discussed
> benefit to using MTPs over height. Since agenda item 1, there is now a
> tangible benefit to using MTP.
>
> The changes AJ promulgated for MTP neutralizes the argument, mostly, that
> MTP was easier to review. As such, the main conversation in this agenda
> item is around the pros/cons of height or MTP and determining if we can
> reach consensus on either approach.
>
> 3. Timeline Discussion
> In all hope, we will reach consensus around item 2. Should that occur, we
> can use this time to discuss a final selection on parameters, mindful of
> Core's process.
>
> If the meeting doesn't reach rough consensus around item 2, it seems that
> we may fall short on the proposed schedule from last time. In this section,
> we can discuss realities around scheduling.
>
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 activation rather
than limiting themselves to suport bip9/bip8(false) and hope it doesn't get
activated it.

Some other arguments seem to be based on the wrong assumption that miners
should decide the rules.

Thisproposal solves nothing, just adds to the noise and thus is really
disappointing.


On Sat, Mar 6, 2021, 12:33 Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Wed, Mar 03, 2021 at 11:49:57AM -0500, Matt Corallo wrote:
> > On 3/3/21 09:59, Anthony Towns wrote:
> > > A couple of days ago I would have disagreed with this; but with Luke
> > > now strongly pushing against implementing lot=false, I can at least see
> > > your point...
> > Right. It may be the case that the minority group threatening to fork off
> > onto a lot=true chain is not large enough to give a second thought to.
> > However, I'm not certain that its worth the risk, and, as Chris noted in
> his
> > post this morning, that approach is likely to include more drama.
>
> I think there's two different interpretations of what a "user-activated
> fork" means:
>
>  1) if people try to take bitcoin in a direction that risks destroying
> it, it's possible to ignore both devs and hashpower entirely and force
> a chain split to ensure it's possible to continue transacting with
> "the real bitcoin".
>
>  2) removing miners' influence over consensus rules entirely -- so that
> not only can users overcome miner objections by risking a chain split,
> but so that miners don't have any greater ability to object than
> anyone else in the ecosystem.
>
> In my opinion, bip8's optional lockinontimeout setting and must-signal
> approach is well-designed for case 1; if miners object for good reasons,
> then there is no need to override them (if there's a good reason not to do
> something, it shouldn't be done!), while still having the possibility to
> override them if they object for bad reasons. Because hashpower disagrees,
> there's always a risk of a chain split in that case, so the additional
> risk introduced by a signalling requirement is pretty minimal. That the
> lockinontimeout value is a setting means it can be switched only when
> we're sure there aren't good reasons for the objection.
>
> There is a lot of work to be done to make bitcoind have an acceptable
> chance of gracefully *surviving* a network split introduced by this sort
> of conflict; but provided no one started setting lockinontimeout=true
> until we were six or so months into an activation attempt (and hence
> had the opportunity to judge whether the reasons for not activating
> were bad), that would likely be enough time to start implementing some
> safety mechanisms.
>
> But there seems to be much more signficant support for the case 2 than I
> expected; as evidenced by the "let's do lockinontimeout=true immediately"
> advocacy, eg:
>
>   I am not willing to go to war for Taproot. I'll be honest the reason
>   I'm interested at all is that devs I respect spent a lot of energy and
>   time on it and I was reluctant to let their marginally beneficial work
>   go to waste.
>
>   I am, however, willing to go to war against LOT=False.
>
>-- https://twitter.com/francispouliot_/status/1363876292169465856
>
> I don't think bip8 is well-designed for that approach: most importantly,
> with early adoption of lockinontimeout=true, bip8 *encourages* a consensus
> split in the event that good reasons for not activating are discovered
> afterwards, because lockinontimeout=false nodes remain able to abandon
> the activation attempt. Consensus splits are terrible; they should be
> a last resort used only in the event that bitcoin's fundamental nature
> is threatened, not a standard risk if bugs happened to be discovered
> late. But additionally, if we are worried miners might not be acting
> in the interests of all bitcoin users, there are other games they could
> play, such as "if you want X activated quickly, also give us Y; otherwise
> we'll delay it as long as possible".
>
> Losing the opportunity to abandon an activation attempt, by whatever
> mechanism, also puts a lot more pressure on being absolutely sure of the
> desirability of the change at the point when it's merged; because miners,
> third-party devs, businesses, and users don't even have the option of
> attempting to influence miners, all objections needs to be raised when
> the activation parameters are merged, which raises the stakes for that
> event substantially.
>
> I think my conclusions from that are:
>
>  * as it stands, people are expecting to run bip8/lot=true nodes on the
>network immediately; so deploying bip8/lot=false with compatible
>parameters risks causing 

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 this, but if people want it I offer
myself to code it,
I mean, just imagine that a day after publishing a bitcoin core
release with activation software for taproot some one, let's say in
New York reach an Agreement to "just use the same activation
mechanism, but for our 32 mb hardfork, it's about time, now computers
are 64 bits anyway". How convenient would it be to just cancel that
with 2 lines in bitcoin core?
Not that I think it will be necessary, but perhaps we want it just in case.

On Mon, Feb 22, 2021 at 5:31 PM Jorge Timón  wrote:
>
> 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).
> Some may argue than it's easier to move from LOT=false to LOT=true
> than viceversa (I think I'm getting this right), but either way
> different clients could interpret things more differently more easily
> and, you know, that's really bad.
> If anyone is against the consensus change itself, what they should do
> is run a client in which the must is turned into a MUST NOT. Whenever
> miners signal activation, blocks aren't valid so that it doesn't
> happen.
> That way both sides can be cleanly separated and both communities
> (assuming there's a community of users opposing the change) can stick
> together with their own in the same chain. That is, having only 2
> chains in total if there are users opposing the change or only one if
> not, but never 2 chains for people who want the change or 2 chains for
> pople who don't want it.
>
> Just my two sats, please nobody ask me "why would anyone oppose
> taproot?" or anything similar. Because I'm trying to generalize here,
> if we're talking about activation, I think the specifics of the change
> are kind of irrelevant.
>
> Separately: thanks to everyone who worked on taproot.
>
>
> On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
>  wrote:
> >
> >
> >
> > On Feb 22, 2021, at 05:16, Anthony Towns  wrote:
> >
> > If a lockinontimeout=true node is requesting compact blocks from a
> > lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> > I think that could result in a ban.
> >
> > More importantly, nodes on both sides of the fork need to find each other.
> >
> >
> > (If there was going to be an ongoing fork there'd be bigger things to
> > worry about...)
> >
> >
> > I think it should be clear that a UASF-style command line option to allow 
> > consensus rule changes in the node in the short term, immediately before a 
> > fork carries some risk of a fork, even if I agree it may not persist over 
> > months. We can’t simply ignore that.
> >
> > I think the important specific case of this is something like "if a chain
> > where taproot is impossible to activate is temporarily the most work,
> > miners with lockinontimeout=true need to be well connected so they don't
> > end up competing with each other while they're catching back up".
> >
> >
> > Between this and your above point, I think we probably agree - there is 
> > material  technical complexity hiding behind a “change the consensus rules“ 
> > option. Given it’s not a critical feature by any means, putting resources 
> > into fixing these issues probably isn’t worth it.
> >
> > Matt
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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).
Some may argue than it's easier to move from LOT=false to LOT=true
than viceversa (I think I'm getting this right), but either way
different clients could interpret things more differently more easily
and, you know, that's really bad.
If anyone is against the consensus change itself, what they should do
is run a client in which the must is turned into a MUST NOT. Whenever
miners signal activation, blocks aren't valid so that it doesn't
happen.
That way both sides can be cleanly separated and both communities
(assuming there's a community of users opposing the change) can stick
together with their own in the same chain. That is, having only 2
chains in total if there are users opposing the change or only one if
not, but never 2 chains for people who want the change or 2 chains for
pople who don't want it.

Just my two sats, please nobody ask me "why would anyone oppose
taproot?" or anything similar. Because I'm trying to generalize here,
if we're talking about activation, I think the specifics of the change
are kind of irrelevant.

Separately: thanks to everyone who worked on taproot.


On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev
 wrote:
>
>
>
> On Feb 22, 2021, at 05:16, Anthony Towns  wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
> More importantly, nodes on both sides of the fork need to find each other.
>
>
> (If there was going to be an ongoing fork there'd be bigger things to
> worry about...)
>
>
> I think it should be clear that a UASF-style command line option to allow 
> consensus rule changes in the node in the short term, immediately before a 
> fork carries some risk of a fork, even if I agree it may not persist over 
> months. We can’t simply ignore that.
>
> I think the important specific case of this is something like "if a chain
> where taproot is impossible to activate is temporarily the most work,
> miners with lockinontimeout=true need to be well connected so they don't
> end up competing with each other while they're catching back up".
>
>
> Between this and your above point, I think we probably agree - there is 
> material  technical complexity hiding behind a “change the consensus rules“ 
> option. Given it’s not a critical feature by any means, putting resources 
> into fixing these issues probably isn’t worth it.
>
> Matt
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 help to reduce upgrade risks unless they
upgrade. It doesn't matter if the activation is silent or with
mandatory signaling. Am I missing something?

>  in order to nudge miners

That's not the goal at all. All my arguments have been focused on
users, not miners.

> If you want to fork yourself off the network, you can do it in easier ways,

Well, it's not that you want to fork yourself off the network, is that
you don't want change X. Ideally change X wouldn't be activated, but
if it is, you prefer to be in a chain without change X.
Let's say we're using your system to deploy change X you oppose for
legitimate reasons.
What easier thing would you do as a user to resist change X with all
other users who also oppose it?

If there are simpler and better ways to do this, great. It's just
something to think about.





On Fri, Jan 10, 2020 at 11:43 PM Matt Corallo  wrote:
>
> I went back and forth with a few folks on this one. I think the fact that we 
> lose goals 3/4 very explicitly in order to nudge miners seems like a poor 
> trade off. I’ll note that your point 2 here seems a bit disconnected to me. 
> If you want to fork yourself off the network, you can do it in easier ways, 
> and if miners want to maliciously censors transactions to the detriment of 
> users, rejecting a version bit doesn’t really help avoid that.
>
> Your point about upgrade warnings is well-made, but I’m dubious of it’s value 
> over the network chaos many large forks might otherwise cause.
>
> Matt
>
> > On Jan 10, 2020, at 17:22, Jorge Timón  wrote:
> >
> > 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 date x if failed to do so by miners' signaling, a
> > consensus rule could require the blocks to signal for activation in
> > the last activation window.
> > I see 2 main advantages for this:
> >
> > 1) Outdated nodes can implement warnings (like in bip9) and they can
> > see those warnings even if it's activated in the last activation
> > window. Of course this can become counterproductive if miners' squat
> > signaling bits for asicboost again.
> >
> > 2) It is easier for users to actively resist a given change they
> > oppose. Instead of requiring signaling, their nodes can be set to
> > ignore chains that activate it. This will result in a fork, but if
> > different groups of users want different things, this is arguably the
> > best behaviour: a "clean" split.
> >
> > I assume many people won't like this, but I really think we should
> > consider how users should ideally resist an unwanted change, even if
> > the proponents had the best intentions in mind, there may be
> > legitimate reasons to resist it that they may not have considered.
> >
> >> On Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev
> >>  wrote:
> >>
> >> There are a series of soft-fork designs which have recently been making
> >> good progress towards implementation and future adoption. However, for
> >> various reasons, activation methods therefor have gotten limited
> >> discussion. I'd like to reopen that discussion here.
> >>
> >> It is likely worth revisiting the goals both for soft forks and their
> >> activation methods to start. I'm probably missing some, but some basic
> >> requirements:
> >>
> >> 1) Avoid activating in the face of significant, reasonable, and directed
> >> objection. Period. If someone has a well-accepted, reasonable use of
> >> Bitcoin that is working today, have no reason to believe wouldn't work
> >> long into the future without a change, and which would be made
> >> impossible or significantly more difficult by a change, that change must
> >> not happen. I certainly hope there is no objection on this point (see
> >> the last point for an important caveat that I'm sure everyone will jump
> >> to point out).
> >>
> >> 2) Avoid activating within a timeframe which does not make high
> >> node-level-adoption likely. As with all "node" arguments, I'll note that
> >> I mean "economically-used" nodes, not the thousand or so spy nodes on
> >> Google Cloud and AWS. Rule changes don't make sense without nodes
> >> enforcing them, whether they happen to be a soft fork, hard fork, or a
> >> blue fork, so activating in a reduced timeframe that doesn't allow for
> >> large-scale node adoption doesn't have any value, and may cause other
> >> unintended side effects.
> >>
> >> 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of
> >> Bitcoin's security 

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 date x if failed to do so by miners' signaling, a
consensus rule could require the blocks to signal for activation in
the last activation window.
I see 2 main advantages for this:

1) Outdated nodes can implement warnings (like in bip9) and they can
see those warnings even if it's activated in the last activation
window. Of course this can become counterproductive if miners' squat
signaling bits for asicboost again.

2) It is easier for users to actively resist a given change they
oppose. Instead of requiring signaling, their nodes can be set to
ignore chains that activate it. This will result in a fork, but if
different groups of users want different things, this is arguably the
best behaviour: a "clean" split.

I assume many people won't like this, but I really think we should
consider how users should ideally resist an unwanted change, even if
the proponents had the best intentions in mind, there may be
legitimate reasons to resist it that they may not have considered.

On Fri, Jan 10, 2020 at 10:30 PM Matt Corallo via bitcoin-dev
 wrote:
>
> There are a series of soft-fork designs which have recently been making
> good progress towards implementation and future adoption. However, for
> various reasons, activation methods therefor have gotten limited
> discussion. I'd like to reopen that discussion here.
>
> It is likely worth revisiting the goals both for soft forks and their
> activation methods to start. I'm probably missing some, but some basic
> requirements:
>
> 1) Avoid activating in the face of significant, reasonable, and directed
> objection. Period. If someone has a well-accepted, reasonable use of
> Bitcoin that is working today, have no reason to believe wouldn't work
> long into the future without a change, and which would be made
> impossible or significantly more difficult by a change, that change must
> not happen. I certainly hope there is no objection on this point (see
> the last point for an important caveat that I'm sure everyone will jump
> to point out).
>
> 2) Avoid activating within a timeframe which does not make high
> node-level-adoption likely. As with all "node" arguments, I'll note that
> I mean "economically-used" nodes, not the thousand or so spy nodes on
> Google Cloud and AWS. Rule changes don't make sense without nodes
> enforcing them, whether they happen to be a soft fork, hard fork, or a
> blue fork, so activating in a reduced timeframe that doesn't allow for
> large-scale node adoption doesn't have any value, and may cause other
> unintended side effects.
>
> 3) Don't (needlessly) lose hashpower to un-upgraded miners. As a part of
> Bitcoin's security comes from miners, reducing the hashpower of the
> network as a side effect of a rule change is a needless reduction in a
> key security parameter of the network. This is why, in recent history,
> soft forks required 95% of hashpower to indicate that they have upgraded
> and are capable of enforcing the new rules. Further, this is why recent
> soft forks have not included changes which would result in a standard
> Bitcoin Core instance mining invalid-by-new-rules changes (by relying on
> the standardness behavior of Bitcoin Core).
>
> 4) Use hashpower enforcement to de-risk the upgrade process, wherever
> possible. As a corollary of the above, one of the primary reasons we use
> soft forks is that hashpower-based enforcement of rules is an elegant
> way to prevent network splits during the node upgrade process. While it
> does not make sense to invest material value in systems protected by new
> rules until a significant majority of "economic nodes" is enforcing said
> rules, hashpower lets us neatly bridge the gap in time between
> activation and then. By having a supermajority of miners enforce the new
> rules, attempts at violating the new rules does not result in a
> significant network split, disrupting existing users of the system. If
> we aren't going to take advantage of this, we should do a hard fork
> instead, with the necessarily slow timescale that entails.
>
> 5) Follow the will of the community, irrespective of individuals or
> unreasoned objection, but without ever overruling any reasonable
> objection. Recent history also includes "objection" to soft forks in the
> form of "this is bad because it doesn't fix a different problem I want
> fixed ASAP". I don't think anyone would argue this qualifies as a
> reasonable objection to a change, and we should be in a place, as a
> community (never as developers or purely one group), to ignore such
> objections and make forward progress in spite of them. We don't make
> good engineering decisions by "bundling" unrelated features together to
> enable political 

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 situation is less likely in this case than
with op_expiry, but it is still possible.
Another complain I could imagine is this kind of forces the
implementation to break some existing encapsulations, but I guess
those are just implementation details not that relevant here.
I personally don't have strong feelings towards this proposal one way
or the other, I'm just imagining what other people may complain about.

On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
 wrote:
>
> Difficulty change has profound impact on miner’s production thereby introduce 
> the biggest risk while considering an investment.
> Commodity markets offer futures and options to hedge risks on traditional 
> trading venues. Some might soon list difficulty futures.
>
> I think we could do much better than them natively within Bitcoin.
>
> A better solution could be a transaction that uses nLocktime denominated in 
> block height, such that it is valid after the difficulty adjusted block in 
> the future.
> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for 
> the block the transaction is included into.
> The output script may then decide comparing that value with a strike which 
> key can spend it.
> The input of the transaction would be a multi-sig escrow of those who entered 
> the bet.
> The winner would broadcast.
>
> Once signed by both the transaction would not carry any counterparty risk and 
> would not need an oracle to settle according to the bet.
>
> I plan to draft a BIP for this as I think this opcode would serve significant 
> economic interest of Bitcoin economy, and is compatible with Bitcoin’s aim 
> not to introduce 3rd party to do so.
>
> Do you see a fault in this proposal or want to contribute?
>
> Tamas Blummer
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 version 0.17.0 is now available from:
>
>   
>
> or through BitTorrent:
>
>   
> magnet:?xt=urn:btih:1c72f17bc1667a2ce81860b75135e491f6637d05=bitcoin-core-0.17.0=udp%3A%2F%2Ftracker.openbittorrent.com%3A80=udp%3A%2F%2Ftracker.opentrackr.org%3A1337=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969=udp%3A%2F%2Fzer0day.ch%3A1337=udp%3A%2F%2Fexplodie.org%3A6969
>
> This is a new major version release, including new features, various bugfixes
> and performance improvements, as well as updated translations.
>
> Please report bugs using the issue tracker at GitHub:
>
>   
>
> To receive security and update notifications, please subscribe to:
>
>   
>
> How to Upgrade
> ==
>
> If you are running an older version, shut it down. Wait until it has 
> completely
> shut down (which might take a few minutes for older versions), then run the
> installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
> or `bitcoind`/`bitcoin-qt` (on Linux).
>
> If your node has a txindex, the txindex db will be migrated the first time 
> you run 0.17.0 or newer, which may take up to a few hours. Your node will not 
> be functional until this migration completes.
>
> The first time you run version 0.15.0 or newer, your chainstate database will 
> be converted to a
> new format, which will take anywhere from a few minutes to half an hour,
> depending on the speed of your machine.
>
> Note that the block database format also changed in version 0.8.0 and there 
> is no
> automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
> directly from 0.7.x and earlier without redownloading the blockchain is not 
> supported.
> However, as usual, old wallet versions are still supported.
>
> Downgrading warning
> - ---
>
> The chainstate database for this release is not compatible with previous
> releases, so if you run 0.15 and then decide to switch back to any
> older version, you will need to run the old release with the 
> `-reindex-chainstate`
> option to rebuild the chainstate data structures in the old format.
>
> If your node has pruning enabled, this will entail re-downloading and
> processing the entire blockchain.
>
> Compatibility
> ==
>
> Bitcoin Core is extensively tested on multiple operating systems using
> the Linux kernel, macOS 10.10+, and Windows 7 and newer (Windows XP is not 
> supported).
>
> Bitcoin Core should also work on most other Unix-like systems but is not
> frequently tested on them.
>
> - From 0.17.0 onwards macOS <10.10 is no longer supported. 0.17.0 is built 
> using Qt 5.9.x, which doesn't
> support versions of macOS older than 10.10.
>
> Known issues
> 
>
> - - Upgrading from 0.13.0 or older currently results in memory blow-up during 
> the roll-back of blocks to the SegWit activation point. In these cases, a 
> full `-reindex` is necessary.
>
> - - The GUI suffers from visual glitches in the new MacOS dark mode. This has 
> to do with our Qt theme handling and is not a new problem in 0.17.0, but is 
> expected to be resolved in 0.17.1.
>
> Notable changes
> ===
>
> Changed configuration options
> - -
>
> - - `-includeconf=` can be used to include additional configuration 
> files.
>   Only works inside the `bitcoin.conf` file, not inside included files or from
>   command-line. Multiple files may be included. Can be disabled from command-
>   line via `-noincludeconf`. Note that multi-argument commands like
>   `-includeconf` will override preceding `-noincludeconf`, i.e.
>   ```
>   noincludeconf=1
>   includeconf=relative.conf
>   ```
>
>   as bitcoin.conf will still include `relative.conf`.
>
> GUI changes
> - ---
>
> - - Block storage can be limited under Preferences, in the Main tab. Undoing 
> this setting requires downloading the full blockchain again. This mode is 
> incompatible with -txindex and -rescan.
>
> External wallet files
> - -
>
> The `-wallet=` option now accepts full paths instead of requiring 
> wallets
> to be located in the -walletdir directory.
>
> Newly created wallet format
> - ---
>
> If `-wallet=` is specified with a path that does not exist, it will now
> create a wallet directory at the specified location (containing a wallet.dat
> data file, a db.log file, and database/log.?? files) instead of just
> creating a data file at the path and storing log files in the parent
> directory. This should make backing up wallets 

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:
> Since 2012 (IIRC) we've known that Bitcoin's non-overlapping
> difficulty calculation was vulnerable to gaming with inaccurate
> timestamps to massively increase the rate of block production beyond
> the system's intentional design. It can be fixed with a soft-fork that
> further constraints block timestamps, and a couple of proposals have
> been floated along these lines.
>
> I put a demonstration of timewarp early in the testnet3 chain to also
> let people test mitigations against that.  It pegs the difficulty way
> down and then churned out blocks at the maximum rate that the median
> time protocol rule allows.
>
> I, and I assume others, haven't put a big priority into fixing this
> vulnerability because it requires a majority hashrate and could easily
> be blocked if someone started using it.
>
> But there haven't been too many other network consensus rules going on
> right now, and I believe at least several of the proposals suggested
> are fully compatible with existing behaviour and only trigger in the
> presence of exceptional circumstances-- e.g. a timewarp attack.  So
> the risk of deploying these mitigations would be minimal.
>
> Before I dust off my old fix and perhaps prematurely cause fixation on
> a particular approach, I thought it would be useful to ask the list if
> anyone else was aware of a favourite backwards compatible timewarp fix
> proposal they wanted to point out.
>
> Cheers.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 timestamping I would recommend using pay 2 contract  instead.

On Tue, Aug 14, 2018 at 8:34 PM, Christopher Allen via bitcoin-dev
 wrote:
> On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev
>  wrote:
>>Should we actually be using the BIP process to claim a prefix?
>
> I recommend against using an op_return prefix, as they allow for transaction
> censorship.
>
> In fact, in our case, where we use an IPFS hash in an op_return, we remove
> the IPFS multihash prefix information to post a “bare” SHA256 hash to look
> like many other hashes being posted in op_returns, to minimize any ability
> for a miner to identify our transaction. The more projects that do this the
> better — a form of herd immunity.
>
> Longer term I’m looking for more responsible ways to publish this hash, for
> instance have the hash be in the witness script data, so that it can be
> easily purged from nodes that do not wish to preserve it and prevent block
> size bloat. However, to do so everyone has to do it the same way, ideally
> have it look like any other transaction. I’ve not quite seen a solid
> proposal for best practices here.
>
> — Christopher Allen
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 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, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> The largest problem we are having today with the lightning
>> protocol is trying to predict future fees.  Eltoo solves this elegantly,
>> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
>> commitment transactions so that we use minimal fees and then use CPFP
>> (which can't be done at the moment due to CSV delays on outputs).
>>
>> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
>> non-standard.  Are there any reasons not to suggest such a policy
>> change?
>>
>> Thanks!
>> Rusty.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> The largest problem we are having today with the lightning
> protocol is trying to predict future fees.  Eltoo solves this elegantly,
> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> commitment transactions so that we use minimal fees and then use CPFP
> (which can't be done at the moment due to CSV delays on outputs).
>
> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> non-standard.  Are there any reasons not to suggest such a policy
> change?
>
> Thanks!
> Rusty.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/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 plan out the
> future upgrades properly.
> Since I see 0.15 and 0.16 use block versions as 0x2000, whereas the
> current deployed codebase (based on bitcoin 0.9.4) makes versions 0x0002
> (as seen by a 0.15 client), it appears safe to activate soft forks which
> require a minimum of version 3 and 4 blocks (0x0003 and 0x0004,
> respectively). Would you agree?
>
> On Wed, Mar 28, 2018 at 7:55 AM, Jorge Timón  wrote:
>>
>> 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. IIRC the last thing
>> was bip65.
>>
>> On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev
>>  wrote:
>> > Is it possible to activate soft forks such as BIP65 and BIP66 without
>> > prior
>> > signaling from miners? I noticed in chainparams.cpp that there are block
>> > heights where the enforcement begins.
>> >
>> > I understand this is already active on bitcoin. I'm working on a project
>> > that is a clone of a clone of bitcoin, and we currently do not have
>> > BIP65 or
>> > BIP66 enforced - no signaling of these soft forks either (most of the
>> > network is on a source code fork of bitcoin 0.9). This project does not
>> > and
>> > never intends to attempt to replace bitcoin - we know that without
>> > bitcoin
>> > our project could never exist, so we owe a great deal of gratitude to
>> > the
>> > bitcoin developers.
>> >
>> > If the entire network upgrades to the correct version of the software
>> > (based
>> > on bitcoin 0.15), which includes the block height that has enforcement,
>> > can
>> > we simply skip over the signaling and go straight into
>> > activation/enforcement?
>> >
>> > At this time we are lucky that our network is very small, so it is
>> > reasonable to assume that the whole network will upgrade their clients
>> > within a short window (~2 weeks). We would schedule the activation ~2
>> > months
>> > out from when the client is released, just to ensure everyone has time
>> > to
>> > upgrade.
>> >
>> > We have been stuck on the 0.9 code branch and my goal is to bring it up
>> > to
>> > 0.15 at least, so that we can implement Segwit and other key features
>> > that
>> > bitcoin has introduced. The 0.15 client currently works with regards to
>> > sending and receiving transactions but the soft forks are not active. I
>> > understand that activating them will segregate the 0.15 clients onto
>> > their
>> > own fork, which is why I'd like to understand the repercussions of doing
>> > it
>> > without any signaling beforehand. I also would prefer not to have to
>> > make
>> > intermediate releases such as 0.10, 0.11.. etc to get the soft forks
>> > activated.
>> >
>> > Another related question - does the block version get bumped up
>> > automatically at the time that a soft fork activates, or is there
>> > additional
>> > stuff that I need to do within the code to ensure it bumps up at the
>> > same
>> > time? From what I saw in the code it appears that it will bump up
>> > automatically, but I would like some confirmation on that.
>> >
>> > Regards,
>> > Samad
>> >
>> >
>> >
>> > ___
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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. IIRC the last thing
was bip65.

On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev
 wrote:
> Is it possible to activate soft forks such as BIP65 and BIP66 without prior
> signaling from miners? I noticed in chainparams.cpp that there are block
> heights where the enforcement begins.
>
> I understand this is already active on bitcoin. I'm working on a project
> that is a clone of a clone of bitcoin, and we currently do not have BIP65 or
> BIP66 enforced - no signaling of these soft forks either (most of the
> network is on a source code fork of bitcoin 0.9). This project does not and
> never intends to attempt to replace bitcoin - we know that without bitcoin
> our project could never exist, so we owe a great deal of gratitude to the
> bitcoin developers.
>
> If the entire network upgrades to the correct version of the software (based
> on bitcoin 0.15), which includes the block height that has enforcement, can
> we simply skip over the signaling and go straight into
> activation/enforcement?
>
> At this time we are lucky that our network is very small, so it is
> reasonable to assume that the whole network will upgrade their clients
> within a short window (~2 weeks). We would schedule the activation ~2 months
> out from when the client is released, just to ensure everyone has time to
> upgrade.
>
> We have been stuck on the 0.9 code branch and my goal is to bring it up to
> 0.15 at least, so that we can implement Segwit and other key features that
> bitcoin has introduced. The 0.15 client currently works with regards to
> sending and receiving transactions but the soft forks are not active. I
> understand that activating them will segregate the 0.15 clients onto their
> own fork, which is why I'd like to understand the repercussions of doing it
> without any signaling beforehand. I also would prefer not to have to make
> intermediate releases such as 0.10, 0.11.. etc to get the soft forks
> activated.
>
> Another related question - does the block version get bumped up
> automatically at the time that a soft fork activates, or is there additional
> stuff that I need to do within the code to ensure it bumps up at the same
> time? From what I saw in the code it appears that it will bump up
> automatically, but I would like some confirmation on that.
>
> Regards,
> Samad
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

> I really don't see how this "outlier behaviour" can be prevented. I think
> it would be the norm even with your proposed "fix". Perhaps I'm missing
> something too.
>
> On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is correct. Under assumptions of a continuous mempool model however
>> this should be considered the outlier behavior, other than a little bit of
>> empty space at the end, now and then. A maximum fee rate calculated as a
>> filter over past block rates could constrain this outlier behavior from
>> ever happening too.
>>
>> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna 
>> wrote:
>> >
>> > Maybe I'm getting this wrong but wouldn't this scheme imply that a
>> miner is incentivized to limit the amount of transactions in a block to
>> capture the maximum fee of the ones included?
>> >
>> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
>> If I were to submit a transaction paying 1 btc in maximal money fees, then
>> the miner would be incentivized to include my transaction alone to avoid
>> that lower fee paying transactions reduce the amount of fees he can earn
>> from my transaction alone. This would mean that I could literally clog the
>> network by paying 1btc every ten minutes.
>> >
>> > Am I missing something?
>> >
>> > Daniele
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2017-09-09 Thread Jorge Timón via bitcoin-dev
Tier Nolan, right, a new tx version would be required.

I have to look deeper into the CT as sf proposal.

What futures upgrades could this conflict with it's precisely the
question here. So that vague statement without providing any example
it's not very valuable.

Although TXO commitments are interesting, I don't think they make UTXO
growth a "non-issue" and I also don't think they justify not doing
this.

Yeah, the costs for spammers are very small and doesn't really improve
things all that much, as acknowledged in the initial post.



On Thu, Sep 7, 2017 at 8:00 PM, Peter 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 (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 slightly better than the current
>> situation.
>
> Given that this has a very minimal cost for spammers - just a single satoshi -
> I don't think this is worth the risk of making future upgrades more complex as
> other posters have brought up.
>
> Secondly, I think we have good reason to think that things like my own TXO
> commitments and Bram's related work will make UTXO growth a non-issue in the
> future.
>
> So, I'd NACK such a proposal myself.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[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 slightly better than the current
situation.

Is there any reason or use case to keep allowing spendable outputs
with null amounts in them?

If not, I'm happy to create a BIP with its code, this should be simple.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 relevance.
> https://bitcointalk.org/index.php?topic=52859.0 : This idea does not seem
> to talking about trimming the full node. Trimming the full node is the key,
> the full node is what keeps us secure from hackers. If it can be trimmed
> without losing security, that would be good, that is what I am proposing.
> https://bitcointalk.org/index.php?topic=12376.0 : Same answer as 505.0.
> https://bitcointalk.org/index.php?topic=74559.15 : I think his proposal
> is similar to mine, unfortunately for us his predictions were way off. He
> was trying to fix this problem while believing that in the year 2020 the
> blockchain would be 4GB!!! It is not his fault, his prediction was in 2011.
> But you can see, by his prediction, which was rational at the time, was way
> off. And it stresses my point, we need to fix this now. Too bad, no one
> took him seriously back then, when the block chain i was 1GB.
> *https://bitcointalk.org/index.php?topic=56226.0
> *: Another guy with a
> valid point, who was first acknowledged and then apparently ignored.
> .
> To summarize, this problem was brought up about 6 years ago, when the
> blockchain was 1GB in size, Now it is about 140GB in size. I think it is
> about time we stop ignoring this problem, and realize something needs to
> change, or else the only full-nodes you will have will be with private
> multi-million dollar companies, because no private citizen will have the
> storage space to keep it. That would make bitcoin the worst decentralized
> or uncentralized system in history.
>
>
> On 27 August 2017 at 00:42, Christian Riley  wrote:
>
>> There have been a number of similar (identical?) proposals over the
>> years, some were discussed in these threads:
>> https://bitcointalk.org/index.php?topic=56226.0
>> https://bitcointalk.org/index.php?topic=505.0
>> https://bitcointalk.org/index.php?topic=473.0
>> https://bitcointalk.org/index.php?topic=52859.0
>> https://bitcointalk.org/index.php?topic=12376.0
>> https://bitcointalk.org/index.php?topic=74559.15
>>
>>
>> On Aug 26, 2017, at 5:01 PM, Adam Tamir Shem-Tov via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Solving the Scalability Problem Part II
>> 
>> 
>> In the previous post I showed a way to minimize the blocks on the block
>> chain, to lower the amount of space it takes on the hard drive, without
>> losing any relevant information.
>> I added a note, saying that the transaction chain needs to be rewritten,
>> but I did not give much detail to it.
>> Here is how that would work:
>> The Genesis Account:
>> -
>> The problem with changing the transaction and block chain, is that it
>> cannot be done without knowing the private key of the sender of the of the
>> funds for each account. There is however a way to circumvent that problem.
>> That is to create a special account called the “Genesis Account”, this
>> account’s Private Key and Public Key will be available to everyone.
>> But this account will not be able to send or receive any funds in a
>> normal block, it will be blocked--blacklisted. So no one can intentionally
>> use it. The only time this account will be used is in the pruning block,
>> a.k.a Exodus Block.
>> When creating the new pruned block chain and transaction chain, all the
>> funds that are now in accounts must be legitimate, and it would be
>> difficult to legitimize them unless they were sent from a legitimate
>> account, with a public key, and a private key which can be verified. That
>> is where the Genesis account comes in. All funds in the Exodus Block will
>> show as though they originated and were sent from the Genesis Account using
>> its privatekey to generate each transaction.
>> The funds which are sent, must match exactly the funds existing in the
>> most updated ledger in block 1000 (the last block as stated in my previous
>> post).
>> In this way the Exodus Block can be verified, and the Genesis Account
>> cannot give free money to anyway, because if someone tried to, it would
>> fail verification.
>>
>> 
>> Now the next problem is that the number of Bitcoins keeps expanding and
>> so the funds in the Genesis Account need to expand as well. That can be
>> done by showing as though this account is the account which is mining the
>> coins, and it will be the only account in the Exodus Block which “mines”
>> the coins, and receives the mining bonus. In the Exodus Block all coins
>> mined by the real miners will show as though they were mined by Genesis and
>> sent to the miners through a regular 

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 irresponsible for any hardfork, even a very
> simple one.

Good news!

Code to support 2x (the hard fork part of the proposal) has been out and
tested for much longer than that.


Not true. It's different code on top of segwit. The first attempt in btc1
(very recent) didn't even increased the size (because it changed the
meaningless "base size" without touching the weight limit. As for the
current code, I don't think it has been properly tested today, let alone
"for mucj longer than 1 year.
Anyway, I said, one year from tested release. Segwitx2 hasn't been
released, has it? If so, too late to discuss a bip imo, the bip may end up
being different from what has been released due to feedback (unless it is
ignored again, of course).


--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 right, you are falling for a "tu quoque" fallacy.

> More than 80% of the miners and many users are willing to go in the Segwit2x
> direction.

There's no logical reason I can think of (and I've heard many attempts
at explaining it) for miners to consider segwit bad for Bitcoin but
segwitx2 harmless. But I don't see 80% hashrate support for bip141, so
your claim doesn't seem accurate for the segwit part, let alone the
more controversial hardfork part.

I read some people controlling mining pools that control 80% of the
hashrate signed a paper saying they would "support segwit
immediately". Either what I read wasn't true, or the signed paper is
just a proof of the signing pool operators word being something we
cannot trust.

So where does this 80% figure come from? How can we trust the source?

> I want a Bitcoin united. But maybe a split of Bitcoin, each side with its
> own vision, is not so bad.

It would be unfortunate to split the network into 2 coins only because
of lack of patience for deploying non-urgent consensus changes like a
size increase or disagreements about the right time schedule.
I think anything less than 1 year after release of tested code by some
implementation would be irresponsible for any hardfork, even a very
simple one.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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
>
> "lockinontimeout" was just an implementation detail to allow BIP8 the BIP9
> implementation code. With the change to height based, we can dispense with
> it entirely.
>
> So the two changes BIP8 brings is BIP9 modified to use height not time,
> and remove the veto failed state.
>
> Code: https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip8-
> height
> BIP: https://github.com/bitcoin/bips/compare/master...
> shaolinfry:bip8-height
>
>
>  Original Message 
> Subject: [bitcoin-dev] Height based vs block time based thresholds
>
> Some people have criticized BIP9's blocktime based thresholds arguing they
> are confusing (the first retarget after threshold). It is also vulnerable
> to miners fiddling with timestamps in a way that could prevent or delay
> activation - for example by only advancing the block timestamp by 1 second
> you would never meet the threshold (although this would come a the penalty
> of hiking the difficulty dramatically).
>
> On the other hand, the exact date of a height based thresholds is hard to
> predict a long time in advance due to difficulty fluctuations. However,
> there is certainty at a given block height and it's easy to monitor.
>
> If there is sufficient interest, I would be happy to amend BIP8 to be
> height based. I originally omitted height based thresholds in the interests
> of simplicity of review - but now that the proposal has been widely
> reviewed it would be a trivial amendment.
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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, like bip9 always does when an unknown deployment is locked
in.

But there's a simpler way to do that which doesn't require to add
consensus rules as to what versionbits should be.
I'm honestly not worried about it being "coersive" and I don't think
it's inherently reckless (although used with short deployment times
like bip148 it can be IMO). But it adds more complexity to the
consensus rules, with something that could merely be "warning code".

You can just use a special bit in versionbits for nodes to get the warning.
My proposal doesn't guarantee that the warning will be signaled, for
example, if the miner that mines the block right after lock in doesn't
know about the deployment, he can't possibly know that he was supposed
to signal the warning bit, even if he has the best intentions. Miners
can also intentionally not signal it out of pure malice. But that's no
worse than the current form, when deployments activated by final date
instead of miner signaling never get a warning.

Shaolinfry had more concerns with my proposed modification, but I
think I answered all of them here:

https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218

The implementation of the proposal is there too. I'm happy to reopen
and rebase to simplify (#10464 was merged and there's at least 1
commit to squash).

> It also enables deploying softforks as a MASF, and only upgrading them to UASF
on an as-needed basis.

You can also do

consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight = 50;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight = 51;
consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout = false;

and "if needed", simply add the following at any time (before the new
nStartHeight, obviously):


consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit = 0;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight = 51;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight = 515000;
consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout = true;


On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sjöberg via bitcoin-dev
 wrote:
> From the PR change:
>
>> Miners must continue setting the bit in LOCKED_IN phase so uptake is
>> visible and acknowledged. Blocks without the applicable bit set are invalid
>> during this period
>
> Luke, it seems like the amendments to BIP8 make it drastically different to
> how it first was designed to work.
> It now looks more akin to BIP148, which was AFAICT not how BIP8 was
> originally intended to work.
> Perhaps this should be made into its own BIP instead, or make it so it's
> possible to decide how the LOCKED_IN state should work when designing the
> softfork.
>
> Hampus
>
> 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev
> :
>>
>> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
>> to
>> ensure they upgrade in time. Not having a mandatory signal turned out to
>> be a
>> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
>> problem
>> for BIP 149 as-is). Additionally, it makes the activation decisive and
>> unambiguous: once the lock-in period is complete, there remains no
>> question as
>> to what the correct protocol rules are.
>>
>> It also enables deploying softforks as a MASF, and only upgrading them to
>> UASF
>> on an as-needed basis.
>>
>> Luke
>>
>>
>> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
>> > Luke,
>> > I previously explored an extra state to require signalling before
>> > activation in an earlier draft of BIP8, but the overall impression I got
>> > was that gratuitous orphaning was undesirable, so I dropped it. I
>> > understand the motivation behind it (to ensure miners are upgraded), but
>> > it's also rather pointless when miners can just fake signal. A properly
>> > constructed soft fork is generally such that miners have to deliberately
>> > do something invalid - they cannot be tricked into it... and miners can
>> > always chose to do something invalid anyway.
>> >
>> > >  Original Message 
>> > > From: l...@dashjr.org
>> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry
>> > >  I"ve already opened a PR almost 2 weeks ago
>> > > to do this and fix the other issues BIP 9 has.
>> > > https://github.com/bitcoin/bips/pull/550
>> > > It just needs your ACK to merge.
>> > >
>> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
>> > >> Some people have criticized BIP9"s blocktime based thresholds arguing
>> > >> they are confusing 

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, "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Currently the only implementation that fulfills the requirements of the NYA
agreement is the segwit2x/btc1 implementation, which is being finalized
this week.

Segwit2mb does not fulfill the NYA agreement.

I'm asking now the segwit2x development team when a BIP will be ready so
that Core has the opportunity to evaluate the technical proposal.




On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Well, this Saturday's "Chinese roundtable" statement from a bunch of
> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
> coinbase as support for "the New York consensus SegWit2x program btc1 (
> https://github.com/btc1)", whose code includes the (accelerated
> 336-block) BIP 91 change.  So, other facts or interpretations could come to
> light, but until they do we should probably assume that's what the "NYA"
> (which just broke 80% over the last 24h) means.
>
>
> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach 
> wrote:
>
>> 80% have set "NYA" in their coinbase string. We have no idea what that
>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
>> the time of the New York agreement, and differs from the actual text
>> of the NYA in substantive ways. The "Segwit2MB" that existed at the
>> time of the NYA, and which was explicitly referenced by the text is
>> the proposal by Sergio Demian Lerner that was made to this mailing
>> list on 31 March. The text of the NYA grants no authority for
>> upgrading this proposal while remaining compliant with the agreement.
>> This is without even considering the fact that in the days after the
>> NYA there was disagreement among those who signed it as to what it
>> meant.
>>
>> I feel it is a very dangerous and unwarranted assumption people are
>> making that what we are seeing now is either 80% support for BIP-91 or
>> for the code in the btc1 repo.
>>
>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty  wrote:
>> > # Jacob Eliosoff:
>> >
>> >>  will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
>> split.
>> >
>> > Correct.  There are 2 short activation periods in BIP91 either of which
>> > would avoid a split.
>> >
>> > # Gregory Maxwell:
>> >
>> >> unclear to me _exactly_ what it would need to implement to be
>> consistent.
>> >
>> > This is the relevant pull req to core:
>> >
>> > https://github.com/bitcoin/bitcoin/pull/10444
>> >
>> > Seems OK.  It's technically running now on testnet5.   I think it (or a
>> > -bip148 option) should be merged as soon as feasible.
>> >
>> >> previously debunked "XT" and "Classic" hysteria.
>> >
>> > apples vs oranges, imo.   segwit is not a contentious feature.   the
>> > "bundling" in segwit2x is, but that's not the issue here.   the issue
>> is we
>> > are indirectly requiring miners that strongly support segwit to install
>> > consensus protocol changes outside of bitcoin's standard reference.
>>  80% of
>> > them have signaled they will do so.   these are uncharted waters.
>> >
>> >
>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
>> >  wrote:
>> >>
>> >> I could be wrong, but the latest BIP91 implementation (also included in
>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days).  (This
>> has
>> >> been updated at
>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.)  So
>> if 80%
>> >> of hashpower is actually running that code and signaling on bit 4 by
>> July 25
>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before
>> Aug 1,
>> >> and we avoid a split.
>> >>
>> >> There may still be a few non-bit-1 blocks that get orphaned after Aug
>> 1,
>> >> because they're mined by old BIP141 nodes.  But it seems like very few
>> >> miners won't be signaling either Segwit2x *or* BIP141 by then...
>> >>
>> >> Make sense?
>> >>
>> >>
>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <
>> m...@friedenbach.org>
>> >> wrote:
>> >>>
>> >>> Why do you say activation by August 1st is likely? That would require
>> an
>> >>> entire difficulty adjustment period with >=95% bit1 signaling. That
>> seems a
>> >>> tall order to organize in the scant few weeks remaining.
>> >>>
>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
>> >>>  wrote:
>> >>>
>> >>> If segwit is activated before Aug 1, as now seems likely, there will
>> be
>> >>> no split that day.  But if activation is via Segwit2x (also likely),
>> and at
>> >>> least some nodes do & some don't 

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 may have left an overly pessimistic impression -
>>
>> In short: the timing isn't as dire as I suggested, BUT unless concrete
>> progress on a plan starts taking shape, esp miner support, *the split is
>> indeed coming.*
>>
>> THE GOOD NEWS: several refinements have been noted which could get BIP91 (or
>> splitprotection, Segwit2x, etc) deployed faster:
>> - Of course the 80% threshold could just be reduced, eg to splitprotection's
>> 65%
>
> This still doesn't prevent the split if 45% or more of the hashrate
> keeps blocking segwit, so I don't see how this help.
>
>> - BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
>> lock-in, rather than waiting another period until it  "activates".
>
> Miners could start signaling bit 1 today, before they use bip91 too
> and signal bit 4 in addition.
> But they aren't doing it, it seems they prefer to block segwit. I
> don't see why changing using bit 4 or reducing the threshold would
> change their mind.
>
>> THE BAD NEWS: no one should underestimate the steps that would need to be
>> completed by that deadline:
>> 1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148
>> itself, ...)
>> 2. Implement and test it
>> 3. Convince >50% of miners to run it [2]
>> 4. Miners upgrade to the new software and begin signaling
>>
>> In particular, #3: afaict a lot of convincing is still needed before miner
>> support for any of these reaches anything like 50%.  (With the exception of
>> Segwit2x, but it has the additional handicap that it probably needs to
>> include deployable hard fork code, obviously ambitious in 1.5 months.)
>>
>
> Or you can replace this whole plan with the step 3, convincing miners
> to stop blocking segwit, upgrade to segwit capable code if they
> haven't already and signal bit 1 to activate it.
> If you don't get that, there's going to be a split. Unless bip148 is
> aborted in favor of bip149, which seems unlikely.
>
> If we had 51%+ of the hashrate currently signaling segwit, I believe
> there would be no problem convincing people to move from bip148 to
> bip91, but we don't have that.
>
> To me the lesson is not rushed deployments but bip8 and never commit
> the mistake of giving miners the ability to block changes again, like
> we did with csv and segwit, but using bip8 instead of bip9 from now
> on.
>
>> [1] See Saicere's comment:
>> https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and related
>> discussion at
>> https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.
>>
>> [2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodes
>> signaling segwit support do *not* count, since they won't orphan non-bit-1
>> blocks.  The impending split isn't between nodes that support segwit vs
>> don't, but between those that reject non-segwit-supporting blocks vs don't.
>>
>>
>> On Fri, Jun 9, 2017 at 1:23 AM, Jacob Eliosoff 
>> wrote:
>>>
>>> Ah, two corrections:
>>> 1. I meant to include an option c): of course >50% of hashpower running
>>> BIP148 by Aug 1 avoids a split.
>>> 2. More seriously, I misrepresented BIP148's logic: it doesn't require
>>> segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks from
>>> Aug 1.
>>>
>>> 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.
>>>
>>> Sorry about the errors.
>>>
>>>
>>> On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff 
>>> wrote:

 I've been trying to work out the expected interaction between James
 Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
 use variants of BIP91 activation) and the BIP148 UASF [4].  Some of this is
 subtle so CORRECTIONS WELCOME, but my conclusions are:
 1. It's extremely unlikely BIP91-type logic can activate segwit in time
 to avoid a BIP148 chain split.
 2. So, in practice all we can do is ensure the BIP148 split is as
 painless as possible.

 REASONING:  First, some dates.  BIP148, whose deadline is already
 deployed and thus unlikely to be postponed, starts orphaning non-segwit
 blocks on midnight (GMT) the morning of August 1.  Meanwhile, here are
 Bitcoin's rough expected next four difficulty adjustment dates (they could
 vary by ~1-3 days depending on block times, but it's unlikely to matter
 here):
 1. June 17
 2. June 30
 3. July 13
 4. July 27

 If Segwit activates on adj date #5 or later (August), it will be too late
 to avoid BIP148's split, which 

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 suggested, BUT unless concrete
> progress on a plan starts taking shape, esp miner support, *the split is
> indeed coming.*
>
> THE GOOD NEWS: several refinements have been noted which could get BIP91 (or
> splitprotection, Segwit2x, etc) deployed faster:
> - Of course the 80% threshold could just be reduced, eg to splitprotection's
> 65%

This still doesn't prevent the split if 45% or more of the hashrate
keeps blocking segwit, so I don't see how this help.

> - BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
> lock-in, rather than waiting another period until it  "activates".

Miners could start signaling bit 1 today, before they use bip91 too
and signal bit 4 in addition.
But they aren't doing it, it seems they prefer to block segwit. I
don't see why changing using bit 4 or reducing the threshold would
change their mind.

> THE BAD NEWS: no one should underestimate the steps that would need to be
> completed by that deadline:
> 1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148
> itself, ...)
> 2. Implement and test it
> 3. Convince >50% of miners to run it [2]
> 4. Miners upgrade to the new software and begin signaling
>
> In particular, #3: afaict a lot of convincing is still needed before miner
> support for any of these reaches anything like 50%.  (With the exception of
> Segwit2x, but it has the additional handicap that it probably needs to
> include deployable hard fork code, obviously ambitious in 1.5 months.)
>

Or you can replace this whole plan with the step 3, convincing miners
to stop blocking segwit, upgrade to segwit capable code if they
haven't already and signal bit 1 to activate it.
If you don't get that, there's going to be a split. Unless bip148 is
aborted in favor of bip149, which seems unlikely.

If we had 51%+ of the hashrate currently signaling segwit, I believe
there would be no problem convincing people to move from bip148 to
bip91, but we don't have that.

To me the lesson is not rushed deployments but bip8 and never commit
the mistake of giving miners the ability to block changes again, like
we did with csv and segwit, but using bip8 instead of bip9 from now
on.

> [1] See Saicere's comment:
> https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and related
> discussion at
> https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011.
>
> [2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodes
> signaling segwit support do *not* count, since they won't orphan non-bit-1
> blocks.  The impending split isn't between nodes that support segwit vs
> don't, but between those that reject non-segwit-supporting blocks vs don't.
>
>
> On Fri, Jun 9, 2017 at 1:23 AM, Jacob Eliosoff 
> wrote:
>>
>> Ah, two corrections:
>> 1. I meant to include an option c): of course >50% of hashpower running
>> BIP148 by Aug 1 avoids a split.
>> 2. More seriously, I misrepresented BIP148's logic: it doesn't require
>> segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks from
>> Aug 1.
>>
>> 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.
>>
>> Sorry about the errors.
>>
>>
>> On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff 
>> wrote:
>>>
>>> I've been trying to work out the expected interaction between James
>>> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
>>> use variants of BIP91 activation) and the BIP148 UASF [4].  Some of this is
>>> subtle so CORRECTIONS WELCOME, but my conclusions are:
>>> 1. It's extremely unlikely BIP91-type logic can activate segwit in time
>>> to avoid a BIP148 chain split.
>>> 2. So, in practice all we can do is ensure the BIP148 split is as
>>> painless as possible.
>>>
>>> REASONING:  First, some dates.  BIP148, whose deadline is already
>>> deployed and thus unlikely to be postponed, starts orphaning non-segwit
>>> blocks on midnight (GMT) the morning of August 1.  Meanwhile, here are
>>> Bitcoin's rough expected next four difficulty adjustment dates (they could
>>> vary by ~1-3 days depending on block times, but it's unlikely to matter
>>> here):
>>> 1. June 17
>>> 2. June 30
>>> 3. July 13
>>> 4. July 27
>>>
>>> If Segwit activates on adj date #5 or later (August), it will be too late
>>> to avoid BIP148's split, which will have occurred the moment August began.
>>> So, working backwards, and assuming we want compatibility with old BIP141
>>> nodes:
>>>
>>> - Segwit MUST activate by adj #4 (~July 27)
>>> - Therefore segwit MUST be 

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 without
bip91), no split will happen even if segwit is not active yet.
So the hashrate majority could avoid the split that way (or adopting bip148).

But it doesn't seem like they are planning to do this (with or without
bip91), the last thing I've heard, it's they will wait until
"immediately" before they signal sw (but there must be some language
barrier here, perhaps "immediately" and "inmediatamente" are false
friends). The reason why they will wait until "immediately" instead of
just starting to signal sw today, it's still unclear to me.

The other way to prevent the split is if bip148 users abort bip148
deployment, but unfortunately that seems increasingly unlikely.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 BIP141
deployment with bip9.
See 
https://github.com/jtimon/bitcoin/commit/62efd741740f5c75c43d78358d6318941e6d3c04

> If BIP 141 should unexpectly activate, then
> BIP 149 nodes would notice and act as pre-SegWit nodes indefinitely,
> but remain in consensus with BIP 141 nodes.
>
> It might be slightly less convenient for BIP 149 users to upgrade
> again, but then at least we could start deploying BIP 149 sooner.

No, if segwit activates pre nov15, bip149 nodse can detect and
interpret that just fine.
The problem if it activates post nov15, then you need a separate
service bit in the p2p network, for pre-BIP149 will think sw hasn't
activated while post-BIP149 would know it has activated.

If you release it only after nov15, you don't need to test
compatibility between the two for neither of this two cases.
Or do you? Actually you only save testing the easier case of pre-nov15
activation.


> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 sw gets activated pre
nov15, then you want bip149 nodes to use the old service bit for
segwit, not the new one (you would use that one if it activates post
nov15, so that pre-bip149 nodes don't get confused).

I was slowly modifying shaolinfry's code to try to code that, but I'm
currently not working on it because there doesn't seem there's a lot
of interest in releasing bip149 before nov15...

https://github.com/jtimon/bitcoin/commits/b15-shaolinfry-bip149


On Sun, Jun 11, 2017 at 7:48 AM, Ryan Grant via bitcoin-dev
 wrote:
> Is there any reason that BIP149 activation on November 16th would
> cause a problem?
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Why is it 
https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661
not enough at this point?
Why the need for a transaction size limit?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

2017-05-30 Thread Jorge Timón via bitcoin-dev
My understanding is that you cannot possibly violate the 1 MB block
size rule without also violating the 4 MB weight rule.
Regarding size alone, the only check we care about if we accept segwit is:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2891 [size4]

If that doesn't fail due to excessive non-witness data, then there's no way that

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2681 [size1]

would have failed before due to excessive non-witness data.
If I understood it correctly when I was explained, if I remember
correctly, that last check is really just an optimization or a
protection against DoS invalid blocks. If the size without any witness
data is bigger than 1/4 the max_weight, then the max_weight check is
certain to fail as well without having to look at any witness data at
that validation stage (assuming the failure is due to excessive
non-witness data).

I think you are not referring to the 1 mb size limit but to related
one for sigops:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2704
[sigops1]

whose segwit parallel is in:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1661
[sigops4]

I believe the situation is similar in checking before knowing anything
about the witness data just in case that's already too much. In fact,
here is clearer because MAX_BLOCK_SIGOPS_COST is used for both (and
WITNESS_SCALE_FACTOR is used for the optimization case).

So what I would do in a hardfork after segwit activation would be to
simply equal MAX_BLOCK_BASE_SIZE=MAX_BLOCK_WEIGHT/WITNESS_SCALE_FACTOR
for size1, and increase MAX_BLOCK_WEIGHT and MAX_BLOCK_ SIGOPS_COST
proportionally for size4 and sigops4 respectively (well, the sigops
const for sigops1 as well).

If I understood segwit correctly, I believe that even though it is not
activated yet, you could remove both the size1 and sigops1 checks and
your node would still not accept invalid blocks by pre-bip141 rules,
your node would just spend more time on invalid blocks due to
currently excessive size/sigops, because it would only realize at a
later validation stage. Sorry for the redundancy about the validation
stage.

But it is not unlikely that I'm missing something. If I am wrong about
this I am spreading misinformation about segwit in several channels,
so I'm very interested in corrections to my statements in this mail.

On Tue, May 30, 2017 at 11:24 PM, Mark Friedenbach <m...@friedenbach.org> wrote:
> The 1MB classic block size is not redundant after segwit activation.
> Segwit prevents the quadratic hashing problems, but only for segwit
> outputs. The 1MB classic block size prevents quadratic hashing
> problems from being any worse than they are today.
>
> Mark
>
> On Tue, May 30, 2017 at 6:27 AM, Jorge Timón via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Why not simply remove the (redundant after sw activation) 1 mb size
>> limit check and increasing the weight limit without changing the
>> discount or having 2 limits?
>>
>>
>> On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing.
>>>
>>> I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM
>>> growth, of which bandwidth seems the most constraining.
>>>
>>> - Erik
>>>
>>>
>>> On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>> In light of some recent discussions, I wrote up this BIP for a real 2 MB
>>>> block
>>>> size hardfork following Segwit BIP148 activation. This is not part of any
>>>> agreement I am party to, nor anything of that sort. Just something to
>>>> throw
>>>> out there as a possible (and realistic) option.
>>>>
>>>> Note that I cannot recommend this to be adopted, since frankly 1 MB blocks
>>>> really are still too large, and this blunt-style hardfork quite risky even
>>>> with consensus. But if the community wishes to adopt (by unanimous
>>>> consensus)
>>>> a 2 MB block size hardfork, this is probably the best way to do it right
>>>> now.
>>>> The only possible way to improve on this IMO would be to integrate it into
>>>> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size
>>>> HF
>>>> improvements).
>>>>
>>>> I have left Author blank, as I do not intend to personally champion this.
>>>> Before it may be assigned a BIP number, someone else will need to step up
>>>> to
>&

[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 activated that he is
not aware of will see a warning. See the implementation:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1832

But with bip8, if a deployment is made at the end of the period
instead of through 95% signaling, nodes that implement bip8 but don't
implement a certain deployment that is activated can't receive such a
warning.

The solution that comes to mind is to reserve one of the nVersion for
the specific purpose of requiring that the bit is active for one block
when a deployment is locked in in this way (or maybe also when it's
activated with miners' signaling too, maybe that can be used to
simplify the way the current warnings are checked).

I expect the code changes to do this to be simple, and I'm happy to
help with it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 risk, so yes, this is about
>> protecting users of the base Bitcoin Core implementation.
>
> In this case, NOT enforcing BIP148 puts users at more risk. Since devs are
> divided in opinion, we should at the very least have an option to let users
> decide one way or the other.

Well, it's putting users at more risk only if for those users who
actively decided to put themselves at risk.
I also feel bip148 is rushed and that makes it more risky. I don't
want to reiterate points other have made but I don't fully agree with
all of them.
I prefer the way it is over the way it was (just activating at a given
date without forcing mining signaling), but I still think it's rushed
and unnecessarily risky (unless activating segwit was urgent, which I
think it's not, no matter how much I want it to become active as soon
as possible).
On the other hand, I support uasf and bip8 to replace bip9 for future
deployments, since bip9 made assumptions that weren't correct (like
assuming miners would always signal changes that don't harm any user
and are good for some of them).
Perhaps bip149 can be modified to activate earlier if the current
proposal is perceived as unnecessarily cautious.

Luke, I've seen you say in other forums that "bip148 is less risky
than bip149", but I think that's clearly false.

As a reminder, one of my complains about bip109 was precisely that it
was also rushed in how fast it could activate.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 limiting myself to changing the parameters of Segwit as
> it is..
>
> This is motivated by the idea that a consensual HF in the current state
> would have greater chance of acceptance if it changes the minimum number of
> lines of code.
>
>
>
> On Tue, May 9, 2017 at 5:13 PM, Gregory Maxwell  wrote:
>
>> On Tue, May 9, 2017 at 7:42 PM, Matt Corallo 
>> wrote:
>> > at beast.
>>
>> Rawr.
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 a new BIP
> or try to convince the authors of BIP141 to modify their BIP? Could someone
> inform me on the next part of the process?

See bip2, specifically
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-workflow

"Following a discussion, the proposal should be submitted to the BIPs
git repository as a pull request. This draft must be written in BIP
style as described below, and named with an alias such as
"bip-johndoe-infinitebitcoins" until the editor has assigned it a BIP
number (authors MUST NOT self-assign BIP numbers)."

But I think it's kind of late to modify bip141, given that there's
code out there with the current specification.
I guess you can propose extensions or alternatives to replace it. I'm
really not sure what's the next step, but I don't think you have
provided enough motivation as to why we would want to maintain
asicboost. You said it makes the network more secure, but that's not
the case, as explained, not even if all honest miners use it.

> On Tue, Apr 11, 2017 at 8:25 AM, Sancho Panza via bitcoin-dev
>  wrote:
>>
>> Tom Zander wrote:
>>
>> > The version field is still needed to actually allow future block version
>> > upgrades. We would cut off our road forward if that were to be blocked.
>>
>> I tend to agree, if all 32 bits were given up to grinding.
>>
>> But it's worth pointing out that BIP9 is purely informational, and the top
>> 3 bits are still reserved for other purposes. One of them could perhaps be
>> used to signal for an extended version field somewhere else, leaving the
>> bottom 29 as entropy?
>>
>> Not a direction I prefer, but just a technical possibility perhaps.
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 ASICBoost,
you're right, the network would be in an equivalent situation whether
ASICBoost was banned or not.


Only if all honest miners use asicboost, otherwise the situation for an
attack is not equivalent but worse with asicboost.

I want to point out again that overt ASICBoost can be used on the network
today. My proposal is to bring ASICBoost usage out into the open vs hiding
it. Banning ASICBoost via protocol changes is another issue completely.


Doesn't greg's proposal of disabling covert asicboost "bring asicboost
usage into the open vs hiding it" too? It also does it without making any
assumptions on whether we want to completely disable it later (I want)
while your proposal assumes we do not.

Jimmy


> 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
>> implementation. If you ban ASICBoost, someone with this optimization can
>> get 51% of the network by adding N machines with their new optimization. If
>> you allow ASICBoost and assuming this gets a 20% speed boost over
>> non-ASICBoosted hardware, someone with this optimization would need 1.2N
>> machines to get 51%. The network in that sense is 20% stronger against this
>> attack in terms of cost.
>>
>> Jimmy
>>
>> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>>
>>> 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, for the attacker
>>> can use asicboost too.
>>> What about the case when not all the miners are using asicboost? Then
>>> the attacker can actually get an advantage by suing asicboost.
>>>
>>> Sometimes people compare asicboost with the use of asics in general as
>>> both providing more security for the network and users. But I don't
>>> think this is accurate. The existence of sha256d asics makes an attack
>>> with general purpose computing hardware (or even more specialized
>>> architectures like gpgpu) much more expensive and unlikely. As an
>>> alternative the attacker can spend additional resources investing in
>>> asics himself (again, making many attacks more expensive and
>>> unlikely).
>>>
>>> But as far as I know, asicboost can be implemented with software
>>> running on general purpose hardware that integrates with regular
>>> sha256d asics. There is probably an advantage on having the asicboost
>>> implementation "in the same box" as the sha256d, yet again the
>>> attacker can invest in hardware with the competitive advantage from
>>> having asicboost more intergrated with the sha256d asics too.
>>>
>>> To reiterate, whether all miners use asicboost or only a subset of
>>> them, I remain unconvinced that provides any additional security to
>>> the network (to be more precise whether that makes "tx history harder
>>> to rewrite"), even if it results on the hashrate charts looking "more
>>> secure".
>>>
>>>
>>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>>> >
>>> >
>>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>>> >  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 money more vulnerable to 51% attack?
>>> >
>>> >
>>> > Certainly, if only one company made use of the extra nonce space, they
>>> would
>>> > have an advantage. But think of it this way, if some newer ASIC
>>> optimization
>>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>>> with
>>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>>> secure
>>> > the Bitcoin network better against newer optimizations.
>>> >
>>> >
>>> > Why?
>>>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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
> implementation. If you ban ASICBoost, someone with this optimization can
> get 51% of the network by adding N machines with their new optimization. If
> you allow ASICBoost and assuming this gets a 20% speed boost over
> non-ASICBoosted hardware, someone with this optimization would need 1.2N
> machines to get 51%. The network in that sense is 20% stronger against this
> attack in terms of cost.
>
> Jimmy
>
> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>
>> 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, for the attacker
>> can use asicboost too.
>> What about the case when not all the miners are using asicboost? Then
>> the attacker can actually get an advantage by suing asicboost.
>>
>> Sometimes people compare asicboost with the use of asics in general as
>> both providing more security for the network and users. But I don't
>> think this is accurate. The existence of sha256d asics makes an attack
>> with general purpose computing hardware (or even more specialized
>> architectures like gpgpu) much more expensive and unlikely. As an
>> alternative the attacker can spend additional resources investing in
>> asics himself (again, making many attacks more expensive and
>> unlikely).
>>
>> But as far as I know, asicboost can be implemented with software
>> running on general purpose hardware that integrates with regular
>> sha256d asics. There is probably an advantage on having the asicboost
>> implementation "in the same box" as the sha256d, yet again the
>> attacker can invest in hardware with the competitive advantage from
>> having asicboost more intergrated with the sha256d asics too.
>>
>> To reiterate, whether all miners use asicboost or only a subset of
>> them, I remain unconvinced that provides any additional security to
>> the network (to be more precise whether that makes "tx history harder
>> to rewrite"), even if it results on the hashrate charts looking "more
>> secure".
>>
>>
>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>> >
>> >
>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>> >  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 money more vulnerable to 51% attack?
>> >
>> >
>> > Certainly, if only one company made use of the extra nonce space, they
>> would
>> > have an advantage. But think of it this way, if some newer ASIC
>> optimization
>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>> with
>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>> secure
>> > the Bitcoin network better against newer optimizations.
>> >
>> >
>> > Why?
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 subsidy plus the block fees.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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, for the attacker
can use asicboost too.
What about the case when not all the miners are using asicboost? Then
the attacker can actually get an advantage by suing asicboost.

Sometimes people compare asicboost with the use of asics in general as
both providing more security for the network and users. But I don't
think this is accurate. The existence of sha256d asics makes an attack
with general purpose computing hardware (or even more specialized
architectures like gpgpu) much more expensive and unlikely. As an
alternative the attacker can spend additional resources investing in
asics himself (again, making many attacks more expensive and
unlikely).

But as far as I know, asicboost can be implemented with software
running on general purpose hardware that integrates with regular
sha256d asics. There is probably an advantage on having the asicboost
implementation "in the same box" as the sha256d, yet again the
attacker can invest in hardware with the competitive advantage from
having asicboost more intergrated with the sha256d asics too.

To reiterate, whether all miners use asicboost or only a subset of
them, I remain unconvinced that provides any additional security to
the network (to be more precise whether that makes "tx history harder
to rewrite"), even if it results on the hashrate charts looking "more
secure".


On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>
>
> On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>  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 money more vulnerable to 51% attack?
>
>
> Certainly, if only one company made use of the extra nonce space, they would
> have an advantage. But think of it this way, if some newer ASIC optimization
> comes up, would you rather have a non-ASICBoosted hash rate to defend with
> or an ASICBoosted hash rate? Certainly, the latter, being higher will secure
> the Bitcoin network better against newer optimizations.
>
>
> Why?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 money more vulnerable to 51% attack?
>

Certainly, if only one company made use of the extra nonce space, they
would have an advantage. But think of it this way, if some newer ASIC
optimization comes up, would you rather have a non-ASICBoosted hash rate to
defend with or an ASICBoosted hash rate? Certainly, the latter, being
higher will secure the Bitcoin network better against newer optimizations.


Why?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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. That's a very unwanted effect, and
> anything like it should be engineered out on principle.

This is an interesting point.

If you have a precise description why it makes an incentive to make
blocks smaller I would love to read it.
Somebody asked and I didn't have an answer.
I imagine you try several reorderings sometimes excluding certain
branches of the merkle tree, permuting the branches you exclude or
something similar, but I really don't know the algorithm in detail and
I didn't want to say something inaccurate.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 optimisations, Compactblocks.

This is simply a non sequitur. These optimizations benefit users. On
the other hand, asicboost doesn't benefit users in any way, it only
benefits some miners if and only if not all miners use it. It
obviously harms the miners that aren't using it by making them less
profitable (maybe to the point that they lose money).
If all miners use it or if no one of them uses it is equivalent from
the point of view of the user. In fact, the very fact of allowing it
makes the network less secure unless every single honest miner uses
it, for an attacker could use it against the network.

Even if asicboost was good for users in any way (which as explained
isn't), this proposal doesn't disable it, only the covert form that
cannot be proven to be used.

Therefore there's no rational arguments to oppose this proposal unless
you are (or are invested in):

A) A Miner currently using the covert form of asicboost.

B) A Miner planning to use the covert form of asicboost soon.

C) An attacker using or planning to use the covert form of asicboost.

> All of which seek to reduce the efficacy of large miners and selfish mining.

Asicboost doesn't seek this and doesn't help with this in any way.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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, if you missed it, is that there's a mathematical equivalence
> between using two limits (and calculating the ratio) vs using one limit and
> a ratio. The output is fully identical. The only difference is the order of
> operations. Saying there's no blocksize limit with this is pretty
> meaningless, because you're just saying you're using an abstraction that
> doesn't make the limit visible.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 "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.
>> That would make it a hardfork, not a softfork, if done exactly as you say.
> No, because of the way the weight is calculated, it is impossible to
> create a block that old nodes would perceive as bigger than 1 mb
> without also violating the weight limit.
> After segwit activation, nodes supporting segwit don't need to
> validate the 1 mb size limit anymore as long as they validate the
> weight limit.
>
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
>
> Huh, that's odd. It really does still count raw blockchain data blocksize.

It's not odd, it's just counter-intuitive. How can "< 4 mb weight" be
a more restrictive rule than "< 1 mb size"? Well, it is, that's why
segwit's size increase is a softfork.
It is not that hard once you look at the actual weight formula:
segregated_sigs_sise + (other_size * 4) < 4 "mb"

It is impossible to produce to produce a block that violates the 1 mb
size limit but doesn't violate the 4 mb weight limit too.
There can be block that are < 1 mb size but 20 mb in weight, but those
are invalid according to the new 4 mb weight rule.
At the same time, any block that violates the < 1 mb rule for old
nodes will be invalid not only to old nodes but also to any node
validating the new 4mb rule. This is not by chance but a design choice
for any block size increase within segwit to remain a softfork, which
is what can be deployed faster.

One extreme example would be any 1 mb block today. 1 "mb" of a block
today times 4 is 4 mb, so it complies with the new 4 mb weight rule.
The opposite extreme example would be 4 mb of signatures and 0 mb of
"other data", but this example is not really possible in practice
because signatures need some tx to be part of to be part of the block
itself.
The most extreme examples I have seen on testnet are 3.7 mb blocks,
but those don't represent the average usage today (whenever you read
this).

One common misunderstanding is that users who aren't using payment
channels (that includes lightning but also other smart contracts) or
users that aren't using mutlisig can't enjoy the so called "discount":
there's no reasonable argument for rejecting the "discount" on your
own transactions once/if segwit gets activated.

I would prefer to call the absence of "discount" *penalization*.
Signatures are unreasonable penalized pre-segwit, and there's more
things that remain unreasonably penalized with respect to their
influence on the current utxo after segwit. But signatures are by far
the biggest in data space and validation time, and the most important
unreasonable yet unintended penalization pre-segwit.

> It just uses a ratio between how many units each byte is worth for block
> data vs signature data, plus a cap to define the maximum. So the current max
> is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x = 4
> MB. That just means you replaced the two limits with one limit and a ratio.

Exactly, once one maximum limit is defined, no need for two limits.
But the current max is 1 mb size, not 4 mb weight until/unless segwit
is activated.
Some people complain about 4 mb weight not being as much as 4 mb size,
and that is correct, but both are bigger than 1 mb size.

> A hardfork increasing the size would likely have the ratio modified too.

If the single ratio needs to be modified, it can be modified now
before any rule changes are activated, no need to change the consensus
rules more than needed.

> With exactly the same effect as if it was two limits...

If you don't see any disadvantage on having one single limit if/when
segwit gets activated, I don't see the point of maintaining two
limits, but if you're happy to maintain the branch with the redundant
one you may get my ack: I don't see any disadvantage on checking the
same thing twice besides performance,

> Either way, there's still going to be non-segwit nodes for ages.

That's precisely why it's good segwit has been designed to be backward
compatible as a bip9 softfork.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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.
>
>
> That would make it a hardfork, not a softfork, if done exactly as you say.
>
> Segwit only separates out signature data. The 1 MB limit remains, but would
> now only cover the contents of the transaction scripts. With segwit that
> means we have two (2) size limits, not one. This is important to remember.
> Even with segwit + MAST for large complex scripts, there's still going to be
> a very low limit to the total number of possible transactions per block. And
> not all transactions will get the same space savings.

No, because of the way the weight is calculated, it is impossible to
create a block that old nodes would perceive as bigger than 1 mb
without also violating the weight limit.
After segwit activation, nodes supporting segwit don't need to
validate the 1 mb size limit anymore as long as they validate the
weight limit. The weight is also the only notion of cost miners need
to consider when comparing txs by feerate (fee per cost, before segwit
tx_fee/tx_size, post-segwit tx_fee/tx_weight).
This is important to remember, because having 2 separated limits or
costs would make block creation and relay policies much harder to
implement.

Therefore a hardfork after segwit can just increase the weight limit
and completely forget about the pre-segwit 1 mb size limit.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 bit in block.nNersion) as matt comments.

> We're in a deadlock and it seems we can't go forward adding more 
> functionality to segwit without the community approval (which include 
> miners). This is obvious to me.Then we have to go back.

If segwit is controversial the way it is (I still don't understand why
despite having insistently asking to users and miners who claim to
oppose it), adding more consensus rule changes won't make it any less
controversial. If anything, it would be removing consensus rule
changes, not adding them that could make it less controversial.

By no means I want to dissuade you from working on this bip proposal,
but I really don't see how it helps getting out of the deadlock at
all.


On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
 wrote:
> Some people have asked me for the current implementation of this patch to
> review. I remind you that the current patch does not implement the hard-fork
> signaling, as requested by Matt.
>
> The Segwit2Mb patch can be found here:
> https://github.com/SergioDemianLerner/bitcoin/commits/master
>
> For now, the segwit2mb repo has a single test file using the old internal
> blockchain building method (test/block_size_tests.cpp). This must be
> replaced soon with a better external test using the bitcoin/qa/rpc-tests
> tests, which I will begin to work on now after I collect all comments from
> the community.
>
>
> regards
>
>
>
> On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson 
> wrote:
>>
>> > Remember that the "hashpower required to secure bitcoin" is determined
>> > as a percentage of total Bitcoins transacted on-chain in each block
>>
>> Can you explain this statement a little better?  What do you mean by
>> that?  What does the total bitcoins transacted have to do with
>> hashpower required?
>>
>>
>> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
>>  wrote:
>> > Hey Sergio,
>> >
>> > You appear to have ignored the last two years of Bitcoin hardfork
>> > research and understanding, recycling instead BIP 102 from 2015. There
>> > are many proposals which have pushed the state of hard fork research
>> > much further since then, and you may wish to read some of the posts on
>> > this mailing list listed at https://bitcoinhardforkresearch.github.io/
>> > and make further edits based on what you learn. Your goal of "avoid
>> > technical changes" appears to not have any basis outside of perceived
>> > compromise for compromise sake, only making such a hardfork riskier
>> > instead.
>> >
>> > At a minimum, in terms of pure technical changes, you should probably
>> > consider (probably among others):
>> >
>> > a) Utilizing the "hard fork signaling bit" in the nVersion of the block.
>> > b) Either limiting non-SegWit transactions in some way to fix the n**2
>> > sighash and FindAndDelete runtime and memory usage issues or fix them by
>> > utilizing the new sighash type which many wallets and projects have
>> > already implemented for SegWit in the spending of non-SegWit outputs.
>> > c) Your really should have replay protection in any HF. The clever fix
>> > from
>> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to
>> > be spent with SegWit's sighash provides this all in one go.
>> > d) You may wish to consider the possibility of tweaking the witness
>> > discount and possibly discounting other parts of the input - SegWit went
>> > a long ways towards making removal of elements from the UTXO set cheaper
>> > than adding them, but didn't quite get there, you should probably finish
>> > that job. This also provides additional tuneable parameters to allow you
>> > to increase the block size while not having a blowup in the worst-case
>> > block size.
>> > e) Additional commitments at the top of the merkle root - both for
>> > SegWit transactions and as additional space for merged mining and other
>> > commitments which we may wish to add in the future, this should likely
>> > be implemented an "additional header" ala Johnson Lau's Spoonnet
>> > proposal.
>> >
>> > Additionally, I think your parameters here pose very significant risk to
>> > the Bitcoin ecosystem broadly.
>> >
>> > a) Activating a hard fork with less than 18/24 months (and even then...)
>> > from a fully-audited and supported release of full node software to
>> > activation date poses significant risks to many large software projects
>> > and users. I've repeatedly received feedback from various folks that a
>> > year or more is likely required in any hard fork to limit this risk, and
>> > limited pushback on that given the large 

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 find more interesting to talk to the users and see how they think Segwit
harms them, maybe we missed something in segwit that needs to be removed
for segwit to become uncontroversial, or maybe it is just disinformation.

On the other hand, we may want to have our first uncontroversial hardfork
asap, independently of block size. For example, we could do something as
simple as fixing the timewarp attack as bip99 proposes. I cannot think of a
hf that is easier to implement or has less potential for controversy than
that.

On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>

Much as it may be appealing to repeal the block size limit now with a grace
period until a replacement is needed in a repeal and replace strategy, it's
dubious to assume that an idea can be agreed upon later when it can't be
agreed upon now. Trying to put a time limit on it runs into the possibility
that you'll find that whatever reasons there were for not having general
agreement on a new setup before still apply, and running into the
embarrassing situation of winding up sticking with the status quo after
much sturm and drang.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 the full-size proof, each transaction should be assumed
to be at a minimum the stripped-size rather than the fixed 60 bytes."
it seems you are referring to a "full-size block proof" as opposed to
a "full size tx proof", perhaps a better term could be "full-weight
block proof" if what you are referring to is the proof of the weight
instead of only the pre-segwit size.

Perhaps some short definitions for "stripped-size proof", "full tx
size proof", "full-size proof" and maybe also "size component" at the
beginning would be enough.

In "Network protocol", "It should not recheck blocks known to be
valid, " does "known to be valid" include the blocks that the peer
told us where valid (with their hash and 0 in the enumerated varint)?
Those could be invalid too if the peer was lying, no?
Do you mean "It should not recheck blocks known to be invalid,"?

Why do you need to have at least one full tx size?

In Rationale you have:
"
Why must a full tx size proof be included?

This is necessary to establish that the claimed block transaction
count is correct.
"

Why do you need to establish that? If you can establish that the
number of transactions is at least N and that N * 60 bytes is greater
than the size/weight limit, isn't it that enough?


On Wed, Mar 22, 2017 at 10:51 PM, Matt Corallo via bitcoin-dev
 wrote:
> It works today and can be used to prove exact size: the key observation is
> that all you need to show the length and hash of a transaction is the final
> SHA256 midstate and chunk (max 64 bytes). It also uses the observation that
> a valid transaction must be at least 60 bytes long for compression (though
> much of that compression possibility goes away if you're proving something
> other than "too large").
>
>
> On March 22, 2017 1:49:08 PM PDT, Bram Cohen via bitcoin-dev
>  wrote:
>>
>> Some questions:
>>
>> Does this require information to be added to blocks, or can it work today
>> on the existing format?
>>
>> Does this count number of transactions or their total length? The block
>> limit is in bytes rather than number of transactions, but transaction number
>> can be a reasonable proxy if you allow for some false negatives but want a
>> basic sanity check.
>>
>> Does this allow for proofs of length in the positive direction,
>> demonstrating that a block is good, or does it only serve to show that
>> blocks are bad? Ideally we'd like an extension to SPV protocol so light
>> clients require proofs of blocks not being too big, given the credible
>> threat of there being an extremely large-scale attack on the network of that
>> form.
>>
>>
>> On Wed, Mar 22, 2017 at 1:47 AM, Luke Dashjr via bitcoin-dev
>>  wrote:
>>>
>>> Despite the generalised case of fraud proofs being likely impossible,
>>> there
>>> have recently been regular active proposals of miners attacking with
>>> simply
>>> oversized blocks in an attempt to force a hardfork. This specific attack
>>> can
>>> be proven, and reliably so, since the proof cannot be broken without also
>>> breaking their attempted hardfork at the same time.
>>>
>>> While ideally all users ought to use their own full node for validation
>>> (even
>>> when using a light client for their wallet), many bitcoin holders still
>>> do
>>> not. As such, they are likely to need protection from these attacks, to
>>> ensure
>>> they remain on the Bitcoin blockchain.
>>>
>>> I've written up a draft BIP for fraud proofs and how light clients can
>>> detect
>>> blockchains that are simply invalid due to excess size and/or weight:
>>>
>>> https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki
>>>
>>> I believe this draft is probably ready for implementation already, but if
>>> anyone has any idea on how it might first be improved, please feel free
>>> to
>>> make suggestions.
>>>
>>> Luke
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 improvements, new much larger block sizes,
whatever you want.   Even OK to migrate to a new system by not allowing
old->old or new->old transactions.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 by Satoshi
> 
> on the famous August 15, 2010 "misc" commit, at the same time that OP_CAT
> was disabled.
> The previous limit was 5000 bytes.
>
> On Tue, Jan 3, 2017 at 7:13 PM, Jeremy via bitcoin-dev  linuxfoundation.org> wrote:
>
>> Sure, was just upper bounding it anyways. Even less of a problem!
>>
>>
>> RE: OP_CAT, not as OP_CAT was specified, which is why it was disabled. As
>> far as I know, the elements alpha proposal to reenable a limited op_cat to
>> 520 bytes is somewhat controversial...
>>
>>
>>
>> --
>> @JeremyRubin 
>> 
>>
>> On Mon, Jan 2, 2017 at 10:39 PM, Johnson Lau  wrote:
>>
>>> No, there could only have not more than 201 opcodes in a script. So you
>>> may have 198 OP_2DUP at most, i.e. 198 * 520 * 2 = 206kB
>>>
>>> For OP_CAT, just check if the returned item is within the 520 bytes
>>> limit.
>>>
>>> On 3 Jan 2017, at 11:27, Jeremy via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> It is an unfortunate script, but can't actually
>>> ​do
>>>  that much
>>> ​ it seems​
>>> . The MAX_SCRIPT_ELEMENT_SIZE = 520 Bytes.
>>> ​ Thus, it would seem the worst you could do with this would be to 
>>> (1-520*2)*520*2
>>> bytes  ~=~ 10 MB.
>>>
>>> ​Much more concerning would be the op_dup/op_cat style bug, which under
>>> a similar script ​would certainly cause out of memory errors :)
>>>
>>>
>>>
>>> --
>>> @JeremyRubin 
>>> 
>>>
>>> On Mon, Jan 2, 2017 at 4:39 PM, Steve Davis via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 Hi all,

 Suppose someone were to use the following pk_script:

 [op_2dup, op_2dup, op_2dup, op_2dup, op_2dup, ...(to limit)...,
 op_2dup, op_hash160, , op_equalverify, op_checksig]

 This still seems to be valid AFAICS, and may be a potential attack
 vector?

 Thanks.


 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 missing something. I guess you can download the whole
block you're interested in instead of only your txs and that gives you
privacy.
But how do you get to know which blocks are you interested in?

If the questions are too basic or offtopic for the thread, I'm happy
getting answers privately  (but then maybe I get them more than once).


On 4 Jan 2017 09:57, "Aaron Voisine via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

It's easy enough to mark a transaction as "pending". People with bank
accounts are familiar with the concept.

Although the risk of accepting gossip information from multiple random
peers, in the case where the sender does not control the receivers network
is still minimal. Random node operators have no incentive to send fake
transactions, and would need to control all the nodes a client connects to,
and find a non-false-positive address belonging to the victims wallet.

It's not impossible, but it's non trivial, would only temporarily show a
pending transaction, and provide no benefit to the node operator. There are
much juicier targets for an attacker with the ability to sybil attack the
entire bitcoin p2p network.

Aaron

On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli  wrote:

> Hi
>
>
>
> > Unconfirmed transactions are incredibly important for real world use.
>
> > Merchants for instance are willing to accept credit card payments of
>
> > thousands of dollars and ship the goods despite the fact that the
>
> > transaction can be reversed up to 60 days later. There is a very large
>
> > cost to losing the ability to have instant transactions in many or
>
> > even most situations. This cost is typically well above the fraud risk.
>
> >
>
> > It's important to recognize that bitcoin serves a wide variety of use
>
> > cases with different profiles for time sensitivity and fraud risk.
>
> >
>
> I agree that unconfirmed transactions are incredibly important, but not
>
> over SPV against random peers.
>
>
>
> If you offer users/merchants a feature (SPV 0-conf against random
>
> peers), that is fundamentally insecure, it will – sooner or later – lead
>
> to some large scale fiasco, hurting Bitcoins reputation and trust from
>
> merchants.
>
>
>
> Merchants using and trusting 0-conf SPV transactions (retrieved from
>
> random peers) is something we should **really eliminate** through
>
> education and by offering different solution.
>
>
>
> There are plenty, more sane options. If you can't run your own full-node
>
> as a merchant (trivial), maybe co-use a wallet-service with centralized
>
> verification (maybe use two of them), I guess Copay would be one of
>
> those wallets (as an example). Use them in watch-only mode.
>
>
>
> For end-users SPV software, I think it would be recommended to...
>
> ... disable unconfirmed transactions during SPV against random peers
>
> ... enable unconfirmed transactions when using SPV against a trusted
>
> peer with preshared keys after BIP150
>
> ... if unconfirmed transactions are disabled, show how it can be enabled
>
> (how to run a full-node [in a box, etc.])
>
> ... educate, inform users that a transaction with no confirmation can be
>
> "stopped" or "redirected" any time, also inform about the risks during
>
> low-conf phase (1-5).
>
>
>
> I though see the point that it's nice to make use of the "incoming
>
> funds..." feature in SPV wallets. But – for the sake of stability and
>
> (risk-)scaling – we may want to recommend to scarify this feature and –
>
> in the same turn – to use privacy-preserving BFD's.
>
>
>
> 
>
>
>
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 to predict behaviors on older versions
> of the client.

Hard to predict or not, you can't force people to run newer software.

> In order to avoid such wide fragmentation of "Bitcoin Core” node versions
> and to help there be a more predictable protocol improvement process, I
> consider it worth it to analyze introducing some planned obsolescence in
> each new version. In the last year we had 4 new versions so if each version
> is valid for about 1 year (52560 blocks) this may be a reasonable time frame
> for node operators to upgrade. If a node does not upgrade it will stop
> working instead of participating in the network with an outdated protocol
> version.

When you introduce anti-features like this in free software they can
be trivially removed and they likely will.

> These changes may also simplify the developer's jobs in some cases by
> avoiding them having to deal with ancient versions of the client.

There's a simpler solution for this which is what is being done now:
stop maintaining and giving support for older versions.
There's limited resources and developers are rarely interested in
fixing bugs for very old versions. Users shouldn't expect things to be
backported to old versions (if developers do it and there's enough
testing, there's no reason not to do more releases of old versions, it
is just rarely the case).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 (as you say, because it
>> is forbidden since bip34 was deployed).
>
> The difference is that right now, full nodes will happily follow a shorter
> best-valid chain. This BIP would require them to hold back at the best-common
> block between the best-valid chain and the invalid chain, forcing the user to
> make a decision whether to reject the invalid chain permanently, or upgrade to
> a version which can understand that chain as valid.

Ok, so the goal of the softfork then is to hold on is there is to
"hold on" on the most-work valid chain while there's an even-more-work
invalid chain and for new nodes force a response from the user. This
could be clearer in the motivation section.

We can still notify and force a response from the user with a single
invalid block (or N, or W accumulated work). Note that we don't need
to "hold on" while waiting for the user's response. Therefore I insist
there could be a PIB with all the recommended warnings but not
softfork (which this one could extend from).

Thinking as a full node user, I'm not sure I want my node to "hold on"
on validating new valid blocks just because there's some "longest"
invalid chain out there and I may chose to follow that instead later.
Before paying or copying another address to receive, I would
definitely would want the warning though.

Particularly as a miner (not that I'm one), I think validationless
mining shows us that some miners prefer to throw energy to the abyss
of validation uncertainty rather than stop their mining hardware.
What if when I give the response to the system I decide to pass on the
HF but it means my hardware have been not mining in the valid chain
for hours?
I would account that as "money lost thanks to a 'friendly' interface".
Specially if we're talking about a controversial hardfork.

If we're talking about an uncontroversial hardfork, I would definitely
prefer BIP9 coordination.
I would prefer to receive the warning when, say, 30% of the hashrate
is supporting an unknown change to the consensus rules (regardless of
it being a softfork or a hardfork, which I don't know yet until the hf
bit is used because the change is unknown to me), way before I need to
decide what branch to mine.

In fact, if I was a miner but not a user at the same time, after
knowing about the unknown hardfork and if I consider the hardfork to
be potentially controversial, I would try to coordinate with exchanges
(and pools if no solo mining) to be able to write a program that
chooses the chain likely to be most profitable depending on difficulty
and price feeds for every block.

In the case of a SHF, even more reason to keep mining on the old
chain, perhaps I mine one empty block (assuming that's a rule in the
SHF) out of luck, or maybe I should just start mining empty blocks
whenever I see the SHF bit active for a block whose chain keeps
growing.
Perhaps for a SHF we should use a valid bit instead of an invalid one
(clearing all possible fears with old and older nodes perceiving SHFs
differently as HFs and SFs respectively). We can trivially make old an
older nodes coincide in their perception of good-willing SHFs as
either HFs or SFs as we wish. Choosing divergence of perception from
the 2 versions we're considering makes no sense to me.
I'm reserving my judgement for which one I prefer just in case there's
actually an advantage in this divergence, but I've missed it.

>> It seems the softfork serves only to warn about soft-hardforks, assuming it
>> chooses to use this mechanism (which a malicious soft hardfork may not do).
>
> Note: a malicious "SHF" is not a SHF at all, but an "evil fork".

Terminology, I think you get my point. I'm all for formalizing
definitions but please let's not slow down discussion unnecessarily.
I'm fine saying "evil fork" instead of "malicious SHF" if you prefer
that, but they're just the same thing.

>> In fact, you could reuse another of the prohibited bits to signal a soft-
>> hardfork while distinguishing it from a regular hardfork. And this will also
>> serve for old nodes that have not upgraded to the softfork. But, wait,
>> if you signal a soft-hardfork with an invalid bit, it's not a
>> soft-hardfork anymore, is it? It's simply a hardfork.
>
> Nodes implementing this BIP will see it as a simple hardfork, but will
> intentionally provide equivalent behaviour as older nodes which see it as a
> soft-hardfork. In other words, all [compatible] hardforks will now behave like
> a soft-hardfork without any special DMMS design.

Right, and those same mec

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 malicious soft hardfork may not do). In fact, you
could reuse another of the prohibited bits to signal a soft-hardfork
while distinguishing it from a regular hardfork. And this will also
serve for old nodes that have not upgraded to the softfork. But, wait,
if you signal a soft-hardfork with an invalid bit, it's not a
soft-hardfork anymore, is it? It's simply a hardfork.
Your softfork would result in soft hardforks being hardforks for nodes
that upgraded to this softfork, but softforks for older nodes.
Is this the intended behaviour? if so, why?

I would rather have a simpler BIP that doesn't require a softfork
(whether it recommends soft-hardforks to use one of the currently
invalid bits, but a different one than from hardforks or not, but I
also don't see the reason why soft-hardforks should appear as invalid
blocks for older nodes instead of using regular softfork warning
[besides, in this case, after the "unkown softfork" warning you will
get only empty blocks, which may make you suspicious]).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 to
remove them completely from Bitcoin Core in particular.

> Are hard forks okay now?

I personally think uncontroversial hardforks are ok.

> What is the maximum depth of a reorg allowed by this non-machine consensus?

Good question, specially if we plan to do this with future buried
deployments. What about 1 year reorg?

> Shouldn't we just define a max depth so that all cruft deeper than that can
> just be discarded on a regular basis?

Not sure I understand this question.

> Why are there activation heights defined by this hard fork if it's not
> possible to reorg back to them?

If this is a hardfork, it is one that will only be visible if/when
there's a very deep reorg , one of the kind where we can practically
consider Bitcoin done (and only if some nodes keep the ISM code).
But I could accept that definition. Another way to see it (even though
other said the optimization part was not important) as such an
optimization and simplification.
The way I see it, ISM and BIP9 are just coordination mechanisms for
uncontroversial rule changes.
Once the coordination happened and is long in the past, I really don't
see the problem with replacing the mechanism with a simpler height.

> The "BIP" is neither a Proposal (it's been decided, just documenting for
> posterity), nor an Improvement (there is no actual benefit, just some
> tidying up in the notoriously obtuse satoshi code base), nor Bitcoin (a hard
> fork defines an alt coin, so from Aug 4 forward it has been CoreCoin).

Mhmm, I disagree on the notion that any hardfork necessarily
represents an altcoin.
It is certainly an improvement in the sense that it simplifies
implementations and optimizes validation. You may argue that you don't
consider the improvement important though.
These changes to Bitcoin Core could be rolled back (and obviously
other implementations don't need to adopt them unless they want to
benefit from the simplification/optimization or fear such a long
reaorg), but I really hope we don't.

Trying to understand you better...
Accepting your definition of this as a hardfork, do you oppose to it
simply because it is a hardfork, or because you consider this
"hardfork" a bad idea for some reason I am missing?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 is asking for this.
Nobody should produce segwit transactions until the softfork is
activated, after which those transactions aren't anyone-can-spend
anymore.
After activation, nobody can be forced to use the new format
immediately (or ever) if they don't want to reduce their tx fees.
Maybe because they want to be additionally cautious or maybe because
they haven't implemented the new features yet.
Either way, it is fine that some people upgrade later since, as
repeated by many, this is a backward compatible change.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 works. We could at most change BIP9's initial date, but if those
who haven't started to work on supporting segwit will keep waiting for
activation, then changing the initial date won't be of any help to
them can only delay those who are ready and waiting.

The new features are not a requirement after activation. And although
it may take some time after activation for the new features to really
get to the users, that's just a fact of life that won't change by
changing the initial BIP9 date.


On Sun, Oct 16, 2016 at 8:20 PM, Tom Zander via bitcoin-dev
 wrote:
> On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
> wrote:
>> Would I want anyone to lose money due to faulty wallets? Of course not.
>> By the same token, devs have had almost a year to tinker with SegWit and
>> make sure the wallet isn't so poorly written that it'll flame out when
>> SegWit comes along. It's not like this is some untested, mostly unknown
>> feature that's being slipped out at the last minute
>
> There have been objections to the way that SegWit has been implemented for a
> long time, some wallets are taking a "wait and see" approach.  If you look
> at the page you linked[1], that is a very very sad state of affairs. The
> vast majority is not ready.  Would be interesting to get a more up-to-date
> view.
> Wallets probably won't want to invest resources adding support for a feature
> that will never be activated. The fact that we have a much safer alternative
> in the form of Flexible Transactions may mean it will not get activated. We
> won't know until its actually locked in.
> Wallets may not act until its actually locked in either. And I think we
> should respect that.
>
> Even if all wallets support it (and thats a big if), they need to be rolled
> out and people need to actually download those updates.
> This takes time, 2 months after the lock-in of SegWit would be the minimum
> safe time for people to actually upgrade.
>
> 1) https://bitcoincore.org/en/segwit_adoption/
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[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 previously starting the document
with pictures but since things we're changing and the pictures were
already deprecated, I decided to wait after segwit was merged and
include those changes in the pictures too.
This time I created a repository so that people can look at it, even
if it's less advanced than previous versions have been:

https://github.com/jtimon/consensus-doc

Here's a branch with the resulting images, latex file and pdf:

https://github.com/jtimon/consensus-doc/tree/generated

And here's the pdf:

https://github.com/jtimon/consensus-doc/blob/generated/libconsensus.pdf

Any questions or comments are welcomed. If some of the images are
wanted for some other more general documentation or you want me to
create a specific diagram to document Bitcoin Core I'm happy to do so
as well.

Note that some phases can be done in different order or in parallel
(ie phase 3 and phase 4 could happen before phase 2, although I
strongly doubt it because phase 2 is the simplest to review and I've
been harassing different people to do it for a while with little
success [thanks to those who reviewed it and gave feedback] ).

An implementation of phase 2 (expose verifyHeader()) can be seen in
https://github.com/bitcoin/bitcoin/pull/8493
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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
public seed is transfered).

Something different would be to give a different bip32 public seed to each
payer.  That way they can simply start with zero an increment with each new
payment. With those assumptions, the receiver could start listening to new
addresses only after they receive something in the previous address.

Probably not useful for this case, just thinking out loud about using bip32
public seeds instead of one use addresses when there's going to be several
payments from the same payer to the payee.

On Aug 12, 2016 2:37 PM, "Erik Aronesty via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm imagining a "publishable seed" such that:
>
>  - someone can derive a random bitcoin address from it -  and send funds
to it.
>  - the possible derived address space is large enough that generating all
possible addresses would be a barrier
>  - the receiver, however, knowing the private key, can easily scan the
blockchain fairly efficiently and determine which addresses he has the keys
to
>  - another interested party cannot easily do so
>
> Perhaps homomorphic encryption may need to be involved?
>
>
> On Thu, Aug 11, 2016 at 8:36 PM, Gregory Maxwell  wrote:
>>
>> On Thu, Aug 11, 2016 at 8:37 PM, Erik Aronesty via bitcoin-dev
>>  wrote:
>> > Still not sure how you can take a BIP32 public seed and figure out if
an
>> > address was derived from it though.   I mean, wouldn't I have to
compute all
>> > 2^31 possible public child addresses?
>>
>> Which would take a quad core laptop about 8 hours with competent software
>>
>> And presumably you're not using the whole 2^31 space else the receiver
>> also has to do that computation...
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 O (1) ?

Anyway, thanks, I'll read this in more detail.

> > Wouldn't it be better to have both an append-only TXO and an append-only
> > STXO (with all spent outputs, not only the latest ones like in your
"STXO")?
>
> Nope. The reason why this doesn't work is apparent when you ask how will
the
> STXO be indexed?

Just the same way the TXO is (you just stop updating the txo leafs from
unspent to spent.

> If it's indexed by outpoint - that is H(txid:n) - to update the STXO you
need
> he entire thing, as the position of any new STXO that you need to add to
the
> STXO tree is random.
>
> OTOH, if you index the STXO by txout creation order, with the first txout
ever
> created having position #0, the second #1, etc. the data you may need to
update
> the STXO later has predictable locality... but now you have something
that's
> basically identical to my proposed insertion-ordered TXO commitment
anyway.

Yeah, that's what I want. Like your append only TXO but for STXO (that way
we avoid ever updating leafs in the TXO, and I suspect there are other
advantages for fraud proofs).

> Incidentally, it's interesting how if a merbinner tree is insertion-order
> indexed you end up with a datastructure that's almost identical to a MMR.

No complain with MMR. My point is having 2 of them separated: one for the
TXO (entries unmutable) and one for the STXO (again, entries unmutable).

Maybe it doesn't make sense, but I would like to understand why.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 cheaply appended to the tree with minimal storage
requirements,
> just log2(n) "mountain tips". Once an output is added to the TXO MMR it is
> never removed; if an output is spent its status is updated in place. Both
the
> state of a specific item in the MMR, as well the validity of changes to
items
> in the MMR, can be proven with log2(n) sized proofs consisting of a
merkle path
> to the tip of the tree.

How expensive it is to update a leaf from this tree from unspent to spent?

Wouldn't it be better to have both an append-only TXO and an append-only
STXO (with all spent outputs, not only the latest ones like in your "STXO")?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 will survive. I was
only comparing the situation to a contentious hardfork that does not fork
out any hardware. If the latter one is suspected to lead to the permanent
existence of two chains then a hardfork that forks out hardware is even
more likely to do so (I claim it's guaranteed).

You are wrong. Whether 2 chains survive in parallel or not depends SOLELY
in whether both chains maintain demand (aka users).
Anyway, this is a discussion I had with Gavin and Rusty on bitcoin-discuss
already. I suggest we move this particular point there since it is more
philosophical than technical.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 guarantee the persistence of
two chains.

If all users abandon the old rules, why would asicboost miners continue to
spend energy on a chain that everybody else is ignoring?

> To be more precise, if you change the block validation ruleset R to block
validation ruleset S you have to make sure that every hardware that was
capable of mining R-valid blocks is also capable of mining S-valid blocks.

Why?
No, this proposal, for example, may make patented asicboost hardware
obsolete.
I don't accept this claim as true, this is just your opinion.

>
> The only way out is to go the exact opposite way and to embrace as many
optimizations as possible to the point where there are no more
optimizations left to do, or hopefully getting very close to that point.

What do you mean by "embrace" in the context of a patented optimization
that one miner can prevent the rest from using?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 if it's for the lulz.

I still fail to see the harm caused by this attack. At some point the
attacker will get bored of laughing even if the attack has a small costs
(which I'm not that sure it is).

> To reasonably expect that any hark fork - including an uncontroversial
one - will be adapted by every single person in a ecosystem of millions of
people, is wishful thinking and the BIP may as well say "hard fork BIPs
shall never reach final status."

This is what seem to have happened with uncontroversial softforks in the
past. Why is wishful thinking to expect the same for uncontroversial
hardforks?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 instance of one buyer and one
> seller using the blockchain to buy and sell from each other, or set one
up.

And all the attacker will achieve is preventing a field on a text file on
github from moving from "active" to "final".
Seems pretty stupid. Why would an attacker care so much about this? Is
there any way the attacker can make gains or harm bitcoin with this attack?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 Bitcoin holders who wish to
> spend or would spend their bitcoins (including selling for other
> currencies) differently in the event of such a hard-fork.
> What if one shop owner, for example, out of thousands, doesn't adapt the
> hard-fork? It is expected, and should perhaps be encouraged, for a small
> minority to not accept a hard fork, but by the wording of the BIP
> ("entire Bitcoin economy"), one shop owner can veto a hard-fork.

No, the hardfork can still happen, but if a small group remains using the
old chain (a single person will likely abandon it very soon), then it
cannot be said that deployment was universal and thus the hardfork BIP
doesn't move to the final state. As long as there's users using the old
chain, a hardfork BIP shouldn't become final if I understood BIP2
correctly.

In other words,  uncontroversial hardfork bips can make it to the final
state once deployed, controversial hardforks may never become universally
deployed.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 hardfork for this. Rather it should
> be implemented as a safety-mechanism in the client. Perhaps a warning
> can pop up, if one of your conditions A) or B) is met.
>
> All the best
> Henning Kopp
>
>
> On Thu, Mar 03, 2016 at 05:02:11AM -0800, Alice Wonder via bitcoin-dev
> wrote:
> > I think the next hard fork should require a safety rule for TX fees.
> >
> >
> https://blockchain.info/tx/6fe69404e6c12b25b60fcd56cc6dc9fb169b24608943def6dbe1eb0a9388ed08
> >
> > 15 BTC TX fee for < 7 BTC of outputs.
> >
> > Probably either a typo or client bug.
> >
> > My guess is the user was using a client that does not adjust TX fee, and
> > needed to manually set it in order to get the TX in the block sooner, and
> > meant 15 mBTC or something.
> >
> > I suggest that either :
> >
> > A) TX fee may not be larger than sum of outputs
> > B) TX fee per byte may not be larger than 4X largest fee per byte in
> > previous block
> >
> > Either of those would have prevented this TX from going into a block.
> >
> > Many people I know are scared of bitcoin, that they will make a TX and
> make
> > a mistake they can't undo.
> >
> > Adding protections may help give confidence and there is precedence to
> doing
> > things to prevent typo blunders - a public address has a four byte
> checksum
> > to reduce the odds of a typo.
> >
> > This kind of mistake is rare, so a fix could be included in the coming HF
> > for the possible July 2017 block increase.
> >
> > Thank you for your time.
> >
> > Alice Wonder
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 un-maintained full
nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for
three reasons:

None of the reasons you list say anything about the fact that "being lost"
(kicked out of the network) is a problem for those node's users.

> I strongly disagree with the statement that there is no cost to a longer
grace period.

I didn't say that.

> To bring it back to bitcoin-dev territory:  are there any TECHNICAL
arguments why an upgrade would take a business or individual longer than 28
days?

Their own software stack may require more work to integrate the new rules
or their resources may not be immediately available to focus on this within
28 days they hadn't planned.

I believe it wold be less controversial to chose something that nobody can
deny is more than plenty of time for everyone  to implement the changes
like, say, 1 year. I wouldn't personally oppose to something shorter like 6
months for really simple changes, but I don't see how 28 can ever be
considered uncontroversial and safe for everyone. Just trying to help in
removing controversy from the PR, but if you still think 28 can be safe and
uncontroversial, feel free to ignore these comments on the concrete length
and please let me know what you think about the other points I raised.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 I'm happy to change it
to something else if that helps us moving away from consistently using
the same term for two related but very different concepts.
"nearly universal acceptance", "ecosystem-harmonious"...seriously,
almost anything would be better than keep overloading "consensus"...
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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; if
> it happens in the middle, the lower-power fork's difficulty will adjust a
> little quicker.

The reason why BIP9 (versionbits) only checks for new activations
during difficulty retargettings is a simple optimization to only check
1/2016 of the blocks.
I suspect the check itself is not that costly for Bitcoin Core, which
has all the block headers in memory anyway, but I don't think we
should assume that will be the case for all implementations.


As an aside, BIP99 never recommends a 75% mining signaling activation
threshold: it recommends 95% for uncontroversial rule changes and no
miner signaling at all for controversial hardforks.
I still have to update BIP99 with some later changes I commented at
Scaling Bitcoin HK like signaling hardfork activation with the
"negative int32_t bit" so that old clients are forced to
upgrade/decide. We could start deploying better ways to inform users
about a hardfork event, but of course those changes cannot be applied
to older software that is already deployed (but hopefully they will
still notice something is weird is happening if the longest chain that
keeps growing is invalid because it contained a block with a negative
version in it).
But I'm yet to see a single hardfork proposal that follows BIP99's
recommendations besides the hardfork proposed in BIP99 itself, which
should consist on a manageable list of very simple to deploy fixes
like the timewarp fix forward-ported from Freicoin 0.8 for the BIP. I
haven't seen much interest in growing that little list of "a few fixes
nobody disagrees are bugs or sub-optimal design decisions, plus the
changes are easy to implement both separately and as a whole" either.
I cannot say I have seen any opposition at all to BIP99 as a hardfork
either, but I naively expected people would ask me to implement more
things for BIP99 besides
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
or even contribute the patches themselves. For all that, I don't
consider BIP99 a priority to work on and I plan to complete it at some
point later, unless there's a time limit for a BIP to be in the
"draft" state or something.
If someone else considers completing BIP99 a priority, I'm happy to
review and integrate things, though. Thanks again to all the reviewers
and contributors to the BIP at this time and I'm sorry that it has
been stuck for some time. Maybe the classification/recommendations
should have been a BIP without code and the hardfork proposal itself
should have been another one and that would have been clearer. I just
wanted to have some code on my first BIP (and as said the plan is
still to put more code at some point).

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 interface will exist but you will recommend against its use?

The interface will exist but it will be a C++ interface that fits
better with Bitcoin Core internals.
See an initial draft of what could be the storage interface:
https://github.com/jtimon/bitcoin/blob/1717db89c6db17ea65ddbd5eb19034315db0b059/src/consensus/storage_interfaces_cpp.h

Phase 3 will consist on discussing and refining that interface to also
define the C interfaces using structs of function pointers instead of
classes (see 
https://github.com/jtimon/bitcoin/blob/2bcc07c014e5dd30e666be047dfa11f54c10/src/consensus/interfaces.h
for an early draft) that is needed for the "final" C API.
But since I think there will be more discussion and work defining
those interfaces, I would rather start with ANY interface that allows
us to decouple the consensus code from chain.o and coins.o, which we
don't want to be built as part of the consensus building package
(which is used for building both libbitcoinconsensus and Bitcoin
Core).
Future potential users are more than welcomed to draft their own C
APIs and that experience should be useful for phase 3.
I was expecting you, for example, to include the whole consensus code
(even if it lacks a C API) in
https://github.com/libbitcoin/libbitcoin-consensus for better testing
of the equivalent code in libbitcoin. You are kind of taking the C API
part out already, so this time you will just have less things to
delete/ignore.

> This work presumes that the users of the library reject the argument
> that the database implementation is consensus critical code. Faithful
> reproduction of stored data is a prerequisite for a validity. But a
> common store implementation is only slightly more reasonable for this
> library than a common RAM implementation.

This is a concern that has been risen repeatedly.
I am aware that faithful reproduction of the stored data is a
prerequisite for consensus validity. On the other hand, my presumption
is that a libbitcoinconsensus that forces its users to a given unifrom
storage will likely had much less users and any alternative
implementation that wants to implement its own custom storage would
have to necessarily reimplement the consensus validation code.
Doing it this way is more flexible. We can relatively easily implement
another library (if I remember correctly, last time we talked about it
we reffered to it as "libconsensus plus", but there's probably better
names) also takes care of storage for the users that don't want to
take the risks of reimplementing the storage (probably just using
Bitcoin Core's structures).

Unlike me, Luke Dashjr, for example, advocated for the
storage-dependent version, but I believe that implementing both
versions was an acceptable solution to him.
It is certainly an acceptable solution for me. I don't want to force
anyone that doesn't want or need to take the risks reimplementing the
consensus storage part to do so. But at the same time I really believe
that it would be a mistake to not allow it optionally.

Does that make sense?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[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 helped realize that the whole
explanation could be much simpler if #7091 was merged first as the
last step in phase 1 (that phase has so many contributors that I will
probably never get finished documenting it). Matt Corallo's idea of
exposing VerifyScript() through a C API certainly helped a lot in
cementing the more-minimal-than-earlier dependencies (thanks to Cory
Fields among many other people before him) that are not part of the
incomplete but existing libbitcoinconsensus library.

Given this success in protecting encapsulation by exposing things in a
new library, my instinct was to expose more things: VerifyHeader(),
VerifyTx() and VerifyBlock() [in that order].
But all those three new functions depend on storage in one way or
another. That was part of my reasoning to expose VerifyHeader() first,
because I believe there will be less discussion on a common interface
for the stored longest chain than for the utxo view (which may depend
on other transactions spent within the same block).
In any case, I realized we should finish putting all the consensus
critical code in the libconsensus lib and then worry about its "final"
API.

Therefore I changed the goal of the phase 2 in my libconsensus
encapsulation planning from "expose VerifyHeader() in the existing
libconsensus library" to "build all the consensus critical code within
the existing libconsensus library, even if we don't expose anything
else". I believe this is much feasible for a single Bitcoin Core
release cycle and also more of a priority. Other implementations
experimenting with libconsensus like
https://github.com/libbitcoin/libbitcoin-consensus will have the
chance to compare their reimplementations with the future complete
libbitcoinconsensus without having to worry about the C API, which
ideally they will help to define.

I repeat, the goal of phase 2 in my upcoming libconsensus
encapsulation plan is to fully decouple libconsensus from Bitcoin
Core.
In phase 3, we can refine the storage interfaces and focus on a
quasi-final C API.
In phase 4, we can refine and take out code that doesn't belong in
libconsensus like CTxOut::GetDustThreshold() in
primitives/transaction.h and move all those consensus files to the
consensus folder before creating a separate sub-repository like for
libsecp256k1. Note that most of the file-moving work can be in
parallel to phases 2 and 3 and, in fact, by any new developer that is
willing to exchange rebase-patience for meaningless github stats (I'll
do it if nobody else wants, but I'm more than happy to delegate there:
I have more than enough github meaningless stats already).

As said, the document with pictures and the update to #6714 are still
promised, but until they're ready, merging/reviewing #7091, #7287,
#7310 and #7311 could do a great deal to make later steps in
libconsensus phase 2 more readable.
Most reviewers probably don't need to see any "big picture" to tell
whether certain functions on Bitcoin Core are consensus-critical or
not, or whether consensus critical code needs to depend on util.o or
not.
But I wouldn't be writing to the mailing list without a plan with
further words nor pictures if I didn't had what I believe is a
complete implementation of what I just defined as "libconsensus phase
2".

Phase 3 should finish long pending discussions like "should
libconsensus be C++14 or plain C" which should NOT delay phase 2.
Phase 4 should be mostly trivial: rename files to the target dir and
move the remaining unused code out of libconsensus.
Phase 5 should make Bitcoin Core eat its own dog food and use
libbitcoinconsensus oonly by its generic C API (I'm sorry if this
looks too far away for me to even think about detailing it).

The work in progress branch (but hopefully being finished, nit and
merged within the 0.12.99 cycle) can be found in:
https://github.com/jtimon/bitcoin/commits/libconsensus-f2

Before sipa asks, signing code may make it into a new library but
SHOULDN'T BE PART OF LIBBITCOINCONSENSUS. Ideally, all exposed
functions will return true or false and an error string. It is based
on last-0.12.99 3cd836c1 but by popular demand I can open it as a
"DEPENDENT-tagged" PR linking to smaller steps and keeping track of
steps done. Analogous to the about to be replaced (for a simpler and
more maintainable example of testchain) #6382. If people like
Wladimir, Cory and Pieter cannot see that I've been able to reduce my
overall cry-for-review noise thanks to github adoption of emacs'
org-mode's [ ] vs [X] I can alwways leave those "big picture" branches
as "private" branches out of the pull request count.

I expect to publish a phase 3 branch very shortly. But as said I
expect a lot of discussion on the 

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 between crypto strength and code
> complexity, and "the strength of the crypto is all that matters" is NOT
> security first.

If the crypto code is properly encapsulated, the code complexity costs
of choosing one hashing function over another should be non-existent.
You made the space argument which is valid, but in my opinion code
complexity shouldn't be a valid concern in this discussion.

As a maybe uninteresting anecdote, I proposed the asset IDs in
https://github.com/ElementsProject/elements/tree/alpha-0.10-multi-asset
to do the same ```ripemd160 . sha256``` choice that Mark Friedenbach
had proposed and I had approved for
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#asset-tags
. More humble than me, he admitted he had made a design mistake much
earlier than me, who (maybe paradoxically) probably had less knowledge
for making crypto choices at the low level. In the end I was convinced
with examples I failed to write down for documentation and can't
remember.

That's not to say I have anything to say in this debate other than
code complexity (which I do feel qualified to talk about) shouldn't be
a concern in this debate. Just want to focus the discussion on what it
should be: security vs space tradeoff.
Since I am admittedly in doubt, I tend to prefer to play safe, but
neither my feelings nor my anecdote are logical arguments and should,
therefore, be ignored for any conclusions in the ```ripemd160 .
sha256``` vs sha256d debate. Just like you non-sequitor "sha256d will
lead to more code complexity", if anything, sha256d should be simpler
than ```ripemd160 . sha256``` (but not simpler enough that it matters
much).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 whether a hardfork is
accepted or not, we need to be sure that full noded will accept it, and
adopt it in time. A hashpower vote can still be used to be sure that miners
_also_ agree.

To clarify, that's the role of Bitcoin Core maintainers because they decide
what goes into Bitcoin Core, not because they decide the consensus rules of
Bitcoin. Other full node implementations (say, libbitcoin) will have to
decide on their own and Bitcoin Core mainteiners don't have any authority
over libbitcoin (or other alternative implementations). Nobody has such
authority (not even the creator of the system if he was still maintaining
Bitcoin Core).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 confirmations would be
required to achieve the same level of security.
>

I'm not sure I understand this. If mining revenue per unit of time drops,
total pow per unit of time should also drop. Even if the inter-block time
is increased, it's not clear to me that the pow per block would necessarily
be higher.
What am I missing?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 though.
I would have supported segwit for Bitcoin even if it was only possible
as a hardfork, but there's a softfork version and that will hopefully
accelerate its deployment.
Since the plan seems to be to do a softfork first and a hardfork
moving the witness tree (and probably more things) outside of the
coinbase later, I support the plan for segwit deployment.
In fact, the plan is very exciting to me.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 later 95%
confirmation anyway).
On Dec 18, 2015 9:02 PM, "Jeff Garzik"  wrote:

> From a code standpoint, based off height is easy.
>
> My first internal version triggered on block 406,800 (~May 5), and each
> block increased by 20 bytes thereafter.
>
> It was changed to time, because time was the standard used in years past
> for other changes; MTP flag day is more stable than block height.
>
> It is preferred to have a single flag trigger (height or time), rather
> than the more complex trigger-on-time, increment-on-height, but any
> combination of those will work.
>
> Easy to change code back to height-based...
>
>
>
> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I agree that nHeight is the simplest option and is my preference.
>> Another option is to use the median time from the previous block (thus
>> you know whether or not the next block should start the miner confirmation
>> or not). In fact, if we're going to use bip9  for 95% miner upgrade
>> confirmation, it would be nice to always pick a difficulty retarget block
>> (ie block.nHeight % DifficultyAdjustmentInterval == 0).
>> Actually I would always have an initial height in bip9, for softforks too.
>> I would also use the sign bit as the "hardfork bit" that gets activated
>> for the next diff interval after 95% is reached and a hardfork becomes
>> active (that way even SPV nodes will notice when a softfork  or hardfork
>> happens and also be able to tell which one is it).
>> I should update bip99 with all this. And if the 2 mb bump is
>> uncontroversial, maybe I can add that to the timewarp fix and th recovery
>> of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
>> follow bip99's recommendations and doesn't want to give 6 full months as
>> the pre activation grace period).
>> On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> In many BIPs we have seen, include the latest BIP202, it is the block
>>> time that determine the max block size. From from pool's point of
>>> view, it cannot issue a job with a fixed ntime due to the existence of
>>> ntime roll. It is hard to issue a job with the max block size unknown.
>>> For developers, it is also easier to implement if max block size is a
>>> function of block height instead of time. Block height is also much
>>> more simple and elegant than time.
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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).  Height seems KISS.
>
> AFAICT most of the attacks would occur around the already-heavily-watched
> flag day activation event, in a height based environment, a useful
> attribute.
>
> However I would like to hear from others about possible attacks with the
> various approaches, before diverging from the default community approach of
> switch-based-on-time.
>
>
>
>
>
>
> On Fri, Dec 18, 2015 at 3:10 PM, Jorge Timón  wrote:
>
>> 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 later 95%
>> confirmation anyway).
>> On Dec 18, 2015 9:02 PM, "Jeff Garzik"  wrote:
>>
>>> From a code standpoint, based off height is easy.
>>>
>>> My first internal version triggered on block 406,800 (~May 5), and each
>>> block increased by 20 bytes thereafter.
>>>
>>> It was changed to time, because time was the standard used in years past
>>> for other changes; MTP flag day is more stable than block height.
>>>
>>> It is preferred to have a single flag trigger (height or time), rather
>>> than the more complex trigger-on-time, increment-on-height, but any
>>> combination of those will work.
>>>
>>> Easy to change code back to height-based...
>>>
>>>
>>>
>>> On Fri, Dec 18, 2015 at 2:52 PM, Jorge Timón <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
 I agree that nHeight is the simplest option and is my preference.
 Another option is to use the median time from the previous block (thus
 you know whether or not the next block should start the miner confirmation
 or not). In fact, if we're going to use bip9  for 95% miner upgrade
 confirmation, it would be nice to always pick a difficulty retarget block
 (ie block.nHeight % DifficultyAdjustmentInterval == 0).
 Actually I would always have an initial height in bip9, for softforks
 too.
 I would also use the sign bit as the "hardfork bit" that gets activated
 for the next diff interval after 95% is reached and a hardfork becomes
 active (that way even SPV nodes will notice when a softfork  or hardfork
 happens and also be able to tell which one is it).
 I should update bip99 with all this. And if the 2 mb bump is
 uncontroversial, maybe I can add that to the timewarp fix and th recovery
 of the other 2 bits in block.nVersion (given that bip102 doesn't seem to
 follow bip99's recommendations and doesn't want to give 6 full months as
 the pre activation grace period).
 On Dec 18, 2015 8:17 PM, "Chun Wang via bitcoin-dev" <
 bitcoin-dev@lists.linuxfoundation.org> wrote:

> In many BIPs we have seen, include the latest BIP202, it is the block
> time that determine the max block size. From from pool's point of
> view, it cannot issue a job with a fixed ntime due to the existence of
> ntime roll. It is hard to issue a job with the max block size unknown.
> For developers, it is also easier to implement if max block size is a
> function of block height instead of time. Block height is also much
> more simple and elegant than time.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


>>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 after the "planned clock time" you need to wait for the next diff
retarget and then wait for 95% (bip9) I think the value of being able to
use "human friendly clock time" is very dubious (specially since median
time is different from real-world time anyway).
But yeah, not giving the creator of the current block direct control over
whether its block starts the activation process or not is achieved with
median time of the previous block just as well as nHeight does.
So even if I disagree with the value that median time brings over the
simpler height approach, let's please decide on one and always use that for
both hardforks and softforks as part of bip9 (which we would need to
modify).
An initial time threshold is not necessary for uncontroversial softforks,
but it doesn't hurt (you can always set it in the past if you want to not
use it) and in fact it simplifies bip9's implementation.
Let's please decide once and for all, update bip9 and bip99 and stop doing
something different on every hardfork patch we write.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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
than 6 months for a hardfork is starting to push it too much.
For a more complex hardfork (say, a SW hardfork or a collection of many
little fixes) I believe 1 year or more would make more sense.

BIP99 recommends a time threshold (height or median time) + 95% miner
upgrade confirmation with BIP9 (version bits).
So how about the following plan?

1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade
confirmation

2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9.

Note that both "when it's ready" depend on something we are not paying a
lot of attention to: bip9's implementation (just like bip113, bip68-112,
bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork,
etc).

Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
equivalent to the 2-4-8 "compromise" proposal (which by the way I never
liked, because I don't think anybody should be in a position to
"compromise" anything and because I don't see how "let's avoid an
unavoidable economic change for a little bit longer" arguments can
reasoably claim that "we need to kick the can down the road exactly 3 more
times" or whatever is the reasoning behind it).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 4:10 AM, jl2012 via bitcoin-dev
 wrote:
> Jonathan Toomim via bitcoin-dev 於 2015-12-17 21:47 寫到:
>>
>> Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob
>> runs the old rules. Bob creates a p2pkh address for Mallory to use.
>> Mallory takes 1 BTC, and creates an invalid SegWit transaction that
>> Bob cannot properly validate and that pays into one of Mallory's
>> wallets. Mallory then immediately spends the unconfirmed transaction
>> into Bob's address. Bob sees what appears to be a valid transaction
>> chain which is not actually valid.
>>
>> Clueless Carol is one of the 4.9% of miners who forgot to upgrade her
>> mining node. Carol sees that Mallory included an enormous fee in his
>> transactions, so Carol makes sure to include both transactions in her
>> block.
>>
>> Mallory gets free beer.
>>
>> Anything I'm missing?
>
>
> You miss the fact that 0-conf is not safe, neither 1-conf. What you are
> suggesting is just a variation of Finney attack.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

You can always schism hardfork miners out...
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 trusted if done externally:
> Perhaps BIPs for instance.  People would somehow "mark" their BTC as being
> "For Proposition X" (as opposed to all other propositions) and the vote
> would be canceled as soon as the BTC is spent again.
>
> Unfortunately, I've spent the past 2 days trying to find a design that would
> allow this (I don't think my original suggestion made sense in the context
> of how transactions work), and I haven't gotten much yet.

Well, as said, if it's for consensus, you will need to adapt the
system in a special way anyway, but I still don't see why turing
completeness is required.
This type of idea is not new. Since miners can censor votes (and
that's undetectable for consensus), several solutions have been
proposed, time lock the votes, for example.

>>But each scriptSig is only executed once with its corresponding
>> scriptPubKey. Are you proposing we change that?
>
> Sorry, I didn't understand Bitcoin's transaction model well enough when I
> first made the proposal.  If Turing Pseudo-Completeness is possible with
> Bitcoin, then I understand now that it could not require you to execute a
> script more than once.  My current thought is that recursion can be
> accomplished via checking if the next output's scriptPubKey is identical in
> every way to the current scriptPubKey.  Unfortunately, a lot more is needed
> than just recursion in order to do on-chain BTC voting the way I have in
> mind.  I'll keep working on this.

What you call "recursion" seems similar to what we usually call "covenants", see

https://bitcointalk.org/index.php?topic=278122.0

Although the thread says "an amusingly bad idea", I think it's
actually a great idea and there's some use cases that are very hard to
support without covenants.
Again, no Turing completeness required for this.

> On Fri, Dec 11, 2015 at 10:36 AM, Jorge Timón  wrote:
>>
>>
>> On Dec 10, 2015 7:36 AM, "Luke Durback"  wrote:
>> >
>> > Tomorrow, I'll work on writing a way to do voting on proposals with BTC
>> > used as voting shares (This will be difficult as I do not know FORTH).  
>> > That
>> > seems like a fairly simple, useful example that will require loops and
>> > reused functions.  I'll add a fee that goes to the creator.
>>
>> 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 don't see how "loops and reused functions" are needed in the scripting
>> language for this use case, but I'm probably missing some details. Please,
>> the more concrete you make your example, the easiest it will be for me to
>> understand.
>>
>> > IMO, if you write a complicated system of scripts that's used
>> > frequently, it makes sense to charge a fee for its usage.
>>
>> But each scriptSig is only executed once with its corresponding
>> scriptPubKey. Are you proposing we change that?
>>
>> >  A decentralized exchange between colored coins, for instance might take
>> > a small fee on each trade.
>>
>> I've been researching the topic of decentralized exchange from before the
>> term "colored coins" was first used (now there's multiple designs and
>> implementations); contributed to and reviewed many designs: none of them
>> (colored coins or not) required turing completeness.
>> I'm sorry, but what you are saying here is too vague for me to concretely
>> be able to refute the low level "needs" you claim your use cases to have.
>>
>> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev"
>> >  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 mean a scriptSig, but then "paying its creator" doesn't make 
>> > much
>> > sense to me .
>> >
>> > Could you provide some high level examples of the use cases you would
>> > like to support with this?
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 better position for merged mining (such
>> a hardfork was suggested in 2010 as something that could be done if
>> merged mining was used), room for commitments to additional block
>> back-references for compact SPV proofs, and/or UTXO set commitments.
>> Part of the reason to not do it now is that the requirements for the
>> other things that would be there are not yet well defined. For these
>> other applications, the additional overhead is actually fairly
>> meaningful; unlike the fraud proofs.
>
>
> So just design ahead for those future uses. Make the merkle tree:
>
>
>  root_in_block_header
>  /  \
>   tx_data_root  other_root
>/   \
> segwitness_root reserved_for_future_use_root

This is basically what I meant by

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
uint256 hashextendedHeader;
}

but my design doesn't calculate other_root as it appears in your tree (is
not necessary).

Since stop requiring bip34 (height in coinbase) is also a hardfork (and a
trivial one) I suggested to move it at the same time. But thinking more
about it, since BIP34 also elegantly solves BIP30, I would keep the height
in the coinbase (even if we move it to the extented header tree as well for
convenience).
That should be able to include future consensus-enforced commitments (extra
back-refs for compact proofs, txo/utxo commitments, etc) or non-consensus
data (merged mining data, miner-published data).
Greg Maxwell suggested to move those later and I answered fair enough. But
thinking more about it, if the extra commitments field is extensible, we
don't need to move anything now, and therefore we don't need for those
designs (extra back-refs for compact proofs, txo/utxo commitments, etc) to
be ready to deploy a hardfork segregated witness: you just need to make
sure that your format is extensible via softfork in the future.

I'm therefore back to the "let's better deploy segregated witness as a
hardfork" position.
The change required to the softfork segregated witnesses implementation
would be relatively small.

Another option would be to deploy both parts (sw and the movement from the
coinbase to the extra header) at the same time but with different
activation conditions, for example:

- For sw: deploy as soon as possible with bip9.
- For the hardfork codebase to extra header movement: 1 year grace + bip9
for later miner upgrade confirmation.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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
> > you will oppose to that hardfork later just like you are opposing to
> > it now.
> > As said I disagree that making a softfork first and then move the
> > commitment is less disruptive (because people will need to adapt their
> > software twice), but if the intention is to never do the second part
> > then of course I agree it would be less disruptive.
> > How long after the softfork would you like to do the hardfork?
> > 1 year after the softfork? 2 years? never?
>
> I think it would be logical to do as part of a hardfork that moved
> commitments generally; e.g. a better position for merged mining (such
> a hardfork was suggested in 2010 as something that could be done if
> merged mining was used), room for commitments to additional block
> back-references for compact SPV proofs, and/or UTXO set commitments.
> Part of the reason to not do it now is that the requirements for the
> other things that would be there are not yet well defined. For these
> other applications, the additional overhead is actually fairly
> meaningful; unlike the fraud proofs.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 mean a scriptSig, but then "paying its creator" doesn't make much sense
to me .

Could you provide some high level examples of the use cases you would like
to support with this?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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.

Testnet4 ?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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 is compatible with the
> existing network, or should the block hashing data structure
> immediately be changed in an incompatible way to accommodate it in
> order to satisfy an ascetic sense of purity and to make fraud proofs
> somewhat smaller?

>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
you will oppose to that hardfork later just like you are opposing to
it now.
As said I disagree that making a softfork first and then move the
commitment is less disruptive (because people will need to adapt their
software twice), but if the intention is to never do the second part
then of course I agree it would be less disruptive.
How long after the softfork would you like to do the hardfork?
1 year after the softfork? 2 years? never?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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,
> which has almost never been problematic. (A popular block explorer
> recently misimplemented the var-int decode and suffered an outage).

It would be also a nice opportunity to move the height to a more
accessible place.
For example CBlockHeader::hashMerkleRoot (and CBlockIndex's) could be
replaced with a hash of the following struct:

struct hashRootStruct
{
uint256 hashMerkleRoot;
uint256 hashWitnessesRoot;
int32_t nHeight;
}

> From a risk reduction perspective, I think it is much preferable to
> perform the primary change in a backwards compatible manner, and pick
> up the data reorganization in a hardfork if anyone even cares.


But then all wallet software will need to adapt their software twice.
Why introduce technical debt for no good reason?

> I think thats generally a nice cadence to split up risks that way; and
> avoid controversy.

Uncontroversial hardforks can also be deployed with small risks as
described in BIP99.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  1   2   3   >