[ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency

[norulezapply]

Anyone wanna explain the 7769999 value genesis block?

Yeah, I won't be mining this one thanks.

[1713566808]

1713566808

[1713566808]

1713566808

[phelix]

Anyone wanna explain the 7769999 value genesis block?

Yeah, I won't be mining this one thanks.

try fairbrix 

Damn, yet again i came in a bit too late :/

try fairbrix  

[tacotime]

Can someone post a walkthrough of how to get this started.

I have Bitminter running at the same time and Tenebrix says that it cannot bind to port 8333 because bitcoin is already running...can I not run both at the same time?

Tenebrix uses a different port

[coblee]

Anyone wanna explain the 7769999 value genesis block?

Yeah, I won't be mining this one thanks.

Yup, already been discussed. Lolcust premined 7.7 million coins. He's supposed to use about half of that for development work and faucet. The other half will be kept for his yet to be implemented laundry service. And he claims that he will never unload those coins on the market. So far, Lolcust has been doing an awesome job in supporting this chain with pool and exchange.

If the premine coins really bother you, there's Fairbrix: https://bitcointalk.org/index.php?topic=46528.0
Fairbrix is pretty much an exact clone of Tenebrix just without the premined coins. Pool and exchange should be coming pretty soon.

[coblee]

Basically people are wary about the 7.7 million premined coins. It takes 3 years for the network the mine another 7 million coins. So for the foreseeable future, Lolcust has absolute control of the market. And if he decides to unload part of his laundry fund in the future, no one can stop him. Or if some malicious user manages to hack into his computer to steal his coins, they can easily crash the market. And that's troublesome.

Here's a suggestion I made to Lolcust on IRC. Basically have the Tenebrix code enforce that the laundry fund can never be stolen by Lolcust or anyone else for that matter. The laundry can be implemented using 2 buffers: clean buffer and deposit buffer. These buffers are just 2 tenebrix addresses that contain coins. The clean buffer will be where clean coins come out of. The deposit buffer will be where people send their coins that they want cleaned. After a random amount of time, the same amount (minus fees) will be sent to them from the clean buffer. Initially, the clean buffer will contain the 7 million coins and the deposit buffer will have no coins. After 7 million coins are laundered, the clean buffer will run out, and the 2 buffers will swap roles.

Given this implementation, we know that if the laundry is running correctly, the sum of the 2 buffers will always be greater than 7 million coins. If at any point in time there are less than 7 million coins in the 2 buffers, then either there's a mistake in the laundry code or someone is deliberately stealing from the laundry. My proposal is that we change the code to prevent this from ever happening. All you need to do is add an extra check in the transaction checking code. If the transaction involves taking money out of either of these buffer, just make sure that the 2 buffer still sums up to at least 7 million. If it doesn't then the transaction will be considered illegal and will not be added to a block and confirmed. And if a rogue miner tries to add an illegal transaction to a block it found, that block will be rejected by other miners. With this code, people can be sure that this 7 million premined coins cannot be used for anything other than the laundry and will be forever stuck in those two addresses. And in the future, if Lolcust turns rogue and releases code without this check, people will see that and refuse to update their client to that one.

I offered to help Lolcust code this up. What do people think?

[terrytibbs]

Basically people are wary about the 7.7 million premined coins. It takes 3 years for the network the mine another 7 million coins. So for the foreseeable future, Lolcust has absolute control of the market. And if he decides to unload part of his laundry fund in the future, no one can stop him. Or if some malicious user manages to hack into his computer to steal his coins, they can easily crash the market. And that's troublesome.

Here's a suggestion I made to Lolcust on IRC. Basically have the Tenebrix code enforce that the laundry fund can never be stolen by Lolcust or anyone else for that matter. The laundry can be implemented using 2 buffers: clean buffer and deposit buffer. These buffers are just 2 tenebrix addresses that contain coins. The clean buffer will be where clean coins come out of. The deposit buffer will be where people send their coins that they want cleaned. After a random amount of time, the same amount (minus fees) will be sent to them from the clean buffer. Initially, the clean buffer will contain the 7 million coins and the deposit buffer will have no coins. After 7 million coins are laundered, the clean buffer will run out, and the 2 buffers will swap roles.

Given this implementation, we know that if the laundry is running correctly, the sum of the 2 buffers will always be greater than 7 million coins. If at any point in time there are less than 7 million coins in the 2 buffers, then either there's a mistake in the laundry code or someone is deliberately stealing from the laundry. My proposal is that we change the code to prevent this from ever happening. All you need to do is add an extra check in the transaction checking code. If the transaction involves taking money out of either of these buffer, just make sure that the 2 buffer still sums up to at least 7 million. If it doesn't then the transaction will be considered illegal and will not be added to a block and confirmed. And if a rogue miner tries to add an illegal transaction to a block it found, that block will be rejected by other miners. With this code, people can be sure that this 7 million premined coins cannot be used for anything other than the laundry and will be forever stuck in those two addresses. And in the future, if Lolcust turns rogue and releases code without this check, people will see that and refuse to update their client to that one.

I offered to help Lolcust code this up. What do people think?

Knowing what address the laundry sends out clean funds gets "them" one step closer to (partially) identifying the user, no?

[coblee]

Knowing what address the laundry sends out clean funds gets "them" one step closer to (partially) identifying the user, no?

Not really. Someone send 2000 coins to the deposit address. And at random times after that, 20 different 100 coins transactions are sent from the clean buffer to 20 different addresses all belonging to the original sender. Then let's say there are 100 people laundering coins around the same time. There's really no way anyone can associate which clean coins came from which dirty coins.

[ArtForz]

Basically people are wary about the 7.7 million premined coins. It takes 3 years for the network the mine another 7 million coins. So for the foreseeable future, Lolcust has absolute control of the market. And if he decides to unload part of his laundry fund in the future, no one can stop him. Or if some malicious user manages to hack into his computer to steal his coins, they can easily crash the market. And that's troublesome.

Here's a suggestion I made to Lolcust on IRC. Basically have the Tenebrix code enforce that the laundry fund can never be stolen by Lolcust or anyone else for that matter. The laundry can be implemented using 2 buffers: clean buffer and deposit buffer. These buffers are just 2 tenebrix addresses that contain coins. The clean buffer will be where clean coins come out of. The deposit buffer will be where people send their coins that they want cleaned. After a random amount of time, the same amount (minus fees) will be sent to them from the clean buffer. Initially, the clean buffer will contain the 7 million coins and the deposit buffer will have no coins. After 7 million coins are laundered, the clean buffer will run out, and the 2 buffers will swap roles.

Given this implementation, we know that if the laundry is running correctly, the sum of the 2 buffers will always be greater than 7 million coins. If at any point in time there are less than 7 million coins in the 2 buffers, then either there's a mistake in the laundry code or someone is deliberately stealing from the laundry. My proposal is that we change the code to prevent this from ever happening. All you need to do is add an extra check in the transaction checking code. If the transaction involves taking money out of either of these buffer, just make sure that the 2 buffer still sums up to at least 7 million. If it doesn't then the transaction will be considered illegal and will not be added to a block and confirmed. And if a rogue miner tries to add an illegal transaction to a block it found, that block will be rejected by other miners. With this code, people can be sure that this 7 million premined coins cannot be used for anything other than the laundry and will be forever stuck in those two addresses. And in the future, if Lolcust turns rogue and releases code without this check, people will see that and refuse to update their client to that one.

I offered to help Lolcust code this up. What do people think?

Sounds like a damn great idea.
I agree the KISS version should be relatively easy to implement, but I suspect it'll become dog-slow if the laundry ever becomes popular.
Basically, if a tx input is spending a output belonging to one of the 2 laundry addresses, sum up *all* unspent outputs of those 2 and consider the tx invalid if spending that output would bring the total below the threshold.
The problem is when the deposit buffer fills up with 10000s of tx... that scan-and-sum needs caching.

[coblee]

Sounds like a damn great idea.
I agree the KISS version should be relatively easy to implement, but I suspect it'll become dog-slow if the laundry ever becomes popular.
Basically, if a tx input is spending a output belonging to one of the 2 laundry addresses, sum up *all* unspent outputs of those 2 and consider the tx invalid if spending that output would bring the total below the threshold.
The problem is when the deposit buffer fills up with 10000s of tx... that scan-and-sum needs caching.

Should be easy to keep track of a running total, right? When it initially load the blocks, it calculates the coins in those addresses the same way it calculates your unspent coins in your addresses. So at each block, you always know how many coins those 2 addresses contains. It will be similar to how the client won't let you spend coins you don't own. Should be simple enough. And it should be simple enough to test it also. Once the code is out there, Lolcust can create a transaction that tries to spend coins that violates this rule and people can test to make sure that the transaction is indeed rejected by the code.

[ArtForz]

Sounds like a damn great idea.
I agree the KISS version should be relatively easy to implement, but I suspect it'll become dog-slow if the laundry ever becomes popular.
Basically, if a tx input is spending a output belonging to one of the 2 laundry addresses, sum up *all* unspent outputs of those 2 and consider the tx invalid if spending that output would bring the total below the threshold.
The problem is when the deposit buffer fills up with 10000s of tx... that scan-and-sum needs caching.

Should be easy to keep track of a running total, right? When it initially load the blocks, it calculates the coins in those addresses the same way it calculates your unspent coins in your addresses. So at each block, you always know how many coins those 2 addresses contains. It will be similar to how the client won't let you spend coins you don't own. Should be simple enough. And it should be simple enough to test it also. Once the code is out there, Lolcust can create a transaction that tries to spend coins that violates this rule and people can test to make sure that the transaction is indeed rejected by the code.

True. Just wondering how "fun" handling this on reorgs will be.
Thats why I went with the "start with the stupidest possible implementation, optimize later" assumption

[coblee]

Sounds like a damn great idea.
I agree the KISS version should be relatively easy to implement, but I suspect it'll become dog-slow if the laundry ever becomes popular.
Basically, if a tx input is spending a output belonging to one of the 2 laundry addresses, sum up *all* unspent outputs of those 2 and consider the tx invalid if spending that output would bring the total below the threshold.
The problem is when the deposit buffer fills up with 10000s of tx... that scan-and-sum needs caching.

Should be easy to keep track of a running total, right? When it initially load the blocks, it calculates the coins in those addresses the same way it calculates your unspent coins in your addresses. So at each block, you always know how many coins those 2 addresses contains. It will be similar to how the client won't let you spend coins you don't own. Should be simple enough. And it should be simple enough to test it also. Once the code is out there, Lolcust can create a transaction that tries to spend coins that violates this rule and people can test to make sure that the transaction is indeed rejected by the code.

True. Just wondering how "fun" handling this on reorgs will be.
Thats why I went with the "start with the stupidest possible implementation, optimize later" assumption

On a reorg, how does the code handle your unspent coins? Does it do a rescan? I assume it can be done the same way. Basically it could treat these 2 addresses the same as it treats other addresses in your wallet.

If a reorg causes some transactions to be undone and those transactions became "illegal" due to the reorg, then they won't be spent until they become "legal" again. Unfortunately, I don't know enough about this to know if there are edge case issues with this implementation.

[Lolcust]

Well, like I said on IRC, I like this idea - it has elegance to it

However, since the IRC discussion, I have developed a concern as to how it affects an average miner's plausible deniability in regards to involvement in the laundry Quasi-Value token transaction mixing business. Right now, a miner is not technically involved in superfund's operation anymore than an ixcoin miner is involved in fakepanese guy's operations.
With "LolcustLaundryWatch" code being part of every Tenebrix miner forever, the degree of plausible deniability as to connection with laundry-op available to a miner will become, basically, nil.

I also think that performance issues will need to be accounted for early on, since upgrading miners "down the line" is liable to become very painful, very fast (how many slowpoke BTC clients of v <0.3 are still trawling the BTC net ?) but I hope that code magicians can take care of that issue  .

Now, since such a change would affect the status of TBX miner (changing it from "dude who mines cpu-coinz because he has a beefy CPU and coinz can be sold" to "dude who is directly involved with ensuring secure operation of Lolcust laundry Quasi-Value token transaction mixing system", a difference not unlike difference between "having 500 euro bills because they fit in the pocket nicely" and "being directly involved in ensuring that deals carried out via 500 euro bills do not involve double-crossing of any kind"), I think that some sorta-kinda poll should be constructed to make sure that people mining TBX have a say in a decision that will affect their activity "from  block X and forevermore" in a potentially unpleasant way.

But I think that automatic "laundry checker code" should be developed irrespective of whether we decide to splice it into miners, as there are people (to the best of my knowledge, about 6 currently, but who knows how many in the future) who would like to keep an eye on my stuff automatically, and giving them a pre-baked solution (perhaps a pre-baked ABE mod) would be neat (besides, presence of potentially unlimited number of laundry-watch stations ready to raise a horrible fuss on every available venue the moment something fishy happens to it's buffers is almost as strong a deterrent to "fishy acts" as direct "code lock", but one that operates without making every miner in the net part of laundry Quasi-Value token transaction mixing system's immediate operations.

P.S.:

Tenebrix and GG will get a little additional forum home soon. Just sayn'

P.P.S.:

keep forgetting to address a certain... issue

Anyone wanna explain the 7769999 value genesis block?

Yeah, I won't be mining this one thanks.

try fairbrix 

Damn, yet again i came in a bit too late :/

try fairbrix 

Dude, to be completely fair  , would you kindly remove the implication that high-performance FPGAs and such are likely for Tenebrix from your site ?

Current research suggests that FPGAs are economically and, as far as reasonably-priced ones are concerned, performance-wise, inferior to CPUs in this game.

[coblee]

The act of choosing which miner (the current one or the one with the laundry checking code) is a vote in itself. So I suggest we release the client with the laundry checking code. If you care more about making sure the laundry fund stays intact, then you run the new miner client. If you are more worried about not wanting to be tied to a coin laundry service, then you run the original miner client.

If in the future, there is a transaction that steals money from the laundry fund, then the chain will fork. And those people on the wrong side of the fork will likely not want to stay on their fork where the laundry fund is being misused, so they will naturally want to switch to the other fork. I think this will work itself out nicely.

[Lolcust]

The act of choosing which miner (the current one or the one with the laundry checking code) is a vote in itself. So I suggest we release the client with the laundry checking code. If you care more about making sure the laundry fund stays intact, then you run the new miner client. If you are more worried about not wanting to be tied to a coin laundry service, then you run the original miner client.

If in the future, there is a transaction that steals money from the laundry fund, then the chain will fork. And those people on the wrong side of the fork will likely not want to stay on their fork where the laundry fund is being misused, so they will naturally want to switch to the other fork. I think this will work itself out nicely.

Well, that gives "me" more power over the network, not less.

Right now, I can "merely" disrupt the market and murder a potentially very lucrative laundry business which I myself am supposed to benefit from (with my ability to disrupt market in any meaningful way constantly shrinking, though perhaps not as fast as some would have preferred), and in scenario "some miners accept laundry-murdering transactions, some don't", the person who controls the laundry has "magical network-splitting powers".

And, if your threat model is not so much "Lolcust goes insane, decides to kill his own laundry and like 98% of TBX market", but "attacker takes over the laundry, tries to sell it off" (Seems to me that the exact distinction between the two scenarios has not been made so far , and now is as good time as any), the attacker only needs to get as much as possible to an exchange before the reorg-storm invalidates his little game (as per your description "because people will likely not want to stay on their fork where the laundry fund is being misused"), with the exchange being the one to pick up the slack when reorg happens (I bet exchanges would verily not like such a prospect).

Besides, I doubt that TBX laundry could recover after having it's wallet hacked (that's why I want to avoid exposing laundry wallet to any web-like frontends, and for that matter expose the laundry-server to any incoming connections) irrespective of whether some reorg later invalidates the hacker's incursion.

Such affairs are trust-based (though BTW, people are already giving me far more trust than needed to let me run an x-mil laundry by downloading and running binaries I make, as a matter of fact), and having the laundry pwnt destroys this trust irrespective of whether the TBX in buffers are spilled on the market or not.

P.S.:

Having said all that, as TBX's genesis states, "if a technological feat is possible, man will do it. Almost as if it's wired into the core of our being", so I think creation of "miners that don't accept laundry-killing transactions" is pretty imminent

[coblee]

The act of choosing which miner (the current one or the one with the laundry checking code) is a vote in itself. So I suggest we release the client with the laundry checking code. If you care more about making sure the laundry fund stays intact, then you run the new miner client. If you are more worried about not wanting to be tied to a coin laundry service, then you run the original miner client.

If in the future, there is a transaction that steals money from the laundry fund, then the chain will fork. And those people on the wrong side of the fork will likely not want to stay on their fork where the laundry fund is being misused, so they will naturally want to switch to the other fork. I think this will work itself out nicely.

Well, that gives "me" more power over the network, not less.

Right now, I can "merely" disrupt the market and murder a potentially very lucrative laundry business which I myself am supposed to benefit from (with my ability to disrupt market in any meaningful way constantly shrinking, though perhaps not as fast as some would have preferred), and in scenario "some miners accept laundry-murdering transactions, some don't", the person who controls the laundry has "magical network-splitting powers".

And, if your threat model is not so much "Lolcust goes insane, decides to kill his own laundry and like 98% of TBX market", but "attacker takes over the laundry, tries to sell it off" (Seems to me that the exact distinction between the two scenarios has not been made so far , and now is as good time as any), the attacker only needs to get as much as possible to an exchange before the reorg-storm invalidates his little game (as per your description "because people will likely not want to stay on their fork where the laundry fund is being misused"), with the exchange being the one to pick up the slack when reorg happens (I bet exchanges would verily not like such a prospect).

Besides, I doubt that TBX laundry could recover after having it's wallet hacked (that's why I want to avoid exposing laundry wallet to any web-like frontends, and for that matter expose the laundry-server to any incoming connections) irrespective of whether some reorg later invalidates the hacker's incursion.

Such affairs are trust-based (though BTW, people are already giving me far more trust than needed to let me run an x-mil laundry by downloading and running binaries I make, as a matter of fact), and having the laundry pwnt destroys this trust irrespective of whether the TBX in buffers are spilled on the market or not.

The nice thing about this solution is that it will prevent both scenarios: Lolcust goes insane AND hacker steals laundry fund.

I'm going to assume that all exchanges will be running on laundry checking code, since it would be insanely stupid for them to not do that. So if the attack happens, the attacker would not be able to unload their stolen coins to an exchange because the exchange will not consider those transactions as valid. So in that sense, the attacker would not be able to do much with those stolen coins.

I don't quite understand what you mean by "the exchange being the one to pick up the slack when reorg happens (I bet exchanges would verily not like such a prospect)."

There's quite a difference between laundry gets hacked and coins sent to laundry stolen VERSUS 7.7 million laundry fund gets stolen and dumped on the market. The former will only hurt the future of your laundry business. The latter will kill Tenebrix altogether. So this solution should prevent the latter from happening but it does nothing for the former. You still have to protect your laundry service from hackers. But if they do somehow manage to hack into your service, at least the network prevents them from touching any of the 7.7 million coins in the laundry fund.

[Lolcust]

I'm going to assume that all exchanges will be running on laundry checking code, since it would be insanely stupid for them to not do that. So if the attack happens, the attacker would not be able to unload their stolen coins to an exchange because the exchange will not consider those transactions as valid. So in that sense, the attacker would not be able to do much with those stolen coins.

Well, exchanges are known to do silly things (ref: that Polish dude who pwnt his own exchange), and a big-time attacker could run his own exchange (the loss is essentially passed to the users who bought "pwnage coins" in that scenario)

There's quite a difference between laundry gets hacked and coins sent to laundry stolen VERSUS 7.7 million laundry fund gets stolen and dumped on the market. The former will only hurt the future of your laundry business. The latter will kill Tenebrix altogether.

1) Laundry fund isn't 7.7 mil. Given that I have pledged 2 mils to the faucet(s) aka Late Adopters and that about ~1.5 mils are reserved for dev-endeavors, it's quite less than 7.7 mils.

2) In my humble opinion, loss of laundry will be catastrophic enough to doom the project irrespective of whether the funds are dumped or "merely" lost forever

3) In about 6 years, 7.7 mil superfund will be not that super, and its ability to ruin the market won't be so immense. That is even more true for a fund of ~4 mil that is actually intended for laundry per most recent agreement.

So this solution should prevent the latter from happening but it does nothing for the former. You still have to protect your laundry service from hackers. But if they do somehow manage to hack into your service, at least the network prevents them from touching any of the 7.7 million coins in the laundry fund.

Well, like I said in the postscript (that I sadly added only moments before your response), I consider creation of "miners that do not accept laundry-killer tx" to be pretty imminent irrespective of what I, or for that matter the majority of miners, think (even if majority goes "duh", some miners will run such a thing)

I do also think that adding a Laundry-Watcher and Notification thingie to ABE would be verily nice and might get quite popular irrespective of how "laundry lockdown miner code" fares.

P.S.:
I'd like to use this opportunity to remind everyone that per current agreement, Laundry-fund isn't whole whoppin' 7.7 mils

[bulanula]

I'm going to assume that all exchanges will be running on laundry checking code, since it would be insanely stupid for them to not do that. So if the attack happens, the attacker would not be able to unload their stolen coins to an exchange because the exchange will not consider those transactions as valid. So in that sense, the attacker would not be able to do much with those stolen coins.

Well, exchanges are known to do silly things (ref: that Polish dude who pwnt his own exchange), and a big-time attacker could run his own exchange (the loss is essentially passed to the users who bought "pwnage coins" in that scenario)

There's quite a difference between laundry gets hacked and coins sent to laundry stolen VERSUS 7.7 million laundry fund gets stolen and dumped on the market. The former will only hurt the future of your laundry business. The latter will kill Tenebrix altogether.

1) Laundry fund isn't 7.7 mil. Given that I have pledged 2 mils to the faucet(s) aka Late Adopters and that about ~1.5 mils are reserved for dev-endeavors, it's quite less than 7.7 mils.

2) In my humble opinion, loss of laundry will be catastrophic enough to doom the project irrespective of whether the funds are dumped or "merely" lost forever

3) In about 6 years, 7.7 mil superfund will be not that super, and its ability to ruin the market won't be so immense. That is even more true for a fund of ~4 mil that is actually intended for laundry per most recent agreement.

So this solution should prevent the latter from happening but it does nothing for the former. You still have to protect your laundry service from hackers. But if they do somehow manage to hack into your service, at least the network prevents them from touching any of the 7.7 million coins in the laundry fund.

Well, like I said in the postscript (that I sadly added only moments before your response), I consider creation of "miners that do not accept laundry-killer tx" to be pretty imminent irrespective of what I, or for that matter the majority of miners, think (even if majority goes "duh", some miners will run such a thing)

I do also think that adding a Laundry-Watcher and Notification thingie to ABE would be verily nice and might get quite popular irrespective of how "laundry lockdown miner code" fares.

P.S.:
I'd like to use this opportunity to remind everyone that per current agreement, Laundry-fund isn't whole whoppin' 7.7 mils

So how much are you going to take then ?

[Lolcust]

So how much are you going to take then ?

Take ? ^__^

What exactly do you mean, how much will it cost to run moneyz through my laundry ? Hm... you know, I hope to keep it below BTCL's 4.555% - much below, in fact.

But it's somewhat silly to make such inquiries before beta, don't you think?

[bulanula]

So how much are you going to take then ?

Take ? ^__^

What exactly do you mean, how much will it cost to run moneyz through my laundry ? Hm... you know, I hope to keep it below BTCL's 4.555% - much below, in fact.

But it's somewhat silly to make such inquiries before beta, don't you think?

I meant how big is the cut going to be for you personally. You need a new yacht, you know

[Lolcust]

So how much are you going to take then ?

Take ? ^__^

What exactly do you mean, how much will it cost to run moneyz through my laundry ? Hm... you know, I hope to keep it below BTCL's 4.555% - much below, in fact.

But it's somewhat silly to make such inquiries before beta, don't you think?

I meant how big is the cut going to be for you personally. You need a new yacht, you know

My "cut" is laundry's profits, dude.

And I fucking hate yachts. I vomit all the fucking time.