Bitcoin Forum
July 02, 2024, 12:10:28 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 [136] 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 ... 384 »
2701  Alternate cryptocurrencies / Altcoin Discussion / Re: Ixcoin TODO on: September 11, 2013, 01:37:13 AM
rsnel, GeistGeld is getting to need over 16 gigs of RAM or thereabouts, would you be able to upgrade it with I0Coin's nice new stuff so that all of a suddent it too will fit in little RAM and thus be accessible to many more people? There would be a lot of XGG in it for you if you can because the more RAM it takes the less people left who have enough RAM to run it, its difficulty is thus pretty darn low. So you can pick up oodles of them easy and likely improve their value a lot by doing such an update.

A trouble with Ixcoin is it has been merged mined all along so has pretty much always been too high difficulty for small miners. I0Coin went purportedly-dead a nice long time allowing small miners a long time to mine it, GeistGeld has always been low difficulty so has always been a haven for small miners. If you can update it, maybe large miners will still claim it is dead and not bother with it, so maybe we can get it back to small enough RAM for small miners to be able to fit it in their RAM again, and give them thus maybe quite a while longer to mine it again.

-MarkM-
2702  Bitcoin / Project Development / Re: Cunicula System for USD Derivatives backed by escrowed Crypto Currency on: September 10, 2013, 05:41:48 AM
I see mention of 8-fold. 4-fold, and 2-fold backing.

If I recall correctly long ago you had been telling us that you need quite a large warchest, certainly more than "100% reserves" to attempt to peg a currency. Is this thing going therefore to take at least 8 times as much reserves (maybe of both sides of a pair) in order to function? Maybe with 7/8ths of it being investment capital from people hoping the scheme as a whole will turn a profit?

-MarkM-
2703  Alternate cryptocurrencies / Altcoin Discussion / Re: Ixcoin TODO on: September 10, 2013, 12:50:50 AM
Merged mined coins use more RAM. The more blocks they churn out, the faster this makes their RAM needs grow compared to chains that have slower time between blocks.

The fastes block time merged mined coins thus grew to huge RAM needs faster than the chains that have more time between blocks and thus less total blocks to deal with at a given time in history.

The fastest chain was GeistGeld, so it hardly even got adopted in the first place as it was so fast that its huge RAM needs very rapidly become obvious.

Next-fastest apparently is I0Coin, so although e.g. bitparking merged mining pool did initially adopt it, eventually the amount of RAM it needed was large enough doublec apparently no longer thought it worth merging. Also, only recently did it come out that the excessive RAM used is legitimate, not some kind of "memory leak" bug. So for a long long time the urban myth about GeistGeld and I0Coin has been that they have memory leaks. A while back someone really tried hard to find and fix memory leaks in I0Coin but still it kept needing lots of RAM. Much more recently someone figured out it is simply that merged mining leads to needing more RAM, thus went ahead and added code to deal with that. Even more recently, they made the offending data, that merged mined coins keep in RAM, instead get stored to disk. So that now I0Coin is probably one of the best merged mined coins of all in terms of how little RAM it needs since all the others still keep all that "proof of merged mining" data in RAM.

So ultimately all the merged mined coins will reach some level of RAM use that people find excessive, the ones with faster blocks doing so sooner than the ones with slower blocks, so that each in turn reaches large enough RAM use that nodes will either drop them for using too much RAM or upgrade them like I0Coin to store on disk instead of in RAM that data the merged coins use to prove they were indeed merge-mined.

Evidently so far people don't seem to mind how much RAM namecoin, devcoin, ixcoin etc each use, so far only I0Coin and GeistGeld got big enough for people to drop them. But they are all growing in RAM-need faster than non-merged coins so it is just a matter of time unless maybe amount of RAM in off the shelf PCs starts growing fast enough to keep up.

(I could not even run GeistGeld on an 8 gigs of RAM machine, for example, to do so I need to get it upgraded like I0Coin was upgraded. Meanwhile I run it on a 16 gigs of RAM or more machine. I0Coin would run on 8 gigs though, as it only needed 4 or 5 gigs or so before it was upgraded. It uses about half a gig now I think.)

-MarkM-
2704  Bitcoin / Project Development / Re: Cunicula System for USD Derivatives backed by escrowed Crypto Currency on: September 10, 2013, 12:01:19 AM
Wow. Nothing like keeping it simple, eh? Smiley

I look forward to the text version. Smiley

-MarkM-
2705  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [DVC]DevCoin - Official Thread - Moderated on: September 09, 2013, 11:51:49 PM
In case some of our authors don't follow the Project Development part of these forums, I thought I'd bring this to their attention:

https://bitcointalk.org/index.php?topic=290503.0

-MarkM-
2706  Alternate cryptocurrencies / Altcoin Discussion / Re: Ixcoin TODO on: September 09, 2013, 11:15:35 PM
So far for value estimates of assets, including blockchain based currencies, I have been resorting to

http://galaxies.mygamesonline.org/digitalisassets.html

However it has been a long time now since the days when automated order/offer placing scripts were being run against the Digitalis Open Transactions Server daily to post orders/offers based on the figures more-recently being posted as http://galaxies.mygamesonline.org/latestrates.inc so basically the markets are no longer being kept full of offers/bids automatically.

Back then such offers/bids expired after 24 hours, that is why they were being run daily. Also, doing so helped discover that Open Transactions had been allowing one to to be matched against oneself; that glitch is now fixed. (Instead one cancels the offer of one's own that one is being matched against.)

I think the problem with the automated market-making scripts was the tendency of so many assets to just go up and up in value; players were concerned that it was too simple to just buy something from a market-maker script's offer one day and sell it back to the same script the next day, or a few days later anyway, at a higher price than that very script had sold it for.

I guess if there turns out to be demand for such automated market-making again the scripts should be changed to only market-make one side of each pair, that is, either sell the stuff or buy it but don't do both. But is that really "market making"? how do people then easily sell what a script sold to them if the script is not placing offers to buy it back for less than it sold it for?

So I guess right now one would have to try just meeting people and making them offers person to person, such as can be done on IRC and forum threads and so on.

By the way, notice that http://galaxies.mygamesonline.org/latestrates.inc includes a few assets that are not yet part of the tables and plots linked from

http://galaxies.mygamesonline.org/digitalisassets.html

I am not sure yet whether those additional assets are worth the work of adding to the tables-and-lots-building systems yet so am so far merely watching them.

The tables and plots started off as just a quick sketch to let me get an eyeball overview to try to figure out what was going up or down compared to what.

Mostly the goal has been to load-test and debug and develop the Open Transactions system; to that end the Digitalis Open Transactions Server is an abstraction of any/all stock exchanges, and even intergalactic/intragalactic banks, located within the Galactic Milieu, and more specifically, to the extent it models any specific such in-game entity, it is taken to represent the bank and stock exchange located in the city of MI-5ius on the planet known as M5.

Of course once all the bugs are out and so on, it is hoped all banks and stock exchanges on all planets of the Milieu will be represented by Open Transactions servers instead of trying to represent multiple such entities within any one such server.

In other words: it is a game. Don't take it too seriously unless your preferred style of gaming is to take your games seriously (in which case please bear in mind the relevant jurisdiction is the city of MI-5ius on the planet known as M5, NOT the planet known as Earth).

So yeah, over the counter could mean going to a planet far far away, possibly even in a galaxy far far away. Smiley Cheesy

Of course if you happen to have characters on such planets, maybe such characters could meet up with other people's characters who happen to be on such planets, and do some character to character trading?! Smiley

-MarkM-
2707  Alternate cryptocurrencies / Altcoin Discussion / Re: Ixcoin TODO on: September 09, 2013, 07:34:13 PM
Vlad, you do know I0coin now has the most up to date code among the secondary merged chains, right?

It is already too late to merged-mine it at low difficulty anymore, but maybe not too late to pick up cheap over the counter before some exchange picks it up.

Many times when Ixcoin is mentioned people bring up pre-mining. I0coin exists to counter that narrative.

Hopefully they will both do very, very well.

Ixcoin code needs to be updated based on I0coin, of course; but that applies to all the secondary chains, even including namecoin.

-MarkM-
2708  Bitcoin / Development & Technical Discussion / Re: what can Bitcoin learn from high frequency trading regarding the block size? on: September 09, 2013, 03:32:27 PM
Wait, no, not the buggy-whip makers! How are we going to have fully detailed episodes of Sherlock without buggy whips?

Is this why recent Sherlock series' are set in a time when buggies are no longer in use?!?

-MarkM-
2709  Bitcoin / Development & Technical Discussion / Re: NSA and ECC on: September 09, 2013, 03:27:53 PM
Hmm I wonder how many colours of coloured coin it takes to [something something] a blockchain? Wink Cheesy

(You only need four whatzits to build a DNA strand? Hmm....)

Think like the game "sprouts".

(And maybe read Piers Anthony's "Macroscope" while you're at it.)

One point is a point, two is a line, three is a circle.

If the fourth is inside the circle, it is surrounded, no luck there.

If the fourth is outside the circle, how you gonna connect it to the other three without surrounding any of them?

-MarkM-
2710  Bitcoin / Development & Technical Discussion / Re: NSA and ECC on: September 09, 2013, 03:00:25 PM
Sure, if they actually believe it.

But suppose even though you see in front of your eyes the computer produce a solution, all your mathematicians claim it is impossible thus you believe what is really happening is rubber hoses are being wielded somewhere then the PR department is passing off the miraculous results as being due to a secret formula in the computer?

Maybe those who know solutions can be found by that computer think whistleblowing "the government has rubber hoses!" is not exactly breaking news...

The number of people who know the computer really is using math to get the answers need not be nearly as large as the number of people who know the computer is in regular use providing answers.

I probably wouldn't tell people only four colours are needed to colour a 2-D map if knowing it would kill gosh knows how many agents of the five-eyes (brits, canucks, yanks, aussies, kiwis) and the world had not yet proven it to be so. (Scientific American didn't consider it proven until some ridiculously huge computer-generated proof involving iterating over stuff finally proved it long after I thought I had, maybe because my "even a child can grok it" approach is just too darn simple for their complicated little minds.)

Maybe they tell people who would whistleblow if it were rubber hoses that it is math, and people who would whistleblow if it were math that it is rubber hoses, if just letting people imagine whichever they like doesn't seem likely to work in some particular case?

-MarkM-
2711  Bitcoin / Development & Technical Discussion / Re: NSA and ECC on: September 09, 2013, 02:41:48 PM
Whozit's conjecture or whatever, written in a margin long ago, took frikkin centuries for academics to figure out.

Had the guy maybe not really solved it himself afterall but just imagined he had?

I made a proof, as a child, of the four colour theorem that still looks good to me. In my late teens someone even tried submitting it to Scientific American because it looked so good. Yet to this day I still have not managed to get any actual proper refutation of it or explanations as to how, if it is not a "proof", it fails to be one.

My maths teacher when I first came up with it said the whole thing was so far beyond him he could not even begin to judge if it was or was not mathematically a proof but that it sure seemed to be an irrefutable argument to him, lacking as he was in deep enough mathematical training to figure out where it went wrong, if it did in fact go wrong. (It is so simple, even children "get it", thus suspect as in hmm maybe it is not state-able mathematically in rigorous math.)

So between the margin-written thing that people bumped heads with for so long, and my own personal experience, it does not seem far fetched at all to me that some kid somewhere pointed out some insanely simple thing that mathematicians had all overlooked and continue still to overlook.

Then too there is Bell's Theorem, which even now while Joy Christian keeps pointing out Bell's massive deep fundamental flaw in it a lot of physicists just cannot see / understand the flaw, seemingly because they make the same categorical or dimensional error themselves in judging his work.

-MarkM-
2712  Bitcoin / Development & Technical Discussion / Re: NSA and ECC on: September 09, 2013, 02:36:34 PM
So maybe there is a class or category of attacks, making all ECC broken, and they iterated through SHA1 generating curves knowing they could, with their clever class or category, break them, but wanting to not bother recommending those the public already had found attacks for?

The attacks known to the public would maybe mostly be individual subsets of the secret class or individual classes of the secret category or something like that.

(I'd have to go read up on what class and category mean in class theory and category theory if I wanted to check whether I used the words set, class and category correctly.)

-MarkM-
2713  Bitcoin / Development & Technical Discussion / Re: what can Bitcoin learn from high frequency trading regarding the block size? on: September 09, 2013, 02:16:47 PM
I guess there are various different kinds of efficiency.

Does HFT prevent bubbles, by making it so clear so fast that a bubble is in progress that, faster than humans could react, the computers have figured out it is a bubble and taken appropriate steps to discover some kind of actual or realistic price as distinct from some kind of bubble/illusion/runaway-algorithm price?

I have long been mulling over the idea of using batches, like whole minutes or whole block-periods or whole hours or quarter hours or half days or whole days or whatever size/duration batch might be convenient or useful. (Maybe X number of bids/offers even instead of X amount of time), in order to be able to compute an average price per unit of whatever is being bid on and offered on that market. Part of the objective of such an idea is to make more-efficient use of bandwidth, but I am wondering if maybe it might also be more resistant to feedback-loop bubbles, especially ones that run out of control rapidly.

The batches would be in effect some kind of auction, I think.

Maybe in effect the trading house would be saying "this is the average or mean or mode (or somesuch) price, based on the batch of bids and offers we have on hand right now" and presumably clearing any bids/offers that match it.

The idea evolved from what players in certain games actually wanted, which was to set themselves up as "trading houses" that would buy the cheapest offers to sell to the highest bids, taking the difference as their operating budget and (they hoped very lucrative) profits.

Presumably it might be more efficient than such "robber baron" trading houses, and competition between trading houses might lead to increases in efficiency of markets.

If traders need expensive data pipelines driven through expensive parts of town, surely the costs of all that must get passed on to customers? Don't such costs count as lowered efficiency of the transport-and-trade network whereby things get delivered to end-users?

Is it efficient, really, to saddle the end-users of soybeans or APPL shares or any other arbitrary commodity with ridiculous infrastructure costs that serve maybe mostly to fritter away value in a maybe even less useful (to the end users who consume the commodities or who consume the products produced by the corporations whose shares are being traded) way than hashing fritters away resources in the bitcoin network?

-MarkM-
2714  Bitcoin / Development & Technical Discussion / Re: what can Bitcoin learn from high frequency trading regarding the block size? on: September 09, 2013, 06:42:41 AM
Well with luck, for now, satoshis might be a small enough denomination?

If not then maybe people will bid in DeVCoins, or even more than eight decimals could be used, living in players' trading accounts until they accumulate up to at least a whole satoshi.

I think a lot of people accept that eventually blocks larger than one megabyte will end up being allowed, but hopefully not until upgrading their hardware and bandwidth and so on to accomodate a larger size has been profitably accomplished.

(So those who already accomplished it might try to rush things along, but those still trying to accomplish the move to ASICs might prefer to wait for the whole move-to-ASICs wave of upgrades to be basically pretty much over before starting to budget a move-to-larger-blocks wave of upgrades.)

-MarkM-
2715  Alternate cryptocurrencies / Altcoin Discussion / "Why a galaxy far far away" essay on: September 09, 2013, 06:32:15 AM
Why a galaxy far far away? (Essay)

I have started to try to clarify my thoughts about the relating of altcoins and other virtual-world currencies to this so-called "planet known as Earth as compared to various other planets, worlds and universes, virtual and otherwise.

As usual since it is a Devtome page please comment on it here or on its talk page, not by hacking at the page itself, despite Devtome happening to be implemented as a wiki.

-MarkM-

2716  Alternate cryptocurrencies / Altcoin Discussion / "In Praise of Freicoin" essay on: September 09, 2013, 03:42:33 AM
I have started an essay on Devtome...

Unlike most wiki sites, Devtome is not really about hacking away at other people's pages, so please to discuss the essay use this thread or its talk page rather than jumping into the essay itself to add your ideas or remove mine etc.

-MarkM-
2717  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Animation Bounty on: September 09, 2013, 01:32:38 AM
Ok thanks that's great, if others agree don't object.

Fixed that for you. Smiley Wink

(The "no news is good news" principle; no need to eat bandwidth with "I agree" messages.)

DVC is mining both CPU that GPU?
And tolking about GPU they spend a lot of energy resource?

Merged mined alongside bitcoin. So nice efficient ASICs soon hopefully plus many coins all benefit from the same electricity powering the miner.

-MarkM-
2718  Bitcoin / Development & Technical Discussion / Re: RNG using Block informations on: September 09, 2013, 01:18:30 AM
That gets you a completely random number, as long as at least one of the server and the player wants it to be random.

A protocol that allows non random results if both parties want it to would be awesome for money-laundering and bribes!

You could head off to the casino to collect your pre-determined paycheque, and by sheer luck, you win, that exact amount, and no one can prove it wasn't sheer luck!

Your protocol that I don't think quite provides that though. I wonder what protocol would...

Or wait, maybe yours does provide that! I figure its more useful/interesting to raise the question than to bother thinking whether yours does until after I post, so others can experience the joy of thinking too...

Though maybe the real answer is so obvious it doesn't really require any thought.

(Oh yeah? Then how come a few setences ago, back when "I don't think", I didn't necessarily type the right answer? Hmm. Maybe "I do think" would be a more useful general approach to problem-solving.)

I can guess now that legislators will prefer the "seeds to use file made in advance" to "invent a new seed on a per play/player basis on the spot" if only to make launderers have to keep very tight appointments to be sure they were in fact hitting the site precisely at the right point in the sequence of seed-use to get their payseed honoured.

-MarkM-
2719  Alternate cryptocurrencies / Altcoin Discussion / Re: Anyone having issues with P2Pool and Litecoin right now? on: September 08, 2013, 08:53:00 PM
Maybe wait and see, how recent do they mean by recent?

Seems you are saying you recently restarted it and lo and behold it has the same error despite being updated code...

I use p2pool for litecoin and for merged mining, I have seen that message before but am not seeing it right now. I think I git pulled within last few days. (I tend to from time to time anyway.)

-MarkM-
2720  Bitcoin / Development & Technical Discussion / Re: RNG using Block informations on: September 08, 2013, 11:13:56 AM
As soon as the current txs are confirmed (1), I need a provably fair 0-9 RNG.

Okay so tell the user the hash of the seed that you do know, ask them for a random seed they provide themselves (for example, the transaction number of the transaction in which they sent you some bitcoins), wait for the block to confirm, then whether they win or not tell them the actual seed you used, the one you previously told them the hash of.

Notice that even if they lose, they still need to know what seed you had chosen, the one you had told them the hash of, if they want proof of fairness.

If you don't want to publish the proof (the seed you chose) on a diceroll by diceroll basis you can use aggregates such as having each day's seeds-to-use already in files ready to use (more than enough for each day, way more in case you get unexpected amount of traffic) and after the day is over move that day's file to a place where the public can see it, and publish there too the bet by bet / diceroll by diceroll log of all the dicerolls so the public can match up first roll of the day to first seed you had scheduled for use that day, second roll to second seed etc.

Log to public could maybe publish live realtime what the hash of your seed is, what seed a user provided, and, when the block is confirmed, what the dice actually came up as. Then once the day is over, publish the actual file of seeds and enhance the day's log by appending each seed that was actually used to the log entry of the play it was used by.

If you want to spam losing bets to the blockchain you could encode the seed you used into the "you lost" spam as well as coding it into the "you won" payments so the player can see it is fair as soon as they know whether they won or lost.

-MarkM-
Pages: « 1 ... 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 [136] 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 ... 384 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!