 Show Posts
|
|
Pages: [1]
|
https://www.matchtvplus.org/They charge 1 YEAR $216.00 and aren't even accepting new clients at the moment I'm charging $100 for the top package with everything including PPV,WWENetwork,EverySports Channels and so much more... How do I have so many accounts to sell at such a discount? Well i'm a re-seller and when you do enough sales you earn credits towards extra slots and when your a A+ seller you get Diamond privileges. All you need is a ROKU and you are good to go I am willing to give 1 vouch account but will only allow access on that one for a 24 hour period and they must be a trusted member here. Mach tv plus offers a great variety of channels for the whole family. SD and HD channels included along with special events, fights and concerts. Special Events: NBA, NFL Sunday Ticket HD HD channels: NFL Sunday Ticket 1, NFL Sunday Ticket 2, NFL Sunday Ticket 3, NFL Sunday Ticket 4, NFL Sunday Ticket 5, A&E, ABC, CBS, CBS 2, CNN, ESPN, ESPN 2, ESPN Deportes, ESPN USA, FOX, FOX Sport 1, FOX Sport 2, FX, FX Latino, History en Espaņol, NAT GEO WILD Latino, NBA League Pass 1, NBA TV, NFL Network, SKY Sports 1, SKY Sports 2, SKY Sports 3, SKY Sports 4, SKY Sports F1, Sony Latino, SYFY, TLC, TLC Latino, UFC Night, Universal Channel Latino, Univision Deportes, USA Network, Velocity, VEVO Hits, VEVO Hits 2, VEVO Hits 3 Channels: ABC, ABC HD, CBS HD, CBS HD 2, CBS SD, CBS Sport Network, CNBC, FOX, FOX HD, FOX Puerto Rico, NBC, NBC Sports, TBS Puerto Rico, TBS USA Spanish Channels: A&E Latino, Animal Planet Latino, Azteca America, BEIN Sports, BEIN Sports Espaņol, CNN en Espaņol, Discovery Channel en Espaņol, Discovery Channel en Espaņol 2, Discovery Channel Latino, Discovery Familia, Discovery HD Theater Latino, Discovery SCI Latino,, Disney XD Latino, ESPN Deportes HD, FORO TV, FOX Puerto Rico, FOX Sports en Espaņol, FX Latino, Galavision, GOL TV, HBO Latino, History Channel Latino, Infinito Latino, Investigacion Discovery Latino, MAX Latino, MUN2, NAT GEO WILD Latino, NAT GEO Mundo, Sony HD Latino, TBS Puerto Rico, Teleformula, Telefutura, Telemundo Este, Telemundo Puerto Rico, Telemundo West, TLC Latino, TruTV, TruTV Latino, TVE Internacional America, Unimas, Universal Channel Latino, Univision, Univision Deportes 2, Univision Deportes 2 SD, Univision Deportes HD, Univision Deportes SD, Univision Novelas, Univision Puerto Rico, Univision USA, Univision West, WAPA America, WAPA Puerto Rico, Warner Channel. Sport Channels: NFL Red Zone, NBC NFL Sunday Night Football, NFL Sunday Ticket 1, NFL Sunday Ticket 2, NFL Sunday Ticket 3, NFL Sunday Ticket 4, NFL Sunday Ticket 5, NFL Sunday Ticket 6, NFL Sunday Ticket 7, NFL Sunday Ticket 8, NFL Sunday Ticket 9, BEIN Sports, BEIN Sports Espaņol, Benfica TV, CBS HD, CBS HD 2, CBS SD, CBS Sports Network, ESPN 2 HD, ESPN 2 SD, ESPN Deportes, ESPN HD, ESPN News HD, ESPN SD, ESPN U, ESPN USA HD, FOX, FOX HD, FOX Sports HD, FOX Sports SD, FOX Sports 2 HD, FOX Sports 2 SD, FOX Sports En Espaņol, GOL TV, GOLF USA, MLB Network, NBA League Pass 1, NBA League Pass 1 HD, NBA League Pass 2, NBA League Pass 3, NBA League Pass 4, NBA TV HD, NBA TV SD, NBC SD, NBC Sports, NBX Sports, NFL Network HD, NFL Network SD, NHL Network HD, SKY Sports 1, SKY Sports 2, SKY Sports 3, SKY Sports 4, SKY Sports F1, SPOR TV1, SPOR TV2, SPOR TV3, SUN Sports, TBS USA, Tennis Channel, The Fight Network, TNT NBA, UFC Network, UFC Night, UFC SD, Univision Deportes 2, Univision Deportes 2 SD, Univision Deportes HD, Univision Deportes SD. Documentaries: Animal Planet HD, Animal Planet Latino, BBC America, Discovery Channel Espaņol, Discovery Channel 2 Espaņol, Discovery Channel Latino, Discovery Channel USA, Discovery Familia, Discovery HD Theater Latino, Discovery SCI Latino, Food Network HD, G4 Tech TV, History Channel 2, History Channel, History Channel Latino, History Channel en Espaņol, Infinito Latino, Investigacion Discovery SD, NAT GEO Mundo, NAT GEO Wild Latino, National Geographic USA, SCI Discovery Science, TLC HD, TLC Latino, Travel Channel, Velocity HD Entertainment: A&E HD, A&E Latino, AMC, Animal Planet HD, Animal Planet Latino, BBC America, Bravo, Discovery Channel Espaņol, Discovery Channel 2 Espaņol, Discovery Channel Latino, Discovery Channel USA, Discovery Familia, Discovery HD Theater Latino, Discovery SCI, Latino, E!, Food Network HD, FX HD, FX Latino HD, G4 Tech TV, Hallmark Channel, HGTV, History Channel 2, History HD En Espaņol, Infinito Latino, Investigacion Discovery, Investigacion Discovery Latino, NAT GEO Mundo, National Geographic USA, SCI Discovery Science, Sony HD Latino, Spike, SYFY HD, TBS USA, Telemundo East, Telemundo West, TLC HD, TLC HD Latino, TNT, Travel Channel, TruTV, Universal Channel HD Latino, USA Network, Velocity HD, WAPA America, WAPA Puerto Rico, Warner Channel. Kids Channels: Baby First TV, Boomerang, Cartoon Network, CBeebies, Discovery Familia, Discovery Kids Espaņol, Disney Channel, Disney XD, Disney XD Latino, HBO Family, Nick JR, Nick Toons, Nickelodeon Music Channels: VEVO Hits, VEVO Hits 2, VEVO Hits 3, VH1 International Channels: AIJAZEERA America, Benfica, FOX Puerto Rico, Nederlan 1-6, SKY SPORT 1-4, SKY SPORT F1, SPORT TV 1-3, TBS Puerto Rico, Telemundo Puerto Rico, TNT Puerto Rico, Travel Channel, TV Chile, TVE International America, Univision Puerto Rico, WAPA Puerto Rico. Movie Channels: 5 STAR MAX, Action MAX, AMC, Bravo, CineMax, Encore Action, Encore Love, Encore Suspense, FX Latino, HBO, HBO 2, HBO West, HBO Comedy, HBO Family, HBO Latino HD, HBO Signature, Max Latino, MoreMax, ShowTime, ShowTime Beyond, ShowTime Extreme, ShowTime ShowCase, Sony DC, Spike, Starz, Starz Cinema, Starz Comedy, Starz Edge, SYFY HD, TMN The Movie Channel, TMN The Movie Channel XTRA, TNT, Universal Channel HD Latino, USA Network, Warner Channel & many more.
|
|
|
|
For many of those who are forum regulars, you should know that I started a documentation effort with the old doku wiki here: http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1In addition, with the move of the "documentation" to bitcoin.it, there is now a new effort here: https://en.bitcoin.it/wiki/Protocol_specificationFurthermore, there are additional efforts to formally document the protocol at the following locations: In addition, there is always the C++ code of the reference implementation of the Bitcoin client itself that "documents" the protocol by way of the source code itself. Mind you, I'm not here telling anybody that they shouldn't try to start their own documentation effort for the protocol, but I think it would be to a great advantage to everybody involved if we all worked together rather than having this accomplished as a bunch of different and separate efforts. More significantly, I would like to get a forum or some place where we as a community can intelligently debate and discuss the internal workings of the software and specifically do either a "cleanup" of the protocol or to rationally make changes to the overall protocol that can be beneficial. Some of this is planning ahead and trying to anticipate the needs of the community, but I would like to point out that this network protocol really is bitcoin in its most raw and base level. From long experience I've seen how coding first and documenting later can be a bad thing once you are trying to put some stability to some software. Yes, there is a need to do rapid prototyping when you aren't sure about how to proceed with a software development project, and sometimes you can get ahead of yourself where you keep coding, but with the thousands of dollars (and other kinds of currencies) now invested into Bitcoins and (we all hope) soon to be millions involved, it is about time we also discuss just how the "protocol development" ought to proceed. Some new structures were introduced into the Bitcoin software v 0.3.17 and while there has been some introduction to those structures, I think it would be wise to debate those structures in a public forum before they get implemented in software more completely. There are also other ideas which have been discussed elsewhere, including perhaps things related to the "Bitcoin-DNS" projects and other "extensions" to Bitcoin that may prove to be useful. In other words, I am also calling for a more formal approach to the protocol development. This is not really a technical issue so much as a political issue. Enough of the protocol has now been documented that alternate implementations of the protocol are now possible based strictly off of this documentation, and Bitcoin is about to hit a new level of organization where people using this documentation will take the concept of cryptocurrency to many new directions. With web protocols, we have the "world wide web consortium", and of course with more general network protocols we have the IETF. How can or should the "governance" of the bitcoin protocol happen, and in what ways can changes to bitcoin help benefit the community? More specifically, I'd like to end the confusion and make at least one documentation effort more or less "semi-official" at the moment by general community consensus, but at the same time we ought to be discussing where we can or should go from here with this documentation effort too. To me it seems to be the wrong way to get things accomplished by publishing code and expecting the documentation to catch up... at least if the goal is to stabilize the network. There are also some "flaws" in Bitcoin which also need to be intelligently discussed, including known weaknesses with the current specification. |
|
|
|
http://www.sltrib.com/sltrib/home/50949183-76/gold-state-utah-coins.html.cspLegislation which is being proposed for the January legislative session proposes that Utahns should be permitted to use gold for payment of debt to state agencies instead of federal reserve notes. This legislation also gives specific legal authority for private citizens in Utah to coin their own money. I have no idea how this fits with federal constitutional authority for coining money, but it certainly is something that really struck me as something both odd and curious that a formal discussion in at least this state legislature over the validity of federal reserve notes and perhaps this is an indicator of what may be a trend elsewhere if the U.S. Dollar goes hyperinflationary. Note that this is merely proposed legislation, and the reason this is in the news is because state legislators are trying to jockey themselves into position before the legislative session starts at the beginning of next month (January 2011). At least in Utah, the legislative session lasts only 45 days and any legislation not passed by the end of the session is considered dead. December is usually when the more outlandish things come out, but none the less I think this particular bill is going to be at least discussed in committee. It will be interesting to see how much traction this issue may have, and if other states might join with Utah in doing the same thing.
|
|
|
|
|
The Wikipedia article on Bitcoin has a field which describes what the "annual inflation rate" of a currency is at. It sort of got me thinking about what sorts of data could be used at least in terms of what the deflation rate of Bitcoin might be, either on a month to month basis or on an annual basis.
The problem here is mainly trying to find a "basket" of goods which can be used for comparison purposes and somehow "averaged" as a reasonable comparison to show the deflation. About the only consistent transaction that has any sort of history is with the currency exchanges, but would that be a reasonable guide for such a calculation? What other things ought to be included in calculating inflation?
There is the price point of a pizza being sold for 1000 BTC, which is an interesting benchmark for the value of a Bitcoin in regular use and is otherwise independent of other currency transactions. Bidding Pond might be useful here too, although the problem there is the lack of consistency for common goods to be compared.
Perhaps the Bitcoin economy is still far too small. If so, perhaps this is something that simply needs time to work on, but I think a discussion of potential benchmarks for calculating a figure would be useful.
|
|
|
|
|
I came across an idea that I think is worth discussing in regards to a kind of "attack" on the bitcoin network. I'm calling this a "mining cartel attack". I have no idea if this is being done right now, and I'm being pre-emptive in terms of describing it as I'm sure the thought has come across the minds of some other people too. Perhaps I'm missing an essential element of Bitcoin here, but I think this could be a serious issue and I'm not sure of what protections, if any, are in place to stop this.
The assumption right now is that anybody can create a new block through the block generation system in place on Bitcoin and simply throw CPU cycles that eventually will be recognized in one form or another. So far that is true and in fact I've been able to create a block doing just that as have many on this forum and elsewhere. I consider that at least for the moment "proof" this attack isn't happening right now, at least for myself. As long as everybody is being mostly honest and understanding that the strength of the network thrives by having as strong of a block chain as possible, this will continue to be the case.
Instead, in a "mining cartel attack", I'm proposing that a substantial number of "miners" who possess a substantial fraction of the computing power of the network, but not necessarily 50% of the network, could form into a cartel that would only recognize blocks generated by each other. Perhaps they would let a few other blocks get past them from time to time to hide this attack, but the vast majority of the new blocks recognized by this cartel would have to be produced by cartel members. BTW, the "letting a few other blocks past" also reduces the percentage of the network needed by this cartel to pull off this attack as those other blocks are actually contributing to the overall strength by including "independent miners".
Bitcoin works by recognizing the longest block chain in terms of proof of work. Since this cartel is mostly rejecting blocks from other nodes yet they have some substantial computing power under their control, they can create longer chains as a group than the rest of network, especially if the rest of the network is disorganized and consists of mostly small-time "independent miners" not in a cartel. It doesn't take much here, even if only on occasion they are rejecting a few blocks from non-members of the cartel. This in turn, from an economic viewpoint, is going to strengthen the cartel members by "winning" more blocks and thus block generation coins and transaction fees associated with those chains more dominated by the cartel.
The programming for such an attack would be quite tricky, especially if you are trying not to get caught quickly that this kind of manipulation is happening. It is something that could "scale" with the proportion of the network controlled by this cartel as the closer they get to 50% control of the CPU resources of the network also regulates how many "non cartel" blocks can be rejected in favor of cartel members. I'd have to do some simulations to see what percentage of the network would be needed to reject any blocks from other miners as I don't think a single PC could do this attack at all.
Presuming in an ideal situation where the mining cartel persists with this attack, on a social level many of the non-cartel members would drop out of mining (it is already happening anyway) as they simply can't get their blocks recognized and think the effort of running the CPU isn't worth the effort. Cartel members would be claiming that the issue is mainly because of increased mining difficulty (which may be true as well) but it should be noted that isn't the only issue here. Still, the net effect is that the mining cartel ends up with an increasingly larger portion of the network and thus firmer control over the ability to manipulate the network to their own advantage.
Multiple cartels could also exist in this framework, with or without the knowledge of each other. There would be strong incentives to try and identify other cartels and certainly to propose a "merger" of competing cartels if possible under all sort of arrangements.
The primary issue on a technical level would be to identify which blocks belong to cartel members and thus should be used for building the next block of the chain by cartel members. This would likely be done "out of bandwidth" as a separate communication channel independent of the main Bitcoin communications network, although an "in bandwidth" scheme could also be set up.
The net harm to Bitcoin as a whole is that the block chain would ultimately be weaker as a result of this kind of attack, since CPU cycles "spent" by "independent miners" would not be recognized or used for difficulty adjustments on the network. This is also something that a government could use to "capture" Bitcoin if they were patient and were willing to work outside of legal attacks. Still, I see this mostly being done by self-interested participants who already have some substantial CPU resources and are simply being greedy. Transactions themselves would not be harmed and those with Bitcoins already in some form or another can arguably even be supported by such an "attack" as the miners are doing some of the "dirty work" involved with running the network... something cartel members would assert anyway as a sort of "public service".
Is this something to even worry about? I don't see an "easy" way to stop this sort of "attack" either, although there certainly are plenty of historical examples of similar kinds of "conspiracies" to restrain activity like this. Just look at DeBeers in South Africa if you need some examples to look at.
|
|
|
|
An interesting article (via Slashdot) came up that I think is of interest to the Bitcoin community: http://www.h-online.com/security/news/item/NIST-s-search-for-the-super-hash-just-five-candidates-left-in-SHA-3-final-1151325.htmlI know that Satoshi has at least planned for this, but it certainly is worth a look. What the non-geeks who use Bitcoin should know about this: The NIST is conducting a strong mathematical review of these algorithms in an attempt to find their weaknesses. It may be possible that these algorithms may be "better" than the current SHA v. 2 algorithm that is being used in Bitcoin currently. In other words, think of it like a mathematical "safe" for your Bitcoins that can have a much stronger system that is harder to break apart, presuming these algorithms work out. There has been an ongoing investigation and request for ideas on how to strengthen the SHA algorithm, with a sort of "contest" to the cyber-security community for quite a while. This news is mainly that the list of candidates has been narrowed down and that some kind of final decision is going to happen "soon" in terms of which algorithm is going to be considered an "official" standard for hashing. |
|
|
|
|
There are currently three messages in the Bitcoin protocol directly related to conducting IP address transactions:
- checkorder
- submitorder
- reply
The only use for these messages is to conduct transactions over an IP address (unless somebody gives me a better excuse). I get that backward compatibility with earlier clients might make it useful to keep these messages for a time, but at this point the entire notion of sending transactions to an IP address is almost completely refuted as a really bad idea. Other alternatives such as "accounts" and perhaps other systems could be developed through the network itself that I don't understand even the need to maintain these data structures and messages at all.
Is anybody still using IP address transactions? If you want to keep them in the current client on the philosophy "if it ain't broke, don't fix it", perhaps it isn't doing any harm, but it seems like generally a bad thing to encourage other alternate implementations to create this backdoor that isn't really being used. I'm glad that the default situation is to simply prohibit people from using this from within the GUI interface, but my question is mainly if they should be formally marked as depreciated messages that are not going to get additional attention in the future?
Certainly if you are re-implementing a bitcoin client with the protocol, there is no need that I can see to putting these messages into that client. Perhaps I'm missing something as to their importance in the protocol, if so, please enlighten me.
|
|
|
|
I have an interesting discussion going on with another thread that brings up a technical question regarding Bitcoins itself: http://bitcointalk.org/index.php?topic=2001.0There was also another discussion started that suggested some alternate ideas about how to use Bitcoins and a bitcoin-like generator for other purposes: http://bitcointalk.org/index.php?topic=1790.0I'm sure that other discussions of a similar vein have been started too, but in these discussions I've considered the problem of how to transfer Bitcoins to potential miners in this situation. For instance, I would like to set up some algorithm where you could "set aside" some Bitcoins for somebody who can perform a publicly recognized and "certified" form of work. The exact criteria could be defined in some other manner, but what would happen is that the coins would be put perhaps in some sort of escrow until that algorithm releases those coins to a designated Bitcoin address when the work is completed. Explicitly what I'm trying to do is find a way to have miners of a secondary chain be able to collect bitcoins for their "proof of work" hashes on those secondary chains. The issue really is more of a synchronization issue where there is an agreement to have transaction fees on the secondary chain get put into the primary Bitcoin blocks as Bitcoin transfers between users of defined addresses. Specifically, the algorithm I'm thinking of using here in regards to the stock exchange block is one where the share transactions are collected by "miners" for the stock exchange chain and all Bitcoin transfers are in turn relayed to the Bitcoin network as ordinary Bitcoin fee transfers. Since there is the potential for competing nodes and competing chains (based upon similar principles to Bitcoins) the actual transfer of Bitcoins for the miner shouldn't happen until after the block is clearly accepted into the chain, for example when the block is 10-15 blocks deep into the chain. At that point this particular "hash miner" will receive the coins for its part in preparing and processing the transaction of the secondary chain and the "escrow" will be released. I can see this being done with other kinds of escrow services where perhaps some sort of double hash or certification algorithm would be set up with the escrow service then releasing funds when agreed to by both parties. Perhaps this is the same thing, but then again it might be a different problem domain altogether. The real trick here is that it involves a third party in the form of a miner who is receiving funds from at least one of the parties in a transfer "with consideration of other things", and then on top of that this third party isn't defined until after they have performed the work to build the block and get it accepted into the chain. We do this with miners of the main Bitcoin chain, but since they are processing the transactions themselves they also can be selfish and keep "leftover" bitcoins in the form of transaction fees. It gets even more complicated here because a fourth party, the main Bitcoin miner, is also involved in trying to process the fees in question. It is one person sending money to three different people (potentially) where only one of those people is known ahead of time and the other two people must show some kind of "work" to "earn" the money set aside for that work. Perhaps this is impossible, but on the other hand I think it could be resolved in a number of different ways too. Perhaps all of this must be incorporated into the main BTC mining chain as an "extended service" where miners could earn some extra coins (at their option). Perhaps it simply can't be done at all. I'm willing to think "beyond the box" here and realize this isn't an easy problem to find an elegant solution. My preference would be to find a peer to peer network solution, but if it can only be done with a central server doing transactions, so be it too. Please keep this to the technical discussion of this particular problem and not get into the stock market philosophies... which should stay on the other thread. |
|
|
|
The thought came across my mind that there is a niche to be filled for some kind of securities exchange that might be dedicated to transactions involving Bitcoins. This may be something perhaps that is premature or perhaps legally too encumbering. Basically I want to float the idea and see where perhaps those on this forum might even see a way for this to begin. The role of a stock exchange, so far as I see it and how it would certainly work for Bitcoins, is a way to concentrate wealth in such a way that a useful enterprise might be started. Not everybody has access to huge mining farms to collect coins, they may have started later and not have coins, and certainly the number of things with which you can spend the bitcoins on is more limited and sort of chaotic. There would certainly be some sort of programming which would need to be done in terms of setting up this exchange, but I see most of the issues dealing with an exchange to be more political than technical. Rules would have to be established for what qualifies as a security, how those "securities" are organized and recognized by the community at large, and how such an organization could be set up. So far as bitcoins are concerned, electronic securities are essentially the same thing as a bitcoin and would likely have similar hashing algorithms for authentication. Much of the "trading floor" may even be possible to be done with peer-to-peer clients and "seats" on the "trading floor" would likely be much more direct. I am worried a little bit so far as the legal implications of doing something like this are concerned. I came across this page via the SEC website which goes into some of the current laws that at least a "nationally registered exchange" must follow. Then again, if it is a peer to peer network thing with (at the moment) very low volume in terms of dollar value traded it might just fly under the radar until we can afford some more competent legal counsel to make the whole thing "legit"... or perhaps inspire somebody else to build a more "legal" exchange if it is necessary. In this regard, I'm more of a damn the torpedoes kind of guy as long as everybody knows that this is all experimental using an experimental currency which may all fall apart anyway. The law in this case would be a good guideline, however, in terms of what rules we ought to consider for establishing this exchange and we might as well follow the law so far as making that an ultimate goal. The NYSE started as a bunch of merchants gathering underneath a tree that happened to be next to the city wall on the edge of New Amsterdam (hence "Wall Street"). A Bitcoin security exchange can certainly have as humble of a beginning. There certainly are enough enterprises of various kinds using bitcoins that perhaps some way for people to invest in those ideas could be organized with the idea to create an investment mechanism for Bitcoin-related enterprises. Yes, I'm trying to be serious here, and it is something I would like to get organized. Other than the legal issues, I don't see any significant show stoppers but I'd like some feedback on the idea. |
|
|
|
|
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?
|
|
|
|
This is mainly a theoretical discussion rather than an actual proposal I am making in terms of changes to Bitcoins, but I would like to perhaps open up the discussion about other "metrics" that might be used for a peer-to-peer electronic coin system similar to Bitcoins, and perhaps come up with a strong defense for the current system as well from a logical viewpoint. It was this post that got me thinking originally: I like the idea of separating the daemon core from the GUI. That way others can build their own interfaces for using bitcoin like a KDE version for my desktop or a web interface.
Oooh.. I do like the idea of a bitcoin daemon presenting itself through a KDE Plasma widget...  Either way, I have been thinking about the whole mining aspect of Bitcoin these last weeks, since the difficulty has gone through the roof. It would be nice to have the whole generating part be (more) independent of processing power, and more balanced towards the amount of time one puts in. However, I think most alternatives will, sooner or later, fall victim to people using their non-bitcoin wallets in order to change a new more balanced way of generating bitcoins in their favor. If generating would be dependent on time spent, people would simply spawn multiple processes, virtual machines, etc. If generation would be dependent on bandwidth spent (as a Tor middleman node perhaps?  ), people would invest in broadband connections, servers in datacenters, etc. If generation would be shifted from something GPU-optimized towards something only CPU's are good at computing, people would invest in CPU's. As I am running out of ideas, I would like to add that I too am in favor of having Bitcoin default to 10/15% of a CPU core generating for the sake of network stability and security. In fact, it would be nice if Bitcoin allowed me to select percentage in addition to number of cores. I have no clue however if that is easily added or something incredibly complicated to code. What kinds of alternative systems could there be and how could we reward people contributing to the project in some way that is concrete, automatic (or semi-automatic), and could be measured in some way that could be verified independently that those making the contributions are getting rewarded? Network bandwidth is obviously something that is in fact necessary for the whole concept of Bitcoins to work out, yet there currently isn't any metric that encourages people to become the central node to a whole bunch of connection as opposed to having merely one or two connections to the outside world, other than perhaps who is going to get the first jump on the next work unit if it became a contest. How could you monetize network bandwidth in this case? (for the purposes of Bitcoins) Would "potential" capacity be more important or would simply measuring throughput be more significant? Should nodes "pay" for previous work units to be sent their way? If you request the current 90k work units, that represents a sizable amount of data, and it would seem like there could could be some cost to that sort of bandwidth represented in the network itself. That would stink if you had no bitcoins, but then again it might spur on some "buy-in" if you were to set up another client. I'm not talking a huge cost here, but paying 0.000001 BTC per work unit retrieved could be an interesting transaction (perhaps less, I'm just trying to put a starting point on this here). It would also give a way for people who simply run a client but aren't mining to at least make a little bit of money simply running the client. Even an option to voluntarily "pay for work units" might be interesting as perhaps there are some users who would be willing to "share the wealth". Would "time served" or "time connected" be useful by itself? Coming up with a different algorithm which can't be implemented in a GPU is an interesting concept too. That has some of its own issues, but is again something to think about. Ideally it would be nice if each participant in the project was able to get an equal slice of the coins generated. Unfortunately, at best all I can think of is perhaps some other ways to "generate" coins based upon participation with the project. Putting in a bug bounty or paying for participation in the forums seems like a good idea, but again the question comes to how is it being paid for. Some of that is already happening anyway, so I don't see a need for that to be included in the client software itself. Are there any other metrics that you can think of in terms of how else contributors to Bitcoins could be rewarded and automated with network rules? |
|
|
|
It was mentioned in the thread about Splitting/merging wallets ( https://www.bitcoin.org/smf/index.php?topic=751.0), but I think this is an important enough topic on its own right that it deserves its own thread. Bugzilla ( http://www.bugzilla.org/) is the bug tracking software used for the Mozilla and the MediaWiki projects (and several other prominent projects of various kinds). It certainly is stable and has the ability to set priorities, assign projects to individual developers (or have them claimed) and allow for communications between developers, users, and interested 3rd parties on development issues that are specific with a problem-focused approach to development. My question is if this should be implemented for Bitcoins and what other alternatives might be available instead of this system? The development forum certainly has its use, but it is a bit of a kludge when trying to address specific issues. |
|
|
|
I've started the following document on the wiki and I would like to encourage others to help join in writing this document: http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1Basically, I'm trying to come up with a formal specification for Bitcoins as a documentation effort to keep track of the "rules of the road" in terms of how Bitcoins clients interact with one another. This document is intended to focus on the core functionality of the network, and in time it should contain all of the information necessary to create a complete implementation of Bitcoins from scratch in a "clean-sheet" design. I've complained about this in the past, and I'm putting my money where my mouth is. For now, I'm simply going to try and pull the information from the source code as possible, although I would appreciate adding some of the philosophical underpinnings into this document as well. This is not a FAQ, but a rather a technical document going into the fine details of Bitcoins. |
|
|
|
|
I would like to know where a discussion area can be that can refer to the development and creation of articles for the "official" Bitcoins wiki can take place?
There are several schools of thought, where perhaps the discussion of the wiki articles can take place on the wiki itself or it can have its own forum. What I'm referring to here, however, are "meta" discussion such as editorial policies, style guides, and ontological discussions that cover how to simply organize all of the information on the various pages, and even "deletion" discussions.
Considering the nature of how the current wiki software works that has been adopted by this project, it would seem like a separate forum section would be preferable for these kind of discussions. For now a simple stickied "Wiki organization threat" might be all that is needed considering the volume of edits but that could change over time.
I'm not trying to force any particular idea as the best, but I would like to know what is preferred by those who would like to participate with the wiki development, and note that I would like to be adding a whole bunch more content onto the wiki as well.
|
|
|
|
|
I mentioned this in another thread, but I think it has some validity in a general discussion here:
How would you move Bitcoins between the Earth and Mars?
I think the short answer: You can't. At least with the current design of the network.
Mind you, I'm not suggesting here that we need to deal with a science fiction eventuality that won't happen for years or even centuries, but I think it may have other side applications even for more mundane uses here on the Earth. I'm suggesting this mainly as a thought experiment and perhaps a work around for something constrained under these kind of conditions.
The main issue here is the several minutes it takes for round-trip communications (up to about a half-hour or perhaps a bit more with relays) between the Earth and Mars.... constrained by the speed of light. Unless you have a non-Einsteinian physics that allows you to do communications at FTL velocities, this is something that simply has to be dealt with in that sort of situation.
I could imagine for a more mundane terrestrial application to be trying to carry on a transaction where networks might be separated at some point (a couple of "different" bitcoin networks get put into temporary "islands" before they can merge their transaction/coin generation data together) or perhaps you are trying to conduct a transaction "off network" where the transaction wouldn't get recorded on the larger network as a whole.
For the sake of this discussion, consider that most of the nodes involved here are "honest" and trying in earnest to conduct real transfers of Bitcoins, so this isn't necessarily a direct attack by any particular node. This perhaps could be an attack on the network itself or a natural/man-made disaster of some sort (nuclear war, hurricanes, tsunami, mega-volcano, meteor strike) that causes significant communications disruptions where communications between groups of nodes is broken off for an extended period of time.
How would two groups of nodes "re-sync" to each other in a situation like this if some sort of communication bridge could be established but would take significant periods of time to happen?
Yes, I'm being serious here too, and the issues involved have an impact on the performance and stability of this as an alternate currency.
|
|
|
|
|
I've been trying to think of a "solution" to the problems that some people have been having with their wallets, and also thinking about the issue of what I would do if something happened to my computer and I lost my Bitcoin wallet. Backing it up certainly is a good idea, but there obviously are some additional problems that come up with this "solution".
Perhaps this is a solution in search of a problem as well, but I'd like to start a discussion of perhaps adding a "virtual wallet" or better recognized as a sort of digitial escrow for the wallet data that could be preserved in the network in a peer-to-peer network fashion. What I'm proposing here is a way to store the wallet data in the network itself, where all you would need is some sort of hashkey (something very strong!) that could "reload" your wallet if something happened to your wallet data.
I'm also proposing something here that would be completely voluntary, as if you are very paranoid you could still keep your wallet exactly as it currently exists. This is an "opt-in" ability to be used within the client and network, and not all nodes would necessarily even have to be involved with passing TCP/IP packets with the virtual wallet data. As an incentive, there might even be a minor "storage" fee associated with this "service" that we could work out, but the point is to include it into the existing network topology for Bitcoin and provide a safeguard for those who may want to preserve their wallet data.
I'm also hoping this isn't a "bridge too far", but I'd also like to see what sort of technical flaws or problems might come from somebody having something like a credit card that would contain a hash key that could be used in a point of sale device to make payments with Bitcoins. Mind you, this is something purely theoretical at the moment, but I think it would be something useful that could aid in the adoption of bitcoins.
The idea here is that somehow a merchant could have a device that would read the hashkey and load the virtual wallet in some fashion so that a customer could make a purchase with that wallet. The problem here is that once loaded, the merchant would have access to the rest of the coins in that wallet. Perhaps there is some other solution to the issue of a point of sales terminal that does not require a customer to have their own computer (cell phone, PDA, etc.) to issue bitcoins to a potential merchant.
Regardless, a virtual wallet could be useful to have the coins "shared" on multiple computers such as on your PC, a cell phone, or with your spouse who is using some other equipment. Double spending of the same coin would be protected with the current procedures that keep that from happening anyway.
|
|
|
|
|
I'm not entirely sure where to put this, but the whole idea of bitcoins has really got me thinking about potential applications for the concept, and I've been thinking of trying to use the concept for the foundation of a serverless MMORPG that would be using P2P networks instead.
I'm posting in the trading section as I also think that it is nearly impossible to ignore "real world trade" within an MMORPG. It is also something that potentially could also provide an early market for bitcoins or as a generation source for it as well. Buying and selling of virtual goods has value above and beyond real world money, but it is also something that folks who use computers on a regular basis would find appealing and fits in well with the demographics of the early adopters of bitcoins.
I'm also thinking it would be an excellent environment to do some experimentation with the concept of virtual currencies, where different coin generation philosophies could be experimented with in terms of seeing what might be a more optimal generation system.
While what I'm proposing would be an "open source" project (at least that is my intention), it would be a chance for participates to be earning bitcoins in a variety of ways through what is right now a multi-million dollar industry.
This is mainly an initial feeler if there is anybody interested in the idea, or a general query to see if there might another thread with a similar topic. If there is interest in this idea, I would love to expand on the idea and perhaps even go over some notes and white papers on the topic (or at least try to get them written).
|
|
|
|
|
I've been trying to go over the algorithm for coin generation, and I still don't get it even after reading the PDF file, the FAQ, and the source code for where it is apparently generated. Please correct me if I'm wrong here:
Bitcoin generation is restricted due to the fact that the method of generating the coin in the first place is a computationally difficult task that consumes many CPU clock cycles and therefore only can be generated slowly by participating nodes on the network.
I guess I'm having problems seeing where this algorithm is necessarily all that difficult and can't be sped up in some manner where a dedicated coin generator wouldn't have a huge advantage over a normal ordinary client in terms of the creation of Bitcoins. It would have to take requests from other nodes to "look legitimate", but the creation of the currency seems like a major technical hole in the algorithm.
I'm looking at this through the perspective of perhaps implementing a network similar to this, but for the purposes of perhaps a distributed MMORPG where the coins, monsters, resources, and objects found within the game are allocated in a decentralized manner. A distributed game has the advantage of not relying upon a central server to perform the bookkeeping functions and allows a more natural economic model to emerge. It also allows for an "open source" model for client development... something that doesn't work when the development model is security through obscurity.
There is nothing special about a particular monetary unit, such as a bitcoin, and it certainly could represent Linden Dollars, Pounds Sterling, or some other monetary unit as well or even describing some unit of a commodity. In terms of a role playing game of some sort, resources or alternate currencies need to have some sort of scarcity in order to keep a "cheater" hack of the game from destroying the economy. Try as you might, you can't keep real-world money from interacting with virtual currencies, even if that is an explicit goal of the software developers. I know of several companies who have tried (notably Bilzzard and Jagex). I just think the Bitcoin generation system is an effective means of developing a network of clients in a shared virtual reality that could even offer persistent interaction without the need of a server.
I've seen much in the way of hackers that have gone on to wreck on-line games, and indeed I would argue that the development of a virtual economy would do wonders to bullet proof the eventual deployment of something like Bitcoins as an alternative currency. It is sad to say, but some kids are more concerned about trying to get 1 million coins for World of Warcraft than they are to get 1 million dollars.
With all of this, I'm just trying to understand the Bitcoin generation process a little more thoroughly, and perhaps have somebody who really understands it to explain what is going on in the first place.
|
|
|
|
|
