On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote:
>> While to many of us that sounds crazy, if you're threat model assumes
>> Bitcoin is a legal/regulated service provided by a highly trusted
>> mining community it's a reasonable design.
>
> There is a large, grey area all the way to "legal/reg
>While to many of us that sounds crazy, if you're threat model assumes
>Bitcoin is a legal/regulated service provided by a highly trusted mining
>community it's a reasonable design.
There is a large, grey area all the way to "legal/regulated service provided by
a highly trusted mining community"
How them being expensive to generate make them less likely to be reorged?
Would an op_return output used as a nonce to make the hash of the
transaction contain some proof of work make the non-coinbase expirable
transaction more secure against reorgs?
I'm afraid your point is irrelevant.
On Sep 19,
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 discussed" in a
thread branched from bip99's discussion.
Anyway, is this proposing to use the b
On 18/09/15 15:17, Rune Kjær Svendsen via bitcoin-dev wrote:
> Bitcoin does not function if the majority of mining power is dishonest. There
> is no way around that. It’s how proof-of-work functions.
None of those statements are true.
If a majority of Bitcoin miners are mining invalid blocks, t
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/rcltv of 100. That
> makes them as reorg-safe as coinbase transactions.
Not quite as sa
On Fri, Sep 18, 2015 at 08:06:23PM +, Matt Corallo via bitcoin-dev wrote:
> I did not intend to imply that there was agreement on a desire to
> schedule a second hardfork. My wording may have been a bit too loose.
> Instead, I believe there was much agreement that doing a short-term
> hardfork
I am in a timezone that uses DST (currently PDT), but I would like us to
use a timezone that does NOT use DST. It will be nice to have something
that reflects the seasonal patterns like my own body does. I hate the time
change in both ways.
On Fri, Sep 18, 2015 at 2:50 PM, Luke Dashjr via bitcoi
Mark Friedenbach via bitcoin-dev
writes:
> Eric, that would be, I think, my sequencenumbers2 branch in which nSequence
> is an explicit relative lock-time field (unless the most significant bit is
> set). That has absolutely clear semantics. You should comment on #6312
> where this is being discus
Tier Nolan via bitcoin-dev writes:
> On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell
> wrote:
>> You need a timeout: an ancient (non-mining, thus undetectable) node
>> should never fork itself off the network because someone reused a failed
>> BIP bit.
>>
>
> I meant if the 2nd bit was part of the
Tier Nolan via bitcoin-dev
writes:
> 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 think are fine, but which aren't.
Jorge Timón via bitcoin-dev writes:
> 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".
Three years from drafting is reasonable. How many blocks is that? Hmm,
better make it 6 years of blocks ju
Any change that results in this happening all over again in a few years
does not have consensus.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
This way lets us protect from 51% overwrites for a whole year:
1. Hash utxo set as is today, H1, and store it in a block.
2. At the same time, store a copy of the utxo set for H1 on disk, D1
3. After 1 year, create D2, then wait for H2 (if a fork happens then
recreate D2 and see which wins)
4. The
Dear List,
1. Are you sick of hearing about THE BLOCKSIZE?
2. Do you feel that long-settled blocksize issues are coming up again
and again, resulting in duplicated work and communications burnout?
3. Do you feel that, while scalability is important and all, people
should just shut up about it alre
On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> Google calendar is localised, so it doesn't matter. The problem with
> quoting UTC anyway it the meeting times are going to change for those that
> observe DST. It would be much better to quote an actual timezone of an
> act
On Friday, September 18, 2015 8:24:50 PM Btc Drak via bitcoin-dev wrote:
> Google calendar is localised, so it doesn't matter. The problem with
> quoting UTC anyway it the meeting times are going to change for those that
> observe DST. It would be much better to quote an actual timezone of an
> act
Yes, I'm aware, however they are closer to each other than UTC is to either :p.
On September 18, 2015 4:31:28 PM EDT, Gregory Maxwell
wrote:
>On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
> wrote:
>> Google Calendar is localized, but has an option to change the
>timezone
>> of an
I believe that is out of date. I see neither UTC nor GMT on the website nor on
Android.
Matt
On September 18, 2015 4:30:23 PM EDT, Jeffrey Paul wrote:
>
>> On 18 Sep 2015, at 22:27, Matt Corallo via bitcoin-dev
> wrote:
>>
>> Google Calendar is localized, but has an option to change the
>timez
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
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
Urgh... Can we hardfork time? It's clearly in need of an upgrade...
On Fri, Sep 18, 2015 at 9:31 PM, Gregory Maxwell wrote:
> On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
> wrote:
> > Google Calendar is localized, but has an option to change the timezone
> > of an event, it jus
On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
wrote:
> Google Calendar is localized, but has an option to change the timezone
> of an event, it just doesnt have UTC in its options. So, yes, we should
> use something that observes DST in roughly the same way as everyone else
> - CES
> On 18 Sep 2015, at 22:27, Matt Corallo via bitcoin-dev
> wrote:
>
> Google Calendar is localized, but has an option to change the timezone
> of an event, it just doesnt have UTC in its options. So, yes, we should
> use something that observes DST in roughly the same way as everyone else
> - C
Google Calendar is localized, but has an option to change the timezone
of an event, it just doesnt have UTC in its options. So, yes, we should
use something that observes DST in roughly the same way as everyone else
- CEST/PDT/EST/etc.
On 09/18/15 20:24, Btc Drak wrote:
> Google calendar is locali
Google calendar is localised, so it doesn't matter. The problem with
quoting UTC anyway it the meeting times are going to change for those that
observe DST. It would be much better to quote an actual timezone of an
actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
example. O
There are a couple of points I’d like to address.
Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not function
if the majority of mining power is dishonest. There is no way around that. It’s
how proof-of-work functions. And if we lose proof-of-work, we lose Bitcoin.
Secondly,
Generally in favor, but for practical purposes can we select a timezone
that is available in Google Calendar? It appears it does not directly
support UTC...
On 09/18/15 01:07, Wladimir J. van der Laan via bitcoin-dev wrote:
> Hello,
>
> At Monday's code sprint we had a good idea to schedule a reg
I believe the discussion here is on improving initial-sync time by
simply skipping initial-sync and getting a committed-to utxo set. This
is obviously a new security model in between SPV and full-node (I would
call it SPV with future validation). Still, I'm not convinced it buys us
anything, we rea
I guess I always assumed that UTXO set commitments were an alternative
security model (between SPV and full-node), not that they would cause the
existing security model to be deprecated.
On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wr
I did not intend to imply that there was agreement on a desire to
schedule a second hardfork. My wording may have been a bit too loose.
Instead, I believe there was much agreement that doing a short-term
hardfork now, with many agreeing that a second would hopefully be
entirely unnecessary/impossib
Full nodes using UTXO set commitments is a change to the bitcoin
security model.
Currently an attacker with >50% of the network hashrate can rewrite history.
If full nodes rely on UTXO set commitments such an attacker could create
an infinite number of bitcoins (as in many times more than the cur
Currently, when a new node wants to join the network, it needs to retrieve the
entire blockchain history, starting from January 2009 and up until now, in
order to derive a UTXO set that it can verify new blocks/transactions against.
With a blockchain size of 40GB and a UTXO size of around 1GB, t
To be quite frank, I'm a little disappointed we've fallen back on arguing over
numbers pulled out of a hat rather than discussing far more fundamental issues
such as the dev process generally, consensus building, and our basic
understanding of what Bitcoin really is, its strengths and weaknesses
"But if a metric were chosen that addressed my concerns (worst case
propagation and validation time), then I could be in favor of an initial
bump that allowed a larger number of typical transactions in a block."
+1. A ratio is much more valuable than a simple metric. It seems clearly
difficult t
>
> What one needs for that, I think, is a library that communicate with the
> node, and which offers functionality abstractly be similar to 'git pull':
> give me the tree path from my current known tip to the best tip, and supply
> the block hashes (and block data) along the way.
>
This is exactl
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 kill us normally used for trades and I think it can be
> >con
Btc Drak 於 2015-09-18 02:42 寫到:
On Fri, Sep 18, 2015 at 4:27 AM, jl2012 via bitcoin-dev
wrote:
Btc Drak 於 2015-09-17 15:12 寫到:
Forgive me if I have missed the exact use-case, but this seems
overly
complex. Surely fill-or-kill refers to getting a transaction
confirmed
within a few confirms or
You're aware that my entire stack was built around this model and I've even
built a fully fledged desktop GUI, multisig account manager, and servers
supporting pull and event subscription atop it, right?
On September 17, 2015 5:07:20 PM PDT, "Wladimir J. van der Laan via
bitcoin-dev" wrote:
>O
I love the weekly meeting idea...but timezones might be an issue.
My general preference would be afternoons to late evenings pacific time, but
that translates to late night/early morning for those in europe.
On September 18, 2015 12:04:58 AM PDT, Jonas Schnelli via bitcoin-dev
wrote:
>-BEG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> On Friday, September 18, 2015 1:07:10 AM Wladimir J. van der Laan
> via bitcoin-dev wrote:
>> At Monday's code sprint we had a good idea to schedule a regular
>> developer meeting in #bitcoin-dev.
>>
>> Attendance is of course voluntary, but it ma
41 matches
Mail list logo
