Wait, why did Bitcoin-XT use that nVersion???
Definitely option 3 is much cleaner technically, and it would be nice to have
that code implemented, but I'd be rather concerned about the size of the fork
ballooning. It's already four separate features in one fork, which seems pretty
big, even if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/19/2015 04:06 AM, Jorge Timón wrote:
On Wed, Aug 19, 2015 at 12:14 PM, odinn
odinn.cyberguerri...@riseup.net wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
Firstly, XT is controversial, not uncontroversial;
XT it's just a
On 19 August 2015 at 13:44, Jameson Lopp jameson.l...@gmail.com wrote:
It's possible to check that a transaction is cryptographically valid without
having any blockchain data available; are you referring to a different type
of validation?
It seems laborious to enumerate all the validations
On 19 August 2015 at 12:42, Jameson Lopp jameson.l...@gmail.com wrote:
If you can actually come up with a technical solution that allows for a node
operator to prove to the rest of the network that they are running an honest
full node that hosts the entire blockchain, then you can move forward
If operating as an SPV node then it can check the transactions by querying
other nodes.
On an unrelated note, it sounds like your proposal will significantly
increase the data size of every transaction, which will create even more
contention for block space.
- Jameson
On Wed, Aug 19, 2015 at
On Wed, Aug 19, 2015 at 7:15 AM, Hector Chu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Bitcoin is imploding due to a failure of consensus. There has been a
failure of consensus on how to fix the design flaw evinced by the block
size fiasco.
I disagree, but this isn't a
1.) Most people are running XT as a vote for bigger blocks and not because
they specifically support BIP101. If Core supported bigger blocks, most XT
users would switch back to Core and XT would die.
2.) In this high stakes game of poker, XT just went all in, but Core still
has the far better
4.) Investors hate uncertainty, and the blocksize issue is adding a lot
of uncertainty right now, ...
That is true VC investors and people starting companies. People who
invest directly in Bitcoin love all this stuff.
A few weeks back a bunch of stories quoting nonsense spouted by Bitcoin
odinn via bitcoin-dev 於 2015-08-19 07:25 寫到:
The big problem is
BIP101 being deployed as a Schism hardfork.
This is certainly a problem.
No, BitcoinXT won't become a Schism hardfork, or may be just for a few
days, at most.
There is one, and only one scenario that BitcoinXT will win:
As jl2012 indicated, this is an insufficient analysis.
You cannot assume that because X time passed since the last block, the
miner's internal block maker has updated the template, and from there, is
shipped out to the hashers in the field. Further, even if you update the
block template at time
On Wed, Aug 19, 2015 at 1:25 PM, odinn odinn.cyberguerri...@riseup.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/19/2015 04:06 AM, Jorge Timón wrote:
On Wed, Aug 19, 2015 at 12:14 PM, odinn
odinn.cyberguerri...@riseup.net wrote:
-BEGIN PGP SIGNED MESSAGE- Hash:
On Wed, Aug 19, 2015 at 4:22 PM, jl2012 via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Will the adoption of BitcoinXT lead by miners? No, it won't. Actually,
Chinese miners who control 60% of the network has already said that they
would not adopt XT. So they must not be the
The code was peer reviewed, in the XT project. I didn't bother submitting
other revisions to Core, obviously, as it was already rejected.
The quantity of incorrect statements in this thread is quite ridiculous.
___
bitcoin-dev mailing list
Hello Jorge, Eric,
With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
_very_ important to highlight some things. I am neither for the
On Wed, Aug 19, 2015 at 10:22:32AM -0700, Simon Liu via bitcoin-dev wrote:
Olivier Janssens claims that one of your colleagues is asking for Gavin
to be removed from his position. Is this true?
On 19/08/2015 09:24, Ken Friece via bitcoin-dev wrote:
5.) Not-BitcoinXT is a really terrible idea. Mike has proven time and time
again that he will not blink or back down. The chances of Not-BitcoinXT
gaining 25% of the hashrate are pretty much nil, so in effect, all
Not-BitcoinXT will do is
I think, keeping the reduction part is necessary to have it demand driven.
Otherwise, we could just increase it to a fixed size. If the max cap is
high, but there is not enough Tx in the mempool, then after one big block
many will go small. This will not be good when block reward become small
and
On Wed, Aug 19, 2015 at 4:45 PM, Mike Hearn via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
The code was peer reviewed, in the XT project. I didn't bother submitting
other revisions to Core, obviously, as it was already rejected.
The quantity of incorrect statements in this thread
Gavin has been very clear about the fact that he's on vacation. I'm not sure
what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks
are out for him so there isn't really anything he can possibly say which will
be constructively received on this highly adversarial and
On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd p...@petertodd.org wrote:
Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
other users' comments on their own pull-reqs...
IMO that's an abuse of the pull-req process, and in turn, Gavin
Andresens's commit access rights for the
On Aug 19, 2015, at 12:12 PM, Santino Napolitano via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Gavin has been very clear about the fact that he's on vacation. I'm not sure
what you want Mike to say. It's obvious the Bitcoin Core developer pitchforks
are out for him so
Alex,
With all due respect, right now the biggest challenge facing Bitcoin is not
technical but political. I would love to see this list go back to technical
discussions, but unfortunately, until this political stuff is resolved, even
technical discussion is purely philosophical as there’s
On Wed, Aug 19, 2015 at 7:30 PM, Danny Thorpe danny.tho...@gmail.com wrote:
How do big-block testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and -addnode
another 2MB block testnet node (say, JornC's node) to it, and my
On Wed, Aug 19, 2015 at 3:20 PM, Jeff Garzik jgar...@gmail.com wrote:
bitcoin-dev for protocol discussion and bitcoin-core for Bitcoin Core
discussion?
Well -dev or both, I dont particularly see a difference at the moment,
and establishing two lists isnt really going to make a difference so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
re. Gavin and commit access
On 08/19/2015 12:15 PM, Btc Drak via bitcoin-dev wrote:
On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd p...@petertodd.org
wrote:
Normal GitHub users submitting pull-reqs to Bitcoin Core can't
delete other users' comments
This is a message that I wrote and had hoped that all the core devs would
sign on to, but I failed to finish organizing it. So I'll just say it from
myself.
There has been a valuable discussion over the last several months regarding
a hard fork with respect to block size. However the sheer
Unfortunately, I think that from a PR angle, removing Gavin from commit
privileges right now will probably play into his hand. Sadly.
Say what you will regarding Gavin and Mike’s technical merits, they’ve been
quite clever on the PR front. Framing this issue as “obstructionism from the
core
On Wed, Aug 19, 2015 at 9:48 PM, Eric Lombrozo via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
[...]
core devs” and relying on the fact that many people out there can’t seem to
tell the difference between a source code fork and a blockchain fork.
And this is precisely why we
On Wed, Aug 19, 2015 at 11:25 PM, Gary Mulder via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
So guys, do we need a BIP to address the existence of XT and its possible
impact to the block chain?
I believe there is BIP99 that addresses hard forks.
[cross-posted to libbitcoin]
On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote: On Wed, Aug
19, 2015 at 10:04 PM, Eric Lombrozo elombr...@gmail.com wrote:
But the consensus code should NOT be subject to the same commit
policies…and we should make an effort to separate the two clearly.
On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote:
Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.
Actually
By the way, now that I remember why I subscribed to the libbitcoin
list I want to share it with you.
I met Amir Taaki in person in a spanish hackmeeting and had the chance
to talk a lot with him, very interesting person whose input in this
blocksize matter I would greatly appreciate. He explained
Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.
Adam
On 19 August 2015 at 15:28, Jorge Timón
bitcoin-dev@lists.linuxfoundation.org
Yes, you're right, the Bitcoin Foundation is facing many challenges, but
that's an entirely different discussion.
The question in hand is this: was the request to remove Gavin made by an
individual of their own volition, reflecting their own personal opinion,
or was it made on behalf of the
On Thu, Aug 20, 2015 at 12:25 AM, Gary Mulder via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
So guys, do we need a BIP to address the existence of XT and its possible
impact to the block chain?
The potential impacts of Schism/controversial/contentious hardforks
are shortly covered
On Thu, Aug 20, 2015 at 1:07 AM, Eric Voskuil e...@voskuil.org wrote:
[cross-posted to libbitcoin]
On 08/19/2015 03:00 PM, Jorge Timón via bitcoin-dev wrote: On Wed, Aug
19, 2015 at 10:04 PM, Eric Lombrozo elombr...@gmail.com wrote:
But the consensus code should NOT be subject to the same
So guys, do we need a BIP to address the existence of XT and its possible
impact to the block chain?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Wed, Aug 19, 2015 at 11:27 PM, Joseph Poon joseph@lightning.network wrote:
On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev
wrote:
If anyone feels strongly about this, please speak up.
On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n
And this is why I love Bitcoin, politics + technical = all in one.
Regards,
Theo Chino
https://www.facebook.com/groups/557495624389384 (politics in NYS about
bitcoin.)
http://frenchmorning.com/en/2014/08/18/french-robin-hood-bitcoin-new-york
On Wed, Aug 19, 2015 at 5:19 PM, Hector Chu via
Nelson,
Talking politics, Devs do day and night, however politics is also about
knocking on door and not sitting behind a keyboard writing a perl script to
spam the politicians with the same content. Politics is about maneuvering
to be in a position to get the elected official to do what you want
On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev
wrote:
If anyone feels strongly about this, please speak up.
On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n
bitcoin-dev@lists.linuxfoundation.org wrote:
I repeated my nit on
On Wed, Aug 19, 2015 at 4:51 PM, Theo Chino via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
And this is why I love Bitcoin, politics + technical = all in one.
If you think developers do not talk politics go read LKML... Politics are
inevitable.
I think the I don't know enough to
On Wed, Aug 19, 2015 at 10:04 PM, Eric Lombrozo elombr...@gmail.com wrote:
But the consensus code should NOT be subject to the same commit policies…and
we should make an effort to separate the two clearly. And we should find a
way to communicate the difference succinctly and clearly to
On Wed, Aug 19, 2015 at 5:41 PM, s7r s...@sky-ip.org wrote:
Hello Jorge, Eric,
With all this noise on the -dev mail list I had to implement application
level filters so I can treat with priority posts from certain people,
you are on that list. While I agree with your arguments, I think it is
On Thu, Aug 20, 2015 at 1:44 AM, NxtChg via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Number of posts, August:
72, Jorge Timón
Certainly I have talked to much this month, my apologies.
I believe most of my posts (if not all) were on-topic but I could
still had repeated
Can this anecdote and similar be removed from the mailing list.
Possibly one of the reddits is a better place for this kind of thing.
On 20/8/15 7:56 am, Jorge Timón via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
By the way, now that I remember why I subscribed to the libbitcoin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Firstly, XT is controversial, not uncontroversial;
Second, this issue has been beat to death quite a while ago
https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117
815987
Third, it poses major risks as a non-peer reviewed alt with
On Wed, Aug 19, 2015 at 11:58 AM, Btc Drak btcd...@gmail.com wrote:
On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón jti...@jtimon.cc wrote:
Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
But technical people run away from noise while non-technical people
chase them
On Wed, Aug 19, 2015 at 12:14 PM, odinn odinn.cyberguerri...@riseup.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Firstly, XT is controversial, not uncontroversial;
XT it's just a software fork.
BIP101 (as currently implemented in Bitcoin XT) is a Schism hardfork
(or an altcoin),
I don't think just using version=4 for cltv and friends would be a
problem if it wasn't for the XT/nonXT issue.
On Wed, Aug 19, 2015 at 12:20 PM, Btc Drak btcd...@gmail.com wrote:
On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón
bitcoin-dev@lists.linuxfoundation.org wrote:
Seems like 3 is
I repeated my nit on https://github.com/bitcoin/bips/pull/179
On Mon, Aug 17, 2015 at 9:58 PM, Btc Drak via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Please note there is now a PR for this BIP[1] and also a pull request for
the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
On Wed, Aug 19, 2015 at 12:34 PM, jl2...@xbt.hk wrote:
You misunderstand my intention. The experiment is not about a random
hardfork. It's about a block size increase hardfork.
One of your goals is show the world that reaching consensus for a
Bitcoin hardfork is possible, right?
BIP99 can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Recently I was re-reading the following (which has been edited
periodically):
https://bitcoin.org/en/alerts
It currently reads, There is no ongoing event on the Bitcoin network.
However, in reading the most recent alert on that page, we are (it
We can use nVersion 0x8 to signal support, while keeping the consensus
rule as nVersion = 4, right? That way we don't waste a bit after this all
clears up.
On Aug 18, 2015 10:50 PM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Deployment of the proposed CLTV, CSV,
On Tue, Aug 18, 2015 at 11:46 AM, NxtChg via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Eric,
FWIW...
These are all good points and I agree with most of them. Yes, the block size
debate is a lucky historical accident, which makes it easier for XT to pull
off the split, but
On Wed, Aug 19, 2015 at 9:59 AM, Jorge Timón jti...@jtimon.cc wrote:
Apparently that existed already: http://sourceforge.net/p/bitcoin/mailman/
But technical people run away from noise while non-technical people
chase them wherever their voices sounds more loud.
Regarding disruptors, if
On Mon, Aug 17, 2015 at 1:02 AM, Cameron Garnham via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I think that it is important to note that Bitcoin XT faces a natural
uphill battle.
Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could
On Wed, Aug 19, 2015 at 10:25 AM, Btc Drak via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I see no problem with Satoshi returning to participate in peer review.
Bitcoin development has long since migrated from a single authority figure
to a system of technical peer review
On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
As I understand, there is already a consensus among core dev that block size
should/could be raised. The remaining questions are how, when, how much, and
how fast. These are the questions for
On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Ya, so? All that means is that the experiment might reach the hard fork
tipping point faster than mainnet would. Verifying that the network can
handle such transitions, and how larger
60 matches
Mail list logo
