Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2015-02-05 Thread Peter Todd
On Wed, Feb 04, 2015 at 02:54:43PM +0100, Isidor Zeuner wrote:
 Hi there,
 
 comments in-line:
 
  I later wrote up the idea in the context of adding Zerocoin to
  Bitcoin:
 
  http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
 
 
 For the sake of maximum clarity with respect to modelling the value of
 a Bitcoin, I don't think that approaches which change the number
 of coins that can possibly be circulated should be encouraged.
 
 So, I like the idea of having the sacrificed coins appearing in the
 mining fees in a future block. But what is meant with OP_DEPTH in this
 context? From what I read, this operation just manipulates the stack
 size when evaluating the script, so I don't see how it would
 affect miner incentives.

Oh, where I was saying OP_DEPTH, I was referring to a *hypothetical*
opcode; I'd forgotten when I wrote that post that OP_DEPTH is an real
opcode.

These days I'd suggest you use the (upcoming on BTC/live on Viacoin)
OP_CHECKLOCKTIMEVERIFY opcode instead. Pretty simple really:

current blockheight + 1 year worth of blocks CHECKLOCKTIMEVERIFY

-- 
'peter'[:-1]@petertodd.org
165ecbd638ec09226f84c34d3d775d34ca5df4abfa8cb57c


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
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

2015-02-04 Thread Isidor Zeuner
Hi there,

comments in-line:

  I later wrote up the idea in the context of adding Zerocoin to
  Bitcoin:
 
  http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
 

For the sake of maximum clarity with respect to modelling the value of
a Bitcoin, I don't think that approaches which change the number
of coins that can possibly be circulated should be encouraged.

So, I like the idea of having the sacrificed coins appearing in the
mining fees in a future block. But what is meant with OP_DEPTH in this
context? From what I read, this operation just manipulates the stack
size when evaluating the script, so I don't see how it would
affect miner incentives.

Best regards,

Isidor

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
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

2014-12-18 Thread Tamas Blummer
Moving further with the Idea:

Alternative to re-adjusting the lottery criteria, the side chain block 
candidate could be required to prove a work to be eligible for the burn 
lottery. 

A mix of required burn, work and luck could be tailored to achieve the desired 
51% resilience” of the side chain. 

The side chain could use work for regular blocks and a much higher “difficulty” 
parent chain burn lottery for less frequent “checkpoints. 

Eg. the side chain difficulty of 1/n of Bitcoin is attainable for a small side 
chain miner community to advance its chain at Bitcoin’s speed. Simultaneously 
the block candidates
would be submitted to a Bitcoin burn lottery with 1/n odds, so the security of 
the side chain roughly equals that of Bitcoin at every successful burn mined 
checkpoint.

Tamas Blummer
Bits of Proof

On Dec 16, 2014, at 1:30 PM, Tamas Blummer ta...@bitsofproof.com wrote:

 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 ta...@bitsofproof.com 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 

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Tamas Blummer
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 cryptocurrenc...@quidecco.de 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=164703151iu=/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

2014-12-16 Thread Alex Mizrahi
  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=164703151iu=/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

2014-12-16 Thread Tamas Blummer
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 ta...@bitsofproof.com 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 corporations, FREE

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2014-12-16 Thread Peter Todd
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=164703151iu=/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

2014-12-15 Thread Tamas Blummer
Burn mining side chains might be one of the foundation ideas for that 
ecosystem, enabling permission-less merge mining for
anyone with interest in a side chain.

I am puzzled by the lack of feedback on the idea.

Tamas Blummer
Bits of Proof


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=164703151iu=/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

2014-12-15 Thread Peter Todd
On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
 Burn mining side chains might be one of the foundation ideas for that 
 ecosystem, enabling permission-less merge mining for
 anyone with interest in a side chain.
 
 I am puzzled by the lack of feedback on the idea.

It's not a new idea actually - I outlined a system I eventually called
zookeyv¹ based on the notion of sacrificing Bitcoins to achieve
consensus a year and a half ago on #bitcoin-wizards. The discussion
started here and continued for a few days:

https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log

I later wrote up the idea in the context of adding Zerocoin to Bitcoin:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html

For key-value mapping I eventually decided that the system didn't
necessarily need to be a strict linear blockchain - a directed acyclic
graph of commitments had advantages as there needed to be less
syncronization between transactions. This also means that the graph
doesn't necessarily need to be revealed directly in the blockchain,
exposing it to miner censorship. OTOH revealing it makes it easy to
determine if an attacker larger than you exists. These days I'd suggest
using timelock crypto to defeat miner censorship, while ensuring that in
principle consensus over all possible parts of the chain can eventually
be reached.²

Proof-of-sacrifice for consensus has a few weird properties. For
instance you can defeat attackers after the fact by simply sacrificing
more than the attacker. Not unlike having a infinite amount of mining
equipment available with the only constraint being funds to pay for the
electricity. (which *is* semi-true with altcoins!)

As for your specific example, you can improve it's censorship resistance
by having the transactions commit to a nonce in advance in some way
indistinguishable from normal transactions, and then making the
selection criteria be some function of H(nonce | blockhash) - for
instance highest wins. So long as the chain selection is based on
cumulative difficulty based on a fixed target - as is the case in
Bitcoin proper - you should get a proper incentive to publish blocks, as
well as the total work information rachet effect Bitcoin has against
attackers.


1) In honor of Zooko's triangle.

2) This doesn't necessarily take as much work as you might expect: you
   can work backwards from the most recent block(s) if the scheme
   requires block B_i to include the decryption key for block B_{i-1}.

-- 
'peter'[:-1]@petertodd.org
18d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c


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=164703151iu=/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

2014-12-15 Thread Tamas Blummer
Peter,

Thanks for the research, I am glad that the idea, that proof-of-burn can 
“transfer proof-of-work 
was discussed earlier, as those discussions give some attack vectors that I can 
reevaluate in 
a new context, that is side chains. 

I think that the lottery component I suggested, makes it much more resilient to 
“outspend” attack, since
the attacker not only needs to outspend but win the lottery for a reorg. This 
raises the cost of the attack
by magnitudes above the regular miner burn cost.

In addition, I suggest the burn transaction to include the Bitcoin block 
height, thereby disabling re-use of a burn,
for a later reorg.

Tamas Blummer
Bits of Proof

On Dec 15, 2014, at 1:39 PM, Peter Todd p...@petertodd.org wrote:

 On Mon, Dec 15, 2014 at 11:21:01AM +0100, Tamas Blummer wrote:
 Burn mining side chains might be one of the foundation ideas for that 
 ecosystem, enabling permission-less merge mining for
 anyone with interest in a side chain.
 
 I am puzzled by the lack of feedback on the idea.
 
 It's not a new idea actually - I outlined a system I eventually called
 zookeyv¹ based on the notion of sacrificing Bitcoins to achieve
 consensus a year and a half ago on #bitcoin-wizards. The discussion
 started here and continued for a few days:
 
 https://download.wpsoftware.net/bitcoin/wizards/2013/05/13-05-29.log
 
 I later wrote up the idea in the context of adding Zerocoin to Bitcoin:
 
 http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
 
 For key-value mapping I eventually decided that the system didn't
 necessarily need to be a strict linear blockchain - a directed acyclic
 graph of commitments had advantages as there needed to be less
 syncronization between transactions. This also means that the graph
 doesn't necessarily need to be revealed directly in the blockchain,
 exposing it to miner censorship. OTOH revealing it makes it easy to
 determine if an attacker larger than you exists. These days I'd suggest
 using timelock crypto to defeat miner censorship, while ensuring that in
 principle consensus over all possible parts of the chain can eventually
 be reached.²
 
 Proof-of-sacrifice for consensus has a few weird properties. For
 instance you can defeat attackers after the fact by simply sacrificing
 more than the attacker. Not unlike having a infinite amount of mining
 equipment available with the only constraint being funds to pay for the
 electricity. (which *is* semi-true with altcoins!)
 
 As for your specific example, you can improve it's censorship resistance
 by having the transactions commit to a nonce in advance in some way
 indistinguishable from normal transactions, and then making the
 selection criteria be some function of H(nonce | blockhash) - for
 instance highest wins. So long as the chain selection is based on
 cumulative difficulty based on a fixed target - as is the case in
 Bitcoin proper - you should get a proper incentive to publish blocks, as
 well as the total work information rachet effect Bitcoin has against
 attackers.
 
 
 1) In honor of Zooko's triangle.
 
 2) This doesn't necessarily take as much work as you might expect: you
   can work backwards from the most recent block(s) if the scheme
   requires block B_i to include the decryption key for block B_{i-1}.
 
 -- 
 'peter'[:-1]@petertodd.org
 18d439a78581d2a9ecd762a2b37dd5b403a82beb58dcbc7c



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=164703151iu=/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

2014-12-15 Thread Isidor Zeuner
 The goal is to have an opportunity cost to breaking the rules.

 Proof of Burn is a real cost for following the rules.


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

--
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=164703151iu=/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

2014-12-11 Thread Isidor Zeuner
[...]
 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.


Miners might decide to block all burn transactions, and other nodes
might decide to stop relaying them. This may be considered as
preferable by all participants who do not want to add more potential
for deflation.

Best regards,

Isidor

--
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=164703151iu=/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

2014-12-11 Thread Tamas Blummer
Isodor: Rational Miner will include burn transaction for fee, no doubt. 
Censoring transactions is against Bitcoin’s core values, unlikely to get wide 
support for any form of that.

Patrick: Mining is at cost even if following the rules. No change to that.

Tamas Blummer
Bits of Proof


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=164703151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development