incentive to validate the children not by merge mining, but by collecting
fees from the children for putting those transactions inside (fees that can
be spent at the children chains). So, ya no merge mining needed for my
proposal. But I will think about it a bit more :)
On Tue, Jun 16, 2015 at 6:43
On Tue, Jun 16, 2015 at 6:17 PM, Peter Todd 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
> tree miners ca
ually,
rusty asked this on #bitcoin-wizards last night and no one was able to
answer it.
On Mon, Jun 15, 2015 at 6:00 PM, Andrew wrote:
> Pieter: I kind of see your point (but I think you're missing some key
> points). You mean just download all the headers and then just verify the
>
Pieter: I kind of see your point (but I think you're missing some key
points). You mean just download all the headers and then just verify the
transactions you filter out by using their corresponding merkle trees,
right? But still, I don't think that would scale as well as with the tree
structure I
Hi All,
I talked with Pieter off-list. And I guess the main opposition is that
coins that are coming from chains that you are not directly validating are
not fully validated by you in the sense that you only get an SPV type proof
to prove that miners have accepted those coins. Yes, it's true, but
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
wrote:
>
> In your proposal, transactions go to a chain based the addresses involved.
> We can reasonably assume that different people's wallet wil
Hello Adam
First of all, thank you for inventing hashcash, which is basically what
bitcoin is!
Some people have said that my proposal, subject line "Scaling Bitcoin with
Subchains" is essentially the idea of blockchain extensions. Though, I
think there is quite a difference between what I propose
in my opinion.
On Mon, May 25, 2015 at 6:15 PM, Mike Hearn 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 t
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
defin
On Sat, May 9, 2015 at 12:53 PM, Justus Ranvier
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 on
t; be a critical part for the overall scalability of the network. I was
>> actually trying to make the point 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
On Fri, May 8, 2015 at 2:59 PM, Alan Reiner 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
> that makes money
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
We (Joseph Bonneau, myself Arvind Narayanan, Jeremy Clark, Ed Felten,
Josh Kroll -- from Stanford, Maryland, Concordia, Princeton) have
written a “systemization” paper about Bitcoin-related research. It’s
going to appear in the Oakland security conference later this year
(IEEE Security and Privacy)
ward that is paid to "endorsers". 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.wpso
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
lar to double-spending, attacker doesn't need to own coins to perform
> 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 fals
otherwise inhibited from relaying.
I would go so far as to say that any UI which suggests otherwise (e.g.
offering a "cancel" feature which does not involve respending inputs or
that makes any guarantees about being effective) is dangerously broken.
--
Andrew Poelstra
Mathematics
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 1
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
is triggering your intuition 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
roceedings/sec98/full_papers/nissim/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
22 matches
Mail list logo
