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
Please see the following draft BIP which should decrease the amount of
bytes needed per transaction. This is very much a draft BIP, as the design
space for this type of improvement is large.
This BIP can be rolled out by a soft fork.
Improvements are around 12% for standard one in two out txn,
On Thu, Jul 23, 2015 at 4:57 PM, Milly Bitcoin via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On 7/23/2015 10:30 AM, Jorge Timón via bitcoin-dev wrote:
[4] http://lmgtfy.com/?q=mike+hearn+dictatorl=1
Mike has sincerely said that he would like Bitcoin Core to have a
benevolent
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
Yes that is completely doable for the next crawl, however I am not sure how
much that reflects the behavior bitcoind would see when making connections.
Nodes do not make any attempt to sync with close peers, which is an undesirable
property if you are attempting to be sybil resistant. With some
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
I used Google to establish that there is not already a post from 2015 that
mentions roadmap in the subject line. Such would be a good skeleton for
anyone new to the list (like me).
1. Increase the 7 Tx per second - by increasing block size.
2. Do something about the trend toward centralization.
On 07/23/2015 08:42 PM, Slurms MacKenzie via bitcoin-dev wrote:
From: Eric Voskuil via bitcoin-dev
From our perspective, another important objective of query privacy is
allowing the caller make the trade-off between the relative levels of
privacy and performance - from absolute to
It's worth noting that even massive companies with $30M USD of funding don't
run a single Bitcoin Core node, which is somewhat against the general concept
people present of companies having an incentive to run their own to protect
their own wallet.
Sent: Friday, July 24, 2015 at 4:57 AM
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
You may see much better throughput if you run a few servers around the
globe and test based on closest-by-geoip. TCP throughput is rather
significantly effected by latency, though I'm not really sure what you
should be testing here, ideally.
On 07/23/15 14:19, slurms--- via bitcoin-dev wrote:
On
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
He measured the upload capacity of the peers by downloading from them, or
am I being dumb? :)
2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23 July 2015 10:19:59 GMT-04:00, slurms--- via
That is how I read it as well.
On Thu, Jul 23, 2015 at 12:56 PM Marcel Jamin via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
He measured the upload capacity of the peers by downloading from them, or
am I being dumb? :)
2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-dev
Similar to the Bitcoin Node Speed Test, this is a quick quantitative look at
how the Electrum server software handles under load. The Electrum wallet is
extremely popular, and the distributed servers which power it are all hosted by
volunteers without budget. The server requires a fully indexed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
This does not support the theory that the network has the available
bandwidth for increased block sizes, as in its current state 37% of
The library used isnt open source, so unfortunately not. It shouldnt be too hard to replicate in python-bitcoinlib or bitcoinj though.
Sent:Thursday, July 23, 2015 at 6:55 PM
From:Jameson Lopp jameson.l...@gmail.com
To:slu...@gmx.us
Cc:bitcoin-dev@lists.linuxfoundation.org
Subject:Re:
I have concerns about the performance of the Electrum server software as
well. It seems to load data one block at a time (which normally makes
sense) and I think it is even single threaded on transactions inside the
block.
To try to addresses these issues, I made my own implementation of the
Great data points, but isn't this an argument for improving Electrum Server's
database performance, not for holding Bitcoin back?
(Nice alias, by the way. Whimmy wham wham wozzle!)
On Thursday, 23 July 2015, at 5:56 pm, Slurms MacKenzie via bitcoin-dev wrote:
Similar to the Bitcoin Node Speed
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
Quoting Tier Nolan via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org:
On Thu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
2) Full nodes and SPV nodes following original consensus rules may not be
aware of the deployment of a hardfork.
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
That's purely the time on the wall for electrum-server, validation in bitcoind
happens before. As ThomasV has pointed out it is significantly faster with a
solid state disk (but much more expensive to operate), if we get to that point
it'll only be expensive servers with lots of SSD space which
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 5:23 PM, jl2012 via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
2) Full nodes and SPV nodes following original consensus rules may not be
aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowingly accept devalued
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
This looks like the beginnings of some great analysis.
Per Peter's remarks, I think it would be productive to run the test(s) on a
simulated network with worst case network failure(s) so that we can
determine the safety margin needed.
I have potential access to h/w resources that would be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Does to process into the index include time for transport and/or
block validation (presumably by bitcoind) or this this exclusively the
time for Electrum Server to index a validated block?
e
On 07/23/2015 08:56 AM, Slurms MacKenzie via bitcoin-dev
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,
Thank you a lot for doing this test!
Two questions:
1) A node is typically connected to many nodes that would all in parallel
download said block. In your test you measured how fast new blocks that
presumably are being uploaded in parallel to all those other nodes are being
uploaded? Or did you
I was testing against otherwise idle nodes, fetching blocks back from the tip of the chain in an attempt to eliminate any unfair effects of caching. During the time my crawler was running there was no new blocks on the network (luck more than design), so other than initially syncing nodes and
38 matches
Mail list logo
