[Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Evan Duffield]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

Hello,

We’re a startup looking for 1 or 2 really good C++ programmer that is
familiar with the bitcoin internals to help with a for-profit startup.

We will be able to provide more information about the project after signing
a non-compete/non-disclosure agreement. Our coin will be one of the truly
unique coins that are not just a clone of the original Bitcoin code. In
short the project will be a merge-mined altcoin that will provide a very
useful service to the whole crypto-coin ecosystem.

If you have added any features to Bitcoin or related technologies this is a
definite bonus. Please include information about the work you’re done in
the space.

We have detailed plans on how to implement it and the roles we are looking
to fill. If interested please email eduffield82@gmail.com with a
description of your work experience and we’ll vett the applications and
share our plans to see if you’re interested.

Thanks,

Evan & Kyle
Hawk Financial Group, LLC

[-- Attachment #2: Type: text/html, Size: 4084 bytes --]

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

I'm not sure where you got the idea that Bitcoin-development was ideal for hiring scamcoin developers, but it's not. Most of the people on this list are smart enough to realize posts like this are dumb ideas backed by greedy "entrepreneurs" who don't understand the system they're trying to improve 99.9% of the time.


Evan Duffield <eduffield82@gmail.com> wrote:
>Hello,
>
>We’re a startup looking for 1 or 2 really good C++ programmer that is
>familiar with the bitcoin internals to help with a for-profit startup.
>
>We will be able to provide more information about the project after
>signing
>a non-compete/non-disclosure agreement. Our coin will be one of the
>truly
>unique coins that are not just a clone of the original Bitcoin code. In
>short the project will be a merge-mined altcoin that will provide a
>very
>useful service to the whole crypto-coin ecosystem.
>
>If you have added any features to Bitcoin or related technologies this
>is a
>definite bonus. Please include information about the work you’re done
>in
>the space.
>
>We have detailed plans on how to implement it and the roles we are
>looking
>to fill. If interested please email eduffield82@gmail.com with a
>description of your work experience and we’ll vett the applications and
>share our plans to see if you’re interested.
>
>Thanks,
>
>Evan & Kyle
>Hawk Financial Group, LLC
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>
>organizations don't have a clear picture of how application performance
>
>affects their revenue. With AppDynamics, you get 100% visibility into
>your 
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 5704 bytes --]

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

On Sun, Dec 29, 2013 at 11:53:19AM -0700, Evan Duffield wrote:
> Hello,
> 
> We’re a startup looking for 1 or 2 really good C++ programmer that is
> familiar with the bitcoin internals to help with a for-profit startup.
> 
> We will be able to provide more information about the project after signing
> a non-compete/non-disclosure agreement. Our coin will be one of the truly
> unique coins that are not just a clone of the original Bitcoin code. In
> short the project will be a merge-mined altcoin that will provide a very
> useful service to the whole crypto-coin ecosystem.

I would strongly suggest that if you have not done so already you hire
someone competent to do an analysis of whether or not your idea makes
sense at all; that you are using merge-mining is a red-flag because
without majority, or at least near-majority, hashing power an attacker
can 51% attack your altcoin at negligible cost by re-using existing
hashing power. If you are starting a timestamping service that may be an
exception, but how to turn a profit doing so is non-obvious.


I would offer that consulting myself, but it would likely be a conflict
of interest with my employers. I'd be happy to speak informally in
private, but am explicitly unwilling to agree to any
non-compete/non-disclosure terms.

-- 
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Luke-Jr]

On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
> that you are using merge-mining is a red-flag because without majority, or
> at least near-majority, hashing power an attacker can 51% attack your
> altcoin at negligible cost by re-using existing hashing power.

I strongly disagree on this isolated point. Using the same logic, Bitcoin is 
vulnerable to an attacker at negligible cost by re-using existing hashing 
power from mining Namecoin. Any non-scam altcoin is pretty safe using merged 
mining, since any would-be attacker is going to have it in their interests to 
invest in the altcoin instead of attacking it. It's only the scam ones that 
want to pump & dump with no improvements, that are really at risk here.

The rational decision for a non-scam altcoin, is to take advantage of merged 
mining to get as much security as possible. There are also some possible 
tricks to get the full security of the bitcoin miners even when not all 
participate in your altcoin (but this area probably needs some studying to get 
right).

Luke

[Bitcoin-development] Merge mining

[Jeremy Spilman]

Merge mining lets Bitcoin miners support or attack an alt-coin without any  
additional cost for their proof-of-work.

Since bitcoin miners have to install software to build and claim blocks in  
the alt-coin, the percentage of bitcoin hashing power reflected toward the  
alt-coin will follow some adoption curve based on convincing bitcoin  
miners to opt-in.

Depending on where you are on that adoption curve or 'participation rate',  
you need [a lot] less than 51% of of total Bitcoin hashing power in order  
to 51% attack the alt-coin.

But there's so much 'dry powder' out there (GPUs), I wonder if *not*  
supporting merge-mining is any better? At least the attacker has to do  
some unique PoW, so you hope it's costing them something. Relatively large  
amounts of hashing can definitely be deployed on target with zero startup  
cost, and perhaps very little runtime cost (botnets).

I think the absolute cost of the PoW is very likely *not* the determining  
factor in preventing a 51% attack on all but one or two blockchains  
currently in existence.

Do I understand correctly, the question here is mostly a matter a game  
theory?

On Mon, 30 Dec 2013 17:14:05 -0800, Luke-Jr <luke@dashjr.org> wrote:

> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
>> that you are using merge-mining is a red-flag because without majority,  
>> or
>> at least near-majority, hashing power an attacker can 51% attack your
>> altcoin at negligible cost by re-using existing hashing power.
>
> I strongly disagree on this isolated point. Using the same logic,  
> Bitcoin is
> vulnerable to an attacker at negligible cost by re-using existing hashing
> power from mining Namecoin. Any non-scam altcoin is pretty safe using  
> merged
> mining, since any would-be attacker is going to have it in their  
> interests to
> invest in the altcoin instead of attacking it. It's only the scam ones  
> that want to pump & dump with no improvements, that are really at risk  
> here.
>
> The rational decision for a non-scam altcoin, is to take advantage of  
> merged mining to get as much security as possible. There are also some  
> possible
> tricks to get the full security of the bitcoin miners even when not all
> participate in your altcoin (but this area probably needs some studying  
> to get right).
>
> Luke
>

Re: [Bitcoin-development] Merge mining

[rob.golding]

> But there's so much 'dry powder' out there (GPUs), I wonder if *not*
> supporting merge-mining is any better? At least the attacker has to do
> some unique PoW, so you hope it's costing them something.

With lots of people having access to 100TH+ there's not really much 
'cost' to doing a 51% attack on an alt-coin beyond a short-term 
diversion away from 'profitable' mining.

At least by supporting merged mining, more miners are likely to 
'support' multiple coin types, thus making a 51% attack from an 
individual/group less straightforward.

>> The rational decision for a non-scam altcoin, is to take advantage of
>> merged mining to get as much security as possible.

Exactly.

Rob

Re: [Bitcoin-development] Merge mining

[David Vorick]

[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]

If you have the resources to attack one of the bigger altcoins, you
probably have a significant investment in the cryptocurrency space, and a
significant interest in protecting it. Compromising even something like
dogecoin would cause a lot of questions to be raised and likely drop the
value of bitcoin as well as all the cryptocurrencies using the same work
function as dogecoin.

Right now, there's very little benefit to attacking a significant currency,
because it would be very expensive and likely traumatize the whole system.
Unless it's some power like the NSA, I don't think there's much to worry
about.


On Tue, Dec 31, 2013 at 2:38 AM, <rob.golding@astutium.com> wrote:

> > But there's so much 'dry powder' out there (GPUs), I wonder if *not*
> > supporting merge-mining is any better? At least the attacker has to do
> > some unique PoW, so you hope it's costing them something.
>
> With lots of people having access to 100TH+ there's not really much
> 'cost' to doing a 51% attack on an alt-coin beyond a short-term
> diversion away from 'profitable' mining.
>
> At least by supporting merged mining, more miners are likely to
> 'support' multiple coin types, thus making a 51% attack from an
> individual/group less straightforward.
>
> >> The rational decision for a non-scam altcoin, is to take advantage of
> >> merged mining to get as much security as possible.
>
> Exactly.
>
> Rob
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2943 bytes --]

Re: [Bitcoin-development] Merge mining

[Jorge Timón]

On 1/4/14, David Vorick <david.vorick@gmail.com> wrote:
> If you have the resources to attack one of the bigger altcoins, you
> probably have a significant investment in the cryptocurrency space, and a
> significant interest in protecting it. Compromising even something like
> dogecoin would cause a lot of questions to be raised and likely drop the
> value of bitcoin as well as all the cryptocurrencies using the same work
> function as dogecoin.
>
> Right now, there's very little benefit to attacking a significant currency,
> because it would be very expensive and likely traumatize the whole system.
> Unless it's some power like the NSA, I don't think there's much to worry
> about.

The launch thread says it clear: "very scrypt, such random, much
profit, wow, many coin".
So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt
like most of the other scamcoins.
Anyway, I don't see anything in your comment in favor or against
merged mining...

Re: [Bitcoin-development] Merge mining

[David Vorick]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

It's meant to be in favor of merge mining.

Dogecoin uses scrypt, which is a very popular algorithm. If any large
currency were to be attacked through merge mining, it would probably be
litecoin miners attacking dogecoin. But if you control enough of the
litecoin network to do attack mining against dogecoin, you almost certainly
have a huge vested interest in cryptocurrencies doing well. By attacking
dogecoin successfully, you'll cast doubt on the entire cryptocurrency
ecosystem and hurt yourself in the process.


On Sat, Jan 4, 2014 at 5:05 AM, Jorge Timón <jtimon@monetize.io> wrote:

> On 1/4/14, David Vorick <david.vorick@gmail.com> wrote:
> > If you have the resources to attack one of the bigger altcoins, you
> > probably have a significant investment in the cryptocurrency space, and a
> > significant interest in protecting it. Compromising even something like
> > dogecoin would cause a lot of questions to be raised and likely drop the
> > value of bitcoin as well as all the cryptocurrencies using the same work
> > function as dogecoin.
> >
> > Right now, there's very little benefit to attacking a significant
> currency,
> > because it would be very expensive and likely traumatize the whole
> system.
> > Unless it's some power like the NSA, I don't think there's much to worry
> > about.
>
> The launch thread says it clear: "very scrypt, such random, much
> profit, wow, many coin".
> So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt
> like most of the other scamcoins.
> Anyway, I don't see anything in your comment in favor or against
> merged mining...
>

[-- Attachment #2: Type: text/html, Size: 2102 bytes --]

Re: [Bitcoin-development] Merge mining

[Jorge Timón]

On 1/4/14, David Vorick <david.vorick@gmail.com> wrote:
> It's meant to be in favor of merge mining.
>
> Dogecoin uses scrypt, which is a very popular algorithm.

Also, MS windows is a very popular operative system.
That's a fallacy:
http://en.wikipedia.org/wiki/Argumentum_ad_populum

> If any large
> currency were to be attacked through merge mining, it would probably be
> litecoin miners attacking dogecoin. But if you control enough of the
> litecoin network to do attack mining against dogecoin, you almost certainly
> have a huge vested interest in cryptocurrencies doing well.

Wait, wait, is Dogecoin merge-mineable with litecoin?
It could be if its developers wanted to, but I highly doubt it.
Precisely because of the myths spread against merged mining.

> By attacking
> dogecoin successfully, you'll cast doubt on the entire cryptocurrency
> ecosystem and hurt yourself in the process.

You shouldn't make such assumptions about the interests of a potential attacker.
For example, even being of the "cryptocurrency ecosystem" I could
consider that their slogans and videos are confusing newcomers and
they're really harming the general image of p2p currencies by
associating them with mad speculation and pump and dump schemes.

Being heavily involved in this "ecosystem", I would be very happy if
dogecoin disappeared tomorrow. Personally I've never mined anything,
but if I had the resources I would actually consider such an attack.

Again, I think we're getting off-topic with perrocoin. It hardly has
anything to do with MM.

> On Sat, Jan 4, 2014 at 5:05 AM, Jorge Timón <jtimon@monetize.io> wrote:
>
>> On 1/4/14, David Vorick <david.vorick@gmail.com> wrote:
>> > If you have the resources to attack one of the bigger altcoins, you
>> > probably have a significant investment in the cryptocurrency space, and
>> > a
>> > significant interest in protecting it. Compromising even something like
>> > dogecoin would cause a lot of questions to be raised and likely drop
>> > the
>> > value of bitcoin as well as all the cryptocurrencies using the same
>> > work
>> > function as dogecoin.
>> >
>> > Right now, there's very little benefit to attacking a significant
>> currency,
>> > because it would be very expensive and likely traumatize the whole
>> system.
>> > Unless it's some power like the NSA, I don't think there's much to
>> > worry
>> > about.
>>
>> The launch thread says it clear: "very scrypt, such random, much
>> profit, wow, many coin".
>> So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt
>> like most of the other scamcoins.
>> Anyway, I don't see anything in your comment in favor or against
>> merged mining...
>>
>


-- 
Jorge Timón

http://freico.in/

Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]

On Tue, Dec 31, 2013 at 01:14:05AM +0000, Luke-Jr wrote:
> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
> > that you are using merge-mining is a red-flag because without majority, or
> > at least near-majority, hashing power an attacker can 51% attack your
> > altcoin at negligible cost by re-using existing hashing power.
> 
> I strongly disagree on this isolated point. Using the same logic, Bitcoin is 
> vulnerable to an attacker at negligible cost by re-using existing hashing 
> power from mining Namecoin. Any non-scam altcoin is pretty safe using merged 
> mining, since any would-be attacker is going to have it in their interests to 
> invest in the altcoin instead of attacking it. It's only the scam ones that 
> want to pump & dump with no improvements, that are really at risk here.
> 
> The rational decision for a non-scam altcoin, is to take advantage of merged 
> mining to get as much security as possible. There are also some possible 
> tricks to get the full security of the bitcoin miners even when not all 
> participate in your altcoin (but this area probably needs some studying to get 
> right).

You assume the value of a crypto-currency is equal to all miners, it's
not.

Suppose I create a merge-mined Zerocoin implementation with a 1:1
BTC/ZTC exchange rate enforced by the software. You can't argue this is
a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
only thing you can do with the coin is get some privacy. But inevitably
some miners won't agree that enabling better privacy is a good thing, or
their local governments won't. Either way, they can attack the Zerocoin
merge-mined chain with a marginal cost of nearly zero.

OTOH if the Zerocoin scheme was implemented by embedding ZTC
transactions within standard Bitcoin transactions - even without any
attempt at hiding them - the attackers would need a 50% majority of
hashing power to succeed. Of course potentially slow confirmations is a
trade-off, but that's likely a perfectly OK trade-off in this case.

-- 
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] The insecurity of merge-mining

[Luke-Jr]

On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote:
> On Tue, Dec 31, 2013 at 01:14:05AM +0000, Luke-Jr wrote:
> > On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
> > > that you are using merge-mining is a red-flag because without majority,
> > > or at least near-majority, hashing power an attacker can 51% attack
> > > your altcoin at negligible cost by re-using existing hashing power.
> > 
> > I strongly disagree on this isolated point. Using the same logic, Bitcoin
> > is vulnerable to an attacker at negligible cost by re-using existing
> > hashing power from mining Namecoin. Any non-scam altcoin is pretty safe
> > using merged mining, since any would-be attacker is going to have it in
> > their interests to invest in the altcoin instead of attacking it. It's
> > only the scam ones that want to pump & dump with no improvements, that
> > are really at risk here.
> > 
> > The rational decision for a non-scam altcoin, is to take advantage of
> > merged mining to get as much security as possible. There are also some
> > possible tricks to get the full security of the bitcoin miners even when
> > not all participate in your altcoin (but this area probably needs some
> > studying to get right).
> 
> You assume the value of a crypto-currency is equal to all miners, it's
> not.
> 
> Suppose I create a merge-mined Zerocoin implementation with a 1:1
> BTC/ZTC exchange rate enforced by the software. You can't argue this is
> a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
> only thing you can do with the coin is get some privacy. But inevitably
> some miners won't agree that enabling better privacy is a good thing, or
> their local governments won't. Either way, they can attack the Zerocoin
> merge-mined chain with a marginal cost of nearly zero.

Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the 
worst they could do is not-participate by mining empty blocks.

> OTOH if the Zerocoin scheme was implemented by embedding ZTC
> transactions within standard Bitcoin transactions - even without any
> attempt at hiding them - the attackers would need a 50% majority of
> hashing power to succeed. Of course potentially slow confirmations is a
> trade-off, but that's likely a perfectly OK trade-off in this case.

Potentially slow confirmation is also the only shortcoming of using Bitcoin's 
proof-of-work directly.

Luke

Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

On Wed, Jan 01, 2014 at 05:09:27AM +0000, Luke-Jr wrote:
> > You assume the value of a crypto-currency is equal to all miners, it's
> > not.
> > 
> > Suppose I create a merge-mined Zerocoin implementation with a 1:1
> > BTC/ZTC exchange rate enforced by the software. You can't argue this is
> > a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
> > only thing you can do with the coin is get some privacy. But inevitably
> > some miners won't agree that enabling better privacy is a good thing, or
> > their local governments won't. Either way, they can attack the Zerocoin
> > merge-mined chain with a marginal cost of nearly zero.
> 
> Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the 
> worst they could do is not-participate by mining empty blocks.

Nope. Tying the alt-coin difficulty to the Bitcoin difficulty isn't some
magic way to avoid a 51% attack - you still need a majority of
consensus. The attackers can still mine a conflicting chain and there's
still no reasonable way to choose between the two chains other than
proof-of-something. Even worse, then can do a data-hiding attack by
mining a conflicting chain without publishing the blockchain data, then
revealing it some time in the future, or just sowing FUD by making it
clear that the mining is happening. Like it or not crypto-coins solve
double-spending with proof-of-publication, and that can't be done
without some kind of mathematically verifiable majority aligned with the
interests of the crypto-coin users.

Recall that my zookeyv(1) and zerocoin alt(2) proposals from last summer
was specifically designed to take that situation into account, and of
course could at best only make it clear that it was happening and how
many Bitcoins needed to be sacrificed to make the chain secure.


1) #bitcoin-wizards, 2013-05-31
2) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html

-- 
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] The insecurity of merge-mining

[Jorge Timón]

On 1/1/14, Peter Todd <pete@petertodd.org> wrote:
> On Tue, Dec 31, 2013 at 01:14:05AM +0000, Luke-Jr wrote:
>> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
>> > that you are using merge-mining is a red-flag because without majority,
>> > or
>> > at least near-majority, hashing power an attacker can 51% attack your
>> > altcoin at negligible cost by re-using existing hashing power.
>>
>> I strongly disagree on this isolated point. Using the same logic, Bitcoin
>> is
>> vulnerable to an attacker at negligible cost by re-using existing hashing
>>
>> power from mining Namecoin. Any non-scam altcoin is pretty safe using
>> merged
>> mining, since any would-be attacker is going to have it in their interests
>> to
>> invest in the altcoin instead of attacking it. It's only the scam ones
>> that
>> want to pump & dump with no improvements, that are really at risk here.
>>
>> The rational decision for a non-scam altcoin, is to take advantage of
>> merged
>> mining to get as much security as possible. There are also some possible
>> tricks to get the full security of the bitcoin miners even when not all
>> participate in your altcoin (but this area probably needs some studying to
>> get
>> right).
>
> You assume the value of a crypto-currency is equal to all miners, it's
> not.

They should be able to sell the reward at similar prices in the market.
Attackers are losing the opportunity cost of mining the currency by
attacking it, just like with Bitcoin.

> Suppose I create a merge-mined Zerocoin implementation with a 1:1
> BTC/ZTC exchange rate enforced by the software. You can't argue this is
> a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
> only thing you can do with the coin is get some privacy.

The idea of sacrificing something external and make bitcoins appear
still sounds crazy to me.
I don't see how this pegging contributes in anything to a technical
argument against merged mining, just looks like a moral argument
against altcoin in general.

But anyway, if you're going to make bitcoin's validation dependent on
some external chain, it surprises me even more that you prefer that
external dependency to be non-merge mineable.

> But inevitably
> some miners won't agree that enabling better privacy is a good thing, or
> their local governments won't. Either way, they can attack the Zerocoin
> merge-mined chain with a marginal cost of nearly zero.

Ok, so either we assume that the external-pegging hardfork wasn't a
consensus or we just forget about the pegging and go back to talk
about merged mining in general.
Your argument is still "for some reason some miners don't like the MM
altcoin and prefer to attack it than to be profitable miners".

If I mine BTC + NMC and you only mine BTC, it will be harder for you
to compete against me: I can afford higher costs than you for the same
BTC reward, since I'm also getting NMC.

What you're saying is that Litecoin is more secure than Namecoin
because while Litecoin can only be attacked by external attackers and
current miners of other scrypt coins, Namecoin can also be attacked
the Bitcoin miners that aren't currently mining Namecoin.
This doesn't sound very reasonable to me.
I think Namecoin is more secure than Litecoin and new coins should be
created with SHA256 and merged mining in mind. At least merged mine
with Litecoin if the still believe scrypt is so "anti-ASIC" and
"centralization-resistant" (in fact Litecoin is more centralized than
bitcoin with their shorter block intervals since better connections
are favored, but that's another story).

Merged mining is not only about not competing for proof of work like
Satoshi defended.
It is also about wasting resources: the more mining subsidies to
different chains, the more wasted resources.
By criticizing merged mining you're also indirectly legitimizing the
same scamcoin madness you criticize.
If you don't plan to merge mine, having SHA256 doesn't make sense
because that makes you more fragile to potential bitcoin miners
attacks and chainhopers.
I don't think we would have this many alts living right now if all
proof of work was SHA256.

So if the "anti-asic PoW" myth and the absurd emerging morals of
"GPU-mining as an universal right" weren't enough, you want to add an
equally false "merged mining is insecure" to the collection of
arguments supporting the search of the more absurd possible PoW holy
grail.

Please try to prove that MM is insecure and I'll try to prove your
wrong. But we don't need zerocoin or an artificial pegging to discuss
about this.

I think Namecoin has a lower reward for miners than litecoin and still
has much better security. I haven't run the numbers but, will you deny
it?
How many amazon VMs do you need to attack each one of them?

Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 4647 bytes --]

On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote:
> > You assume the value of a crypto-currency is equal to all miners, it's
> > not.
> 
> They should be able to sell the reward at similar prices in the market.
> Attackers are losing the opportunity cost of mining the currency by
> attacking it, just like with Bitcoin.

As I showed with my zerocoin example, often that is not the case, e.g. I
do not support anonymity, or *can't* support it because of the local
laws.

Or for that matter, really boring examples like there's two competing
implementations of some basic idea and we'd rather the winner be picked
on technical merits rather than "I have a grudge and a small pool so
I'll this upstart at birth"

> > Suppose I create a merge-mined Zerocoin implementation with a 1:1
> > BTC/ZTC exchange rate enforced by the software. You can't argue this is
> > a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
> > only thing you can do with the coin is get some privacy.
> 
> The idea of sacrificing something external and make bitcoins appear
> still sounds crazy to me.
> I don't see how this pegging contributes in anything to a technical
> argument against merged mining, just looks like a moral argument
> against altcoin in general.

It's a thought experiment; read my original post on how to make a
zerocoin alt-chain and it might make more sense:

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

Even better might be to use a merge-mined version of Mastercoin as an
example, where the initial distribution of coins is fixed at genesis and
forward from that is independent of the Bitcoin blockchain.


> > But inevitably
> > some miners won't agree that enabling better privacy is a good thing, or
> > their local governments won't. Either way, they can attack the Zerocoin
> > merge-mined chain with a marginal cost of nearly zero.
> 
> Ok, so either we assume that the external-pegging hardfork wasn't a
> consensus or we just forget about the pegging and go back to talk
> about merged mining in general.
> Your argument is still "for some reason some miners don't like the MM
> altcoin and prefer to attack it than to be profitable miners".
> 
> If I mine BTC + NMC and you only mine BTC, it will be harder for you
> to compete against me: I can afford higher costs than you for the same
> BTC reward, since I'm also getting NMC.
> 
> What you're saying is that Litecoin is more secure than Namecoin
> because while Litecoin can only be attacked by external attackers and
> current miners of other scrypt coins, Namecoin can also be attacked
> the Bitcoin miners that aren't currently mining Namecoin.
> This doesn't sound very reasonable to me.
> I think Namecoin is more secure than Litecoin and new coins should be
> created with SHA256 and merged mining in mind. At least merged mine
> with Litecoin if the still believe scrypt is so "anti-ASIC" and
> "centralization-resistant" (in fact Litecoin is more centralized than
> bitcoin with their shorter block intervals since better connections
> are favored, but that's another story).
> 
> Merged mining is not only about not competing for proof of work like
> Satoshi defended.
> It is also about wasting resources: the more mining subsidies to
> different chains, the more wasted resources.
> By criticizing merged mining you're also indirectly legitimizing the
> same scamcoin madness you criticize.
> If you don't plan to merge mine, having SHA256 doesn't make sense
> because that makes you more fragile to potential bitcoin miners
> attacks and chainhopers.
> I don't think we would have this many alts living right now if all
> proof of work was SHA256.
> 
> So if the "anti-asic PoW" myth and the absurd emerging morals of
> "GPU-mining as an universal right" weren't enough, you want to add an
> equally false "merged mining is insecure" to the collection of
> arguments supporting the search of the more absurd possible PoW holy
> grail.
> 
> Please try to prove that MM is insecure and I'll try to prove your
> wrong. But we don't need zerocoin or an artificial pegging to discuss
> about this.
> 
> I think Namecoin has a lower reward for miners than litecoin and still
> has much better security. I haven't run the numbers but, will you deny
> it?
> How many amazon VMs do you need to attack each one of them?

I'll give you a hint: "marginal cost"

You're rant has rather little to do with my argument.

-- 
'peter'[:-1]@petertodd.org
0000000000000003065f32da26de1deda93eb722bf1dc4a1b787e7d68d282dbc

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] The insecurity of merge-mining

[Jorge Timón]

On 1/3/14, Peter Todd <pete@petertodd.org> wrote:
> On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote:
>> > You assume the value of a crypto-currency is equal to all miners, it's
>> > not.
>>
>> They should be able to sell the reward at similar prices in the market.
>> Attackers are losing the opportunity cost of mining the currency by
>> attacking it, just like with Bitcoin.
>
> As I showed with my zerocoin example, often that is not the case, e.g. I
> do not support anonymity, or *can't* support it because of the local
> laws.
>
> Or for that matter, really boring examples like there's two competing
> implementations of some basic idea and we'd rather the winner be picked
> on technical merits rather than "I have a grudge and a small pool so
> I'll this upstart at birth"

For whatever reason, someone wants to attack one chain, fine.
But if the market is competitive enough and/or the reward of the
MM-coin is high enough comparatively to the biggest ones in the MM
group, then it is not profitable to mine.
If you make a MM coin, it's fees reward are 5% of BTC + NMC rewards,
and a jurisdiction somehow prohibits to mine the new coin (I can't
imagine such a law being enforced, but I'll follow your argument),
then BTC + NMC miners will just tend to disappear from that
jurisdiction.

> It's a thought experiment; read my original post on how to make a
> zerocoin alt-chain and it might make more sense:
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
>
> Even better might be to use a merge-mined version of Mastercoin as an
> example, where the initial distribution of coins is fixed at genesis and
> forward from that is independent of the Bitcoin blockchain.

I've read it until the end this time, and I have many doubts about
proof of sacrifice as a security mechanism. Although it's certainly
not proof of stake, it smells similarly to me. I'll have to think more
about it.
I still think that link doesn't prove anything against merged mining security.

>> I think Namecoin has a lower reward for miners than litecoin and still
>> has much better security. I haven't run the numbers but, will you deny
>> it?
>> How many amazon VMs do you need to attack each one of them?
>
> I'll give you a hint: "marginal cost"

Please, don't give me clues and let's discuss the economics, that's
precisely what I want and where I think you're getting it wrong.
Since you refuse to try to prove that MM is less secure, I'll try
myself to prove the opposite.

Let's say we have currencies A, B, C and D, with daily rewards of 70,
20, 10 and 10 valuns respectively.

A, B and C are merged mined, D is not.
So with an equivalent reward to miners and one being merged mined
while the other being independent, what's the more secure chain? C or
D?

Assuming similar hashing algorithms and perfect competition, the cost
of producing enough hashing power to obtain 1 valun in rewards from D
equals the cost of extracting 1 valun in rewards from the group A + B
+ C.
Let's define 1 valun as the costs in energy and capital resources to
produce X GH/s.
So we have the following hashrates for each chain:

A = 100*X GH/s
B = 100*X GH/s
C = 100*X GH/s
D = 10*X GH/s

Now here it comes our attacker paying for amazon servers.
The costs in value to rent a server to produce X GH/s during a day
cannot be lower than 1 valun, given the earlier assumptions. Let's
assume it is equal to 1 valun for simplicity.

So the cost to have 50% of D's hashing power for a day is 10 valuns.
The cost to to have 50% of C's hashing power for a day is 100 valuns,
but, hey, I'll use your hint now.
Marginal costs.
So I'm using 100 valuns to attack C, but I'm still getting my rewards
from A and B as normal.
As normal?
Let's assume it's as normal first.
I would be getting 90 valuns from chains A and B, so 100 - 90 = 10 valuns.
Mhmm, it seems that although I need to make a considerably bigger
investment in the case of attacking C, in the end the total costs will
be the same of attacking D, that is 10 valuns.
But, wait, I've doubled the hashrate!!
Miners were getting 1 valun in reward per valun in mining costs when
the hashrate was 100*X GH/s, now A and B hashrates are 200*X GH/s
because I came to mine.
Some of them will be smart enough to leave fast, but I will be really
getting something between 45 and 90 valuns from honestly mining A + B,
not 90 valuns as I was assuming.
So it turns out that attacking D is actually cheaper than attacking C.

Feel free to ask for corrections in the example if you think it needs them.
Feel free to bring your edge legal cases back, but please try to do it
on top of the example.

PD I'm eager to read your post on BIP32-ish payment protocol, bloom
filters and prefix filters, so I hope I'm not distracting you too much
with this.

Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]

On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
> > It's a thought experiment; read my original post on how to make a
> > zerocoin alt-chain and it might make more sense:
> >
> > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
> >
> > Even better might be to use a merge-mined version of Mastercoin as an
> > example, where the initial distribution of coins is fixed at genesis and
> > forward from that is independent of the Bitcoin blockchain.
> 
> I've read it until the end this time, and I have many doubts about
> proof of sacrifice as a security mechanism. Although it's certainly
> not proof of stake, it smells similarly to me. I'll have to think more
> about it.
> I still think that link doesn't prove anything against merged mining security.

It's not meant to prove anything - the proof-of-sacrificed-bitcoins
mentioned(*) in it is secure only if Bitcoin itself is secure and
functional. I referred you to it because understanding the system will
help you understand my thinking behind merge-mining.

*) It also mentions proof-of-sacrificed-zerocoins which *is* distinct
because you're sacrificing the thing that the chain is about. Now that
has some proof-of-stake tinges to it for sure - I myself am not
convinced it is or isn't a viable scheme.

> >> I think Namecoin has a lower reward for miners than litecoin and still
> >> has much better security. I haven't run the numbers but, will you deny
> >> it?
> >> How many amazon VMs do you need to attack each one of them?
> >
> > I'll give you a hint: "marginal cost"
> 
> Please, don't give me clues and let's discuss the economics, that's
> precisely what I want and where I think you're getting it wrong.
> Since you refuse to try to prove that MM is less secure, I'll try
> myself to prove the opposite.

<snip>

> Feel free to ask for corrections in the example if you think it needs them.
> Feel free to bring your edge legal cases back, but please try to do it
> on top of the example.

You're argument is perfectly valid and correct, *if* the assumptions
behind it hold. The problem is you're assuming miners act rationally and
have equal opportunities - that's a very big assumption and I have
strong doubts it holds, particularly for alts with a small amount of
hashing power.

You know, something that I haven't made clear in this discussion is that
while I think merge-mining is insecure, in the sense of "should my new
fancy alt-coin protocol widget use it?", I *also* don't think regular
mining is much better. In some cases it will be worse due to social
factors. (e.g. a bunch of big pools are going to merge-mine my scheme on
launch day because it makes puppies cuter and kids smile)

All I'm saying is that if you can afford the transaction fees stuffing
your data into the Bitcoin blockchain has orders of magnitude better
security. I'm not saying it'll be cheap - if miners start trying to
block your protocol blacklists they can make it fairly expensive for
your alt - but it will be just as secure against reorganization attack
as Bitcoin itself.

> PD I'm eager to read your post on BIP32-ish payment protocol, bloom
> filters and prefix filters, so I hope I'm not distracting you too much
> with this.

Heh, my one line reply might have been a bit harsh because of that. :)

-- 
'peter'[:-1]@petertodd.org
0000000000000000bf0a7634ebb2c909bada84ce0dce859e9298d3ac504db3c8

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] The insecurity of merge-mining

[Jorge Timón]

On 1/6/14, Peter Todd <pete@petertodd.org> wrote:
> On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
> It's not meant to prove anything - the proof-of-sacrificed-bitcoins
> mentioned(*) in it is secure only if Bitcoin itself is secure and
> functional. I referred you to it because understanding the system will
> help you understand my thinking behind merge-mining.
>
> *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct
> because you're sacrificing the thing that the chain is about. Now that
> has some proof-of-stake tinges to it for sure - I myself am not
> convinced it is or isn't a viable scheme.

I'm not sure I understand all the differences between
proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm
still convinced this doesn't have anything to do with MM PoW vs PoW.
The idea looks very interesting and I will ask you and adam to
understand it better on IRC, but take into account that when you say
"merged mining is insecure" some people hear "merged mined altcoins
are less secure than non-MM altcoins" (which is false) and somehow
conclude "scrypt altchains are more secure than SHA256 altchains".
Whether we like it or not, many people believe that scrypt, quark or
primecoin PoW algorithms are somehow more secure than SHA256, and
claims that "merged mining is insecure" from core bitcoin developers
contribute to spread those beliefs and that no new altcoin has been
created with the intend of being merged mined for quite a while.
I'm not trying to make you or anyone here responsible for the mistakes
other people make.

But rephrasing your claims as "We're exploring new ideas for altchains
that could be more secure than MM..." sounds very different from "MM
is insecure, by the way look at this new idea..."

>> Feel free to ask for corrections in the example if you think it needs
>> them.
>> Feel free to bring your edge legal cases back, but please try to do it
>> on top of the example.
>
> You're argument is perfectly valid and correct, *if* the assumptions
> behind it hold. The problem is you're assuming miners act rationally and
> have equal opportunities - that's a very big assumption and I have
> strong doubts it holds, particularly for alts with a small amount of
> hashing power.

That's why I made the offer above.
What you point out is the reason why freicoin started without merged
mining, to grow its own independent security first, before starting to
be merged mined.

> You know, something that I haven't made clear in this discussion is that
> while I think merge-mining is insecure, in the sense of "should my new
> fancy alt-coin protocol widget use it?", I *also* don't think regular
> mining is much better. In some cases it will be worse due to social
> factors. (e.g. a bunch of big pools are going to merge-mine my scheme on
> launch day because it makes puppies cuter and kids smile)

Fair enough.
Do you see any case where an independently pow validated altcoin is
more secure than a merged mined one?
The reason why I participated in the discussion was that I believe
that merged mined PoW is more secure than
completely-independent-from-bitcoin pow.
And I thought that that was the general understanding in the Bitcoin
development community.

If that's the case, we agree on what's more important to me.

About the new proposal, I don't have a firm opinion yet. I'm sorry but
I have to understand it better and think about it in more depth.

Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3663 bytes --]

On Thu, Jan 09, 2014 at 06:19:04PM +0100, Jorge Timón wrote:
> On 1/6/14, Peter Todd <pete@petertodd.org> wrote:
> > On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
> > It's not meant to prove anything - the proof-of-sacrificed-bitcoins
> > mentioned(*) in it is secure only if Bitcoin itself is secure and
> > functional. I referred you to it because understanding the system will
> > help you understand my thinking behind merge-mining.
> >
> > *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct
> > because you're sacrificing the thing that the chain is about. Now that
> > has some proof-of-stake tinges to it for sure - I myself am not
> > convinced it is or isn't a viable scheme.
> 
> I'm not sure I understand all the differences between
> proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm
> still convinced this doesn't have anything to do with MM PoW vs PoW.

Proof-of-sacrified-bitcoins is always a true sacrifice - provided
Bitcoin itself maintains consensus the proof is a guarantee that
something of value was given up.

Proof-of-sacrificed-"newcoins" means that within some consensus system I
created a signed statement that *within the system* means I lose
something of value. However that sacrifice is only valid if the
consensus of the system includes that sacrifice within the consensus,
and if the mechanism by which that consensus is maintained has anything
to do with those sacrifices you quickly find yourself on pretty shakey
ground.

> > You know, something that I haven't made clear in this discussion is that
> > while I think merge-mining is insecure, in the sense of "should my new
> > fancy alt-coin protocol widget use it?", I *also* don't think regular
> > mining is much better. In some cases it will be worse due to social
> > factors. (e.g. a bunch of big pools are going to merge-mine my scheme on
> > launch day because it makes puppies cuter and kids smile)
> 
> Fair enough.
> Do you see any case where an independently pow validated altcoin is
> more secure than a merged mined one?

Situations where decentralized consensus systems are competing for
market share in some domain certainely apply. For instance if I were to
create a competitor to Namecoin, perhaps because I thought the existing
allocation of names was unfair, and/or I had technical improvements like
SPV, it's easy to imagine Namecoin miners deciding to attack my
competitor to preserve the value of their namecoins and domain names
registered in Namecoin.

The problem here is that my new system has a substantial *negative*
value to those existing Namecoin holders - if it catches on the value of
their Namecoin investment in the form of coins and domain names may go
down. Thus for them doing nothing has a negative return, attacking my
coin has a positive return minus costs, and with merge-mining the costs
are zero.

Without merge mining if the value to the participants in the new system
is greater than the harm done to the participants in the old system the
total work on the new system's chain will still be positive and it has a
chance of surviving.

Of course, this is what Luke-Jr was getting at when he was talking about
scam-coins and merge mining: if you're alt-currency is a currency, and
it catches on, then it dilutes the value of your existing coins and
people who own those coins have an incentive to attack the competitor.
That's why merge-mined alt-coins that are currencies get often get
attacked very quickly.

-- 
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Fri, Jan 10, 2014 at 06:11:28AM -0500, Peter Todd wrote:
> > Fair enough.
> > Do you see any case where an independently pow validated altcoin is
> > more secure than a merged mined one?
> 
> Situations where decentralized consensus systems are competing for
> market share in some domain certainely apply. For instance if I were to
> create a competitor to Namecoin, perhaps because I thought the existing
> allocation of names was unfair, and/or I had technical improvements like
> SPV, it's easy to imagine Namecoin miners deciding to attack my
> competitor to preserve the value of their namecoins and domain names
> registered in Namecoin.

Come to think of it, we've got that exact situation right now: the new
Twister P2P Microblogging thing has a blockchain for registering
usernames that could have been easily done with Namecoin, thus in theory
Namecoin owners have an incentive to make sure the Twister blockchain
gets killed at birth.

Pretty easy to do right now too as the hashing power behind Twister is
miniscule and probably will stay that way - the only incentive to mining
is that you get the right to make a "promoted post" - called a spam
message in the codebase - that in theory Twister clients are supposed to
show to their users. Of course, there's absolutely no way to guarantee
that clients actually do that.

-- 
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] The insecurity of merge-mining

[Jorge Timón]

On 1/10/14, Peter Todd <pete@petertodd.org> wrote:
> Come to think of it, we've got that exact situation right now: the new
> Twister P2P Microblogging thing has a blockchain for registering
> usernames that could have been easily done with Namecoin, thus in theory
> Namecoin owners have an incentive to make sure the Twister blockchain
> gets killed at birth.

You don't have to MM from birth. That I've already agreed is
dangerous. But if you start with SHA256, then merged mining is a
trivial fork at least 3 currencies have done successfully.
As said we plan to make Freicoin merge-mineable in the future, and we
expect to get much more security after we do.
The only "adverse" effect may be a temporary drop in price due to the
new miners selling all the frc they get until a new price equilibrates
with the demand. But that's not really "bad for the currency", just to
the holders at that moment.

> Pretty easy to do right now too as the hashing power behind Twister is
> miniscule and probably will stay that way - the only incentive to mining
> is that you get the right to make a "promoted post" - called a spam
> message in the codebase - that in theory Twister clients are supposed to
> show to their users. Of course, there's absolutely no way to guarantee
> that clients actually do that.

If a system doesn't compensate its miners in a liquid enough way, the
system will probably be insecure, but that's another topic...

Re: [Bitcoin-development] The insecurity of merge-mining

[Jorge Timón]

On 1/10/14, Peter Todd <pete@petertodd.org> wrote:
>> Fair enough.
>> Do you see any case where an independently pow validated altcoin is
>> more secure than a merged mined one?
>
> Situations where decentralized consensus systems are competing for
> market share in some domain certainely apply. For instance if I were to
> create a competitor to Namecoin, perhaps because I thought the existing
> allocation of names was unfair, and/or I had technical improvements like
> SPV, it's easy to imagine Namecoin miners deciding to attack my
> competitor to preserve the value of their namecoins and domain names
> registered in Namecoin.

Namecoin, Devcoin and Ixcoin are also currencies and therefore compete
with Bitcoin.
How is that even Ixcoin (clearly a scamcoin that indirectly damages
the image of Bitcoin) has survived?

My explanation is that miners aren't necessarily holders. It's certain
that there's holders who don't mind and "can't do anything about it".
In fact, I think many miners sell their mined coins for fiat to cover
their investment and costs. The profit margin is reduced as the mining
market becomes more competitive, so even for miners it will get very
expensive and risky to do stupid things.
Talking about stupid things, I don't see many bitcoiners throwing
rocks at local currency users or barter clubs nor burning down banks
to "protect their investment". Barter is just another competitor in
the media of exchange market.

> The problem here is that my new system has a substantial *negative*
> value to those existing Namecoin holders - if it catches on the value of
> their Namecoin investment in the form of coins and domain names may go
> down. Thus for them doing nothing has a negative return, attacking my
> coin has a positive return minus costs, and with merge-mining the costs
> are zero.

What percentage of Bitcoin/Namecoin miners do you think own namecoins?
How much can they afford to lose to attack competition?

> Without merge mining if the value to the participants in the new system
> is greater than the harm done to the participants in the old system the
> total work on the new system's chain will still be positive and it has a
> chance of surviving.

No, the "harm to the old system participants" is distributed among all
the participants, not only miners (assuming miners have any
speculative position at all).
I'm not denying that people do crazy and stupid things, but let's at
least allow the "anti-competition attacker" be equally crazy in both
cases.
Miners attacking "competition" for one or more of the chains they mine
are acting irrationally in both cases.
You're trying to rationalize the actions of the MM attackers, but
they're just being stupid, since if they weren't, they would just try
to maximize profits.

> Of course, this is what Luke-Jr was getting at when he was talking about
> scam-coins and merge mining: if you're alt-currency is a currency, and
> it catches on, then it dilutes the value of your existing coins and
> people who own those coins have an incentive to attack the competitor.
> That's why merge-mined alt-coins that are currencies get often get
> attacked very quickly.

I have many other explanations for the few currencies that died with
MM (can you remember any name?). At the beginning all altcoins were
much smaller and easier to attack, all of them. Bitcoin mining pools
didn't wanted to update to merged mining and didn't acted very
rationally about it.
Namecoin went through a really delicate situation just before
hardforking to MM, but now is by far the most secure altcoin of them
all, all thanks to MM.
All rational bitcoin miners should also mine namecoin. Period. All
those who consider it competition with their current Bitcoin
speculative position, should just "attack in the market" by selling
the namecoins as soon as they get them.
Providing security for a chain DOES NOT give it an utility or rise its demand.
Operation COSTS DO NOT CAUSE VALUE.

About Luke-Jr's thinking, I don't think it's along those lines.

If you create a new chain for the long term, you should try to
maximize its security and that currently means you should merged mine
with bitcoin.
The main rational reason to never do merged mining is to prevent
competitive and rational miners from crashing the price of your
currency, which is everything a scamcoiner cares about, the price and
market cap.

Of course Luke-Jr can correct me if that's not how he thinks.

Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5040 bytes --]

On Fri, Jan 10, 2014 at 01:29:03PM +0100, Jorge Timón wrote:
> On 1/10/14, Peter Todd <pete@petertodd.org> wrote:
> > Situations where decentralized consensus systems are competing for
> > market share in some domain certainely apply. For instance if I were to
> > create a competitor to Namecoin, perhaps because I thought the existing
> > allocation of names was unfair, and/or I had technical improvements like
> > SPV, it's easy to imagine Namecoin miners deciding to attack my
> > competitor to preserve the value of their namecoins and domain names
> > registered in Namecoin.
> 
> Namecoin, Devcoin and Ixcoin are also currencies and therefore compete
> with Bitcoin.
> How is that even Ixcoin (clearly a scamcoin that indirectly damages
> the image of Bitcoin) has survived?

Because there aren't that many pools out there and Ixcoin (and devcoin)
appear to have been lucky enough to servive long enough to get the
support of a reasonably big one. Once you do that, the potential
attackers have PR to think about. (namecoin especially has a PR
advantage) None of this stuff is hard and fast rules after all.

> Talking about stupid things, I don't see many bitcoiners throwing
> rocks at local currency users or barter clubs nor burning down banks
> to "protect their investment". Barter is just another competitor in
> the media of exchange market.

Those are all examples where the cost to the "bitcoiner defending their
currency" is high - I might get arrested trying to burn down a bank.


Anyway, I'm starting to think you're reading too much into my statement
"merge mining is insecure", which, keep in mind, I said in relation to a
guy who was trying to recruit devs to implement some unknown "altcoin"
thing.

Imagine you're one of the first US cave divers back in the early 70's.
You've been doing it for only a few years yourself, and you and your
buddies, some of them now late, realized pretty quick it's bloody
dangerous and there's all kinds of ways to get yourself killed. (caving
itself is bad enough) On the other hand, if you're careful and have good
training it *is* possible to reduce the risks significantly. Meanwhile
the media and public in general is starting to pick up on caving and
cave diving and there's a tonne of new people - most of whome don't seem
to know what they're doing - are getting into both sports. You just know
this is going to lead to a lot of people getting hurt and killed who
probably should have just stuck to caving. (IE, stuck to making
Bitcoin-using applications)

In that context I sure as heck would loudly yell "CAVE DIVING IS FUCKING
DANGEROUS, DON'T DO IT". Sure, that's not quite telling the whole story,
but the message is pretty close to the truth. The people that should be
in the sport are the ones that take a statement like that as a warning
to do their research; I have no reason to think the OP asking for
developers was one of those people.

> > Without merge mining if the value to the participants in the new system
> > is greater than the harm done to the participants in the old system the
> > total work on the new system's chain will still be positive and it has a
> > chance of surviving.
> 
> No, the "harm to the old system participants" is distributed among all
> the participants, not only miners (assuming miners have any
> speculative position at all).
> I'm not denying that people do crazy and stupid things, but let's at
> least allow the "anti-competition attacker" be equally crazy in both
> cases.

Distributing harm among n people just reduces the harm for each person
by a factor of n. That may or may not make that harm smaller than
whatever tiny reward mining the chain would be.

> I have many other explanations for the few currencies that died with
> MM (can you remember any name?). At the beginning all altcoins were
> much smaller and easier to attack, all of them. Bitcoin mining pools
> didn't wanted to update to merged mining and didn't acted very
> rationally about it.
> Namecoin went through a really delicate situation just before
> hardforking to MM, but now is by far the most secure altcoin of them
> all, all thanks to MM.
> All rational bitcoin miners should also mine namecoin. Period. All

You assume doing so has zero cost - it doesn't. Running namecoind
involves effort and bandwidth on my part.

> those who consider it competition with their current Bitcoin
> speculative position, should just "attack in the market" by selling
> the namecoins as soon as they get them.
> Providing security for a chain DOES NOT give it an utility or rise its demand.
> Operation COSTS DO NOT CAUSE VALUE.

Lets rephrase that "A secure chain is no more useful than a less secure
chain. A secure chain will not be more valuable than a less secure
chain, all other things being equal."

I don't think we're going to see eye to eye on this.

-- 
'peter'[:-1]@petertodd.org
000000000000000028e2c0ade6ce50b5ce4d95037e5e2dcd500b4bb52adbe73c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] The insecurity of merge-mining

[Jorge Timón]

On 1/10/14, Peter Todd <pete@petertodd.org> wrote:
> Because there aren't that many pools out there and Ixcoin (and devcoin)
> appear to have been lucky enough to servive long enough to get the
> support of a reasonably big one. Once you do that, the potential
> attackers have PR to think about. (namecoin especially has a PR
> advantage) None of this stuff is hard and fast rules after all.

But shouldn't your reasoning apply here so that ixcoin would be
destroyed by those who aren't even mining it. Because of the
"supposedly obvious" harm it does to Bitcoin through competition?

> Anyway, I'm starting to think you're reading too much into my statement
> "merge mining is insecure", which, keep in mind, I said in relation to a
> guy who was trying to recruit devs to implement some unknown "altcoin"
> thing.

That's precisely my worry. Most of those guys planning to implement
random altcoins will conclude after reading you that what they need is
not merged mining but yet another independent scrypt coin, or worse,
yet another stupid PoW algorithm.

> In that context I sure as heck would loudly yell "CAVE DIVING IS FUCKING
> DANGEROUS, DON'T DO IT". Sure, that's not quite telling the whole story,
> but the message is pretty close to the truth. The people that should be
> in the sport are the ones that take a statement like that as a warning
> to do their research; I have no reason to think the OP asking for
> developers was one of those people.

I'm approached many times with questions like "How much would it cost
to create a new altcoin?" (Thanks, BlueMatt for creating coingen!!).
I try to explain them that there's more currencies beyond p2p
currencies and they probably don't need that. I talk them about local
currencies, colored coins or open transactions as solution that
probably fit their needs much better without the need to bootstrap and
antire economy with a network of computer that consumes plenty of
resources.

If none of that fits them (say, for crazy experiments like datacoin or
gridcoin), I recommend them merged mining because is more secure for
them, more secure for bitcoin, and better for the environment and
everyone in general.

Still, for some reason a new non merged mined chain is the most popular choice.
Less efficient, less secure, more popular.
Why?
I wonder if devs warning against merged mining or making stupid
predictions like "bitcoin's PoW algorithm won't survive the year" have
anything to do with that...

>> > Without merge mining if the value to the participants in the new system
>> > is greater than the harm done to the participants in the old system the
>> > total work on the new system's chain will still be positive and it has
>> > a
>> > chance of surviving.
>>
>> No, the "harm to the old system participants" is distributed among all
>> the participants, not only miners (assuming miners have any
>> speculative position at all).
>> I'm not denying that people do crazy and stupid things, but let's at
>> least allow the "anti-competition attacker" be equally crazy in both
>> cases.
>
> Distributing harm among n people just reduces the harm for each person
> by a factor of n. That may or may not make that harm smaller than
> whatever tiny reward mining the chain would be.

The harm TO THE MINERS alone (again, assuming they have any position
at all in the coins they're mining) is less than the "total harm" to
the competing system, assuming that's quantifiable at all.
Miners won't think about the "total harm", but only about their share
of harm vs their share of just mining the competing system alongside
with the old one.

>> I have many other explanations for the few currencies that died with
>> MM (can you remember any name?). At the beginning all altcoins were
>> much smaller and easier to attack, all of them. Bitcoin mining pools
>> didn't wanted to update to merged mining and didn't acted very
>> rationally about it.
>> Namecoin went through a really delicate situation just before
>> hardforking to MM, but now is by far the most secure altcoin of them
>> all, all thanks to MM.
>> All rational bitcoin miners should also mine namecoin. Period. All
>
> You assume doing so has zero cost - it doesn't. Running namecoind
> involves effort and bandwidth on my part.

Yeah, true, they will only mine if all those costs are lower than the
reward. Only the hashing is "for free".
I'm assuming that those costs are very small compared to the reward,
that is, that most of the reward pays for hashing and not validation.

>> those who consider it competition with their current Bitcoin
>> speculative position, should just "attack in the market" by selling
>> the namecoins as soon as they get them.
>> Providing security for a chain DOES NOT give it an utility or rise its
>> demand.
>> Operation COSTS DO NOT CAUSE VALUE.
>
> Lets rephrase that "A secure chain is no more useful than a less secure
> chain. A secure chain will not be more valuable than a less secure
> chain, all other things being equal."

Not exactly, a less secure chain can become completely useless due to
the lack of security.
What I'm saying is that a useless chain is still useless no matter the security.

> I don't think we're going to see eye to eye on this.

It is possible.
At least now we know each other position in MM.
I'm not sure if the silence means that only Maaku and Luke-Jr agree
with me on merged mining, that it is you who are more alone than me on
this one, or if it's just that not many people had taken the time to
think about this...

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Troy Benjegerdes]

On Sun, Dec 29, 2013 at 11:53:19AM -0700, Evan Duffield wrote:
> Hello,
> 
> We’re a startup looking for 1 or 2 really good C++ programmer that is
> familiar with the bitcoin internals to help with a for-profit startup.
> 
> We will be able to provide more information about the project after signing
> a non-compete/non-disclosure agreement. Our coin will be one of the truly
> unique coins that are not just a clone of the original Bitcoin code. In
> short the project will be a merge-mined altcoin that will provide a very
> useful service to the whole crypto-coin ecosystem.
> 
> If you have added any features to Bitcoin or related technologies this is a
> definite bonus. Please include information about the work you’re done in
> the space.
> 
> We have detailed plans on how to implement it and the roles we are looking
> to fill. If interested please email eduffield82@gmail.com with a
> description of your work experience and we’ll vett the applications and
> share our plans to see if you’re interested.
> 
> Thanks,
> 
> Evan & Kyle
> Hawk Financial Group, LLC

Evan & Kyle,

I have a very unique and one-of-a kind offer for you. I will buy your company
from the revenue generated from my AGPLv3 copyright licensed Minco.me(c) 
cryptographic currency, which will revolutionize work by ensuring that anyone
with a Mincome(C) address doesn't need to work.

Ask yourself.. why would someone who can write a cryptocurrency want to *work*
for you, to get paid with... money.. that they can just ...
  ** write code that makes them money **

Please be aware that any concept(s) that I have publicly discussed, or that 
we may or may not have talked about if I would have signed a non-enforceable
non-compete agreement are COPYRIGHT 2013,2014 Troy Benjegerdes, and that I
would advise you seek competent legal council to ensure that this email, or
any other contact we may or may not have had does not contaminate your 
business model with a viral copyright license.


To everyone else on this list, I'm sorry, I just could not resist feeding 
the VC/marketing trolls.


-- Troy, 'da hozer'

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

[Jérémie Dubois-Lacoste]

Hey,

I doubt this list is for this kind of thing. I am following
bitcoin-development since a long time but never participated because I
believe discussions should be well-focused and I never had anything
relevant to say.
Evan, I am pretty sure that emails such as yours will cause the true
discussions between core-dev (or those closely graviting around) to
move elsewhere on a less public channel, where people like me won't be
able to follow them anymore. Thus my request: please post this kind of
things elsewhere, because you are hijacking a list just to target his
audience, but not to contribute relevant content. (A definition
usually describing spam).

Cheers,

Jeremie


2013/12/29 Evan Duffield <eduffield82@gmail.com>:
> Hello,
>
>
> We’re a startup looking for 1 or 2 really good C++ programmer that is
> familiar with the bitcoin internals to help with a for-profit startup.
>
>
> We will be able to provide more information about the project after signing
> a non-compete/non-disclosure agreement. Our coin will be one of the truly
> unique coins that are not just a clone of the original Bitcoin code. In
> short the project will be a merge-mined altcoin that will provide a very
> useful service to the whole crypto-coin ecosystem.
>
>
> If you have added any features to Bitcoin or related technologies this is a
> definite bonus. Please include information about the work you’re done in the
> space.
>
>
> We have detailed plans on how to implement it and the roles we are looking
> to fill. If interested please email eduffield82@gmail.com with a description
> of your work experience and we’ll vett the applications and share our plans
> to see if you’re interested.
>
>
> Thanks,
>
>
> Evan & Kyle
>
> Hawk Financial Group, LLC
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>