All,
We are looking for participants in a Bitcoin related competition: the aim
is to build a trading platform (initially for foreign exchange, other
assets will follow) which lets participants settle their trades through the
blockchain via coloured coins. To facilitate a quicker trade
reconciliati
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, for example.
It seems more
While I would like to get some form of explicit acknowledgment from
miners that a new rule is in effect, the truth of the matter is we
still lack a means to determine whether or not miners are actually
enforcing these rules...unless someone happens to mine a block that
breaks the new rule. Th
Good points, Greg.
The way I see it, this mechanism isn't really about "voting" - it's
about deployment of fairly uncontroversial changes with the minimum
amount of negative disruption. If we have reason to believe a particular
BIP stands little chance of hitting the 95% mark relatively quickl
"Wladimir J. van der Laan via bitcoin-dev"
writes:
> On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote:
>
>> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> There appears to be common agreement on that.
>
> The only source of some controversy is how to deploy: versionbi
On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell wrote:
> Hi all,
>
> Pieter and Eric pointed out that the current BIP has miners
> turning off the bit as soon as it's locked in (75% testnet / 95%
> mainnet). It's better for them to keep setting the bit until activation
> (2016 blocks later
Tom Harding via bitcoin-dev
writes:
> On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
>> '''Success: Activation Delay'''
>> The consensus rules related to ''locked-in'' soft fork will be enforced in
>> the second retarget period; ie. there is a one retarget period in
>> which the remai
Hi all,
Pieter and Eric pointed out that the current BIP has miners
turning off the bit as soon as it's locked in (75% testnet / 95%
mainnet). It's better for them to keep setting the bit until activation
(2016 blocks later), so network adoption is visible.
I'm not proposing another sugg
On Tue, Sep 29, 2015 at 8:07 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> What happened years ago is not really relevant as Bitcoin has changed and
>> the stakeholders have expanded. What is relevant is the actual
>> description. Whatever you want to discus
Since 2011 and bitcoin-development, the list was always intended to
focus on the highly technical bits of the core software, and avoid
wandering into never-ending philosophical discussions. Example:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-June/thread.html
What happened years
On Tue, Sep 29, 2015 at 7:16 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote:
>
>> Making statements about a developer's personal character is also
>> off-topic for this list.
>>
>
> If that were true the
On 9/29/2015 7:02 PM, Jonathan Toomim (Toomim Bros) wrote:
Making statements about a developer's personal character is also off-topic for
this list.
If that were true then probably 20-30% of the posting here would be
off-topic. lol.
Russ
___
bi
Making statements about a developer's personal character is also off-topic for
this list.
On Sep 29, 2015, at 3:58 PM, Milly Bitcoin via bitcoin-dev
wrote:
> On 9/29/2015 5:07 PM, Jeff Garzik via bitcoin-dev wrote:
>> This is off-topic for this list.
>
> You like to go around pretending you a
On 9/29/2015 5:07 PM, Jeff Garzik via bitcoin-dev wrote:
This is off-topic for this list.
You like to go around pretending you are in charge and telling people
what to do. You have no such authority and your time is probably better
spent reviewing your company's Bitcoin handling and security
ACK
On Thu, Sep 24, 2015 at 7:25 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello all,
>
> The next major release of Bitcoin Core, 0.12.0 is planned for the end of
> the year. Let's propose a more detailed schedule:
>
> 2015-11-01
> ---
This is off-topic for this list.
On Sun, Sep 27, 2015 at 1:53 PM, Neil Haran via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
>
> I have an idea for a gamified bitcoin mining app that I'd like to partner
> with someone on that is very good with cryptography and knows the bi
On Mon, Sep 28, 2015 at 10:16 PM, Dave Scotese via bitcoin-dev
wrote:
> Why are they called soft forks when they are really hidden forks? Isn't the
> point of a soft fork to prevent old clients from rejecting what they don't
> have the code to validate? That seems dangerous.
As an aside, this l
On Sun, Sep 27, 2015 at 02:50:31PM -0400, Peter Todd via bitcoin-dev wrote:
> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
There appears to be common agreement on that.
The only source of some controversy is how to deploy: versionbits versus
IsSuperMajority. I think the versionbits proposal sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello, (see my remarks below)
jl2012 via bitcoin-dev:
> Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫
> 到:
>> SPV clients will appear to behave normally, and will continue to
>> show new transactions and get confirmations in a t
>I started this thread as a sanity check on myself, because I keep seeing
smart people saying that two chains could persist for more than a few days
after a hard fork, and I still don't see how that would possibly work.
When you start with the assumption that anyone who disagrees with you is
insan
On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev
wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
> On 29 Sep 2015, at 19:29, Mike Hearn via bitcoin-dev
> wrote:
>
> There's a simple way to cut down on "noise" that doesn't involve people
> shouting OFFTOPIC at each other: the maintainer needs to resolve discussions
> by making decisions and saying, this is how Core does it.
Looks like yo
>
> Mining empty blocks is not fraud.
>
I didn't say it was, sorry, the comma was separating two list items. By
"fraud" I meant double spending. Mining only empty blocks would be a DoS
attack rather than double spending.
___
bitcoin-dev mailing list
bitc
We really shouldn't have to go over "Bitcoin 101" on this mailing list, and
this discussion should move to the not-yet-created more general discussion
list. I started this thread as a sanity check on myself, because I keep
seeing smart people saying that two chains could persist for more than a
fe
>A dishonest miner majority can commit fraud against you, they can mine
only empty blocks, they can do various other things that render your money
worthless.
Mining empty blocks is not fraud.
If you want to use terms like "honest miners" and "fraud", please define
them so we can at least be on th
>
> >because Bitcoin's basic security assumption is that a supermajority of
> miners are 'honest.'
>
> Only if you rely on SPV.
>
No, you rely on miners honesty even if you run a full node. This is in the
white paper. A dishonest miner majority can commit fraud against you, they
can mine only empt
>If you start with the premise that more than half of Bitcoin miners would
do something crazy that would either destroy Bitcoin or would be completely
unacceptable to you, personally... then maybe you should look for some
other system that you might trust more, because Bitcoin's basic security
assu
On Tue, Sep 29, 2015 at 1:24 PM, Allen Piscitello <
allen.piscite...@gmail.com> wrote:
> I fail to see how always following a majority of miners no matter what
> their actions somehow equates to insanity.
Ok, I have a hidden assumption: I assume most miners are also not
completely insane.
I hav
There's a simple way to cut down on "noise" that doesn't involve people
shouting OFFTOPIC at each other: the maintainer needs to resolve
discussions by making decisions and saying, this is how Core does it. If
you disagree, go make/join a fork because there's no point in discussing
this any further
You're entire argument seems to be based on this assumption.
>I support the 95% chain (because I'm not insane)
I fail to see how always following a majority of miners no matter what
their actions somehow equates to insanity.
On Tue, Sep 29, 2015 at 9:04 AM, Gavin Andresen via bitcoin-dev <
bitc
This mailing list was never meant to be a place "to hold the bitcoin
development community accountable for its actions [sic]." I know other
developers that have switched to digest-only or unsubscribed. I know if
this became a channel for PR and populist venting as you describe, I would
leave as wel
I'm not intending to completely dismiss your concerns but as a data point: I
read this list daily and it usually takes 15 minutes or less while I drink a
cup of coffee.
My concern is that this is one of the (maybe *the*) last uncensored persisted
forums related to technical bitcoin discussion w
Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫到:
SPV clients will appear to behave normally, and
will continue to show new transactions and get confirmations in a
timely fashion. However, they will be systematically susceptible to
attack from double-spends that attempt to spen
This was discussed in IRC, but (did I miss it?) never made it to the list
outside of being buried in a longer summary.
There is a common complain that bitcoin-dev is too noisy. The response
plan is to narrow the focus of the list to near term technical changes to
the bitcoin protocol and its impl
> So I'll repeat the question that I posed before - given that there are clear,
> explicit downsides,
> what is the purpose of doing things this way? Where is the gain for ordinary
> Bitcoin users?
+1 for a direct answer to this question.
___
bitcoin-d
You don't need to appeal to human psychology. At 75% threshold, it takes
only 25.01% of the hashpower to report but not actually enforce the fork to
cause the majority hashpower to remain on the old chain, but for upgraded
clients to start rejecting the old chain. With 95% the same problem exists
b
At the 95% threshold, I don't think it would happen unless there was a very
strong motivating factor, like a small group believing that CLTV was a
conspiracy run by the NSA agent John Titor to contaminate our precious bodily
fluids with time-traveling traveler's cheques.
At the 75% threshold, I
I keep seeing statements like this:
On Tue, Sep 29, 2015 at 9:30 AM, Jonathan Toomim (Toomim Bros) via
bitcoin-dev wrote:
> As a further benefit to hard forks, anybody who is ideologically opposed
> to the change can continue to use the old version successfully, as long as
> there are enough min
On Sep 28, 2015, at 7:43 AM, Peter Todd via bitcoin-dev
wrote:
>
> Ok, so again, if that's your security criteria, what's the issue with
> soft-forks? With soft-forks, the result of a SPV wallet following the
> highest work chain is the same: eventually invalid blocks are reorged
> out.
>
> H
There seemed to be some agreement on IRC - after a bit of haranguing by
myself :) -- that large refactors should (a) occur over a small window of
time and (b) have a written plan beforehand.
On Tue, Sep 22, 2015 at 7:49 PM, Dave Scotese
wrote:
> If I'm reading this situation correctly, Jeff is
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't explain why this would make any difference to how fast miners
>
> Other than the fact that doing this as a soft fork requires an extra
> OP_DROP, how would doing this as a hard fork make any difference to SPV
> clients? If, as others have suggested, all clients warn the user on
> unrecognized nVersion
>
All clients do *not* do this. Why would they? What acti
42 matches
Mail list logo