-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Grosses me out that you have enforced KYC as part of what you are
doing for anyone who would decide to get involved:
https://wiki.lykkex.com/?id=start#lykke_citizens
Good luck with that, I'm sure not going to be a part of it, and I
recommend that n
I am waiting for the bitcoin (not bitcoin-dev) mailing list so that anyone
who writes "That's off-topic" can also include a link to it.
Someone else mentioned that they read all these emails in about 15
minutes. I'm a bit slower than that, but I'm reading the vitcoin-xt stuff
too. It isn't too m
I can go along with making it optional but recommended for the first deployment
and making it mandatory later on. It would be purely informational for
now...but it will give us valuable data.
As has been said before, most of these BIP deployments will likely be
accompanied by recommended defaul
Gregory Maxwell writes:
> I can, however, argue it the other way (and probably have in the
> past): The bit is easily checked by thin clients, so thin clients
> could use it to reject potentially ill-fated blocks from non-upgraded
> miners post switch (which otherwise they couldn't reject without
On Wed, Sep 30, 2015 at 10:14 PM, Jorge Timón
wrote:
> reason you don't think guaranteed eventual consistency has any value
Obligatory pedantic correction: In Bitcoin we don't actually achieve
"eventual consistency" of the kind which is usually described in the
literature. In Bitcoin the probabil
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
Adam Back writes:
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing. For example in relation to versionBits Gavin
> said he'd be willing to update XT with an updated/improved
> versionBits
John Winslow via bitcoin-dev
writes:
> Two observations from a Bitcoin investor and non-programmer:
Please take this off the -dev list.
Thanks,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/
On 9/29/2015 7:05 PM, Rusty Russell wrote:
Tom Harding via bitcoin-dev
writes:
With a simple delay, you can have the embarrassing situation where
support falls off during the delay period and there is far below
threshold support just moments prior to enforcement, but enforcement
happens anyway.
On Wed, Sep 30, 2015 at 10:17 PM, Jeff Garzik wrote:
> It is correct that security is slightly reduced for full nodes that have not
> upgraded. It is not correct that the choice is binary, full node or SPV.
>
> Any user running a not-upgraded full node still retains protection against
> many atta
On Wed, Sep 30, 2015 at 9:01 PM, Mike Hearn wrote:
> I coined the term SPV so I know exactly what it means, and bitcoinj
The term comes from the Bitcoin whitepaper.
> On the other hand, full nodes all claim they run scripts. Users expect that
> and may be relying on it. The unstated assumption h
On Wed, Sep 30, 2015 at 3:56 PM, Mike Hearn wrote:
> Field experience shows it successfully delivers new features to end users
>> without a global software upgrade.
>>
>
> The global upgrade is required for all full nodes in both types. If a full
> node doesn't upgrade then it no longer does what
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
>
> 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 and upgrades. This was happening for weeks after
P2SH trigge
tl;dr Nothing I have read here has changed my mind. There is still no
consensus to deploy CLTV in this way.
> Yes, your article contained numerous factual and logical inaccuracies
> which I corrected
>
I responded to your response several times. It was not convincing, and I do
not think you corr
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 5:11 PM, Mike Hearn wrote:
> Hi Gregory,
>
>>
>> I'm surprised to see this response
>
>
> Why? I have objected to the idea of soft forks many times. I wrote an entire
> article about it in August.
Yes, your article contained numerous factual and logical inaccuracies
which
>
> Field experience shows it successfully delivers new features to end users
> without a global software upgrade.
>
The global upgrade is required for all full nodes in both types. If a full
node doesn't upgrade then it no longer does what it was designed to do; if
the user is OK with that, they
On Wed, Sep 30, 2015 at 1:11 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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
Two observations from a Bitcoin investor and non-programmer:
1) I think it's possible that those who are adamantly opposed to a soft
fork may be largely (if not completely) correct on purely technical
terms, but that they also may be underestimating the risk of a
contentious hardfork.
2) The
Right; In general, the consensus is to decouple from Bitcoin Core releases.
On Wed, Sep 30, 2015 at 1:57 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via
> bitcoin-dev wrote:
> > 2015-12-01
On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev
wrote:
>> Have I missed a proposal to change BIP101 to be a real hardfork
>
> There's no such thing as a "real" hard fork - don't try and move the goal
> posts. SPV clients do not need any changes to do the right thing with BIP
> 101, they
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 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
On Thursday, September 24, 2015 11:25:56 AM Wladimir J. van der Laan via
bitcoin-dev wrote:
> 2015-12-01
> ---
> - Feature freeze
Where is "Consensus freeze"? Shouldn't this be put off until after the HK
workshop in case a hardfork is decided on? Or have we de-coupled it from the
releas
I was talking about the versionBits from Rusty's email (pasted below) and
simplifying that by XT adopting the patch as Gavin had seemed agreeable to.
Adam
Rusty wrote:
> Agreed. Unfortunately, a simple "block version >= 4" check is
> insufficient, due to XT which sets version bits 001111.
>
Hi Gregory,
> I'm surprised to see this response
Why? I have objected to the idea of soft forks many times. I wrote an
entire article about it in August. I also objected in April 2014, for
instance, where Pieter agreed with me that soft forks can result in ugly
hacks, and that they are "not nic
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 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'
Hi Richard,
its great that people with a lot of experience in financial markets take
interest in these topics. I don't think you will receive the best answers
here. The Bitcointalk Altcoin section is currently the best place for such
announcements. I believe there is room for a better board/list f
Lykke Corp based in Zürich funds the competition.
2 Mio Lykke coins (8'000 USD) is allocated to funding core development in next
3 months,
Richard
> On 30.09.2015, at 14:22, Thomas Kerin wrote:
>
> Who is funding this?
>
> Why not fund Core development?
>
>> On 30 Sep 2015 7:37 am, "Richard
This sounds like a cool competition; it is also off-topic for this mailing
list, which is focused on bitcoin protocol and reference implementation
development.
On Wed, Sep 30, 2015 at 2:37 AM, Richard Olsen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> All,
>
> We are looking
>
> I think from discussion with Gavin sometime during the montreal
> scaling bitcoin workshop, XT maybe willing to make things easy and
> adapt what it's doing.
If Core ships CLTV as is, then XT will have to adopt it - such is the
nature of a consensus system.
This will not change the fact that
Who is funding this?
Why not fund Core development?
On 30 Sep 2015 7:37 am, "Richard Olsen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> All,
>
> We are looking for participants in a Bitcoin related competition: the aim
> is to build a trading platform (initially for foreign
On 9/30/2015 3:16 AM, Eric Lombrozo via bitcoin-dev wrote:
I've also got a competition where the object is to build a spaceship
using only a watermelon, two donkeys, some duct tape, and a fire hydrant.
There are many people interested in starting new services and who are
interested in hiring d
I've also got a competition where the object is to build a spaceship
using only a watermelon, two donkeys, some duct tape, and a fire
hydrant.
-- Original Message --
From: "Richard Olsen via bitcoin-dev"
To: "bitcoin-dev"
Sent: 9/29/2015 11:37:07 PM
Subject: [bitcoin-dev] Design Com
36 matches
Mail list logo
