On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd p...@petertodd.org wrote:
Merge-mined sidechains are not a scaling solution any more than SPV is a
scaling solution because they don't solve the scaling problem for
miners.
Some kind of treechain like sidechain / subchains where what part of the
First of all, I added more info to bitcointalk.org:
https://bitcointalk.org/index.php?topic=1083345.0
On Sat, Jun 13, 2015 at 2:39 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
In your proposal, transactions go to a chain based the addresses involved.
We can reasonably assume that
wrote:
Hi Andrew,
Your belief that Bitcoin has to be constrained by the belief that hardware
will never improve is extremist, but regardless, your concerns are easy to
assuage: there is no requirement that the block chain be stored on hard
disks. As you note yourself the block chain is used
Hi
I briefly mentioned something about this on the bitcoin-dev IRC room. In
general, it seems experts (like sipa i.e. Pieter) are against using
sidechains as a way of scaling. As I only have a high level understanding
of the Bitcoin protocol, I cannot be sure if what I want to do is actually
that (insert some huge block size here)
will be needed to even accommodate the reduced traffic.
I believe that it is definitely over 20MB. If it was determined to be 100
MB ten years from now, that wouldn't surprise me.
Sent from my overpriced smartphone
On May 8, 2015 1:17 PM, Andrew onelinepr
On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier justusranv...@riseup.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/2015 02:02 PM, Andrew wrote:
The nice thing about 1 MB is that you can store ALL bitcoin
transactions relevant to your lifetime (~100 years) on one 5 TB
On Fri, May 8, 2015 at 2:59 PM, Alan Reiner etothe...@gmail.com wrote:
This isn't about everyone's coffee. This is about an absolute minimum
amount of participation by people who wish to use the network. If our
goal is really for bitcoin to really be a global, open transaction network
I'm mainly just an observer on this. I mostly agree with Pieter. Also, I
think the main reason why people like Gavin and Mike Hearn are trying to
rush this through is because they have some kind of apps that depend on
zero conf instant transactions, so this would of course require more
traffic on
. Another side effect is that miners
would have a bigger economy of scale. The more stake a miner has, the
more they can endorse their own blocks and not others blocks. I
recommend reading this: https://download.wpsoftware.net/bitcoin/pos.pdf
-Andrew Lapp
I've read this and it looks A-OK to me.
Andrew
On Tue, Jan 20, 2015 at 07:35:49PM -0500, Pieter Wuille wrote:
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability
an attack.
Well, even in the absense of a reorganization, the attacker's false proof
will just be invalidated by a proof of longer work on the real chain.
And there is still a real cost to producing the false proof.
--
Andrew Poelstra
Mathematics Department, University of Texas at Austin
Email
My node (based in Dallas, TX) has about 240 connections and is using a
little under 4 Mbps in bandwidth right now.
According the hosting provider I'm at 11.85 Mbps for this week, using 95th
percentile billing. The report from my provider includes my other servers
though.
On Mon, Apr 7, 2014 at
Well, not sure I wanted to subscribe the mbtc vs ubtc list... its a
default, not a big deal.
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
/nissim.pdf
[2] A General Model for Authenticated Data Structures
Martel, Nuckolls, Devanbu, Michael Gertz, Kwong, Stubblebine. 2004
http://truthsayer.cs.ucdavis.edu/algorithmica.pdf
--
Andrew Miller
--
Live Security
to desire this! I am
indeed assuming that the tree will be incrementally constructed
according to the canonical (blockchain) ordering of transactions, and
that the balancing rules are agreed on as part of the protocol.
--
Andrew Miller
15 matches
Mail list logo