On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote:
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote:
Equally this proposal is no more consensus enforcement than simply
increasing the fee (and possibly decreasing the absolute nLockTime) for
You've
I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The deadline could be matched to a start-line. The definition would then
be something like
BIP 105
Start block: 325000
End block: 35
Activation: 750 of 1000
Sequence numbers appear to have been originally intended as a mechanism
for transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel.
Yes indeed they were. Satoshis mechanism was more general than micropayment
channels and could do HFT
On Wed, May 27, 2015 at 11:15 AM, Peter Todd p...@petertodd.org wrote:
The median time mechanism is basically a way for hashing power to show
what time they think it is. Equally, the nVersion soft-fork mechanism is
a way for hashing power to show what features they want to support.
Fair
On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote:
I think it would be better to have the deadlines set as block counts. That
eliminates the need to use the median time mechanism.
The median time mechanism is basically a way for hashing power to show
what time they think it is.
This could cause legacy transactions to become unspendable.
A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.
Legacy transactions should not have the rule applied to them.
On Wed, May 27, 2015 at 9:18 AM, Gregory
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote:
Equally this proposal is no more consensus enforcement than simply
increasing the fee (and possibly decreasing the absolute nLockTime) for
You've misunderstood it, I think-- Functionally nlocktime but relative
to each txin's
Also think it would be useful.
Created an issue for it some time back:
https://github.com/bitcoin/bitcoin/issues/3802
I think nodes don't only have to connect to LAN nodes. Especially with
headers first.
They can still connect to other nodes as well. Having said that security
is problematic in
On May 27, 2015 11:35 AM, Tier Nolan tier.no...@gmail.com wrote:
Was the intention to change the 95% rule. You need 750 of the last 1000
to activate and then must wait at least 1000 for implication?
You need 75% to start applying it, 95% to start rejecting blocks that don't
apply it.
On Wed, May 27, 2015 at 3:11 AM, Mike Hearn m...@plan99.net wrote:
As I believe out of all proposed protocols Satoshi's is still the most
powerful, I would suggest that any change to the semantics on nSequence be
gated by a high bit or something, so the original meaning remains available
On May 27, 2015 12:58 PM, Peter Todd p...@petertodd.org wrote:
What I'm not seeing is how the relative nLockTime that nSequence
provides fundamentally changes any of this.
This allows the implementation of a rcltv that doesn't make script depend
on the current height, in a similar way that
Mike, this proposal was purposefully constructed to maintain as well as
possible the semantics of Satoshi's original construction. Higher sequence
numbers -- chronologically later transactions -- are able to hit the chain
earlier, and therefore it can be reasonably argued will be selected by
Hi Peter,
Thanks for your reply.
I know and bookmarked your branch - nice work.
So, to clarify:
- bitcoin core (official / default) 0.10.x currently has First-seen
mempool behavior
- your custom branch uses replace by fee mempool behavior which allows
an user to change anything in a tx (I guess
There is absolutely no reason to do this.
Any reasonable micro-controller can build merkle tree roots
significantly faster than is necessary.
1 Th/s walks the nonce range once every 4.3ms.
The largest valid merkle trees are 14 nodes high.
That translates to 28 SHA256 ops per 4.3ms or 6511
On Wed, May 27, 2015 at 9:16 PM, Andrew onelinepr...@gmail.com wrote:
You should also keep in mind the big picture when it comes to
decentralization. If the hard drives (or tapes) can only be produced by a
small number of large companies like Western Digital or Seagate, then you
can't really
Hi All
I discussed this idea with some other core developers (on IRC) and they
generally seem to agree that it can be done.
It may be equivalent to an idea called blockchain extensions but when I
looked it up on bitcointalk.org I didn't see exactly the same proposal I am
making.
One person
I like the idea but I think we should leave at least 16 bits of the
version fixed as an extra-nonce.
If we don't then miners may use them as a nonce anyway, and mess with
the soft-fork voting system.
My original proposal was this: https://github.com/bitcoin/bitcoin/pull/5102
Best regards
I wrote an article that explains the hashing assurance contract concept:
https://medium.com/@octskyward/hashing-7d04a887acc8
(it doesn't contain an in depth protocol description)
--
On Wed, May 27, 2015 at 9:59 PM, Mike Hearn m...@plan99.net wrote:
I wrote an article that explains the hashing assurance contract concept:
https://medium.com/@octskyward/hashing-7d04a887acc8
(it doesn't contain an in depth protocol description)
The prior (and seemingly this) assurance
On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote:
Case 1: Increasing the fee on a single tx
-
We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size
with the minimal relay fee, 2.26uBTC. Increasing the fee while
respecting
On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote:
Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign
Please remove me from the mailing list
2015-05-27 3:50 GMT+02:00 Mark Friedenbach m...@friedenbach.org:
Sequence numbers appear to have been originally intended as a mechanism
for transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel.
22 matches
Mail list logo
