Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 bleep bloop Peter Todd: > On Fri, Dec 12, 2014 at 01:41:34PM +, odinn wrote: >> Peter... It kind of sounds to me that (as fine of a position >> paper as this is) on _certain_ points, you're falling prey to the >> "but it's inefficient, but it's a scamcoin, but luke-jr told me >> so" argument... > > I prefer to make robust arguments; if I can start with accepting > that 95% of what my opponents say is true, yet still end up being > correct, all the better! > >> I think the Mastercoin devs are doing fine work and I consider >> the zerocash devs to have developed (in v2, mint and pour) to >> have developed something that will really turn the world on its >> ear, but what do I know? Nothing. Nothing at all. > > My personal opinion is that what Mastercoin has started will turn > the world on its ear, but I'd be surprised if the succesful > implementations of the underlying ideas come from that team. But > there's nothing surprising about that - when was the last time you > used Netscape Navigator, let alone NCSA Mosaic? > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJUkNluAAoJEGxwq/inSG8CKy0IAJmCUmDbaCx33/km0J2mP7ha kxX3fxiPpicD8hXa4FXBsrYqj7ZFu0OmFOU/ei0AXMOuu94rQdIp6hon3f5GO73J WVT2Toqd2GTCXhmddyqtOzZ5mYOyZhlJUYlNjbwTmlk+U2hQbZC1aJ4AKdmjQn5v 9DFkZfqBSsNhcoLCKoVqY3l4qzw0XqeL6fOYkz2H9AssWdcUV9JB5C0wm8rI70AX qcxABgrKDwhThWgHyHGZXHLCvRRpMUFFVbzO67BPZA2R+gXYtOAVDozl7jdx7PLl x3nyzZK3pX1bqcT2T5fD8wQtu4yJ3RCBVWzHfrA5MF6q4Yh6DEh7DnO8ccOnPlk= =1os7 -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] ACK NACK utACK "Concept ACK"
Would someone also clarify the use of "nit" for nitpicking and how it plays in the role of consensus? It seems like it's used for minor complaints/preferences. Drak On Wed, Dec 10, 2014 at 3:52 PM, Jeff Garzik wrote: > > On Wed, Dec 10, 2014 at 1:47 AM, Wladimir wrote: > >> Concept ACK -> agree with the idea and overall direction, but haven't >> reviewed the code changes nor tested it >> > > Concept ACK -> like the idea; the code may need rewriting (or haven't > reviewed). > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Setting the record straight on Proof-of-Publication
Peter provides an excellent summary of Proof of Publication, which starts with defining it as being composed of a solution to the double spend problem. He requires Proof-of-receipt (proof every member of p in audience P has received a message m), Proof-of-non-publication (proof a message m has not been published to an audience P), and Proof-of-membership (proof some q is a member of P). He goes on to state (curiously) that Factom cannot provide Proof of Publication. Proof of Audience = Let's first satisfy the easier proofs. A Factom user can know they are in the Factom audience if they have access to the Bitcoin Blockchain, knowledge of Factom's first anchor (Merkle root stored in the blockchain) and the Factom network for distributing Factom's structures. They can pretty much know that they are in the Audience. Proof of Receipt Proof of receipt is also pretty easy for the Factom user. User submit entries, and Factom publishes a Merkle Root to the Bitcoin Blockchain. The Merkle proof to the entry proves receipt. To get the Merkle proof requires access to Factom structures, which all in the audience have access to by definition. But the proof itself only requires the blockchain. At this point the user can have a Merkle proof of their entry rooted in the blockchain. Proof of non-publication == Last, can the Factom user have a Proof-of-non-publication. Well, absolutely. The Factom state limits the public keys that can be used to write the anchors in the blockchain. Entries that are not written with those public keys are discounted out of hand. Just like publishing in Mad Magazine does not qualify if publishing a notice in the New York Times is the standard. The complaint Peter has that the user cannot see all the "child chains" (what we call Factom Chains) is invalid. The user can absolutely see all the Directory Blocks (which documents all Factom Chains) if they have access to Factom. But the user doesn't need to prove publication in all chains. Some of those chains are like Car Magazines, Math Textbooks, Toaster manuals, etc. Without restricting the domain of publication there is no proof of the negative. The negative must be proved in the standard of publication, i.e. the user's chain. And the user can in fact know their chain, and can enumerate their chain, without regard to most of the other data in Factom. Peter seems to be operating under the assumption that the audience for a Factom user must necessarily be limited to information found in the blockchain. Yet the user certainly should have access to Factom if they are a Factom user. Factom then is no different from the New York Times, and the trust in Factom is less. As Peter says himself, he has to trust the New York Times doesn't publish multiple versions of the same issue. The user of the New York Times would have no way to know if there were other versions of an issue outside of looking at all New York Times issues ever published. Factom on the other hand documents their "issues" on the blockchain. Any fork in publication is obvious as it would require different Bitcoin addresses to be used, and the blocks would have to have validating signatures of majorities of all the Factom servers. As long as a fork in Factom can be clearly identified, and no fork exists, proof of the negative is assured. And upon a fork, one must assume the users will specify which fork should be used. Proof of publication does not require a system that cannot fork, since no such non-trivial system exists. What is required is that forks can be detected, and that a path can be chosen to move forward. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Open development processes and reddit charms
Thank you Jeff.
Having looked at a lot of linux code, and now a lot of bitcoin code, the
biggest long-term systemic risk I see is that Bitcoin has is the lack of
code janitors.
The problem is that janitoring was *disruptive* for non-x86 linux architectures
when it first got going, and it's going to be very disruptive for bitcoin as
well, but it **needs** to happen.
The code is too complex and hard to follow as it is now. (now, I could just
be speaking because I haven't paid the social debt of looking at the latest
bitcoin code, including libconsensus), but there really needs to be a focus
on readability, maintainability, and (as much as I hate to say it) a rather
hard-line policy on coding standards.
I don't care which tabbing style or column width you pick, but **pick one**,
and enforce it across the entire codebase.
Maybe this should be bitcoin-stable, and bitcoin-devel, with a 6-9 month
social expectation of minimal cosmetic changes in -stable, with a 1 month
'merge window' where -devel turns into -stable.
On Tue, Dec 16, 2014 at 12:59:06PM -0500, Jeff Garzik wrote:
> It can be useful to review open source development processes from time to
> time. This reddit thread[1] serves use both as a case study, and also a
> moment of OSS process introduction for newbies.
> [1]
> http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/
>
>
>
>
> *Dirty Laundry*
> When building businesses or commercial software projects, outsiders
> typically hear little about the internals of project development. The
> public only hears what the companies release, which is prepped and
> polished. Internal disagreements, schedule slips, engineer fistfights are
> all unseen.
>
> Open source development is the opposite. The goal is radical
> transparency. Inevitably there is private chatter (0day bugs etc.), but
> the default is openness. This means that is it normal practice to "air
> dirty laundry in public." Engineers will disagree, sometimes quietly,
> sometimes loudly, sometimes rudely and with ad hominem attacks. On the
> Internet, there is a pile-on effect, where informed and uninformed
> supporters add their 0.02 BTC.
>
> Competing interests cloud the issues further. Engineers are typically
> employed by an organization, as a technology matures. Those organizations
> have different strategies and motivations. These organizations will
> sponsor work they find beneficial. Sometimes those orgs are non-profit
> foundations, sometimes for-profit corporations. Sometimes that work is
> maintenance ("keep it running"), sometimes that work is developing new,
> competitive features that company feels will give it a better market
> position. In a transparent development environment, all parties are
> hyperaware of these competing interests. Internet natterers painstakingly
> document and repeat every conspiracy theory about Bitcoin Foundation,
> Blockstream, BitPay, various altcoin developers, and more as a result of
> these competing interests.
>
> Bitcoin and altcoin development adds an interesting new dimension.
> Sometimes engineers have a more direct conflict of interest, in that the
> technology they are developing is also potentially their road to instant
> $millions. Investors, amateur and professional, have direct stakes in a
> certain coin or coin technology. Engineers also have an emotional stake in
> technology they design and nurture. This results in incentives where
> supporters of a non-bitcoin technology work very hard to thump bitcoin.
> And vice versa. Even inside bitcoin, you see "tree chains vs. side chains"
> threads of a similar stripe. This can lead to a very skewed debate.
>
> That should not distract from the engineering discussion. Starting from
> first principles, Assume Good Faith[2]. Most engineers in open source tend
> to mean what they say. Typically they speak for themselves first, and
> their employers value that engineer's freedom of opinion. Pay attention to
> the engineers actually working on the technology, and less attention to the
> noise bubbling around the Internet like the kindergarten game of grapevine.
> [2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
>
> Being open and transparent means engineering disagreements happen in
> public. This is normal. Open source engineers live an aquarium life[3].
> [3] https://www.youtube.com/watch?v=QKe-aO44R7k
>
>
>
>
> *What the fork?*
> In this case, a tweet suggests consensus bug risks, which reddit account
> "treeorsidechains" hyperbolizes into a dramatic headline[1]. However, the
> headline would seem to be the opposite of the truth. Several changes were
> merged during 0.10 development which move snippets of source code into new
> files and new sub-directories. The general direction of this work is
> creating a "libconsensus" library that carefully encapsulates consensus
> code in a manner usable by external projects. This is a good thing.
>
> The d
[Bitcoin-development] Open development processes and reddit charms
It can be useful to review open source development processes from time to
time. This reddit thread[1] serves use both as a case study, and also a
moment of OSS process introduction for newbies.
[1]
http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/
*Dirty Laundry*
When building businesses or commercial software projects, outsiders
typically hear little about the internals of project development. The
public only hears what the companies release, which is prepped and
polished. Internal disagreements, schedule slips, engineer fistfights are
all unseen.
Open source development is the opposite. The goal is radical
transparency. Inevitably there is private chatter (0day bugs etc.), but
the default is openness. This means that is it normal practice to "air
dirty laundry in public." Engineers will disagree, sometimes quietly,
sometimes loudly, sometimes rudely and with ad hominem attacks. On the
Internet, there is a pile-on effect, where informed and uninformed
supporters add their 0.02 BTC.
Competing interests cloud the issues further. Engineers are typically
employed by an organization, as a technology matures. Those organizations
have different strategies and motivations. These organizations will
sponsor work they find beneficial. Sometimes those orgs are non-profit
foundations, sometimes for-profit corporations. Sometimes that work is
maintenance ("keep it running"), sometimes that work is developing new,
competitive features that company feels will give it a better market
position. In a transparent development environment, all parties are
hyperaware of these competing interests. Internet natterers painstakingly
document and repeat every conspiracy theory about Bitcoin Foundation,
Blockstream, BitPay, various altcoin developers, and more as a result of
these competing interests.
Bitcoin and altcoin development adds an interesting new dimension.
Sometimes engineers have a more direct conflict of interest, in that the
technology they are developing is also potentially their road to instant
$millions. Investors, amateur and professional, have direct stakes in a
certain coin or coin technology. Engineers also have an emotional stake in
technology they design and nurture. This results in incentives where
supporters of a non-bitcoin technology work very hard to thump bitcoin.
And vice versa. Even inside bitcoin, you see "tree chains vs. side chains"
threads of a similar stripe. This can lead to a very skewed debate.
That should not distract from the engineering discussion. Starting from
first principles, Assume Good Faith[2]. Most engineers in open source tend
to mean what they say. Typically they speak for themselves first, and
their employers value that engineer's freedom of opinion. Pay attention to
the engineers actually working on the technology, and less attention to the
noise bubbling around the Internet like the kindergarten game of grapevine.
[2] http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
Being open and transparent means engineering disagreements happen in
public. This is normal. Open source engineers live an aquarium life[3].
[3] https://www.youtube.com/watch?v=QKe-aO44R7k
*What the fork?*
In this case, a tweet suggests consensus bug risks, which reddit account
"treeorsidechains" hyperbolizes into a dramatic headline[1]. However, the
headline would seem to be the opposite of the truth. Several changes were
merged during 0.10 development which move snippets of source code into new
files and new sub-directories. The general direction of this work is
creating a "libconsensus" library that carefully encapsulates consensus
code in a manner usable by external projects. This is a good thing.
The development was performed quite responsible: Multiple developers would
verify each cosmetic change, ensuring no behavior changes had been
accidentally (or maliciously!) introduced. Each pull request receives a
full multi-platform build + automated testing, over and above individual
dev testing. Comparisons at the assembly language level were sometimes
made in critical areas, to ensure zero before-and-after change. Each
transformation gets the Bitcoin Core codebase to a more sustainable, more
reusable state.
Certainly zero-change is the most conservative approach. Strictly speaking,
that has the lowest consensus risk. But that is a short term mentality.
Both Bitcoin Core and the larger ecosystem will benefit when the "hairball"
pile of source code is cleaned up. Progress has been made on that front in
the past 2 years, and continues. *Long term*, combined with the
"libconsensus" work, that leads to less community-wide risk.
The key is balance. Continue software engineering practices -- like those
just mentioned above -- that enable change with least consensus risk. Part
of those practices is review at each step of the development process:
social media thought bubble, mailing list post, pull request, git merge,
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
On Tue, Dec 16, 2014 at 11:55:50AM +0200, Alex Mizrahi wrote: > Usually at this point people say "we assume that miners aren't going to > collude, otherwise even Bitcoin is not secure". > Well, this is BS. The fact that a pool can acquire more than 50% of total > hashpower was successfully demonstrated by ghash.io. > But the thing is, Bitcoin doesn't offer one a good way to attack the whole, > as there are powerful factors which will work against the attacker. > But this is not the case with sidechains (or any merged-mined chains, for > that matter). > And once you have a clear incentive, collusion is much more likely. +1 It's notable that blockstream hasn't published much if anything concrete on what exactly you'd use merge-mined sidechains for; they're even worse than Ethereum in that regard. > > Proof of Burn is a real cost for following the rules. > > > > So what? As long as cost is less than revenue, it is OK. It's even better than that: if an attack does happen, the participants in the consensus system have an incentive to defend against it to maintain the value of their tokens. Proof-of-burn allows that defense to be in response to a threat, and essentially unlimited in size. So now any attacker knows that if they launch an attack in theory the response could be as strong as the value of the system itself. This can be improved upon with systems that allow the tokens to be burned, "internal" proof-of-burn. This suffers from "nothing-at-stake" vulnerabilities to an extent, OTOH within the context of the system it is a true sacrifice of value; probably not a big deal in a zookeyv-style block-DAG where multiple lines of history can be combined. Here the incentives of the defenders are even more strongly tipped towards burning their value to preserve the system, not unlike replace-by-fee-scorched-earth thinking. -- 'peter'[:-1]@petertodd.org 0e0c078667795abe21bfdebb913eba60cc7a625c732f0a89 signature.asc Description: Digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Let me be more concrete in implementation details: 1) burn transaction sends at least n satoshis to an OP_RETURN h, 2) h mod m matches the bitcoin block hash mod m, for the block the burn transaction was mined into. 3) The side chain block header hashes to h and also contains the bitcoin block hight. 4) a side chain block releases x new side coins Since the burn hash does not reveal in advance which side chain it will be used for, the Bitcoin miner can not selectively block burn mining. They will include loosing bets for the Bitcoin fee. Bitcoin miner have no advantage over independent burn miner of the side chain. Anyone who issues a burn transaction that complies the rules 1-3 has 1/m the chance to win the next block on the side chain. This implies a fair exchange rate of n*m satoshis = x side coins (at the margin). Should two burn transactions fulfill the mod m lottery criteria, then we have a competing fork on the side chain. Just as for Bitcoin, the next block(s) will pick the winner. To contain fork rate, the parameter m would have to be adjusted dynamically, similar to Bitcoins difficulty. It needs to increase if fork rate increases and decrease if no valid block is burned with Bitcoin blocks. Unfortunately SPV can only prove the existence of a transaction, but not the non-existence of an alternative. Therefore the fork rate within a block cycle can not be evaluated with SPV proofs. Rational burn miner who frequently faces and loses head-to-head runs with a competing forks would increase his bet for the next burn cycle, as increasing the individual bet amount has the advantage that if he wins his victory is more stable. Remember the side chain trunk is selected as the one with highest cumulative burn. Consequently cumulative burn within an adjustment period (measured in Bitcoin blocks) is expected to rise in face of high fork rate. If the sample period burn exceeds a target, then it would trigger a rise to the lottery criteria m, reducing the fork rate and vs. Tamas Blummer Bits of Proof On Dec 10, 2014, at 8:35 AM, Tamas Blummer wrote: > > We spend scarce resources external to the digital realm to create Bitcoin. > Real world sacrifice is needed to avoid “nothing at stake” and sybil > attacks. With Bitcoin we now have a scarce resource within the digital realm, > so it appeals my intuition to re-use it for sacrifice instead of linking > again an external, real world resource. > > In following I outline a new mining algorithm for side chains, that burn > Bitcoins to secure them. > > The side chain block validity rules would require that a transaction on the > Bitcoin block chain provably destroys Bitcoins with an OP_RET output, that > contains the hash of the block header of the side chain. To also introduce a > lottery, the burn transaction’s hash is required to satisfy some function of > the block hash it was included in on the Bitcoin block chain. For example > modulo m of the burn transaction hash must match modulo m of the block hash, > that is not known in advance. > > Those who want to mine the side chain will assemble side chain block > candidates that comply the rules of the side chain, then a Bitcoin > transaction burning to the hash of the block candidate and submit it to the > Bitcoin network. Should he burn transaction be included into the Bitcoin > block chain and the Bitcoin block’s hash satisfy the lottery criteria, then > the block candidate can be submitted to extend the side chain. > > A side chain block header sequence would be accepted as side chain trunk if a > sequence of Bitcoin SPV proofs for burn transactions prove, that linked > blocks have the highest cumulative burn, if compared to alternative > sequences. > > The Bitcoin miner will include burn transactions because they offer Bitcoin > fees. Bitcoin miner can not selectively block side chains since the hashes > associated with the burn do not disclose which side chain or other project > they are for. Here you have a “merged mining” that does not need Bitcoin > miner support or even consent. > > Mining difficulty of the side chain could be adjusted by stepping up the > required burn and/or hardening the criteria that links a burn proof > transaction with the bitcoin block hash it is included in. > > The difficulty to mine with burn would be dynamic and would also imply a > floating exchange rate between Bitcoin and the side coin. > > Tamas Blummer > Bits of Proof > > 1172380e63346e3e915b52fcbae838ba958948ac9aa85edd signature.asc Description: Message signed with OpenPGP using GPGMail -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corpo
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
> The goal is to have an opportunity cost to breaking the rules. > You could as well have said "The goal is to implement it in a specific way I want it to be implemented." This makes zero sense. You aren't even trying to compare properties of different possible implementations, you just outright reject the alternatives. So the thing is, relying on opportunity cost is rather problematic. 1. can't work when system isn't heavily used (you'll have to rely on the honesty of miners instead) 2. chicken-and-egg: system is not secure until it is heavily used, and it isn't heavily used until it is secure 3. finally, if the expected profit from attack is higher than the opportunity cost of it, it just makes no sense Let's put 1 and 2 aside. For the start, you need to prove that attack cannot yield profits which are higher than honest mining. The problem with it is that the total amount of money is much higher than the amount of money which is being transacted in a short time frame. And it is much higher than what fees might yield within a reasonable time frame. So if there is a way to attack the whole (with a profit proportional to the whole), you won't be able to rely on opportunity cost to prevent the attack. Usually at this point people say "we assume that miners aren't going to collude, otherwise even Bitcoin is not secure". Well, this is BS. The fact that a pool can acquire more than 50% of total hashpower was successfully demonstrated by ghash.io. But the thing is, Bitcoin doesn't offer one a good way to attack the whole, as there are powerful factors which will work against the attacker. But this is not the case with sidechains (or any merged-mined chains, for that matter). And once you have a clear incentive, collusion is much more likely. > Proof of Burn is a real cost for following the rules. > So what? As long as cost is less than revenue, it is OK. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
The output has to be burned otherwise there is no cost of expressing any number of alternate opinions the same time. Tamas Blummer Bits of Proof On Dec 15, 2014, at 3:55 PM, Isidor Zeuner wrote: > For every participant who could try to decide about the adequateness > of the cost, no direct effect comes from the difference between Proof > of Burn, and approaches which keep the Bitcoins inside the set of > outputs that can still participate. So, any notion which > differentiates with respect to this must make some assumption about > what defines the interest of the Bitcoin nodes as a community. > > Best regards, > > Isidor > signature.asc Description: Message signed with OpenPGP using GPGMail -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
