Bitcoin Forum
January 23, 2022, 02:36:48 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: [Official] So what happened to Elacoin? on: May 14, 2013, 07:05:03 AM
1. I give the source with everything ready to Hazard
2. Hazard mines 1.3k blocks, and distributes the source


The source that Hazard posted contained the old, pre-release genesis block, the only difference in main.cpp from what I got off of github yesterday was this:
diff ../../elacoin-hazard/src/main.cpp main.cpp
887c887
<       diff = GetDifficulty2(FindBlockByHeight(nHeight-1));
---
>       GetDifficulty2(FindBlockByHeight(nHeight));


(Granted, I downloaded it about 20 pages after he posted it so I have no way of knowing if released the source with the real genesis block then changed it later)
2  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][Exchange Confirmed] PowerCoin PWC RELEASE IS NOW! on: May 13, 2013, 02:49:09 AM
Fun watching the debug log as the blocks come in.  Looks like there is 1 or 2 a second.  Also seeing lots of long block chain re-orgs:

REORGANIZE: Disconnect 6 blocks; 42f941a6031dc3b41af2..cc03f278f04afbde208a
REORGANIZE: Connect 7 blocks; 42f941a6031dc3b41af2..0c8845a4d9d15e7a7507

REORGANIZE: Disconnect 5 blocks; 42f941a6031dc3b41af2..40341ca5c6965be3481e
REORGANIZE: Connect 6 blocks; 42f941a6031dc3b41af2..cc03f278f04afbde208a

REORGANIZE: Disconnect 4 blocks; 42f941a6031dc3b41af2..4acdf17c62282444c8f8
REORGANIZE: Connect 5 blocks; 42f941a6031dc3b41af2..40341ca5c6965be3481e

And the longest I've seen:
REORGANIZE: Disconnect 13 blocks; f243992c9eda69cee1e7..71117064476dd175253f
REORGANIZE: Connect 14 blocks; f243992c9eda69cee1e7..311620c256d3b658ff55

and

REORGANIZE: Disconnect 15 blocks; 651da75d037edf65f818..6788c730fb52a72f2a41
REORGANIZE: Connect 16 blocks; 651da75d037edf65f818..c9039814ed1318c2e2ce

3  Alternate cryptocurrencies / Altcoin Discussion / Re: Terracoin Dead or Dying ? on: April 07, 2013, 09:28:32 PM
While i do support terracoin i think the issue of someone poining asics at the network and thrus forcing up the difficulty of a reletively new coin shows a major flaw in most alt-coin designs - using the same algorythm as bitcoin, imho any alt coin that wants to stand the test of time and actually be taken seriously is going to need a difference algo - take litecoin as the perfect example, different algo and it's followed the same mining evolution as bitcoin.

I agree.  History has now shown that starting an alt coin that uses the same hashing algorithm as an existing, strong, coin is a bad choice.  We now have had several examples of this.

The first was Namecoin, where the difficulty went way up then mining power left and it was stuck for several months at super-high difficulty.

The next was CoildCoin (CLC).  It had merged-mining right from the start in an attempt to have a higher hashrate. However, Luke-Jr (who controled the Elgius pool at the time) set the pool to merge-mine it and not allow anyone elses blocks or allow any transactions in his blocks.  Since Elgius had a much higher hashrate then the rest of the network, he was successful and the network stalled.

For Terracoin (TRC) a single person with a bitcoin ASIC starts mining and causes the difficulty to fluctuate wildly (first difficulty calculation method) or causes it to go up and stay up (second difficulty calculation method).  That person had over 50% of the hashpower and could have done much more damage (and still can if they want to).  They could mine their blocks exclusively, ignoreing any blocks found by anyone else, thus getting all the block rewards, excluding others transactions, and doing double spends at will.

re-using the same hashing algorithm sounds like a good idea, it takes less effort, you don't have to worry about introducing new bugs, and you can take advantage of all the optimized software/hardware to get your hashrate up.  However, an attacker has access to the same software/hardware that you do, may already have a lot of it, and, often has a vested interest in a different coin succeeding so have a reason to use those resources to attack a new chain.

This is certainly true for sha256 and is mostly likely true for scrypt now (if not, certainly when scrypt fpga's come out it will by).
4  Alternate cryptocurrencies / Altcoin Discussion / Re: Terracoin Dead or Dying ? on: April 07, 2013, 08:37:36 PM

quote from terracoin-announce ml :

Quote
Subject:     [Terracoin-announce] build 0.1.3-29 available

This update will bring back a shorter period used in difficulty
computation, until a better algorithm is implemented, making the network
resilient to the huge hashrate spikes we recently saw.




So this means that there is going to be another mandatory update sometime in the near future with yet another difficulty adjustment algorithm?
5  Alternate cryptocurrencies / Altcoin Discussion / Re: MC2: A democratic cryptocurrency based on a hybrid PoW/PoS system on: April 07, 2013, 08:32:08 PM
I like the idea, but have a couple of comments

whitepaper: "BLAKE512, SKEIN512, SHA3-512 (KECCAK512), and SHA2-512 are incorporated with both Salsa20 and Chacha20 stream ciphers."

I like how this makes fpga's and asics harder, but it also means that if there is a flaw in any one of these hashes or stream ciphers then the coin fails.  Is there any other way to achieve this goal?



whitepaper:  "Transactions will largely stay the same as in BTC; coin age will be calculated from the the timestamp of the block in which it appears."

Why calculate from the timestamp and not the block height?  timestamps can be incorrect, the block height can't be. They both give estimates since the block height to time calculation is based on the target block time that isn't always met, but it is good to base as much as possible on truths inherent to the blockchain.
6  Alternate cryptocurrencies / Altcoin Discussion / Re: Coin Mixer currency. on: March 06, 2013, 04:16:18 AM
What if an alternate currency had a large reserve of coins which would be used for a giant coin mixing service for that currency ?

For example opencoin and their 80 billion spare coins could accept "tainted" ripples and swap them out for fresh coins.

Its probably not going to happen for obvious reasons  Cheesy


You should try Tenebrix: https://bitcointalk.org/index.php?topic=45667.0
Quote
Q: I heard you premined, you bad bad person...

A: Well yes, I premined 7 million coins. Why so many - well, to be completely blunt and honest, I got a bit tired of a discussion of how much should one premine that I had going on and used the premine value from GeistGeld. Perhaps not the wisest decision, but worry not though - I will use 2 millions do fuel verry slow (no more than 4 TBX per user, may get less if their price rises) faucets with strong user ID (Google Acc + captchas), and about 1.5 mils are set aside to help recruit developers and sustain support for no less than 6 years (you gotta agree that it is a looong road and a lot of money-gulping things can happen)

I will use the rest to start a unique transaction-anonymization service, using them as a buffer of sorts (old TBX + fee enters, crispy TBX from reserve exit in a certain randomized manner. In the end, I keep only the "fees" and the "old TBX" that entered the service are retained to form a new buffer as old one shrinks. Thus, the amount of TBX destined for buffer remains static forever, and never ever enters circulation, sequestered as a "transaction mixing service buffer" forever. I think we can all agree that stronger transaction mixing is a good thing and a benefit to community Smiley )

Should be done "real soon now" Smiley
7  Bitcoin / Bitcoin Discussion / Re: ZeroHedge on: March 04, 2013, 02:50:19 AM
One self-assured genius went so far as to suggest jugs of Tide were a better form of "currency" than BTC.

The poster was probably alluding to an article like this one: http://www.usnews.com/news/articles/2012/03/14/pilfered-tide-detergent-new-drug-currency

Authorities say a bottle of Tide detergent is relatively easy to steal, hard to track, and can fetch anywhere between $5 to $10 on the black market. Normal retail prices range from $10 to $20.
8  Alternate cryptocurrencies / Altcoin Discussion / Re: Terracoin faucet on: February 18, 2013, 07:08:17 AM
Hello,

Maybe someone already heard about me  Wink
I opened a litecoin faucet few days ago and, as I said, now I opened another one for an alt-coin.

Terracoin faucet:

URL: http://coinofmidas.com/terracoin
You can get free coins every 60 minutes. You will receive a percent of the total balance. For testing I added around 10 TRC.

If you have any suggestions or if you find any bugs, contact my via PM here or use the contact page from the faucet.

Enjoy :-)


I like that you are hosting multiple faucets, thanks.

If these are funded by advertising revenue, how are you going to allocate the revenue between them?  Are you tracking which page/faucet the click came from, dividing it equally, dividing it based on number of faucet requests, or something else?
9  Alternate cryptocurrencies / Altcoin Discussion / Re: Free Terracoins just post your wallet! on: February 18, 2013, 07:04:08 AM
Giving out 2 terracoins per person that posts their wallet. Have a lot of them atm so I will try to keep this faucet open for a while =].

Yes please: 1M7pkz73gX4vkeUACGQaTtgf9T6XyRiXV8
10  Bitcoin / Bitcoin Discussion / Re: New Bitcoin ODP (Open Directory Project) Editor on: December 31, 2012, 11:12:12 PM
I'd have the structure be like this:
# Alternative Monetary Systems
   # Crypto Currencies
      # Bitcoin
      # Litecoin
      # ...
   # Local Currency Systems

I wouldn't put 'market' under data either.
11  Alternate cryptocurrencies / Altcoin Discussion / Re: Idea to reduce deflation on: February 07, 2012, 03:14:03 AM
My idea is to have the amount of coin produced be higher when the difficulty is higher.  To give an extreme example, lets say that when that when the difficulty is doubled, the block reward is also doubled.  If this new coin gets popular, the price will go up.  When the price goes up it will be profitable for people to buy mining hardware (or turn on the hardware they already have) so more people will mine.   Since more people are mining, the difficulty will go up.  Since the difficulty goes up, the block reward will go up.  With more coins being created, the price will begin to go back down.  With the price going back down, the difficulty will follow.
Solidcoin does this (or did this, with the last change I'm not sure it still does).

I think a better way to capture changes in demand would be to base the reward on  the rate of change of the difficulty instead of the absolute value of the difficulty.  If the difficulty is rising rapidly, the block reward goes up.  If the difficulty isn't changing, the block reward goes back to the standard 50 coins per block.  For example, if the difficulty re-targets from 1,000 to 1,500 then the amount of coins per block goes to 75, if, at the next retarget the difficulty stays at 1,500 then the reward goes back to 50, if it jumps to 3,000 then the reward would go to 100.  This keeps technological breakthroughs from having a permanent effect.  The exact percentage to raise it, and how long to keep it raised would have to be determined.
12  Bitcoin / Development & Technical Discussion / Re: The way how to double protection bitcoin network against 51% attack on: December 24, 2011, 03:16:15 AM
My service would essentially be to offer a tiebreaker to choose the more legitimate of two competing blocks, each hint I sign would be open to scrutiny.  If I start publishing crap (for example, I am favoring a revision of a block that contains an obvious double spend against an earlier revision of that same block, or condemning a block with perfectly valid transactions, or am attempting to roll back several blocks at the same time without a flamingly obvious well-known good reason), people would see this, they would ignore me and go elsewhere for the same service.
But it would take hours, if not days for enough people to notice and start ignoring you.  In that time a lot of damage would be done.
13  Alternate cryptocurrencies / Altcoin Discussion / Re: Innovation in the alt chains on: December 24, 2011, 03:00:59 AM
I had hoped that they would be full of interesting experiments with different transaction types or smart contracts or different fee-setting algorithms or maybe some innovative scheme for instant transactions.
These things are very complicated and take a long time to understand, I doubt there are more than a few people in the bitcoin community that really understand them. I'm not even sure these things belong in the block chain instead of being handled outside of it (via Open Transactions or something similar).

Instead, it seems like you've been too busy dealing with low hashrates and transaction-spam attacks, and have been spending all of your time re-inventing a lot of infrastructure (exchanges and block explorers and mining pool software and etc.).
Extending the single-purpose bitcoin infrastructures (exchanges and block explorers and mining pool software and etc.) to be multi-coin is a real accomplishment.  Sites like allchains.info, blockexplorer.sytes.net, and the multi-coin exchanges are a big improvement over having lots of coin-specific sites.  You might not consider them innovative, but you aren't giving them enough credit.

Most of attacks on the alt-chains were possible against bitcoin too, bitcoin was just lucky that no one attacked when it was young and didn't have the value it has now.  Even so, a well-funded adversary could easily spam the bitcoin block chain.  Be glad that these issues are being worked out on the alt-chains where the stakes aren't as high.

There has also been a lot of experimentation with the fundamental economic models.  No one knows if  a coin should be deflationary, inflationary, or stable-value, nor do they know the best way to accomplish the goal.  Pre-mining to provide funding for improvements versus no premine and no funding for improvements has been another area of experimentation (it looks like pre-mining lost). The economic basis for a coin can't be changed easily (if at all) so it isn't surprising that is the first area that is worked on.

Merged-mining is pretty innovative, as is namecoin,  both were developed this year.

I'm curious to hear what other people think:  will altchain innovation pick up in 2012?  Am I irrationally biased and just not seeing the awesome power of (insert-your-favorite-altchain-feature-here)?
I think you are trying to get people riled up so that they try and prove you wrong.

I wonder if that means the experimentation will only happen with brand-new blockchains, and if a blockchain will only really take off it the inventor manages to "get it 99% right" the very first time...
Your probably right on this.  It is very hard to make substantial changes to an existing block chain.
14  Alternate cryptocurrencies / Mining (Altcoins) / Re: An (even more) optimized version of cpuminer - LTC/FBX/TBX on: December 20, 2011, 01:36:48 AM
That's an impressive improvement.  It doubled my hash power with a small decrease in power consumption.  My spidey sense is tingling, there will be a big jump in difficulty soon.

On the old miner I found that I'd get a small increase in hash power by running more threads than cores, for this one there isn't any advantage to extra threads.
15  Bitcoin / Bitcoin Discussion / Re: Internet Archive (Home of the Wayback Machine) Accepting Bitcoin Donations! on: December 13, 2011, 02:50:15 AM
I have to say that I'll break my pledge at this time meaning that I am not donating a satoshi until my concerns are noted. I'm extremely unhappy with the positioning of that Bitcoin donation link, it's not up there with the other donation methods. I would have NEVER found it if I wasn't explicitly looking for it. I'm sorry to be this negative but I'm genuinely pissed about this.

The purpose of the Internet Archive isn't to publicize bitcoin, it is "universal access to all knowledge".  Their accepting bitcoin is great, breaking your pledge because they don't position it as prominently as paypal seems rather petty.
16  Other / Beginners & Help / Re: What's the first thing you're gonna do when you become a Jr. Member? on: December 02, 2011, 08:01:09 AM
I'm going to come back to the newbie forum and post on random threads.
17  Alternate cryptocurrencies / Altcoin Discussion / Re: [Announce] Fairbrix relaunched! on: December 01, 2011, 04:26:16 AM
Yes, both fairbrix and tenebrix are susceptible to the same transaction spams. I do not plan to update fairbrix with the fixes. If anyone wants to keep fairbrix alive, feel free to take over.
I won't be taking over, but since I have been digging around the litecoin code recently I decided to see how hard it would be to port my changes to fairbrix.  If people are really still interested in fairbrix they should put together a bounty pool to pay for future updates.

I made changes in line with what coblee did for litecoin, but modified them some to take into account the differing block times and current value of a coin.  I've also put in some other changes that I think will help fairbrix resist attack in the future.  All the changes I made relate to spam transactions being included or relayed by honest nodes.  If an attacker controls a significant portion of the hash power (a real possibility in fairbrix) he can bypass these checks and write 1,000,000 byte blocks.

You can get the source from: https://github.com/beecee1/Fairbrix   sorry, no pre-compiled binaries.

If you like what I have done, you can donate: fVQZtuBPRdVjbNskqHLB4e75Uq64dM9vWN

Here is a description of all the changes I made (and, you have the source code so you can verify it yourself).


In main.h:

From:
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
To 125,000 bytes:
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/8;
Why: reduces the size of a block that an unmodified client will generate, helps protect against block-chain growth attacks


From:
static const int64 CENT = 1000000;
To:
static const int64 CENT = COIN/100;
Why: easier to read, no real change


From:
static const int64 MIN_TX_FEE = 50000;
static const int64 MIN_RELAY_TX_FEE = 10000;
To:
static const int64 MIN_TX_FEE = 1000000;
static const int64 MIN_RELAY_TX_FEE = MIN_TX_FEE;
Why: increase the minimum fee (when fees apply) to 0.01.  This is less than litecoins so you that the fee isn't quite so large when you send an output that is nearly a cent.  However, there is code elsewhere that will increase this fee for very small outputs.


From:
int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:
int64 nMinFee = (1 + (int64)nBytes / 500) * nBaseFee;
Why: This makes large sized transactions cost a more than before.


From:
if (nNewBlockSize < 27000)
To:
if (nNewBlockSize < 12000)
Why: since blocks are faster than in bitcoin, reserve less space for free transactions.


From:
        if (nMinFee < nBaseFee)
            BOOST_FOREACH(const CTxOut& txout, vout)
                if (txout.nValue < CENT)
                    nMinFee = nBaseFee;
To:
        BOOST_FOREACH(const CTxOut& txout, vout) {
            if (txout.nValue < CENT/10) { // outputs smaller than 0.0001
                nMinFee += nBaseFee * 10; // fee of 1
                smallTxOutCount++;
            }
            else if ((txout.nValue < CENT)) {
                nMinFee += nBaseFee;
                smallTxOutCount++;
            }
        }
Also add:
        if(smallTxOutCount > 15)
            nMinFee = MAX_MONEY;
Why:  This is the core change to limit dust spam.  Instead of a flat fee for small outputs charge a fee for each small output.  If there are more than 15 small outputs than don't allow the transaction at all.




In main.cpp

From:
if (dFreeCount > GetArg("-limitfreerelay", 15)*10*1000 && !IsFromMe(*this))
To:
                dFreeRelay = GetArg("-limitfreerelay", 5)*10*1000;
                dPartialRelay = dFreeRelay * 0.75;
                dNewFreeCount = dFreeCount + nSize;
                if( !( dNewFreeCount <= dFreeRelay
                    || dFreeCount < dPartialRelay
                    || IsFromMe(*this)
                  )
                )
Why: another spam attack mitigation. Don't relay more than (on average) 5000 bytes of free transactions a minute.  This is roughly equivilant to 20 normal sized transactions per minute, which is far in excess of the current volume.


Add:
        (nHeight == 15000 && hash != uint256("0x7c7fc755c19616fd3eb156b53dae2bbf058972e0731f3d0ee54785cc222f4bbf")))
Why:  add a checkpoint lockin at block 15000



From:
bool fAllowFree = (nBlockSize + nTxSize < 4000 || CTransaction::AllowFree(dPriority));
To:
bool fAllowFree = (nBlockSize + nTxSize < 1800 || CTransaction::AllowFree(dPriority));
Why:  Since blocks are faster in Fairbrix, don't allow as many exempted free transactions. (But they are slower than Litecoin's so allow more than that).



In wallet.cpp:

From:
int64 nPayFee = nTransactionFee * (1 + (int64)nBytes / 1000);
To:
int64 nPayFee = nTransactionFee * (1 + (int64)nBytes / 500);
Why: matching a change made in main.h

18  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Litecoin - a lite version of Bitcoin. Launched! on: November 23, 2011, 02:26:31 AM
Err, by being gone I mean "the entire client doesn't load, outside of a process in explorer called litecoin-qt, using 400MB of RAM, and litecoind -getinfo says that the server is not running." The problem isn't my coins being gone, it's the whole client. I can still use litecoind, but I'm lazy and prefer the gui.
I have a minute or so of delay between when the splash screen goes away and the gui shows up.  How long have you waited?  If you have tons of spam transactions it could be a while.

Check the debug.log, I'm not sure where it is under windows but look in the same directory as the wallet.dat file.  If it is still getting written to then the process is still working and hasn't gotten around to showing the window.
19  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Litecoin - a lite version of Bitcoin. Launched! on: November 21, 2011, 11:58:26 PM
I like the idea of charging higher fees for lots of small outputs, however, we risk capturing small-but-useful transactions in the mix.  I also want to have fee formulas we can keep instead of temporarily changing them and planning on changing them back.  Instead of two tiers we could have three with only the lowest tier getting charged per-output fees
large value = no fee
small value = .1 fee per transaction
very small value = .1 fee per output

Make "very small" be 10% of small and all these too small to be useful even when aggregated transactions are really expensive, but leaves open the possibility of small but potentially useful transactions (like paypershare mining)

Why do you draw the line at 0.001 ltc? is there really a special use case where someone would need to send tons of ~0.005 ltc to other people and only pay .1 in fees?

It is really just an acknowledgment that my imagination is limited and other people might be able to come up with something useful that wouldn't be possible with higher fees. Pay per share mining is one possible example, but I haven't every joined a pay per share pool so I don't know what they do when someone is due a very small payout.  I'm also thinking that if someone started trying to spam with >= 0.001 ltc then it would quickly add up to a useful amount of ltc.  Dust spam would still be prohibitively expensive though.

We can also have a higher fee for large-sized transactions.
From:        int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:          int64 nMinFee = (1 + (int64)nBytes /  500) * nBaseFee;

I've thought about this, but that's effectively just doubling the nBaseFee. So I'd rather change the base fee than mess with that code b/c there are other places that expect 1*basefee per 1000 bytes. (like the GUI)
It isn't quite the same since we use nBaseFee other places, like in the small transaction case.  If it is too hard to change then it might not be worth it.

Code:
            BOOST_FOREACH(const CTxOut& txout, vout) {
                if (txout.nValue < (CENT/10))
                    nMinFee += nBaseFee;
                else if ((txout.nValue < CENT) && (nMinFee < nBaseFee))
                    nMinFee = nBaseFee;
            }

I may want change CENT here to nBaseFee/10. As Litecoin gets more popular, and ltc price goes higher, what's classified as dust spam should also be lower.

I like your concept of auto-scaling the definition of spam.  Much better than requiring periodic intervention.
20  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Litecoin - a lite version of Bitcoin. Launched! on: November 21, 2011, 11:13:52 PM
Basically, we were setting min fee to at least 0.1 LTC if any of your output is less than 0.01 LTC. I'd like to extend that to add 0.1 LTC for every output less than 0.01 LTC. So using sendmany to send to 1000 outputs is fine as long as you are paying the 0.1 LTC fee per 1000 bytes. But if you are sending 0.00000001 LTC to each of those 1000 outputs, then you need to pay an additional 100 LTC in fees.

        // To limit dust spam, add MIN_TX_FEE/MIN_RELAY_TX_FEE for any output is less than 0.01
        BOOST_FOREACH(const CTxOut& txout, vout)
            if (txout.nValue < CENT)
                nMinFee += nBaseFee;

The spammer can still send a ton of 0.01 outputs, but this will deal with the dust spam. It's really hard for the receiving end to collect these worthless transactions.
I like the idea of charging higher fees for lots of small outputs, however, we risk capturing small-but-useful transactions in the mix.  I also want to have fee formulas we can keep instead of temporarily changing them and planning on changing them back.  Instead of two tiers we could have three with only the lowest tier getting charged per-output fees
large value = no fee
small value = .1 fee per transaction
very small value = .1 fee per output

Make "very small" be 10% of small and all these too small to be useful even when aggregated transactions are really expensive, but leaves open the possibility of small but potentially useful transactions (like paypershare mining)

If we are making the fees additive, we'd want to remove the "if (nMinFee < nBaseFee)" check so people can't escape the per txout fee by making the block larger.

We can also have a higher fee for large-sized transactions.
From:        int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:          int64 nMinFee = (1 + (int64)nBytes /  500) * nBaseFee;

That would only have an effect on blocks larger than 27000 bytes (but we could make that smaller too).
Code:
            BOOST_FOREACH(const CTxOut& txout, vout) {
                if (txout.nValue < (CENT/10))
                    nMinFee += nBaseFee;
                else if ((txout.nValue < CENT) && (nMinFee < nBaseFee))
                    nMinFee = nBaseFee;
            }

This would be independent of any nMinFee scaling that was done based on difficulty.
Pages: [1] 2 3 4 5 6 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!