I thought there was only 500 bytes of space allocated for free transactions, that block has over 3k and there aren't even any paid transactions.

That would probably be ok, however, you can't choose which coins to use so if you had a bunch of older coins and one new one which was exactly the size you want, I think the client would choose that one.  We'd need to combine it with a tweak to the coin selection algorithm.

I posted a thread on liteco.in earlier with some suggestions for rate-limiting.  I think if we changed that we could reduce the number of spam transactions that get through. (since we have more frequent blocks and less space reserved for free transactions we should have a lower rate limit). http://liteco.in/threads/rate-limiting-to-prevent-flood-attacks.43/

Your ssl certificate expired a few days ago,  I now get a security warning when I go to https://lc.ozco.in/

for bitcoin there is the list of Incidents  but it would be nice to have a cross-coin list.

He is probably going to figure out what types of transactions get in the block chain for free then try to send a bunch of those, pushing out genuine free transactions.  This will make litecoin less inviting to newbies which is bad.

I think we should come up with several algorithms for deciding which transactions are free and let miners decide which one to use (via a config file option)

It would also be good to let miners configure a blacklist of addresses that they don't want included in blocks.  I wouldn't want it populated by default, but if a user wanted to they could add addresses to it themselves and those wouldn't go in blocks or be broadcast to other connecting clients.

I'm not sure about when bitcoin first came out, but the minimum fee was 0.01 back when bitcoins went for around $0.10.

I also think a 0.01 fee for litecoin would be better than 0.1.  Are you going to open up a thread on liteco.in to discuss this?

I don't expect people to make changes blindly.  The more people who look at the change and post what they think about it the better.


Wow, you're really pouring on the FUD.   Yes, it is easy to see what it does.  Litecoin behaves the same way as bitcoin when faced with transactions with too small a fee, it doesn't broadcast the transactions to peers, it doesn't insert them into a block if it is mining.  It does keep them and if a block shows up with them in it it will accept the block.

So no, there aren't any forking issues, I'm not rejecting those blocks, and I'm not going to be an outcast from the block chain.


Several sites seem to have had problems with this torrent of transactions, maybe it was insufficient hardware, maybe it was something else.  Everyone should think about the value they get out of a block chain and its cost to them.  Since litecoin is very new, the value it provides is still low so if they have to have more powerful machines and dedicate more disk space to it some people will decide it isn't worth it.  Years from now, if litecoin proves to be durable this volume of transactions won't be an issue since the value people get from litecoin will be higher.  Today, it is an issue.

I know these points are moot since coblee has released an updated client, but I wanted to address your issues.

1 LTC seems a pretty steep fee.  I took out a zero in a couple of places to make the fee 0.1 when I recompiled, but I think 0.01 would be sufficient.

The good thing about this is that all these spam transactions now put a message in the log:
ERROR: AcceptToMemoryPool() : not enough fees

If everyone made these modifications the spam 0.00000001 transactions wouldn't propagate.

If you simply mine every other difficulty adjustment period you won't be taking advantage of the asymmetric difficulty adjustment.  You'd just be sending a big pulse of mining power for one period when difficulty is low then going away the next one when it is high.  You can do this on any blockchain out there.  This happened to NameCoin earlier this summer before merged mining, lots of people left which caused a huge difficulty drop then everyone rushed back in and completed two weeks worth of blocks in less than two days.

Now that there are lots of block chains out there someone is sure to come up with a script (or a pool) that switches to the most profitable one at any given time, be it bitcoin, litecoin, or solid coin.  They may stay for one (power)block or they may stay for weeks.  Lots of people will use scripts/pools with similar rules so you'll see large pulses of mining power jump among the systems. Pulsed mining will soon be taken for granted.

Where solid coin's asymmetric difficulty adjustment comes in is when 1) you have over 14% of the mining power, and 2) even after an adjustment it is still more profitable than other chains.   Number 2 is more likely with solidcoin than other blockchains since the difficulty doesn't adjust up as fast.  This happened right when it launched when there was a huge influx of miners and difficulty didn't adjust up very fast.

He's not talking about mining every other block, hes suggesting mining every other difficulty adjustment period.  So you mine the user blocks for one 360 block period then you go away for the next 360 block period.  If over 14% of the mining power does this you will come out ahead (on a per cpu cycle spent mining solidcoin) of where you would be if you mined solidcoin full time.

Interesting, you'd effectively be slowing the velocity of money.  I'd hate it if I really needed to spend that money, and it would create some odd change transactions.  Instead of freezing a percent of all coins, you could increase the waiting period before transactions are confirmed.  If value goes down, a coinbase transaction doesn't mature for 240 or more blocks, a normal transaction doesn't get confirmed until 12 blocks have passed.  I wonder how long you could freeze the funds before it had a negative impact.  I know you're thinking of enCoin which has different mechanics, but I think it would apply to either (with some variation).

Explain why this is dangerous.  The way I see it a miner creates a transaction with a huge fee but doesn't propagate it unless/until they mine a block.   If they succeed they get lower fees, if they fail, they flush the transaction.  It seems like it has no downside.

If you only include transactions that have the minimal fee you eliminate the ability for someone to pay extra to get priority service (only really important if block sizes are nearing the maximum).  You also penalize transactions that are using a different algorithm that happens to be more generous, that seems like an odd thing to do.

The current block being a Power Block depends on both the last trusted block and the last user block:

    if(trustedcount>=128 && usercount>=239) return true;        //1 in 16 chance for user, 1 in 2 for trusted, = 1 in 32 total

As of now, there is only one control node generating trusted blocks at a time.  This control node can effectively "turn off" power blocks entirely, or double the probability of one occurring, or anything in between.

When a control node generates a block it can count up the bits, if they are >= 128, it could discard the block and generate another one instead of transmitting it.  It could be a bit more clever by checking if the prior user block was >=239 before deciding if it should discard the block it just generated, this would minimize the impact on the network.

A control node could increase the probability of a power block in a similar way.  It could discard blocks it generates unless they meet the criteria for power blocks ( bits >=128 ) this would make the power blocks be entirely depended on the prior user block, gving it a 1 in 16 chance.

I think Microsoft's assumption of a directed graph oversimplifies things to the extent that in invalidates their research.  In short, a node always has an incentive to try and follow the chain back towards the source to insert themselves higher in the chain and to shorten it.  This gives them a larger reward.

Acording to their  paper, each node in the chain up to a depth of 'H' gets a reward B.  The node that solves the block gets a fixed reward plus some additonal reward based on how much shorter than H the chain was "1+(H-L+1)B"  This means the shorter the chain is, the greater the reward that goes to  the miner.  For simplicity, lets take H to be 4 and a chain of the full length:

NodeA
NodeB
NodeC
NodeD

NodeD solves the transaction so gets a reward of 1+(4-4+1)*B = 1+B. The total reward would be B for NodeA, NodeB, and NodeC and 2B for NodeD for a total of 1+4B.  However, if NodeD were able to contact NodeA directly the chain would be:

NodeA
NodeD

Node D again solves the transaction but this time its reward is 1+(4-2+1)*B = 1+3B with nodeA getting the remaining B, the total reward is still 1+4B.

Initially NodeD doesn't know how to contact NodeA, it only has a public key not an IP address, however, over time, as NodeD sees more transactions it will be able to associate particular keys with particular IP addresss.  For instance, in the first example, NodeD learned what NodeC's ip address is since it got the transaction directly from it.  In the event that NodeD didn't know how to contact any other nodes in the chain, it would be to its advantage to contact every node it knows and ask for the transaction in the hopes that one peer would be part of a shorter chain, this could greatly increase the amount of traffic that goes over the network.

The stated goal of the paper was to incentivise forwarding of transactions by paying intermediate nodes.  Intermediate nodes, however, would be cut out of the chain fairly quickly so would have the same incentive they have today (which is none, but that may not stop them from forwarding).

This scheme could have a perverse effect though.  Right now you can't gain any real advantage by trying to monopolize the connections a node has.  Under this proposal you would.  If all the nodes connected to a particular originating node were controlled by you, you couldn't be cut out of the chain since no one would know how to contact the originating node.  Instead of encouraging more peers by providing them with fees, it would encourage more centralization.

Taking advantage of SoldCoin's PowerBlock weakness is easy.  All you have to do is modify the get_work function to return an error unless the current block being mined is a power block.  Even when you are solo mining you still go through the rpc interface for getting work.  This won't work if you are using someone else s pool because the check is done in the server before get_work returns, however, if you have several computers you can set them all to mine against a single solid coin instance and have your own mini-pool.

Here's all you need to do:
Open  rpc.cpp

after line 2106: "BLOCK_DATA blk;" add the line:
int isPowerBlock = 0;

after line 2153: "blk=pBlock->blk;" add the line:
if(pBlock->m_bPower) isPowerBlock = 1;

before line 2174: "return result'" add the line
if(!isPowerBlock) throw JSONRPCError(-10, "This is not a Power Block...");

Recompile, restart solidcoin, and start solo mining.  Your Hash Rate will be at zero and you'll see a steady stream of messages:
sc_getwork error: This is not a Power Block...

When it is time to mine a power block your Hash Rate will go above zero until the block is solved (by you or someone else) then it will go back down to zero as it waits for another power block.

If you are mining other coins at the same time, you'll want to 'nice' them so that solid coin gets most of the cpu when it is running.  (you should nice them anyway so mining doesn't slow down the rest of the stuff running on the computer.)  You can start your miners niced by putting "nice +19" in front of your minerd command like so:
nice +19 minerd --url http://example.com ---userpass greater:fool

You wouldn't want to 'nice' solidcoin so it gets more of the cpu when it is running.

Modifying the built-in miner to do exactly this is incredibly easy.

According to SolidCoin, there is a 1 in 32 chance that a block is a PowerBlock, the number of coins you generate in a power block is double a normal block.

You can't use a random function to determine if a block is a powerblock because other clients wouldn't be able to verify it.  You also can't use information in the block being generated because a miner could manipulate it to make every block a power block.  The only thing you can use is the block chain since that's the only state that all clients share, and, that is what solidcoin does.

Here's the code that determines if a block is a power block:

bool Block_IsPowerBlock(const uint256 &trustedhash,const uint256 &userhash)
{
    unsigned char trustedcount=trustedhash.SumOfBytes();
    unsigned char usercount=userhash.SumOfBytes();
    if(trustedcount>=128 && usercount>=239) return true;        //1 in 16 chance for user, 1 in 2 for trusted, = 1 in 32 total
    return false;
}

It is called with the two previous block's hashes as arguments.

Since you can tell if a block is a power block just by looking at the hashes of two prior blocks, you can decide if you want to mine the block or not. You can choose to only mine power blocks.

I don't think this works out to exactly 1 in 32 blocks in practice since a good hash has to have some number of leading zero bits, as the difficulty gets higher the chance of a block being a power block goes down slightly.  Although this is unintended, it probably isn't bad.

If you only mine powerblocks, you'll get a higher payout for your cpu cycles. Most of the time (about 56 minutes per hour) you'll be idle. During the down times you can mine some other coin (like litecoin, or another cpu-friendly coin).

People have talked about using "balance sheets" to do exactly this.  See https://bitcointalk.org/?topic=473.0 and https://bitcointalk.org/?topic=505.0 for a more complete discussion.

If you got the note from someone else, how would you know if one of the prior owners was colluding with the bank?  Let's say your employer pays you with bit notes.  Unknown to you, your employer didn't get them directly by depositing money in the bank but bought them on the secondary market.  What if the bank was selling it's own notes on the secondary market (and your employer bought them from that bank without knowning it), ie, the bank was one of the prior owners?  Then it would have everything needed to spend the money on deposit.

I think on each transfer you would have to not only get a new secret from the bank, but generate a new private key, which means you'd have to have a bitcoin transaction, which is what you were trying to avoid.

Now it is up to around 15, right around half the network.  And all of it in the "other" category, not in one of the pools.  It could be an attack, or it could be a user with a lot of cpu's.  Should make for an interesting couple of hourse.