Bitcoin Forum
May 22, 2018, 08:30:40 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 ... 93 »
381  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 09, 2013, 08:18:51 AM
1) Smaller transactions - transactions could use just account tree offsets instead of addresses / public keys. We can address more accounts than we will probably ever need with 5 bytes. Addresses takes 25 bytes and public keys 65 bytes.

In addition to this, 32-byte hashes are not necessary to verify receipt of previous transactions. Peers who have not even communicated with each other before can reference transactions like so:

[timestamp - 4 bytes for each second]
[2-4 bytes of account offset, depending on what is most useful based on transaction activity - 2-4 bytes once for each tx that shares this offset]
[remaining 1-3 bytes for account offset]+[1 byte pseudo-hash]

The 1 byte pseudo-hash could be bigger, but it limits one account to 256 transactions per second, although the client will have to be aware of pseudo-hash collisions. When Visa is only like 4,000 transactions per second, this can't be that big of an issue. So the maximum one transaction could cost in wasted bandwidth is 10 bytes, but on a busy network, most transactions will only cost around 3 bytes to verify receipt or reference it with another peer. This is presuming my initial idea of using timestamps to identify specific transactions. It also allows for an easy way to locate transactions in the transaction block chain, though this is going into my design, but it's the one I know. *shrug*

Although bitcoin could use some protocol tweaking, it still *at best* has to send 32 bytes, but right now just goes ahead and wastes the full 300 bytes or whatever a typical tx is. 32 bytes->3 bytes on a busy network is gigabytes saved daily per node.

Quote
2) Including messages in transactions. We don't need to store transactions indefinitely so we can permit short messages attached to payments (eg. order id). This would improve user experience a lot.

8 bytes I think is an ideal number that allows for setting up a receipt/order system/identity proof. I think bank-like intermediaries (preferably anonymous ones, but that is technology that has to be proposed and advanced outside the network) will be commonly used to preserve anonymity. Account ledgers have some caveats that they are slightly less anonymous than pseudotransactions a la bitcoin. Reusing account numbers needs to be encouraged by lower transaction fees, because it is in the interest of the health of the network. If there are intermediaries that provide you with 8-byte mini-addresses, you can preserve that anonymity completely from everyone except the bank, unless there are ways to provide this anonymously in the future. Those who want bitcoin's pseudonymity can still do it, but tx fees will be higher.

Quote
3) We can get rid of sending change back to ourselfs because we can spend any amount of bitcoin from our account.

This is considered part of bitcoin's pseudonymity as only you and the receiver know which part of the tx is the payment and which is the change. But we all know that bitcoin isn't all that anonymous, and with an account ledger making things even trickier, the idea of pseudonymity needs to be redressed.

Quote
1) Accounts with descriptions. We can allow attaching custom names to account eg. 'Payment address for shop.example.com'. This description could be presented to users paying to this address. Huge user experience boost.

I had this idea for early encoin proposals, but I don't like it because it will create a rush of custom address stealing. If businesses are public on the chain, users can associate the addresses manually. If they use intermediaries, this could still be addressed with using business->user account numbers in the tx message.

Quote
2) Multi signature accounts. We can make accounts with multiple pubkeys attached and require M of N signatures to spend from this address.
3) Limited accounts. We can define maximum withdrawal limits per time period for accounts.

Easy peasy stuff with a ledger. Gotta make sure to have "master" keys that can change those account options, not the accounts themselves. Keep the master key cold and let the hot wallet do its work without fear of a total catastrophe if there is an incident.

Quote
4) We can extend account types if needed. This system is actually more powerful than bitcoin scripts (we can always make accounts with scripts).

Yes, but there needs to be a process of acceptance for this. Say, a voting system. Wink Even if account types are just complex uses of the scripting system, to save the data required to store these simply (and to make sure everyone has the exact same ledger), the account "types" need to be defined and everyone needs to agree on it.

Quote
Feel free to extend this list.

Anyone who plans on reusing a custom transaction could set a custom transaction type up themselves, basically a script-hash storage system. Then it could reference the custom type in a tx and only supply the variables needed to suit the script-hash, saving data. Of course there have to be fees to store this stuff, but people who use the same script-hash a lot could save money on a fee-per-function type tx fee.

A somewhat out-there possibility is to have a proof-of-work storage function. Small networks could use the ledger's proof-of-work (or proof-of-consensus) as a timestamping service and have the final say on the order of that network's events.

I have some other ideas somewhere, but it would require digging up really old notes.
382  Alternate cryptocurrencies / Altcoin Discussion / Re: MC2 ("Netcoin"): A cryptocurrency based on a hybrid PoW/PoS system on: May 09, 2013, 01:45:22 AM
Sigh.  Undecided

Can you actually address ANY of the points that people are ACTUALLY bringing up? Strawmanning is uncool.

You're asking someone head-deep in bitcoinomics making arguments that are based around bitcoin-only definitions of inflation and deflation and relating currency to stocks/businesses etc. to make reasonable arguments. It isn't going to happen. Any coin that adopts yet-another-stupid-deflationary scheme is going to lose out to one that drops this nonsense once and for all. The scheme you're probably looking for is in my signature.
383  Alternate cryptocurrencies / Altcoin Discussion / Re: http://ripplescam.org/ on: May 08, 2013, 03:55:38 AM
that's quite a read; do you have a cliff notes version?

i'll try to digest it over the md weekend -- look forward to discussing

Check out the 4th post and see if that helps. The money supply is intended to expand when the people deem it necessary, and do so without using much energy, while also retaining bulletproof security and using an insignificant amount of energy when no new money is necessary.
384  Alternate cryptocurrencies / Altcoin Discussion / Re: Need an energy efficient algo on: May 07, 2013, 11:14:19 PM
You are never going to have an energy efficient coin if proof of work is required to secure the network. You can also, with some ingenuity, have a coin that is both ASIC and botnet unfriendly. It just has to be mining-unfriendly in general. The link is in my signature for such a proposal.
385  Alternate cryptocurrencies / Altcoin Discussion / Re: http://ripplescam.org/ on: May 07, 2013, 11:00:48 PM
The magic number would be correlated with long term real economic growth rate.  Trying to set the money supply growth constant at 2% is likely closer than setting it to 0% yet it has the same flaw that if your number is lower than the observed monetary demand, you will get deflation, if your number is higher you will have built in inflation.

The fractional reserve system allows banks to react to deviations from equilibrium as numbers are observed

If the algo to set money supply growth rate can take in real values of what is transacted on a regular basis then it would solve the problem completely.  Not sure if this is feasible.

i like the way this sounds

+1
I don't think this is feasible. I could run a script to transfer money from A to B all the time. If you are thinking of "oh, then hard code a case to ignore that", you're thinking in the wrong direction because I'll just transfer from A to [B or C or D] to [A or B or C or D].

yeah, you're right, i really didn't take into account how easy it is to game some of these systems.  i was just reading a discussion https://bitcointalk.org/index.php?topic=166302 that talks about better ways to handle transaction fees, with a focus on how to prevent mining pool collusion from gaming that system.
 
with that said .. i never could have imagined someone (Satoshi) creating a system like bitcoin in my wildest dreams; so if someone (or more likely a team) with that same sense of vision would tackle this problem, it could certainly materialize into the next great coin

Hello, I'm Etlase2, and I am tackling this problem. One way to ensure transactions remain fairly honest is to charge a percentage fee rather than a flat fee or a fee based only on bytes/coin age. This is possible when you use an account ledger system instead of a transaction ledger. For this and a million other details, click the link in my sig.
386  Alternate cryptocurrencies / Altcoin Discussion / Re: [Get Involved] New Scrypt Altcoin on: May 07, 2013, 02:23:08 PM
Thinking outside of the square. I like it Wink maybe ram will be the dominant component in hashing my new coin? Wouldn't that be different...

Need to think more meta than "what component can I bottleneck?"
387  Alternate cryptocurrencies / Altcoin Discussion / Re: [Get Involved] New Scrypt Altcoin on: May 07, 2013, 02:10:58 PM
Oh, just so you know:  if you get even close to BTC you will be attacked by the BTC overlords.  They didn't spend all the time creating BTC to let another coin win.  They have all the hashing power in the world to attack your coin.  The best you can hope for is to be a nice Alt Coin.  Just remember the "business" concept of killing the competition.

Too bad they can't do diddly squat if the coin isn't secured by hashing power. Wink
388  Alternate cryptocurrencies / Altcoin Discussion / Re: [Get Involved] New Scrypt Altcoin on: May 07, 2013, 01:21:10 PM
Well I'm a programmer, and I've already got the ideas, and people are actually able to read them (sig). Perhaps there is some overlap? What kind of system are you looking to create that is bitcoin 2.0? Scrypt is not innovative.
389  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 07, 2013, 11:35:36 AM
Yes I agree you cannot really resort to consensus, that's why I said aaxon's solution is probably the best. Simply don't give new nodes a chance to be tricked by the fake chain. This resolves the problem in a fairly neat way. Holding an entire year worth of transactions is still way too much when there's no real point.

There is a point though, you have a "lock block" far enough in the past that the odds of overcoming it are unbelievably overwhelming--and it's a cut-off point where you can have nodes decide unanimously that they can't be fooled or user intervention would *then* be required. Then you don't have to resort to shenanigans.

Lite client would need to download block headers from their last known checkpoint or genesis block (few MB) and download few paths in account tree which correspond to addresses client controls/is interested in (few KB). I think he could even download only few most recent blocks and his accounts info. Even if he would get forged data all he risks is that network will reject his transactions.

This can verify balances of addresses, but it does not verify payments.
390  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 07, 2013, 04:33:13 AM
Ah yes, the secret chain. I missed that along the way and presumed it was a different attack. I just couldn't imagine how you resort to a consensus of untrusted peers as a decision-making process though. Holding the true chain for a year fixes this problem unless the attacker intends to spend an entire year along with the network. Tongue You really can not resort to peer consensus. Remember, mining is a pretty centralized activity, and nodes don't get paid to be nodes. It is fairly easy in theory for EvilCorp to work their way through the hierarchy and control a large view of the network. You are *hoping* altruism wins out. Still inheriting a lot of bitcoin's flaws... and as far as I can tell, SPV is still not possible in the way that bitcoin can do it. Lite nodes are going to need a lot more data than SPV nodes in bitcoin--but perhaps not, I'd have to waste some time thinking on it. But if true, this is not good for bandwidth-unfriendly nodes like mobile devices.
391  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 07, 2013, 03:55:38 AM
What do "lite clients" have to do with anything here? I'm not sure you understand the concept properly or that you've read the white paper properly.

I haven't read the whitepaper at all, because I already know how this process works. And I was responding directly to aaaxn's solution which you said should work. He was talking about new nodes, you must think that the majority of new nodes are going to be "client" nodes rather than full peers (at least in the future when the network is large), because being a full peer costs a lot of bandwidth. Storage is only one aspect. Plus if you intend to earn market share with mobile devices, many clients are simply going to have to rely on what other nodes tell them.

Quote
The new nodes (not lite nodes) would be cut out of the picture. In no way would that shut down commerce, the legitimate older nodes would keep chugging along with the real chain and they wouldn't even pay attention to the fake chain. The fake chain wouldn't even affect anything unless you relied upon a node which was using the fake chain, which cannot happen if new nodes are cut out if the picture until the situation is resolved.

That's great and all for those who can be sure which network is the correct one. For those who can't, they are DDoS'd. Only a stupid attacker is going to start by breaking the chain. He is going to be smart and he is going to play along for some time before making a move. It is again a similar problem to bitcoin's, but you have introduced a vulnerability where the original chain is potentially lost. And the only solutions you have come up with are sybil-poor ones. Right, it's unlikely, it's really hard to do, but it only needs to happen once. Proof-of-work is bad, mmmk?

You still pretty much solve this vulnerability by keeping the chain history for a year. Storage is still bound, and that is a big win. It still suffers from centralization and 51% attacks and wasted energy and all the rest though.

Edit: I have skimmed your proposal now and yes you have addressed the new vulnerability well enough. I'm not sure what vulnerability aaaxn is referring to then. I'll have to redigest. I don't know where this voting crap is coming from. Kudos for putting this into a whitepaper, but this is not enough of an idea to start yet another altcoin imo.
392  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 07, 2013, 03:12:44 AM
If lite clients shut down in the face of competing chains, commerce cannot continue. aaaxn states that it should rarely be a problem, but the problem exists when someone is making a coordinated attack against the network. These are issues with bitcoin as well, there is nothing particularly wrong with your idea, it just allows for completely forking networks. SPV clients (lite clients) AFAIK can work because hash trees can be used to prove the existence of txouts deep in the chain. That can't be done here because the hash tree disappears after a short period of time, being replaced by a ledger. You have to hope that someone does not perform a sustained attack where they ruin other miner's profitability in an effort to get them to leave, then unleash a devastating attack where they *could* rewrite balances. Some full nodes would complain (full nodes only being run as altruistic measures, yay), but they'd have no chain to champion. Very dire situation.
393  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 07, 2013, 02:52:04 AM
Yes that is a valid point but all the older legit nodes can still be trusted, there's no way the attacker can trick them. Not only would the attacker need a boatload of hashing power but also a boatload of IP's and bandwidth to out number the legit nodes.

IPs and bandwidth are hardly issues. Many theoretical attacks should propose "what kind of defense do you have if you're surrounded by bad nodes?" It doesn't necessarily mean the system is weak if it fails to pass these tests, but it does mean it has weaknesses.

Quote
That pretty much seems like the best solution because it would cut new nodes out of the picture and leave the legit nodes to wear down the attacker until he gives up.

It's also effectively DDoSing the network for lite clients. I'm just sayin'...
394  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 07, 2013, 02:27:39 AM
It doesn't know. That's why it's a vote system. The node assumes that the majority of votes will be from legitimate nodes. Of course that wont always be the case but it will be the case at least 80% of the time.

But the basic rule of defending against a sybil attack is that the majority cannot be trusted.

Quote
An attacker with enough power to outpace the blockchain for a day or more is obviously going to get away with something. Even in Bitcoin an attacker with that much power over such a long period of time could do a bit of damage. But it's still not a true form of double spending, and if the attacker had a hard time getting any other node to accept his fake chain wouldn't it be virtually impossible for him to achieve a double spend?

I actually should have said, he can get away with almost anything against a node that hasn't been around recently. And yes, the same is true of bitcoin. Lots of bad things can be accomplished when you rely on hashing power to determine who is right. Hell, new nodes won't have any idea of whom to trust. Grabbing thousands or millions of IPs is easy; will be drastically easier when IPv6 is the standard.

There IS a way to return to the at-worst bitcoin 51% attack while reducing storage, and that is keeping a historic record for at least a year. Keep the hash of the account ledger rolling through each block, have each tx spend from the ledger not previous txouts, and work from there. If a node was suspicious at the validity of someone's block, they could request its history and hashing power proof over that year or whatever seems reasonable. At least then it's not all time. Compressed account ledger and 1 year of tx history+hashing power is pretty solid proof that it's the real chain.

It still requires proof of work though which means it can be 51% attacked and it wastes a boatload of energy for nothing useful when it can be done a better way.
395  Alternate cryptocurrencies / Altcoin Discussion / Re: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain on: May 07, 2013, 02:03:50 AM
One way to really drill the final nail into the coffin of this attack might be this: if a new node detects two full mini-blockchain's which both originate from the same proof chain it can simply resort to a peer vote system by asking older nodes which chain is the valid one. Legitimate older nodes who noticed the fake chain appear out of thin air would reply to the new node telling them not to trust the one which appeared to come out of no where. Now the attacker would have an extremely hard time getting enough slaves in on his little scheme.

What you are trying to accomplish to fix your problem here is an uninformed, relatively untrustworthy consensus (how does a new node know which nodes are legitimate?). The two part amazing solution is to use a proof of consensus system that does not rely on proof of work. Much more secure, much more energy efficient. I wasn't lying when I said I've already solved the problems of doing this.

Quote
Even if the attacker had a huge botnet at his disposal at least 80 to 90 percent of existing and new nodes would reject the fake chain and continue working on the real chain. Soon enough the attacker wouldn't be able to afford continuing the attack and he would give up. The real mini-blockchain would quickly overtake the fake chain once the attacker stopped contributing his hashing power to it. With these mechanisms in place the attacker has no hope of convincing more than half the network to use his fake chain.

He can still repeatedly get away with double spending.
396  Alternate cryptocurrencies / Altcoin Discussion / Re: I am going to create a better alt coin, anyone interested in joining me? on: May 07, 2013, 01:28:51 AM
The focus needs to be speed with a minimum standard of security, unit both can be accomplished, the end goal should be instant confirms like ATMs and Credit Card transactions.

The current technology might not be able to achieve these goals, that's why it's important to have an architecture when changes can easily be made in the future to the coin in terms of speed and security.

Proof-of-consensus can achieve fast confirmations with a high level of security.
397  Alternate cryptocurrencies / Altcoin Discussion / Re: Designing the next generation digital currency! on: May 07, 2013, 01:27:32 AM
[broken record]

Decrits proposes a consensus system in lieu of proof-of-work that should allow for transactions to typically confirm within 5-15 seconds. If the transaction block chain is unbroken, your transaction is 100% confirmed unless there is an immediately ensuing network split. 10 second "blocks" can't be contested over as a "shareholder" is specifically tied to that window of time. I used 10 seconds as that meant retail transactions could be completed in a reasonable amount of time. However, I also have ideas on how to bring that down to 1 second mini-blocks without significantly increasing bandwidth usage.

As far as goal #2, section 4 of my proposal is the same thing, except I have some serious notes on how to make it actually work.

And a lot of your other wants are addressed in the proposal. Especially decentralization.

[/broken record]

Check out decrits. Tongue


edit: especially read this post: https://bitcointalk.org/index.php?topic=189239.msg1960697#msg1960697
398  Alternate cryptocurrencies / Altcoin Discussion / Re: I am going to create a better alt coin, anyone interested in joining me? on: May 06, 2013, 11:56:41 PM
I am a programmer, and I've spent around 2,000 hours learning/designing (on paper) cryptocurrency 2.0. Link is in my signature, you will be interested if you really want to shake things up. The blueprint is ready to go.
399  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: May 06, 2013, 11:26:38 PM
Can we have full-describing paper on Decrits,
or maybe (even better) : dedicated wiki-site,
with all variants of proposal published
separately there ?!


I did a wiki for encoin, though it eventually got taken down. I admit it would be nice, but it's very time-consuming, and I'd really rather like to have discussions such as the one I am having with brenzi before going through the motions only to have to change everything. But I could certainly do an extended proposal type deal like I did with encoin. I don't know, there are too many directions to go, and I have a finite amount of time to spend on this.
400  Alternate cryptocurrencies / Altcoin Discussion / Re: Decrits: The 99%+ attack-proof coin on: May 06, 2013, 11:20:24 PM
I thought about PM'ing you this brenzi, but this is the real type of discussion I want.

I have not gone into detail and am not really willing to go into detail on some of the numbers behind things like deciding the number of coins in a mint block because these are things I want input on. I *do not* want to make those decisions lightly. **Everything in the following post is an ad-hoc example of how the system could potentially work.**

There are two major scenarios to consider with these magic numbers:
1) When the network is small, all bets are off. We can't make any assumptions about how the network will expand, so we must be ready for anything. One defense for this is to make the post-bootstrap minimum block award fairly high. This should cause a bit of deflation assuming the network sees some kind of demand, but it will protect from overshooting too much.
2) When the network is large, we must be looking to some specific percentage of transaction activity to gauge the number. Being ledger-based, it is fairly easy to keep track of useful network information such as transaction activity over certain periods.

In section 1), overshooting isn't such a terrible thing. People are getting rewarded for using the network. A lot of this depends on how quickly price stickiness might come into play. If the price recovers from 2 early overshoots, people would be unlikely to be afraid of "buying low" on the third overshoot. If there could be a P in the PID, then that would be it: opportunity. Can I guarantee people will think this way? No. Is it worth trying? F*** yes.

In section 2), the stance I think is the most useful to take is to make the free money system random, fair, and meaningful, and extrapolate from there to see where our numbers need to be.

Let's say the "network" GDP (on-network txes) is DCR1billion. 50m txes if the average tx is 20 DCR. Something meaningful must be awarded, let's call it 1 DCR. And we want to award txes within a 30 CD window of the MB, a 1.67m tx window. We want to award 10% of those. 166.7k. If we want to award at least 1 DCR, we must have 166.7k/10 or a 16.7k MB award. We're increasing the money supply 183k/500,000k (huge guess that V = 2, but what else can I do?). 16.7k means about 8-10k minters are ready and willing to create money. Is that too low? 183k/500m is a really small percentage, and 8-10k minters seems low, but if each active decrits user spends 1k decrits a year, that is 1 million users, so the minters are about .8-1%. That seems quite reasonable. How much in transaction volume do we wait before allowing a MB to be created? The same 30 CD period or perhaps a 10 day period as that is about how long a MB is intended to take?

And the function is not exponential. It is quite linear, it just starts off with a boost. 10x additional, followed by 12, then 14, then 16, and so on, assuming my initial figures.

Two new ideas I came up with recently that I have not posted that are related to the multipliers: 1) increase the tx volume required before starting the next mint block by 5 or 10% more for each consecutive block that would cause the multipliers increase. This further puts a brake on money creation if money creation doesn't appear to be needed. 2) Reduce the multipliers back down gradually so as not to have all the minters stop when it gets too high, and wait the amount of time (I was thinking 30 CDs) before the multiplier resets to 10. Instead they may have to wait 10 or 15 CDs after the end of a mint block for each multiplier to go back down. This is to prevent minting abuse rather than overshoots though. It will also allow for a big expansion, a rest period, and another big expansion without too many beats skipped.

I see about a 1% increase in the money supply by block 10 in a row, but I may be starting to fudge all the numbers together. At block 10 it's a 1% increase (well, on the base 500m), plus 1-9 equalling a 4-5% increase in the supply over a 100-150 CD period. That also seems reasonable.

So basic gist:
1) Keep the reward meaningful, random/fair, and plentiful (large percentage of people are awarded)
2) Keep minters to <2% of the population. Otherwise we're probably wasting too much energy.
3) Allow only small movements in the money supply at the beginning and allow it to gradually increase if necessary.

I think even the relatively simple scenario I came up with here is a decent base line where everything fits up reasonably well. Does the money supply increase too slowly though? Is it ok if we go through a semi-extended period of deflation, or at least prices that are well above the cost to produce? (How often is a cryptocurrency likely to double in demand in a year? Fairly likely if bitcoin is any indication.) In return, we should rarely if ever see prices go below the CTP. Maybe the last block will overshoot a little, but most of the minters are likely to hold and wait in this scenario. Or if prices are sticky enough, just use the currency and not worry about its fiat value.

What I think is a neat possibility is post-bootstrap setting the block award high, then if there are not enough txes in the 30 CD window to award 10% 1 DCR--money is left over, hold the rest and continue to award it over time, to encourage further adoption and no "missed opportunity". This is yet another brake and incentive all at the same time.

edit: and for all of that I forgot to take into account tx fee gaming. This is protection I knew was necessary even in the original decrits proposal. So if we award 100x the tx fee, we may only award 1-2% of txes (half go to sender, half to receiver) so that it can't be easily gamed during "expected" periods. If we award most of the money to transactions that occurred prior to the MB, we mostly resolve this issue, but it could get complicated when the network is expanding. Or perhaps not. It is just something to keep in mind.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 ... 93 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!