Topic: Bitcoins sub-nets (Read 2439 times)

In terms of another application here, I could imagine that the day may come for a bunch of "local merchants" that might set up a similar kind of sub-net where they would engage in day to day transactions in a "community" (however you define that term) accumulating credit or debt with it eventually getting settled on the main Bitcoin backbone.  The local "chamber of commerce" might be willing to extend what amounts to be credit to a new "citizen" in the community for trade on this sub-net with the understanding that all debts will be eventually repaid.  Failure to make payment would get you kicked from the sub-net and likely make it difficult or impossible to engage in trade within that community.  A "visitor" may have to put money into the sub-net as a sort of escrow against debts.

This is presuming that the main bitcoin backbone is getting hammered real hard with massive numbers of transactions, and that petty transactions worth say less than $100 USD (in BTC equivalent) aren't even worth looking at and would rarely be included in a block.  I can also see that perhaps happening in the future if Bitcoins had widespread adoption the bandwidth and CPU processing needs of running a primary Bitcoin node would be huge even if you weren't doing mining activity at all.  The purpose of the sub-net here would be to isolate the community network bandwidth from the backbone bandwidth, where the transactions within the community (say buying groceries, gasoline, or a burger at the local McDonald's)  would certainly be of interest to the local merchants and they would want these smaller kinds of transactions to happen in their "community".  The purpose of the main Bitcoin network in this case would be to carry on transactions between sub-nets if this situation happened where it started to become difficult to carry on these sort of more mundane kinds of transactions or if transaction fees on Bitcoins started to get to higher levels than most people would want for day to day transactions.  It would also support the use of thin clients a whole lot better if those thin clients stayed on the sub-net.

Yes, I realize that this particular sub-net system isn't really needed at the moment for these kind of transactions and that 0.01 BTC is still currently less than $0.01 and requires no transaction fee at the moment either for 90%+ of the miners current on the network.   I guess this is also anticipating into the future what might be a way to scale Bitcoins in such a way that it could administer to other groups when I do think there will be people complaining about "those greedy miners demanding those outrageous fees".

Yes, the system needs to be decentralized for the application I have in mind and I'm fully aware of what problems happen with what amounts to be two different floating currencies.

Using a system of "voluntary" credits where if somebody owes more than 0.01 BTC would get kicked from the network might be sufficient.  The amount owed would be known to the network as would any transactions between the two parties on the main Bitcoin network.  There are other solutions here, but the intention is to set up a way to exchange fractions of a bitcoin, not some other monetary unit.

The real problem here is more of one addressing the issues of micropayments that are on the order of fractions of a cent.  As good as the Bitcoin concept is, it really doesn't address small quantities very well in practice.  Any such transaction is currently presumed to be a flood attack and will usually not get put into blocks with a typical miner requiring a fee that will be greater than the transaction amount itself.  Furthermore, if micropayments did happen commonly on this scale with Bitcoins, it would chew up perhaps more network bandwidth than really ought to be used for Bitcoins with what amounts to be some specialized applications that ought to carry their own bandwidth requirements "out of band" instead.

IMHO, if you want to rely strictly upon the Bitcoin network itself, these sort of extreme micropayments simply won't happen.  I presume that when 0.01 BTC is worth a dollar, that miners will relax the rules to permit smaller values to be processed for transactions, but I don't anticipate most miners would really care to process transactions where the fee plus the transaction is less than a cent in FRNs or the equivalent in Euros.  There might be some very altruistic miners who from time to time would process those kind of extreme micropayments, but if the network gets flooded with tens of thousands up to millions of these kind of transactions most miners would ignore them altogether and there likely would be blocks on the nodes themselves from even forwarding these kind of transaction messages to miners in the first place.  In a large part this is anticipating potential problems before they even happen.

I have only read the first message and I dont know if someone has told you already, but the one on one exchange ratio with bitcoin is suicide. Since the two currencies will have different market values you are creating a big profit opportunity that someone will use, crashing anyone trying to hold the one on one ration exchange. This is why you felt that part was murky. You need to let the exchange float freely.

Does your system really needs to be decentralized? Because if it does not the solutions are way easier.

It makes sense to use two systems, each to patch the shortcomings of the other.

Also if clients make a 1BTC deposit (escrowed, if there is no server?), they can go "in debt" in the microcurrency without being overall in debt.  This way you don't need CAPTCHAs or trust mechanisms to stop hit'n'run bad debts.


Another idea might be to make a mini-BTC-style currency.  AIUI, Bitcoin's neat feature is using the proof of work to enforce one linear timestamped history, and thereby prevent double-spending.  You could benefit by hanging your linear coin-spend history off this,

• use "mini-blocks" in your world to log the transfers between IDs.  The full anonymous wallet private key thing is optional, but the owner must sign the transfer.  Presumably your world already has IDs?
• choose a "mini-block" creation rate.  I think it can be less than 10min, as well as 1:1 or greater delay; but there will always be the Bitcoin multi-block confirmation time if you need to know for "certain" that history is locked down irrevocably.
• publish the mini-blocks, and put the hash of the top of your chain into Bitcoin's chain..  by moving 0.01BTC.
• you might be able to run on free transactions for this, but otherwise the N participants must spend 0.01BTC/N per mini-block history lockdown.  At 1BTC/$0.25 that looks like $1.30/year for N=100 people and 1:1 miniblock:bitcoin sync.

This way you're not sucking CPU out of the main Bitcoin network, just making a small contribution to its running for the small service you need (timestamping of hashes).

you might be able to do this on top of ripple (ripple-project.org)
people can 'accumulate' ripple credits, which can be 'settled' with bitcoins once they reach a certain amount.

The specifics of the application I'm looking at in particular is with an on-line video game with a persistent "avatar" (essentially an MMORPG) where players could exchange "goods" between each other and be paying for "services" within the environment of the game itself.  The environment here would by its nature be open and arbitrary clients could come and go as they please, and "custom" clients or user interfaces into the network would be permitted.  There would exist other forms of communication, so the payment part would only be a sub-section of the main purpose of the software.... still it would be something I think would draw people to playing especially if they could "earn" real money while playing the game.

One of the purposes I have here to insist on a P2P solution is an attempt to keep from having a massive server farm to run the whole show, and I think Bitcoins itself is a key element to make all of this happen.  This is an application that simply couldn't happen without Bitcoins.

Anonymity would be a nice goal but it isn't for me a key feature and isn't strictly necessary.  Essentially, I'd like people to have to work to prove the identity of somebody but it wouldn't have to be strictly important to be completely opaque in terms of identifying who is using the network at any given time.  If possible, I'd like to give people the same level of anonymity that is found within Bitcoins itself.  Not perfect but pretty good.

Can debts be accumulated?  Yes, but I'd like to keep it small so nobody is really burned hard.  Owing somebody $0.01 USD is likely not going to be that big of a deal, even if they owe that amount to a hundred people.  The main point is that somebody who set up say a virtual restaurant can accumulate a couple bucks every now and then from the "customers" over time.  Somebody trying to milk the system will eventually get booted and may even have something to lose by acting with bad faith.

I have considered that there may even be "exchanges" with "alternate currencies" of the sort that would be found within the game, but those would be floating currencies by their nature and be more typical with MMORPG currencies.  The central part here is to set up some system that would permit content builders (aka somebody designing a village or a dungeon) to "earn" some bitcoins for each person who passes through and uses those features... as this is something which has an existing market and people willing to pay for such content.

I also think there are a great many other applications where something like this, or an adaptation of this concept could be used outside of a virtual world, which is why I'm bringing it up here in this forum section.

I like that idea. It has an appealing simplicity.

I suppose a similar kind of system could simply accumulate "credits" and "debits" until somebody owes a predetermined amount to a given individual and the "network" simply expects you to make good on your promise to make the payment as verified by some kind of confirmed payment on the main bitcoins network.  The amount owed to any single individual (aka node or address hash) would be modest (at most 1 BTC or perhaps even less like 0.01 BTC) and if they fail to make good on the debt owed they would get booted from the sub-net automatically or at least further transactions couldn't happen until the payment is made.  That might work and it could even be decentralized.  It could still use a transaction hash system similar to what Bitcoins is using and develop some system for "publishing" transactions... perhaps even into a chain.  The difference is that no coins would actually be mined in such a system, only a list of credits and debits to each other that are owed.

If there is a major transaction that would have to happen, it would have to go through the main bitcoin network.

You would want to process the chain simply to be a part of the sub-net, and the threat of getting booted due to bad faith might be sufficient to convince participants to make good on their promises.  The bitcoin payment would be automated to "keep the honest people honest", but there might still be some modest losses that based on whatever it is that you might be doing would be considered acceptable simply because you can't stop all trolls.  Perhaps a very small "fee" could also be collected by the processing node that is accumulating transactions in such a network too that would build over time from each person conducting a transaction.

Payment systems of this nature exist anyway in the form of Paypal and credit cards, where the "network as a whole" absorbs the losses of fraud and graft.  I would imagine that a system of this nature might have less fraud than is typical for a credit card.  I'm sort of curious... how much of a loss does a typical retail merchant usually expect from credit card charge-backs and other losses simply from accepting credit cards in their business?  I know there is a monthly fee plus a per transaction fee already established for merely normal transactions... fees that typically a customer is not aware of or for that matter even the cashier even deals directly with but the shop owner sure knows about.

This is certainly giving me some food for thought here.  I don't know if this helps anybody else, but it certainly is a new dimension to Bitcoins to think about.

I believe that it is possible to have a decentralized peer-to-peer crypto-currency solution for frequent micropayments.
There are many parameters to be specified before an appropriate design can be made. Among them are:

• How do you seed the clients with the initial money to make transactions?
• Can they accumulate debts?
• What sort of communication exists "naturally" between the clients apart from the payments?
• Must offline payments be possible?
• Is the system "closed"? Can new arbitrary clients join?
• Is full anonymity desirable or is pseudonymity acceptable?
• Are the transactions a fixed small set of types or do you have to be able to "roll your own" like bitcoin?

If you go into more detail about the application then we can probably infer most of these parameters.

ByteCoin

If you hold balances centrally until amounts reach, say, 1BTC, attacks on you won't be particularly profitable.

There has been some discussion about the downsides of multiple chains. The main problem is that you can't convert 1 to 1 without people trusting that you'll do it for them, and if they do trust you they will generate on your chain until the difficulties are equal and you will bust long before that since you don't have millions of real coins I assume. If by some miracle this happens anyway, we are all worse off because the two networks can be attacked with only 50% of what would be needed to take them down if we worked together.

Eh, it occurs to me that you could tweak generation rates and total coins and such. But that is the same as backing at 10 to 1 or whatever anyway.

Also you will have the same problem, generators on your network still might charge or ignore your spam size transactions.

Effectively you're just using your server to implement a payment cache. It accumulates the micro-transactions, then every time they reach (say) one bitcoin for a user, that transaction gets flushed out to the real bitcoin network. The same thing going the other way, a bitcoin comes in to the payment cache, and that coin gets nibbled away at until it's gone.

Of course this is just another way of thinking about an "account" system. But it shows that you're not "turning" the bitcoin system into anything.

In a very real way, a bitcoin derives its value from the block chain it exists in and the rules which govern that block chain. To use an obvious example, we already have an independent parallel block chain: the test network. Coins on the test network are worth virtually nothing. (That's partly because it's so easy to generate coins on the testnet, but also because there's no one willing to trade for testnet coins.)

It's easy to say that coins from your independent chain are worth the same as coins on the 'real' chain, but I only see one way to enforce that: someone has to act as a central banker, guaranteeing the coins of your chain by promising to always exchange any number of those coins for an equal number of 'real' bitcoins, dealing with anyone, forever.

How do you handle block generation? If it's easier to generate coins on your chain (which it will be) how do you deal with inflation in your currency once 'real' bitcoins begin to deflate? I don't know.

Since you're relying on a central authority anyway, why not just have your clients connect to a central server on which each maintains an account, and which can handle transactions between them? These accounts could be backed by bitcoins or anything else.

A final thought. Eventually bitcoin will have to permit transactions smaller than 0.01 coins as the value of each coin rises. I expect that the developers will lower the limit one order of magnitude at a time as necessary. How small do your transactions really need to be?

If you want a distributed system with 'perfect' double spending protection, there is not much you can do apart from the current 'inefficient' bitcoin protocol.
However, if you trust everyone in your subnet to not try to double spend, you could use a much simpler protocol without global block log.

I doubt a peer-to-peer system is appropriate if you have to make thousands of transactions per minute.   Because all transactions have to spread to the network.  This necessarly takes some time, and I'm not even talking about the process time (hashing of the blocks).

Therefore, cryptocurrencies have an intrinsic limit to the speed it can process transactions.

For very fast transaction, the account/centralised system can be used, as long as it is backed by bitcoins.

I guess I'd like another requirement on this sub-net too:  It should be peer-to-peer and not a centralized solution.  Yes, a central server could perform this kind of system with all of the headaches and problems that such a solution also provides.  I would personally like to avoid having to turn Bitcoins into a conventional client-server model with a central authority which can be attacked.  It goes against the grain of why Bitcoins was originally established.

Bitcoins itself could be built into a central server system too, but I perceive the peer to peer nature of Bitcoins to be an essential strength of the system and something to be modeled onto sub-nets too.

If you really need huge number of micropaiements per client per day, I'd suggest you to use a different paiement system.

You could use an account-based paiement system.  Optionnaly this could use David Chaum's e-cash system if you want anonymity.

Anyway, your clients would have an account on your server, and they could change their balance into bitcoin when it reaches a significtive amount, or on a daily basis.

I have a question, but I'm going to pose it in the form of a problem domain first:

I have a software application which is going to require the use of a substantial number of micropayments (hundreds to perhaps thousands of transactions per day, per client) which will be going out to many different people.  I'd like to use Bitcoins for this, but it seems like it would become the equivalent of a flood attack on the network, something I'd like to avoid.

The other problem is that Bitcoins seems to be increasingly more averse to micropayments in general as of late, in spite of the propaganda that is being spread around with the issue.  Yes, I could throw in 0.01 BTC with every transaction, but that eventually is going to start costing some real money if I'm not careful.  At current exchange rates, 0.01 BTC is too large for the kind of transactions I'm looking at here.  Again, I don't want this to turn into a flood attack either.

The other part of this problem domain is that at least in theory most of the people who are going to be exchanging these micropayments will be a part of a much smaller group and don't necessarily need to interchange with the rest of the Bitcoins community, except on an occasional basis where conventional Bitcoins network rules are more than sufficient.... such as buying $100 USD worth of Bitcoins or selling a similar sized hunk of them.

I'm trying to come up with perhaps another alternative way to deal with the problem, and one of perhaps several solutions I've thought of is to set up a parallel "network" that would perform all of the transactions within the sub-net for these microtransactions but effectively maintain value with Bitcoins.

In theory, I could imagine creating a whole new block chain for this purpose that would have slightly different rules than Bitcoins but following a similar system of blocks, hashes, and accounting between clients.  Essentially a parallel currency which would have a one to one exchange rate with Bitcoins and be recognized as such, although the exchange mechanism between the two currencies seem a bit murky at the moment to me.  Attacks on this sub-net, since it would have at least some worth (perhaps substantial worth) in terms of Bitcoins might make it attractive to go after instead of the main Bitcoins network, so this may be a completely worthless solution too.

Perhaps a debit and credit system could be set up instead that could be secured, where after awhile some sort of accounting goes on to "settle up accounts" on perhaps a weekly or monthly basis where the main Bitcoins network would then be involved.

I would imagine that such a sub-net might have applications beyond just the one specific piece of software I'm going to be using it in, which is why I'm also being very deliberately vague here as well.  So in this sense it really is a genuine "sub-net" of Bitcoins and could also be used as a means to scale the activity of Bitcoins as well in a number of ways.  With sub-nets of this nature, the "backbone" of Bitcoins could be dealing with the major transactions while the sub-nets deal more with the petty transactions of day to day actions.

Any other thoughts on how to crack this kind of problem domain?