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, "Serg
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, lik
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
>
> "lockinontimeou
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" fall
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
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 r
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 slightl
2017 at 8:00 PM, Peter Todd 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 (potentia
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 assu
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"
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. IIR
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 upgr
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.linuxfoundat
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
> th
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 tim
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
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 ve
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 sit
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 d
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 he
On Sep 9, 2015 8:36 PM, "Marcel Jamin via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I propose to:
>
> a) assess what blocklimit is currently technically possible without
driving up costs of running a node up too much. Most systems currently
running a fullnode probably have so
Unfortunately the relation between block maximum size and mining
centralization is much more complex than that.
On Sep 9, 2015 3:00 PM, "Marcel Jamin" wrote:
> I think the overlap of people who want to run a serious mining operation
> and people who are unable to afford a slightly above average i
On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Rather than (promising to, and when they don't actually, at least
pretending to) use the first-seen block, I propose that a more
sophisticated method of choosing which of two block solutions
On Sep 11, 2015 1:54 PM, "Marcel Jamin" wrote:
> And what they felt "remained fair to all to all miners and node operators
worldwide." Increasing network connection requirements might even decrease
mining centralization right now.
No. People seem to think "Chinese have slow connections? Screw the
On Sep 11, 2015 1:18 PM, "Christophe Biocca"
wrote:
>
> It's pretty obvious that Dave is suggesting an alternate tie-breaker:
I thought he was proposing a new consesnsus rule. I see, this would be just
a policy validation that everybody would be free to ignore (like the "first
seen" spend conflic
For enforcing new restrictions on your own blocks (thus at the policy
level, not consensus) you don't need to wait for 75%. You can do it from
the start (this way all miners setting the bit will enforce the new
restrictions.
On Sep 16, 2015 4:20 PM, "Rusty Russell via bitcoin-dev" <
bitcoin-dev@lis
No, 95% is safer and will produce less orphaned blocks.
0%is fine to do it in your own blocks.
I agree on using height vs time. Rusty, what do you mean by being easier
for bip writers? How is writing "block x" any harder than writing "date y".
On Sep 16, 2015 4:32 PM, "Tier Nolan via bitcoin-dev"
On Sep 16, 2015 4:49 PM, "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>
> On Wed, Sep 16, 2015 at 9:38 PM, Jorge Timón wrote:
>>
>> No, 95% is safer and will produce less orphaned blocks.
>
> The point of the 75% is just as a test run. Enforcement wouldn't happ
I understand your proposal, but I don't see what it accomplishes compared
to applying the new rule from the start (in your own blocks) and wait for
95% for consensus activation (which is my preference and it's much simpler
to implement).
What are the disadvantages of my approach? What are the advan
On Thu, Sep 17, 2015 at 12:38 PM, Tier Nolan via bitcoin-dev
wrote:
> The advantage of enforcing the rule when 75% is reached (but only for blocks
> with the bit set) is that miners get early notification that they have
> implemented the rule incorrectly.They might produce blocks that they
> t
Fill or kill us normally used for trades and I think it can be confusing.
Previous times this has been discussed it has been discussed under
nExpiryTime or op_height (which enables expiration), for example, in the
freimarkets white paper.
As Mark points out this can be made safe by requiring that
On Sep 17, 2015 6:48 PM, "Peter Todd" wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Fill or k
Well, with utxo commitments at some point maybe is enough to validate the
full headers history but only the last 5 years of ttansaction history
(assuming utxo commitments are buried 5 years worth of blocks in the past).
This scales much better than validating the full history and if we get a 5
year
s/move the genesis block forward/move your genesis checkpoint forward/
On Sep 18, 2015 4:37 PM, "Jorge Timón" wrote:
> Well, with utxo commitments at some point maybe is enough to validate the
> full headers history but only the last 5 years of ttansaction history
> (assuming utxo commitments are
proposing to use the block time or the median block time?
For some hardforks/softforks the block time complicates the implementation
(ie in acceptToMemoryPool) as discussed in the mentioned thread.
On Sep 19, 2015 1:24 AM, "Rusty Russell" wrote:
> Jorge Timón via bitcoin-dev
> wr
ep 19, 2015 4:01 AM, "Luke Dashjr" wrote:
> On Thursday, September 17, 2015 7:14:38 PM Jorge Timón via bitcoin-dev
> wrote:
> > As Mark points out this can be made safe by requiring that all the
> outputs
> > of a transaction that can expire have op_maturity/csv/
On Sep 20, 2015 10:58 PM, "Rusty Russell" wrote:
>
> Jorge Timón writes:
> > I disagree with the importance of this concern and old soft/hardforks
will
> > replace this activation mechanism with height, so that's an argument in
> > favor of using the height from the start. This is "being discusse
On Fri, Sep 18, 2015 at 12:44 AM, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 17 September 2015 12:14:38 GMT-07:00, "Jorge Timón via bitcoin-dev"
> wrote:
>>Fill or kill us normally used for trades and I think it can be
&
On Tue, Sep 15, 2015 at 6:10 AM, Jeff Garzik via bitcoin-dev
wrote:
> [collating a private mail and a github issue comment, moving it to a
> better forum]
>
> On libconsensus
> ---
> In general there exists the reasonable goal to move consensus state
> and code to a specific, separate
On Fri, Sep 18, 2015 at 2:07 AM, Wladimir J. van der Laan via
bitcoin-dev wrote:
> My long-term vision of bitcoind is a P2P node with validation and blockchain
> store, with a couple of data sources that can be subscribed to or pulled from.
I agree with this long term vision.
Here's how I think
On Tue, Sep 22, 2015 at 8:27 PM, Gavin Andresen wrote:
> You need to write a high-level overview document, explaining things like:
>
> + Who should use libconsensus
Separating the consensus code is extremely important for less risky
and wider contributions regardless of what is exposed.
But once
On Wed, Sep 23, 2015 at 1:49 AM, Dave Scotese wrote:
> If I'm reading this situation correctly, Jeff is basically pointing out that
> developers need more links (hooks, rungs, handholds, data points, whatever
> you want to call them) so that they can see all the things his email
> insinuated are m
On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>> In a hardfork, however, there is no mechanism to stop the old fork and
we may have 2 chains co-exist for a long time.
>
>
> There isn't any difference in how long the divergent state exists for.
On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn wrote:
> Hi Jorge,
>
>> Yes, there is a difference. Assuming the hashrate majority upgrades, in
>> the case of a softfork [snip] .. In the case of a hardfork [snip]
>
> Yes, I know what the difference between them is at a technical level. You
> didn'
Gavin, you assume that users must necessarily always follow the
hashrate majority, but this is not true.
In fact, it is the opposite: market forces make the hashrate follow the users.
Not following the hashrate majority is not necessarily insane.
If some users aren't happy with the new hardfork ru
On Wed, Sep 30, 2015 at 7:11 PM, Mike Hearn via bitcoin-dev
wrote:
> Several people have asked several times now: given the very real and widely
> acknowledged downsides that come with a soft fork, what is the specific
> benefit to end users of doing them?
As previously explained, the biggest adv
Yes, I believe consensus rule changes don't need to be couple with
major releases, there's no problem that I can see in them being minor
releases if they're not ready on time for a major release.
On Wed, Sep 30, 2015 at 7:57 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Thursday, September 24, 2015
On Sep 30, 2015 9:56 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Jorge has said soft forks always lead to network convergence. No, they
don't. You get constant mini divergences until everyone has upgraded, as
opposed to a single divergence with a hard fork (
On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn wrote:
>> Exactly, all those "mini divergences" eventually disappear
>
> A miner that has accepted a newly invalid transaction into its memory pool
> and is trying to mine it, will keep producing invalid blocks forever until
> the owner shuts it down an
On Oct 1, 2015 12:14 AM, "Jorge Timón" wrote:
>
> On Wed, Sep 30, 2015 at 11:06 PM, Mike Hearn wrote:
> >> Exactly, all those "mini divergences" eventually disappear
> >
> > A miner that has accepted a newly invalid transaction into its memory
pool
> > and is trying to mine it, will keep producin
On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> should an algorithm that guarantees protection from ASIC/FPGA
optimization be found.
This is demonstrably impossible: anything that can be done with software
can be done with hardware. This
On Oct 2, 2015 12:46 PM, "NxtChg" wrote:
>
>
> >...obviously not for so called "ASIC-resistance" [an absurd term coined
to promote some altcoins]
>
> Yet another fallacy of "all-or-nothing" thinking, which is so abundant in
the Core camp.
>
> The fact that you can build ASIC for any kind of algori
On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" accordi
On Oct 5, 2015 2:08 PM, "Clément Elbaz" wrote:
>
> It will get correct results about :
> - the existence every block
> - the existence of every transaction
>
> It will get incorrect results :
> - about the nature of some transactions
Given the assumptions above, only of transactions without enoug
"Consensus" it's a term we use for consensus critical code and we
refer to different machines (potentially with different software)
validating in exactly the same way.
I think also using the term for people agreeing on what those
consensus rules is confusing, so in BIP99 I used the term
"uncontrove
On Fri, Oct 2, 2015 at 4:12 AM, GC via bitcoin-dev
wrote:
> Or, you know, enter some discussions on what exactly are the issues that SPV
> clients face during soft forks and see if anything can be done (on all
> sides) to mitigate the risks.
This has already been discussed. The recommended risk m
On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn wrote:
> Hi Jorge,
>
> I'm glad we seem to be reaching agreement that hard forks aren't so bad
> really and can even have advantages. It seems the remaining area of
> disagreement is this rollout specifically.
>>
>> a non-upgraded full node and an upgrade
On Mon, Oct 5, 2015 at 2:29 PM, Clément Elbaz wrote:
> The problem is that some transactions that are meaningless to you are
> actually meaningful to people using an upgraded Bitcoin software.
>
> Therefore during a softfork, while you can not miss the existence of a
> transaction, you can miss it
On Fri, Oct 16, 2015 at 3:26 AM, Rusty Russell via bitcoin-dev
wrote:
> ... Gavin just told me about setmocktime. That's fast service!
Once more functions (specially consensus-critical functions) take
nTime explicitly as parameter instead of relying on the
library-unfriendly GetAdjustedTime(), t
On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote:
>> So this is indeed a form of desired malleability we will likely not be able
>> to fix. I'd argue that this goes more into the direction of double-spending
>> th
On Thu, Nov 5, 2015 at 8:36 PM, Luke Dashjr wrote:
> Ok, then my point is that "signature malleability" is not particularly
> problematic or interesting alone, and the only way to get a practically-useful
> solution, is to address all kinds of malleability.
I disagree. Segregated witnesses, for e
On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev
wrote:
> On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote:
>> * Mining code will use starting priority for ease of implementation
>
> This should be optional, at least for 0.12.
The ease of implementation is
Currently bip99 recommends 95% miner upgrade confirmation with version bits
(bip9) for uncontroversial hardforks just like it does for uncontroversial
softforks. It is true that in the case of hardforks miners don't decide and
it's the whole economy who has to upgrade before activation, but "the wh
I agree with the usefulness of at least trying to define a formal set
of criteria.
I'm afraid that with proposals that schedule future increases to the
blocksize consensus maximum or leave it for miners to decide (like
BIP100, BIP101 and BIP103) cannot be evaluated without making
assumptions about
On Nov 15, 2015 5:10 AM, "Peter R via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> What rules does Bitcoin obey?
Thanks to the worl of many people, part of the consensus rules are finally
encapsulated in the libbitcoinconsensus library. I'm currently writing a
document to compl
Going back on topic, I believe libconsensus shouldn't depend on any
particular database because assuming it will continue to be stateless
(the current libbitcoinconsensus is stateless) end therefore has no
storage. I know some people disagree in various degrees.
At the same time, the parts of the c
Thank you for incorporating the feedback, specifically thank you for
using the genesis block hash as the unique chain ID.
I wen't through the BIP draft and left a few of comments, but I really
like its simplicity and focus. Good work!
On Sun, Nov 15, 2015 at 3:14 AM, Marco Pontello via bitcoin-de
On Sat, Nov 14, 2015 at 10:11 PM, Luke Dashjr wrote:
> On Saturday, November 14, 2015 10:52:12 AM Jorge Timón via bitcoin-dev wrote:
>> Currently bip99 recommends 95% miner upgrade confirmation with version bits
>> (bip9) for uncontroversial hardforks just like it does for
On Mon, Nov 16, 2015 at 2:52 AM, Rusty Russell wrote:
> We have strayed far from both the Subject line and from making progress
> on bitcoin development. Please redirect to bitcoin-discuss.
>
> I have set the moderation bits on the three contributors from here down
> (CC'd): your next post will g
Not a native english speaker myself, so I may have missed some things...
Yes, sorry about the link. I guess you can point to #6230 . I can
rebase it if needed but I would close it again because I don't want to
have too many things from #6382 opened at the same time (is noisy and
worse for review).
On Wed, Nov 18, 2015 at 10:13 AM, Shuning Hong wrote:
> 2015-11-15 20:16 GMT+08:00 Jorge Timón
> :
>> The time threshold must be set enough in the future to give users time to
>> upgrade. But we can perceive miners' adoption, so if the system knows they
>> haven't upgraded, it should wait for t
I can always link to the BIP when I reopen that commit as independent
instead of the other way around.
Btw, the PR needs rebase (probably the conflict is in the README).
On Mon, Nov 16, 2015 at 11:10 PM, Marco Pontello wrote:
> OK, adding the relevant code fragment is probably the simplest and di
On Tue, Nov 17, 2015 at 11:17 PM, telemaco via bitcoin-dev
wrote:
> Shouldn't a odbc jdbc jconnect or equivalent be totally transparent for the
> consensus code?
Yes, but we're only testing levelDB and we couldn't assure that it
won't produce unintentional consensus forks with other databases
beh
I agree, I believe the first name that an op with equivalent functionality
had was simply op_maturity.
At least I remember we discussed such an opcode when discussing pegged
sidechains' design.
I kind of dislike the check_x_verify naming pattern. We want all new
operands to return if whatever they
On Nov 24, 2015 1:21 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Whatever we call it, deciding on that is a simple s/FOO/BAR/ prior to
> release.
While I agree we're not in a hurry, the more we wait, the longer docs (to
be modified later) will accumulate ma
On Nov 26, 2015 12:06 AM, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Again my objection would go away if we renamed nSequence, but I actually
think the nSequence name is better...
I suggested to rename nSequence to nMaturity on this list even before the
bi
Both CPFP and RBF are relay/mining policy and cannot be made consensus
rules because you cannot know which transactions have been received by a
givrn peer and which have not (or at what time). Consensus rules can only
validate information that's in the blockchain.
On Nov 29, 2015 5:33 AM, "Vincent
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
On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I also think that a hard fork is better for SegWit, as it reduces the
size of fraud proofs considerably, makes the whole design more elegant and
less kludgey, and is safer for clients who do
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 mis
On Wed, Dec 9, 2015 at 1:58 AM, Jorge Timón wrote:
> struct hashRootStruct
> {
> uint256 hashMerkleRoot;
> uint256 hashWitnessesRoot;
> int32_t nHeight;
> }
Or better, for forward compatibility (we may want to include more
things apart from nHeight and hashWitnessesRoot in the future):
struct ha
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 netwo
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 hardfor
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
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
well "only executed once" (every time someone verifies that transaction)...
On Dec 11, 2015 4:36 PM, "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 diffi
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 m
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 externall
On Dec 16, 2015 10:08 PM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille
wrote:
>>
>> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>> wrote:
>> > 2) If block size stays at 1M, the Bitcoin Core develo
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
tha
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 miner
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
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 wo
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 late
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.
>
> A
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 cl
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
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 confirma
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 whe
The hashpower is a function of the block reward (subsidy + fees): it's
economically irrational to have costs greater than the reward (better just
turn off your miners) and in a perfect competition (a theoretical model)
profits tend to zero. That is, the costs tend to equal revenue (block
reward).
O
1 - 100 of 358 matches
Mail list logo
