That's not what I said. We don't seem able to communicate with each other
efficiently, probably my fault since English is not my native language. But
I don't want to use more of my time (or yours) in this discussion, since
it's clearly unproductive.
On Jul 28, 2015 6:45 PM, Tom Harding
On Wed, Jul 22, 2015 at 12:52:20PM -0400, Pieter Wuille via bitcoin-dev wrote:
Hello all,
I'd like to talk a bit about my view on the relation between the Bitcoin
Core project, and the consensus rules of Bitcoin.
I believe it is the responsibility of the maintainers/developers of Bitcoin
https://twitter.com/petertoddbtc
Thanks for the triggering warning, if not for that I may have gone into
seizures.
e
On 07/27/2015 10:05 AM, Alice Larson via bitcoin-dev wrote:
The twitter teenage nonsense from Todd is ridiculous:
https://twitter.com/playatodd (warning, triggering)
Eric Voskuil, Alice Larson, others:
Personal attacks or bullying of any kind are not tolerated on this mailing list.
This list is meant to be a low-volume community for technical proposals and
discussion regarding Bitcoin. See the archive for say, 2012, for example.
What Peter Todd or anyone
On 7/24/2015 2:24 AM, Jorge Timón wrote:
Regarding increasing the exchange rate it would be really nice to
just push a button and double bitcoin's price just before the next
subsidy halving, but unfortunately that's something out of our control.
Jorge, right now, from the activity on github,
On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo elombr...@gmail.com
mailto:elombr...@gmail.com wrote:
Mainstream usage of cryptocurrency will be enabled primarily by direct
party-to-party contract negotiation…with the use of the blockchain primarily
as a dispute resolution mechanism. The
I should also add that I think those who claim that fee pressure will scare
away users and break the industry are *seriously* underestimating human
ingenuity in the face of a challenge. We can do this - we can overcome this
obstacle…we can find good solutions to a fee market. Unless someone can
On Thu, Jul 23, 2015 at 1:52 PM, Eric Lombrozo via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo elombr...@gmail.com wrote:
Mainstream usage of cryptocurrency will be enabled primarily by direct
party-to-party contract negotiation…with
On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Running a node certainly has real-world costs that shouldn't be ignored.
There are plenty of advocates who argue that Bitcoin should strive to keep
it feasible for the average user to run
On Jul 23, 2015, at 4:42 PM, Benedict Chan ben...@fragnetics.com wrote:
Scaling the network will come in the form of a combination of many
optimizations. Just because we do not know for sure how to eventually
serve 7 billion people does not mean we should make decisions on
global
I think it’s pretty clear by now that the assumption that all nodes have pretty
similar computational resources leads to very misplaced incentives. Ultimately,
cryptocurrencies will allow direct outsourcing of computation, making it
possible to distribute computational tasks in an economically
Miners could include their fee tiers in the coinbase, but this is obviously
open to manipulation, with little recourse (unless they are a pool and miners
move away because of it).
In any event, I think that trying out a solution that is both simple and
involves the least number of parties
Doesn't matter.
It's not going to be perfect given the block time variance among other factors
but it's far more workable than guessing whether or not your transaction is
going to end up in a block at all.
jp
On Jul 24, 2015, at 8:53 AM, Peter Todd p...@petertodd.org wrote:
-BEGIN
On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo elombr...@gmail.com wrote:
On Jul 23, 2015, at 11:10 AM, Jameson Lopp jameson.l...@gmail.com wrote:
Larger block sizes don't scale the network, they merely increase how much
load we allow the network to bear.
Very well put, Jameson. And the
On Jul 23, 2015, at 12:35 PM, Gavin Andresen gavinandre...@gmail.com wrote:
There are lots of things we can do to decrease costs, and a lot of things
have ALREADY been done (e.g. running a pruned full node).
I also wanted to point out I fully agree with you that there are still many
On Jul 23, 2015, at 11:10 AM, Jameson Lopp jameson.l...@gmail.com wrote:
Larger block sizes don't scale the network, they merely increase how much
load we allow the network to bear.
Very well put, Jameson. And the cost of bearing this load must be paid for. And
unless we’re willing to
On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
That’s not exactly what’s happened though, is it Cipher? Gavin put forward
20Mb then after analysis and discussion has moved to 8Mb, whereas the other
camp of core developers is
On Thu, Jul 23, 2015 at 7:14 PM, Robert Learney via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
That’s not exactly what’s happened though, is it Cipher? Gavin put forward
20Mb then after analysis and discussion has moved to 8Mb, whereas the other
camp of core developers is firmly
On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I'd really like to move from IMPOSSIBLE because... (electrum hasn't been
optimized
(by the way: you should run on SSDs, LevelDB isn't designed for spinning
disks),
what if the
On Thu, Jul 23, 2015 at 6:17 PM, Tom Harding via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
If the user expectation is that a price would never arise because
supply is going to be increased ad infinitum and they will always
On Thu, Jul 23, 2015 at 1:42 AM, Cory Fields via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I'm not sure why Bitcoin Core and the rules and policies that it
enforces are being conflated in this thread. There's nothing stopping
us from adding the ability for the user to decide what
On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote:
they will simply advance the front and start another battle, because
their true hidden faction is the not ever side. Please,
On Wed, Jul 22, 2015 at 9:52 AM, Pieter Wuille via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Some people have called the prospect of limited block space and the
development of a fee market a change in policy compared to the past. I
respectfully disagree with that. Bitcoin Core
default in case of controversy is no change.
I think the result of this would probably be that no controversial
changes ever get implemented via this process so others will hard fork
the code and eventually make this process irrelevant. Since you need
close to 100% agreement the irrelevance
Jeff I respectively disagree with many of your points, but let me just
point out 2.
Over the last 6 years there may not have been fee pressure, but certainly
there was the expectation that it was going to happen. Look at all the
work that has been put into fee estimation, why do that work if the
On Jul 22, 2015, at 3:01 PM, Mike Hearn he...@vinumeris.com wrote:
Until we’re able to merge blockchain forks like we’re able to merge git repo
forks, the safest option is no fork.
Block chain forks merge in the same way as git forks all the time, that's how
the reorg algorithm works.
So to point out what I consider obvious: if Bitcoin requires central
control over its rules by a group of developers, it is completely
uninteresting to me. Consensus changes should be done using consensus, and
the default in case of controversy is no change.
This is a really interesting
I wouldn't go quite that far. The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:
Quoting BC,
Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or
On Jul 22, 2015, at 2:43 PM, Mike Hearn via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Hi Pieter,
I think a core area of disagreement is this:
Bitcoin Core is not running the Bitcoin economy, and its developers have no
authority to set its rules.
In fact Bitcoin Core
Until we’re able to merge blockchain forks like we’re able to merge git
repo forks, the safest option is no fork.
Block chain forks merge in the same way as git forks all the time, that's
how the reorg algorithm works. Transactions that didn't make it into the
post-reorg chain go back into
If the developers fail to reflect user consensus, the network will let us know.
This is true with the caveat that there must be more than one option present for the network to show it's preference. If developers discourage anything that forks from the rules enforced by Bitcoin Core, they harm the
Hi Pieter,
I think a core area of disagreement is this:
Bitcoin Core is not running the Bitcoin economy, and its developers have
no authority to set its rules.
In fact Bitcoin Core is running the Bitcoin economy, and its developers do
have the authority to set its rules. This is enforced by
I'm not sure why Bitcoin Core and the rules and policies that it
enforces are being conflated in this thread. There's nothing stopping
us from adding the ability for the user to decide what their consensus
parameters should be at runtime. In fact, that's already in use:
./bitcoind -testnet. As
FWIW, I had worked on something similar a while back:
https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf
I like the idea in principle…but we should require a new genesis block,
different magic bytes,
On Jul 22, 2015, at 5:34 PM, Cory Fields li...@coryfields.com wrote:
On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo elombr...@gmail.com wrote:
On Jul 22, 2015, at 5:05 PM, Cory Fields li...@coryfields.com wrote:
On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo elombr...@gmail.com wrote:
On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
It would be irresponsible and dangerous to the network and thus the
users of the software to risk forks, or to take a leading role in
pushing dramatic changes.
Count me among those who see allowing bitcoin to become
On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo elombr...@gmail.com wrote:
On Jul 22, 2015, at 5:05 PM, Cory Fields li...@coryfields.com wrote:
On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo elombr...@gmail.com wrote:
FWIW, I had worked on something similar a while back:
On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo elombr...@gmail.com wrote:
FWIW, I had worked on something similar a while back:
https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
I like the idea in principle…but we should require a new genesis block,
different magic bytes, and a
On Jul 22, 2015, at 5:27 PM, Tom Harding via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On 7/22/2015 9:52 AM, Pieter Wuille via bitcoin-dev wrote:
It would be irresponsible and dangerous to the network and thus the users of
the software to risk forks, or to take a leading
39 matches
Mail list logo
