On 08/16/15 23:22, Andrew LeCody via bitcoin-dev wrote:
Cam, your scenario makes no sense.
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
2. Encourage all miners to false vote for the Bitcoin XT fork.
This would obliterate any confidence in Bitcoin Core.
On Aug 17, 2015 5:29 PM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
From the point of view of a
wallet, it's not very secure to use Hearn-style SPV mode, and volunteers
running full nodes doesn't help things. Sybil attacking the IP address
space is pretty easy in
Dave,
³ highly skilled psychological warfare agents ..²
Paranoia, much?
Or perhaps the ³enemies of Bitcoin are just sitting patiently, waiting for
it to collapse in time due to its internal contradictions.
From: Dave Scotese via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org
Reply-To:
The traffic between the pool server and individual hashers is far busier
than 50kB/30s. If their bandwidth is so limited, hashers would have
switched to other pools already.
All these data may prove is they have very bad mining codes. For
example, their hashers may not be required to update
On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Nobody is going to click that...
I guess I am nobody. Here's a copy of the text:-
*Dynamically Controlled Bitcoin Block Size Max Cap
http://upalc.com/maxblocksize.php*
Am 15.08.2015 um 19:43 schrieb Satoshi Nakamoto via bitcoin-dev:
I have been following the recent block size debates through the mailing list.
I had hoped the debate would resolve and that a fork proposal would achieve
widespread consensus. However with the formal release of Bitcoin XT
Interesting. I am writing down something similar. Will share soon.
Upal Chakraborty via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org
schrieb am Mo., 17. Aug. 2015 um 11:45 Uhr:
I have tried to solve the maximum block size debate, depending on the
previous block size calculation.
Announcing Not-BitcoinXT
https://github.com/xtbit/notbitcoinxt#not-bitcoin-xt
This version can be used to protect the status quo until real technical
consensus is formed about the blocksize.
...real technical consensus...
You mean the bunch of self-proclaimed Bitcoin wizards, who decided
On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
That made it to the news and is now discussed in various places. Could
you please delete Satoshis old email addresses from the list and block
them? Sorry to post this to all members but I
Am 17.08.2015 um 13:44 schrieb Jorge Timón:
On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org
mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
That made it to the news and is now discussed in various places. Could
you please delete Satoshis
It could be laziness but i doubt it, especially when the business is so
competitive and margins ever shrinking.Half a million dollars in revenue mean
little if your running costs are also in the same region.
Also apologies for the bad formatting, outlook must have screwed it up.
EmptyBlock /Time
I have tried to solve the maximum block size debate, depending on the
previous block size calculation.
Requesting for comment - http://upalc.com/maxblocksize.php
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
Nobody is going to click that...
On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
I have tried to solve the maximum block size debate, depending on the
previous block size calculation.
Requesting for comment - http://upalc.com/maxblocksize.php
While Peter Todd's public mention on social media was likely meant to be
disparaging, I'll take the contribution of adding 'data mining' to the
title in future updates of the draft - thank you.
It might be ironic that he posted the remark on Twitter, where his message
will be aggregated and sold
The only bigblock patch you want is actually available here :
https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks
Le lun. 17 août 2015 à 15:16, Tier Nolan via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org a écrit :
One of the comments made by the mining pools is that they won't run
Wouldn't that require a fork that lasts for more than 100 blocks?
On Mon, Aug 17, 2015, 01:43 Peter Todd p...@petertodd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org
I've been sharing a similar solution for the past 2 weeks. I think 2016
blocks is too much of a wait, I think we should look at the mean block size
during the last 60-120 minutes instead and avert any crisis caused by
transactional spikes that could well be caused by organic use of the
network
On 12.08.15 11.45, Jorge Timón via bitcoin-dev wrote:
1) Potential indirect consequence of rising fees.
2) Software problem independent of a concrete block size that needs to
be solved anyway, often specific to Bitcoin Core (ie other
implementations, say libbitcoin may not necessarily share
NxtChg,
In the entire history of Bitcoin we’ve never attempted anything even closely
resembling a hard fork like what’s being proposed here.
Many of us have wanted to push our own hard-forking changes to the protocol…and
have been frustrated because of the inability to do so.
This inability
Or can’t you create a transaction that’s still within the op count and sig ops
limits but is larger than 1MB?
On Aug 17, 2015, at 5:29 AM, Andrew LeCody via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Wouldn't that require a fork that lasts for more than 100 blocks?
On Mon,
On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I haven't run any statistics or simulations, but I'm concerned that the
interplay between the random distribution of transaction arrival and the
random distribution of block times may
Hi,
If you want to write such baseless acusations and inflamatory phrases, please
do it somewhere else. We should have the highest respect for what these people
are doing, and we should try to do something constructive, not waste time with
anger and disrespect.
Nobody should be forced to do
One of the comments made by the mining pools is that they won't run XT
because it is experimental.
Has there been any consideration to making available a version of XT with
only the blocksize changes?
The least experimental version would be one that makes the absolute
minimum changes to core.
We should have the highest respect for what these people are doing, and we
should try to do something constructive, not waste time with anger and
disrespect.
Why, exactly, should I have any respect for what these people are doing (and
supposedly not have any respect for what the other side is
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 that is not being so much focussed on is
Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
Bitcoin
At
http://media.scmagazine.com/documents/127/virtual_currency_rules_31557.pdf,
section 200.3(c)(2) lists consumers that utilize Virtual Currency solely
for the purchase or sale of goods or services or for investment purposes
as Persons [who] are exempt from the licensing requirements.
Who else is
On Mon, Aug 17, 2015 at 10:13 PM, GC slashdevn...@hotmail.com wrote:
Dave,
“ … highly skilled psychological warfare agents ..”
Paranoia, much?
Well, I respect your characterization of it as paranoia, sure. If you
check out the #1 podcast in higher education on podomatic.com, you may find
On Mon, Aug 17, 2015 at 8:37 PM, Oliver Egginger via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Would we discuss his
posting if he would not claim to be Satoshi? There are a lot of smart
people on this list, which publish occasionally quite useful ideas.
I actually learned
Dear Eric,
thank you for sharing your thoughts.
It obviously boils down to political beliefs, not so much technical
arguments. I understand that you are in favor of a guided
decentralization and you are most happily invited to follow this path. I
don't want to be on it. I want total
On Fri, Jun 26, 2015 at 3:47 PM, Tier Nolan tier.no...@gmail.com wrote:
- Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB
minimum)
I don't think is all that interesting to make miners vote on lower
limit. Say the community wants to reduce the size to limit mining
On Mon, Aug 17, 2015 at 7:01 PM, Oliver Egginger bitc...@olivere.de wrote:
Am 17.08.2015 um 18:32 schrieb Jorge Timón:
On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger bitc...@olivere.de wrote:
Am 17.08.2015 um 13:44 schrieb Jorge Timón:
On Aug 17, 2015 1:40 PM, Oliver Egginger via
so you want us to, (i) at the moment of payment decide wether to pay a tx
fee, or to include some data about what the transaction is about...
(ii) and (iii) are out of the question as you'd be forcing people to not
have privacy, which is one of the main reasons people use bitcoin, just
paying like
On Mon, Aug 17, 2015 at 11:51 AM, Oliver Egginger via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
To avoid such discussions.
You seem to be assuming that there is specific reason to believe the
message is unauthentic. This is not the case.
Contrary to other poster's claims, if the
In times of controversy or flamewar on the Linux kernel mailing list,
occasionally fake Linus Torvalds or other spoofed posts would appear. It
is the nature of email. Just ignore it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
By increasing the size of blocks, transaction fees may not be available
to supplement mining revenue and so those who do not have access to cheap
or free power to mine;
why?
wouldn't a bigger block size actually allow for more transactions per
block, therefore more fees to be collected, and the
Did you self-assigned a bip number?
https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki
Anyway, from your document:
The existing (2015) Big Data analysis market is valued at around
$125bn according to market
research firm IDC. As the Bitcoin block chain replaces existing
payment
I should add that in the interest of peace and goodwill, I extend an offer to
both Mike and Gavin to make their grievances heard…but only on the condition
that we make a good effort to avoid misrepresentation and misreading of the
other side’s intentions.
On Aug 17, 2015, at 9:37 AM, Eric
Am 17.08.2015 um 18:32 schrieb Jorge Timón:
On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger bitc...@olivere.de wrote:
Am 17.08.2015 um 13:44 schrieb Jorge Timón:
On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org
Eric,
In the entire history of Bitcoin we've never attempted anything even closely
resembling a hard fork like what's being proposed here.
These concerns are understandable. What's hard to understand is why he, he and
he get to decide what is more risky - hitting the limit or forking for
On Mon, Jun 22, 2015 at 11:32 PM, Ross Nicoll j...@jrn.me.uk wrote:
Potentially daft question, why not use a minimum height? Yes, it's
imprecise, but over an extended period of time they're good enough IMHO.
I'd have to do more careful calculations to confirm, but block 388,000
should be
On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Great, so how about you go tell theymos to stop censoring XT posts and
banning the other side on /r/Bitcoin?
Let users decide what Bitcoin is or isn't.
FWIW,
I don’t think what theymos
Adam,
While greatly appreciating your prior efforts in crypto-ccy RD and
current efforts for Blockstream, its not a plus for your reputation to be
using emotive terms like ³attack², ³fork war and throwing so much FUD
into the developer email channel directly after Eric¹s email.
We would
On Aug 17, 2015, at 8:03 AM, Levin Keller p...@levinkeller.de wrote:
Dear Eric,
thank you for sharing your thoughts.
It obviously boils down to political beliefs, not so much technical
arguments. I understand that you are in favor of a guided decentralization
and you are most
Dude, while it does appear plausible that the box is insecure, is it truly
warranted to jump to any particular conclusion from that alone?
What if all the open ports is just because it is a honey pot?
On Mon, Aug 17, 2015 at 11:41 AM, Jonathan Wilkins via bitcoin-dev
@btc Drak, noted, thanks.
1. Updated - removed reference to self ascribed [104]
https://drive.google.com/file/d/0BwEbhrQ4ELzBX3hCekFRSUVySWs/view?usp=sharing
@Angel Leon
2. Privacy issues are clearly covered.
On Mon, Aug 17, 2015 at 6:48 PM, Btc Drak btcd...@gmail.com wrote:
You
On Mon, Aug 17, 2015 at 7:16 PM, Hector Chu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I suspect we need a better incentive for users to run nodes instead of
relying
On Mon, Aug 17, 2015 at 9:28 PM, Gregory Maxwell via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
enter the mining game. A bit like making P2Pool the one and only pool
allowed on the network.
Thats been suggested, though scalablity reasons make this hard: in the
P2Pool design
Please note there is now a PR for this BIP[1] and also a pull request for
the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
[1] https://github.com/bitcoin/bips/pull/179
[2] https://github.com/bitcoin/bitcoin/pull/6564
___
bitcoin-dev mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17 August 2015 07:49:21 GMT-07:00, BitMinter operator via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I don't think mining pools will immediately make blocks as big as
possible if the hard limit is raised.
Note that XT includes a
On Mon, Aug 17, 2015 at 1:51 PM, Oliver Egginger bitc...@olivere.de wrote:
Am 17.08.2015 um 13:44 schrieb Jorge Timón:
On Aug 17, 2015 1:40 PM, Oliver Egginger via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org
mailto:bitcoin-dev@lists.linuxfoundation.org wrote:
That made it to the news
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The fun thing about this, is you only need 25% of hashing power running
Not-BitcoinXT to screw over the miners running XT, as XT blocks are valid
Bitcoin blocks if they're on a valid Bitcoin chain.
75% upgrade thresholds have a lot of issues...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
There are a few ways: here is my favorite (for the moment).
1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet
Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
This bitcoin-dev list restarted with an empty subscriber list on June
21st, 2015. So whoever posted from sato...@vistomail.com
mailto:sato...@vistomail.com subscribed and verified the address
recently. Do you propose that we manually approve
Hi all,
I previously mentioned in a post that i believe that technically nodes are
capable of handling blocks an order of magnitude larger than the current
blocksize limit, the only missing thing was an incentive to run them. I have
been monitoring the blockchain for the past couple of weeks
54 matches
Mail list logo
