-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
s
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, C
Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
mine blocks with nVersion=0x2007, which would falsely trigger the
previously suggested implementation using the IsSuperMajority()
mechanism and nVersi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Potentially relevant...
"Incentivizing the running of full nodes"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-June/006028
.html
(However, the issue to which I referred here is now closed)
View whole thread:
https://lists.linuxfoun
I created a small website which show a chart of your approvals about
various BIPs (which you must fill by yourself with a signed pgp message)
For each BIP, you can fill if you approve or not, and give comments. (HTML
accepted, so you can link stuff you your posts)
It would help the community a lo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Agreed.
On 08/17/2015 07:36 AM, Adam Back via bitcoin-dev wrote:
> Thank you Eric for saying what needs to be said.
>
> Starting a fork war is just not constructive and there are
> multiple proposals being evaluated here.
>
> I think that one thing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tier ~
I don't think the XT author(s) are going to do what you are
describing. Their recent release, at
https://github.com/bitcoinxt/bitcoinxt/blob/0.11A/README.md
doesn't show any sign of moving toward a version which would be
"increasing consensus.
"How then to end this XT madness?"
Instead of bashing on someone that has actually put a solution forward,
make your own fork and see if your ideas on how to solve the issue are any
better.
As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
block increase every day that pas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The "XT Fork" (better said, a POS alt*) and those behind it make not
even a pretense to work through process involved with bitcoin developmen
t.
(*This is not intended as a slight toward any other alts, as here in
this post I am focusing solely on XT.
As an aside, combining reward halving with block size limit doubling would have
probably been a good idea :)
> On Aug 18, 2015, at 3:51 PM, Ahmed Zsales via bitcoin-dev
> wrote:
>
> -> You need to take into account the reward halving, likely to be in 3Q2016.
> Forks and reward halving at the
On Tue, Aug 18, 2015 at 06:36:45PM -0700, Peter Todd via bitcoin-dev wrote:
> is false. However, in the common scenario of a firewalled node, where
> the operator has neglected to explicitly set -listen=0, the code does
> still download the Tor exit node list, revealing the true location of
> the n
On Wed, Aug 19, 2015 at 1:36 AM, Peter Todd via bitcoin-dev
wrote:
> tl;dr: Yes, Bitcoin XT has a privacy problem with the automatic Tor exit
> node list download.
It's not a bug, it's a feature: These concerns and others were
specifically called out when we rejected this submission to Bitcoin
Co
On Tue, Aug 18, 2015 at 09:08:01PM -0400, Christophe Biocca via bitcoin-dev
wrote:
> So I checked, and the code described *does not* run when behind a
> proxy of any kind, including tor:
>
> https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23#diff-11780fa178b655
So I checked, and the code described *does not* run when behind a
proxy of any kind, including tor:
https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23#diff-11780fa178b655146cb414161c635219R265
At least based on my admittedly weak understanding of how the intern
You are absolutely correct! My apologies for the oversight in editing. If
you could dig up the link though that would be really helpful.
On Tue, Aug 18, 2015 at 6:04 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Aug 18, 2015 at 02:22:10AM +0100, Thomas K
Just to add some superfluous and unessential spice to this discussion,
there were two Satoshi users originally registered in sourceforge, one
registered very soon after the other. So I say Satoshi were at least two
people, so it may be the case that one Satoshi re-appeared, but the other
did not.
On Tue, Aug 18, 2015 at 02:22:10AM +0100, Thomas Kerin via bitcoin-dev wrote:
> ==Acknowledgements==
>
> Mark Friedenbach for designing and authoring the reference
> implementation of this BIP.
>
> Thomas Kerin authored this BIP document.
IIRC Gregory Maxwell came up with the actual idea in ques
First of all I would like to say... LOL
Second Andrew LeCody is correct, this is off topic.
On 08/18/2015 04:31 PM, F L via bitcoin-dev wrote:
> Bitcoin XT contains an unmentioned addition which periodically
> downloads lists of Tor IP addresses for blacklisting, this has
> considerable privacy i
This should probably be posted on the BitcoinXT mailing-list, as Bitcoin
Core does not currently include this feature.
On Tue, Aug 18, 2015 at 6:36 PM F L via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Bitcoin XT contains an unmentioned addition which periodically downloads
> l
Bitcoin XT contains an unmentioned addition which periodically downloads
lists of Tor IP addresses for blacklisting, this has considerable privacy
implications for hapless users which are being prompted to use the
software. The feature is not clearly described, is enabled by default,
and has a swit
-> You need to take into account the reward halving, likely to be in
3Q2016. Forks and reward halving at the same time would possibly be a bad
combination.
-> The original proposed date for the fork was December 2015. It was pushed
back to January as December is a busy period for a lot of people a
On 08/18/2015 03:31 AM, Tamas Blummer via bitcoin-dev wrote:
> The performance of libconsensus is surprisingly close to the java one.
...
> Another nice demonstration why one should not trade in advances
> of languages for the last decades for a marginal gain of performance
> with C/C++...
If per
Again, I'm not suggesting further testing in sterile environments. I'm
suggesting testing on the public global testnet network, so that real-world
hazards such as network lag, bandwidth constraints, traffic bottlenecks,
etc can wreak what havoc they can on the proposed implementation. Also, a
tes
People have already been testing big blocks on testnets.
The biggest problem here isn’t whether we can test the code in a fairly sterile
environment. The biggest problem is convincing enough people to switch without:
1) Pissing off the other side enough to the point where regardless of who wins
I agree with the simplicity of this approach and with removing the
reduction step... it's unlikely the block size would ever need to be
reduced, only increased with demand?
I like this solution better than either kicking the can, or raising the
block size based on chain height (another dynamic sol
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 blocks affect the network, is the
point of testing.
And when I refer to testnet, I mean the public global testnet
And this is how the powers that be compromise bitcoin. They can't stop
TCP/IP, but they sure can take over the development team. It's a good thing
that no one from the CIA has had any conversations with anyone from the
bitcoin development team. Phew...
On Tue, Aug 18, 2015 at 11:57 AM, Oliver Egg
I like the simplicity of this approach. Demand driven response.
Is there really a need to reduce the max block size at all? It is just a
maximum limit, not a required size for every block. If a seasonal
transaction surge bumps the max block size limit up a notch, what harm is
there in leaving t
Problem is if you know most of the people running the testnet personally (as is
pretty much the case with many current testnets) then the deployment amounts to
“hey guys, let’s install the new version”
> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev
> wrote:
>
> Deploying experime
Deploying experimental code onto the "live" bitcoin blockchain seems
unnecessarily risky. Why not deploy a blocksize limit experiment for long
term trials using testnet instead?
On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> As I underst
Sounds like a much better approach than arbitrary deciding what the
block size should be
BR
Le 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit :
Regarding:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
I am arguing with the following statement he
Am 18.08.2015 um 11:15 schrieb Warren Togami Jr.:
> I honestly don't understand your position, but I get the sense that you
> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
> active in development again?
Who am I? Personally I have zero objection if the creator steps in. I
I’m 100% in favor of attempting a hard fork using a far less controversial, far
less risky consensus rule change. We should stop wasting our energy arguing
over stuff we don’t really know and understand and can’t predict very well -
and we should especially avoid using a highly contentious chang
Pull request submitted: https://github.com/bitcoin/bitcoin/pull/6571
Regards,
Cory
On Tue, Aug 18, 2015 at 1:25 PM, Cory Fields wrote:
> See responses inline.
>
> On Tue, Aug 18, 2015 at 6:31 AM, Tamas Blummer wrote:
>> Thanks a lot Cory for following through the test case and producing a patch
I'm no authority on the subject, but I don't understand why there is a max
block-size, other than anti-spam measures.
The only other reason I have heard for a max-block-size is to force people
into paying higher fees.
This seems like the wrong way to force fees. If you want to force fees,
then d
See responses inline.
On Tue, Aug 18, 2015 at 6:31 AM, Tamas Blummer wrote:
> Thanks a lot Cory for following through the test case and producing a patch.
>
> I confirm that libconsensus is now running stable within the Bits of Proof
> stack,
> in-line with test cases we use to verify the java im
Regarding:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
I am arguing with the following statement here...
*I see problems to this approach. The biggest one I see is that a miner
> with 11% of hash power could sabotage block size increases by only ever
> mining e
A smaller block size would make this a soft fork, as unupgraded nodes would
consider the new blocks valid. It would only make things that were allowed
forbidden, which is the definition of a soft fork. For a hard fork, you
need to allow something that was previously invalid.
On Tuesday, August 18,
My interpretation is that he's saying Satoshi wouldn't be welcome to return
as Satoshi, because whatever he did/said would inevitably end up being
treated with authority, which shouldn't be the case.
On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation
Thanks a lot Cory for following through the test case and producing a patch.
I confirm that libconsensus is now running stable within the Bits of Proof
stack,
in-line with test cases we use to verify the java implementation of the script
engine,
that are BTW borrowed from Bitcoin Core.
The perf
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 the coming Bitcoin
Scalability Workshops but immediate consensus in these issues are not
guaranteed.
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 that's not the point.
The point is, the split _must_ happen because the centralized governance of
Bitcoin
I honestly don't understand your position, but I get the sense that you are
suggesting Satoshi wouldn't be welcome to return if he wanted to be active
in development again?
Warren
On Aug 17, 2015 1:38 PM, "Oliver Egginger" wrote:
> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
> > This bitco
43 matches
Mail list logo
