Bitcoin Forum
November 07, 2024, 11:26:40 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: What should we do with dust?
Invalidate dust transactions
Relay, but do not accept, dust transactions
Accept and relay dust transactions.
Require a mandatory fee for dust transactions.
Lower the size required for a transaction to be dust.
Destroy all dust with new fork.
Not now, but someday

Pages: « 1 2 [3] 4 »  All
  Print  
Author Topic: POLL: Allow dust transactions in Bitcoin? (5430 satoshis or less)  (Read 5152 times)
Rant2112
Newbie
*
Offline Offline

Activity: 70
Merit: 0



View Profile
June 24, 2013, 09:25:58 PM
 #41

Is it possible for the network to reject a mined block if it doesn't include a high enough sum of transaction fees?

In other words - if a miner accepts too-low of a fee is it possible for the rest of the network to reject that miner's solution?
giszmo
Legendary
*
Offline Offline

Activity: 1862
Merit: 1114


WalletScrutiny.com


View Profile WWW
June 24, 2013, 09:56:33 PM
 #42

I'm slightly confused not to see a single mention of colored bitoins in this thread.

Colored bitcoins take one transaction as the genesis transaction of, lets say, a stock. Now the output of this transaction has dust value to you but maybe great value to a stock owner.

A contract like "I hearby declare that this 1,000,000 Satoshis deposited via transaction A in address B represent stocks of my company XY and everybody holding them has the right on dividends and voting" would allow me to run stocks of my company based on what is 0.01Ƀ worth of bitcoins to you but a million stocks to me and my fellows. How can you declare storing these stocks not economical?

I guess this kind of alternative uses for Bitcoin were intended and do good to the overall legitimacy of Bitcoin. Sure, if we not only "destroy the banks" but at the same time "destroy the stock exchanges", the establishment might get slightly mader, so maybe we should keep this bullet for the next round.

ɃɃWalletScrutiny.comIs your wallet secure?(Methodology)
WalletScrutiny checks if wallet builds are reproducible, a precondition for code audits to be of value.
ɃɃ
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
June 24, 2013, 10:30:10 PM
 #43

Is it possible for the network to reject a mined block if it doesn't include a high enough sum of transaction fees?

In other words - if a miner accepts too-low of a fee is it possible for the rest of the network to reject that miner's solution?

No.  That is why this is all a much ado about nothing.

If people want to create sub dust transactions, then they can find people willing to relay and mine them.   Problem solved.  The dust threshold is merely a default.  It doesn't invalidate any blocks. 

The reality (and the need for the gnashing of teeth and FUD about the death of Bitcoin) is some people simply WANT to spam the network with transactions which will NEVER be redeemed.  They also want to do it for free and have the cost of keeping those transactions in the UXTO forever paid by someone else.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
June 24, 2013, 10:33:52 PM
 #44

I'm slightly confused not to see a single mention of colored bitoins in this thread.

Colored bitcoins take one transaction as the genesis transaction of, lets say, a stock. Now the output of this transaction has dust value to you but maybe great value to a stock owner.

A contract like "I hearby declare that this 1,000,000 Satoshis deposited via transaction A in address B represent stocks of my company XY and everybody holding them has the right on dividends and voting" would allow me to run stocks of my company based on what is 0.01Ƀ worth of bitcoins to you but a million stocks to me and my fellows. How can you declare storing these stocks not economical?

I guess this kind of alternative uses for Bitcoin were intended and do good to the overall legitimacy of Bitcoin. Sure, if we not only "destroy the banks" but at the same time "destroy the stock exchanges", the establishment might get slightly mader, so maybe we should keep this bullet for the next round.

Then find someone willing to relay and mine it.  Problem solved.

Nothing in 0.8.2 PREVENTS you from doing that.  Some people might not share your view that it is a beneficial use of a critical resource.  Should they be forced to relay and mine your transactions?

0.8.2. doesn't make any transaction regardless of size prohibited.  No block will be rejected even if it is 100% full of spammy garbage. 

However just because you have FREEDOM of speech doesn't mean others have an OBLIGATION to listen.  Likewise just because you can create spammy garbage doesn't mean that other nodes should be forced to relay it.
giszmo
Legendary
*
Offline Offline

Activity: 1862
Merit: 1114


WalletScrutiny.com


View Profile WWW
June 24, 2013, 11:36:17 PM
 #45

I'm slightly confused not to see a single mention of colored bitoins in this thread.

Colored bitcoins take one transaction as the genesis transaction of, lets say, a stock. Now the output of this transaction has dust value to you but maybe great value to a stock owner.

A contract like "I hearby declare that this 1,000,000 Satoshis deposited via transaction A in address B represent stocks of my company XY and everybody holding them has the right on dividends and voting" would allow me to run stocks of my company based on what is 0.01Ƀ worth of bitcoins to you but a million stocks to me and my fellows. How can you declare storing these stocks not economical?

I guess this kind of alternative uses for Bitcoin were intended and do good to the overall legitimacy of Bitcoin. Sure, if we not only "destroy the banks" but at the same time "destroy the stock exchanges", the establishment might get slightly mader, so maybe we should keep this bullet for the next round.

Then find someone willing to relay and mine it.  Problem solved.

Nothing in 0.8.2 PREVENTS you from doing that.  Some people might not share your view that it is a beneficial use of a critical resource.  Should they be forced to relay and mine your transactions?

0.8.2. doesn't make any transaction regardless of size prohibited.  No block will be rejected even if it is 100% full of spammy garbage. 

However just because you have FREEDOM of speech doesn't mean others have an OBLIGATION to listen.  Likewise just because you can create spammy garbage doesn't mean that other nodes should be forced to relay it.

Well then the 0.8.2 doesn't solve any problem. If you don't make the fees scale with the costs, things make no sense. Anybody may include garbage and take a fee or not for that and for all eternity people have to deal with this extra data. We should just assume to have full blocks and miners should include transactions based on the fee in relation to the costs for the network and not in relation to some assumed economic value of that particular transaction.

ɃɃWalletScrutiny.comIs your wallet secure?(Methodology)
WalletScrutiny checks if wallet builds are reproducible, a precondition for code audits to be of value.
ɃɃ
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
June 25, 2013, 12:04:01 AM
 #46

Well then the 0.8.2 doesn't solve any problem. If you don't make the fees scale with the costs, things make no sense. Anybody may include garbage and take a fee or not for that and for all eternity people have to deal with this extra data. We should just assume to have full blocks and miners should include transactions based on the fee in relation to the costs for the network and not in relation to some assumed economic value of that particular transaction.

Well do.  MOST miners and nodes are NOT going to relay uneconomical garbage.  The reason is the UXTO is the critical resource it can't be pruned and to perform high speed validation it should be in memory (or as much in memory as possible).  The creation of outputs that likely will never be spent bloats the UXTO and that makes the entire network less efficient.  Miners pay a perpetual cost that can't be pruned away.  If they are rational they won't include spammy garbage.
EmperorBob
Member
**
Offline Offline

Activity: 67
Merit: 10


View Profile
June 25, 2013, 12:06:24 AM
 #47

A contract like "I hearby declare that this 1,000,000 Satoshis deposited via transaction A in address B represent stocks of my company XY and everybody holding them has the right on dividends and voting" would allow me to run stocks of my company based on what is 0.01Ƀ worth of bitcoins to you but a million stocks to me and my fellows. How can you declare storing these stocks not economical?

Just scale it up so that the per-share amout of satoshis is higher than the dust threshold. So instead of one satoshi per share, make it 10,000 (Approx. 1 penny at this time) per share. Then everything works again. Since, by you own admission, these shares have non-negligible economic value, tying up a larger (still very small) amount of money to each share doesn't harm you at all.
Hyena
Legendary
*
Offline Offline

Activity: 2114
Merit: 1015



View Profile WWW
December 04, 2014, 01:17:37 PM
 #48

I raise this thread from the dead because as a developer, I am being affected by this issue and I want to make my opinion heard even if some people have already decided that this issue has been resolved already.

I choose ACCEPT AND RELAY  because the sender pays to the miner anyway according to the final size of the transaction. it is the size used up in the block chain and only that size in combination with the fee paid to miners that should matter. The sender should be free to do whatever they want in the transaction as long as they pay the minimal fee to miners.

But why would anyone send such a small amount of bitcoins that couldn't be spent? Easy: to save a Proof of Existence in the block chain! Why not use OP_RETURN you might ask? Because anything behind OP_RETURN is non-standard anyway and can be pruned later. Proof of Existence is meant to be forever, and must not be pruned in any way ever.

★★★ CryptoGraffiti.info ★★★ Hidden Messages Found from the Block Chain (Thread)
solex
Legendary
*
Offline Offline

Activity: 1078
Merit: 1006


100 satoshis -> ISO code


View Profile
December 04, 2014, 06:51:06 PM
Last edit: December 04, 2014, 08:19:27 PM by solex
 #49

I raise this thread from the dead because as a developer, I am being affected by this issue and I want to make my opinion heard even if some people have already decided that this issue has been resolved already.

I choose ACCEPT AND RELAY  because the sender pays to the miner anyway according to the final size of the transaction. it is the size used up in the block chain and only that size in combination with the fee paid to miners that should matter. The sender should be free to do whatever they want in the transaction as long as they pay the minimal fee to miners.

But why would anyone send such a small amount of bitcoins that couldn't be spent? Easy: to save a Proof of Existence in the block chain! Why not use OP_RETURN you might ask? Because anything behind OP_RETURN is non-standard anyway and can be pruned later. Proof of Existence is meant to be forever, and must not be pruned in any way ever.

You are looking at a small picture, not the big picture. Also please re-read all D&T's posts.

The block limit needs to be increased and IBLT implemented within new block propagation before micro-tx become even more common.

Then this thread might deserve to be raised from the dead.

Gyrsur
Legendary
*
Offline Offline

Activity: 2856
Merit: 1520


Bitcoin Legal Tender Countries: 2 of 206


View Profile WWW
December 04, 2014, 06:58:49 PM
Last edit: December 04, 2014, 09:35:46 PM by Gyrsur
 #50

can someone post the link to Gavin statemant about this?

luv2drnkbr
Hero Member
*****
Offline Offline

Activity: 793
Merit: 1026



View Profile
December 04, 2014, 08:01:58 PM
 #51

I raise this thread from the dead because as a developer, I am being affected by this issue and I want to make my opinion heard even if some people have already decided that this issue has been resolved already.

I choose ACCEPT AND RELAY  because the sender pays to the miner anyway according to the final size of the transaction. it is the size used up in the block chain and only that size in combination with the fee paid to miners that should matter. The sender should be free to do whatever they want in the transaction as long as they pay the minimal fee to miners.

But why would anyone send such a small amount of bitcoins that couldn't be spent? Easy: to save a Proof of Existence in the block chain! Why not use OP_RETURN you might ask? Because anything behind OP_RETURN is non-standard anyway and can be pruned later. Proof of Existence is meant to be forever, and must not be pruned in any way ever.

To be fair, the blockchain can only be validated if tx's aren't pruned.  So the full blockchain must still exist with *some* miners/users, otherwise the whole security of the system collapses.  So while OP_RETURN outputs will be pruned by most nodes, they will still exist and be able to be verified.  All users must have the option to download and verify the entire blockchain from the beginning, otherwise the system isn't secure.  And in order for users to be able to do that, it has to always be available somewhere.

Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2965


Terminated.


View Profile WWW
December 04, 2014, 08:03:55 PM
 #52

Accepting and relaying them right now would be a mistake.
On the other hand doing so in the future is necessary.

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
Hyena
Legendary
*
Offline Offline

Activity: 2114
Merit: 1015



View Profile WWW
December 04, 2014, 09:51:35 PM
 #53

I raise this thread from the dead because as a developer, I am being affected by this issue and I want to make my opinion heard even if some people have already decided that this issue has been resolved already.

I choose ACCEPT AND RELAY  because the sender pays to the miner anyway according to the final size of the transaction. it is the size used up in the block chain and only that size in combination with the fee paid to miners that should matter. The sender should be free to do whatever they want in the transaction as long as they pay the minimal fee to miners.

But why would anyone send such a small amount of bitcoins that couldn't be spent? Easy: to save a Proof of Existence in the block chain! Why not use OP_RETURN you might ask? Because anything behind OP_RETURN is non-standard anyway and can be pruned later. Proof of Existence is meant to be forever, and must not be pruned in any way ever.

You are looking at a small picture, not the big picture. Also please re-read all D&T's posts.

The block limit needs to be increased and IBLT implemented within new block propagation before micro-tx become even more common.

Then this thread might deserve to be raised from the dead.


I have read the posts again but they didn't tell me anything that I already didn't know. However, somehow something made me change my mind about it and I now support the idea of having this dust threshold. It doesn't solve the problem but it wins us some time. There will be a day when the block chain is simply so big that only a few nodes could host it. The conflict here is that some people want Bitcoin to be forever and others (such as myself) simply acknowledge the fact that Bitcoin will become unsustainable and something else will take its place. If we look at the situation from the point of view that Bitcoin is going to die anyway then dust transactions should be allowed. If we want to push Bitcoin's death as far into the future as possible then we should not allow dust transactions. That's why I wouldn't allow dust transaction --- to buy us more time.

My speculation is that Bitcoin will die because of its technical limitations (ASIC mining sucks and the block chain is growing too fast, also current TPS is not sustainable in the long term). Peercoin's block chain is just 400 MiB and it will remain in that magnitude for long time due to the fact how they have solved the transaction fee problem. Thus, Peercoin is the ultimate store of value and not Bitcoin (said jokingly but then followed by a serious look in the eye). Also, Peercoin has Proof of Stake mining, so anyone could have an ASIC (hint: PoS ASIC is a Raspberry Pi). For everyday use cryptocurrency, Sunny King's community has developed the NuBits project and thanks to NuShares the shareholders can vote on all sorts of things --- the aspect Bitcoin community obviously lacks. Essentially all network related decisions should be voted on and votes be weighted by the share of coins the voter owns. For example, if I have 1 bitcoin, then it gives me 1 vote on any Bitcoin related development decision. As a NuShares shareholder I can vote for issues like that (to allow or disallow dust transactions and what not).

Finally, should the NuBits block chain grow too large the shareholders could just come together and vote how to solve the problem. One solution is resetting the block chain and then redistributing the nubits to their owners. This is the future and in the future block chain's size is not an issue. Also, Open Transactions should solve much of the block chain's size problems. Right now I feel bitcoin development decisions are made by some privileged people who are obviously prone to corruption.

★★★ CryptoGraffiti.info ★★★ Hidden Messages Found from the Block Chain (Thread)
Gyrsur
Legendary
*
Offline Offline

Activity: 2856
Merit: 1520


Bitcoin Legal Tender Countries: 2 of 206


View Profile WWW
December 04, 2014, 10:27:21 PM
Last edit: December 04, 2014, 10:45:20 PM by Gyrsur
 #54

can someone post the link to Gavin statemant about this?

did a tx of 0.00005429 with fee of 0.01

it is included into a block.

EDIT:

dust is new defined below 546 satoshis but it depends

https://github.com/bitcoin/bitcoin/blob/a0417b8cc840ff6f49b4fb1f8ceef54f8e3d0df1/src/primitives/transaction.h#L145

solex
Legendary
*
Offline Offline

Activity: 1078
Merit: 1006


100 satoshis -> ISO code


View Profile
December 05, 2014, 12:31:31 AM
Last edit: December 05, 2014, 08:45:45 AM by solex
 #55

I raise this thread from the dead because as a developer, I am being affected by this issue and I want to make my opinion heard even if some people have already decided that this issue has been resolved already.

I choose ACCEPT AND RELAY  because the sender pays to the miner anyway according to the final size of the transaction. it is the size used up in the block chain and only that size in combination with the fee paid to miners that should matter. The sender should be free to do whatever they want in the transaction as long as they pay the minimal fee to miners.

But why would anyone send such a small amount of bitcoins that couldn't be spent? Easy: to save a Proof of Existence in the block chain! Why not use OP_RETURN you might ask? Because anything behind OP_RETURN is non-standard anyway and can be pruned later. Proof of Existence is meant to be forever, and must not be pruned in any way ever.

You are looking at a small picture, not the big picture. Also please re-read all D&T's posts.

The block limit needs to be increased and IBLT implemented within new block propagation before micro-tx become even more common.

Then this thread might deserve to be raised from the dead.


I have read the posts again but they didn't tell me anything that I already didn't know. However, somehow something made me change my mind about it and I now support the idea of having this dust threshold. It doesn't solve the problem but it wins us some time. There will be a day when the block chain is simply so big that only a few nodes could host it. The conflict here is that some people want Bitcoin to be forever and others (such as myself) simply acknowledge the fact that Bitcoin will become unsustainable and something else will take its place.

Interesting post, I have always found your opinions rational and informed.

When I first found out about Bitcoin I was super-excited about its potential. Super-excitement which lasted about two weeks until I learned about the limits on throughput and storage. I have remained just "excited" about it since, tempered with the knowledge that so much needs to be done. Although, a huge amount has been done, Bitcoin Core 0.9 is vastly superior to Satoshi's 0.1, and soon we will see 0.10 with headers-first for rapid node bootstrapping and synchronization. Greg Maxwell uses the term "low hanging fruit" to describe the range of known technical changes which can improve Bitcoin generally and its volume handling. Also, IBLT has fantastic potential, including reducing the 10 minute lag on blockchain consensus to nearly real-time, by enforcing a high degree of consensus on unconfirmed transactions. Bitcoin rides Moore's Law like a surfer on a wave.

Most of the alts have the luxury of low transaction volume which is basically investors buying, selling and shuffling their wallets. All of them will struggle under serious real-world user volumes (if they ever get it).

I remain very optimistic that Bitcoin can develop to become a significant factor in the world economy.

Hyena
Legendary
*
Offline Offline

Activity: 2114
Merit: 1015



View Profile WWW
December 05, 2014, 10:33:01 AM
 #56

Also, IBLT has fantastic potential, including reducing the 10 minute lag on blockchain consensus to nearly real-time, by enforcing a high degree of consensus on unconfirmed transactions. Bitcoin rides Moore's Law like a surfer on a wave.

Most of the alts have the luxury of low transaction volume which is basically investors buying, selling and shuffling their wallets. All of them will struggle under serious real-world user volumes (if they ever get it).

I remain very optimistic that Bitcoin can develop to become a significant factor in the world economy.


That IBLT is an interesting concept and indeed has fantastic potential.

The only way the good old Bitcoin can survive is to change and evolve. The latter is hard without a hard fork. Many people will oppose a hard fork, especially if it would ruin ASIC mining. On the other hand, people would support a hard fork when they can keep their original wealth. This is where most of the altcoins went wrong --- they started to compete with Bitcoin totally. Instead, they should have made Bitcoin's private keys compatible with their coin. For example, the first block of a new altcoin should include all bitcoin addresses that have at least 0.0001 bitcoins. That's why I hate Ethereum and love Aethereum Cheesy.

In theory, Bitcoin could remain the most dominant cryptocurrency if  it was willing to evolve at the cost of hurting ASIC miners. If Bitcoin decided to take such a radical step that to introduce Peercoin's hybrid proof of work/stake model then I would support it for the greater good. I also think that the Bitcoin's block chain itself could be improved.

For example, instead of dragging all blocks with the network starting from the first block the network should gradually forget the oldest blocks. If there are any unspent outputs in the block that is about to be forgotten then they could be included in the next block in some special way like refreshing the outputs. After 1000 blocks the about-to-be-deleted block would be actually deleted.

So, unless Bitcoin people are willing to take such radical steps to improve the network I will remain pessimistic about Bitcoin. If, however, the community accepts such steps then my optimism will grow. Knowing how things work in this world I would say that by now too much money and interests are tied in this whole Bitcoin thing and we will suffer from serious consequences of being conservative about the changes to the protocol.

I have made some parts of my post bold. I didn't explain these ideas in detail to keep it short. However, if you have more (technical) questions about my ideas then feel free to ask.

★★★ CryptoGraffiti.info ★★★ Hidden Messages Found from the Block Chain (Thread)
Hyena
Legendary
*
Offline Offline

Activity: 2114
Merit: 1015



View Profile WWW
December 05, 2014, 10:39:33 AM
 #57

can someone post the link to Gavin statemant about this?

did a tx of 0.00005429 with fee of 0.01

it is included into a block.

EDIT:

dust is new defined below 546 satoshis but it depends

https://github.com/bitcoin/bitcoin/blob/a0417b8cc840ff6f49b4fb1f8ceef54f8e3d0df1/src/primitives/transaction.h#L145

That's a darn good find, my friend Cheesy and it works:
https://blockchain.info/tx/3b557a4089c93b6d32adddf4fb7666833bfb22d8b3819baa163aba6a01bfdcac

That's much better than sending 0.00005430 at minimum.

★★★ CryptoGraffiti.info ★★★ Hidden Messages Found from the Block Chain (Thread)
Q7
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


View Profile WWW
December 05, 2014, 10:41:59 AM
 #58

If the protocol allows us to choose whether we want to accept the transaction. If let's say there is no confirmation by the recipient then the amount should be returned back to the sender. Not sure if this is workable or considered a good solution but at least this will block spam.

Gyrsur
Legendary
*
Offline Offline

Activity: 2856
Merit: 1520


Bitcoin Legal Tender Countries: 2 of 206


View Profile WWW
December 05, 2014, 11:15:37 AM
Last edit: December 05, 2014, 11:32:41 AM by Gyrsur
 #59

can someone post the link to Gavin statemant about this?

did a tx of 0.00005429 with fee of 0.01

it is included into a block.

EDIT:

dust is new defined below 546 satoshis but it depends

https://github.com/bitcoin/bitcoin/blob/a0417b8cc840ff6f49b4fb1f8ceef54f8e3d0df1/src/primitives/transaction.h#L145

That's a darn good find, my friend Cheesy and it works:
https://blockchain.info/tx/3b557a4089c93b6d32adddf4fb7666833bfb22d8b3819baa163aba6a01bfdcac

That's much better than sending 0.00005430 at minimum.

it works with a fee of 0.0001  Smiley

Discus Fish included relayed it.

El Emperador
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500



View Profile
December 05, 2014, 03:53:20 PM
 #60

I think it could be a nice idea to allow these dust transacions in Bitcoin, because many people could need to send or receive a microtransaction.

.
.7 BTC  WELCOME BONUS!..
███████████████████████████
██████████▀▀▄▄▄▄▄ ▄▀▀██████
█████████▄██████ ████ ▀████
██████▀▀ ▄▄▄▄ ▀▀███▀▄██ ███
████▀   ██████   ▀██████ ██
███ ▄▄▄████████▄▄▄ ██▄▄▄ ██
██ █████▀    ▀█████ ████ ██
██  ▀██        ███▀ ███ ███
██   ▄██▄    ▄██▄   █▀▄████
███ ▄████████████▄ ████████
████▄▀███▀▀▀▀███▀▄█████████
██████▄▄      ▄▄███████████
███████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████
██████████████████████████████▄▄▄█████▄▄▄████████████████████████████████████████████████████
██████████▄█████▄█▄███▄█▄██████████▄██▀▀▀████████████████████████████████████████████████████
██████████████▀████▄████▀██████████████████████████▄█████▄██▄█████▄████▄████▄████▄████████
█████████████████▐█████▌███████████▄█████▀███▀▀████████▀▀▀▀█████▀▀▀██████▀▀███▀▀███████████
██████████████▄████▀████▄██████████████████▄▄▄▄▄███▄▄▄▄█████▄▄▄████████████████████████
████████████████▀█▀███▀█▀██████████▀███████▀█████████▀█████▀██▀█████▀███████████████████████
██████████████████████████████▀▀▀████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████████████████████████████████████
███████████████████████████
████████▀▀  ▐█▌  ▀▀████████
██████▄     ▐█▌     ▄██████
████ ▀██▄▄███████▄▄██▀ ████
███    ██▀▀  ▄  ▀▀██    ███
██    ██   ▄███▄   ██    ██
████████  ███████  ████████
██    ██  ▀▀ █ ▀▀  ██    ██
███    ██▄▄ ▀▀▀ ▄▄██    ███
████ ▄██▀▀██████▀▀▀██▄ ████
██████▀     ▐█▌     ▀██████
████████▄▄  ▐█▌  ▄▄████████
███████████████████████████
.
.30+  ALTCOINS AVAILABLE..
Pages: « 1 2 [3] 4 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!