In CoffeeMUD, it turns out that cooked food does not spoil, so characters who hunt, even just kill critters for the experience, basically BBQ the meat to turn it into a lasting resource. This not only stops them from getting sick eating rotten meat themselves, or having to waste meat by just throwing it away when it smells bad and hunting fresh meat again. So maybe this coin would be just the right coin for such players to favour.  Maybe even set a standard price list, so many for snake steak, so many for dragon steak and so on, depending on how regular a market they can make for their steaks... -MarkM- |
|
|
|
|
I recently read (yesterday, in this or related thread) that 7 transzctions per second is calculated from the artificial, soft, canary in the coalmine limit Gavin recently put in, of quarter of a meg. So actual limit, accordingly, would be 28 transactions per second.
I do not know where the blog linked to in the original post got the 40 transactions per second figure that it was saying is current limit back when I read the blog.
Also look at all the demurrage literature. Deliberately devaluing-constantly currency because that speeds up actual commerce.
It seems maybe ideal would be a gold-like currency for storing value, and a cheap, maybe constantly going down in value currency to spend. Each day or week or whatever you borrow the cheap stuff using the good stuff as collateral, getting a good interest rate since its hold wants to get rid of it fast before it loses value, and you never move your good stuff from the vaults where it sits, acting (unmoving) as collateral...
-MarkM-
|
|
|
|
|
Still, the number of hops (nodes) a block has to be checked by in order for the network to be flooded / saturated with that block is linear to the average radius of the net, in hops, from the node that solves the block, isn't it?
-MarkM-
|
|
|
|
|
Multiplying by two every time we halve the block subsidy would be pretty bulletproof, as we'd have four years to prepare for each upcoming change.
We'd also have four years to figure out whether that was far too optimistic (increasing too fast) and would have to be slowed down.
So I think merely just a fixed constant is not likely at all.
The main thing might be sheer predictability, so people can do their five year, ten year, and twenty-year plans, or something like that.
Thing is, people don't think that specific rate I cited above would be fast enough.
They hope for exponential uptake, but are not even doing tests like, say picking one branch/city store in which to do a market study, seeing how much that affects the system so as to judge how many more of their branches to expand the test into, coming back when the current limit is full to say hey we brought in all the traffic that is making blocks nicely full now, that was only 1% of our branches world wide, so we now know to start accepting bitcoins at the rest of our branches will cause X amount more traffic on your blockchain, how soon will you be ready for me to bring that new traffic?
We have not seen anything like that, just wild fantasies about the future by people who seem not to even have enough customer base to bring in to even fill the blocks we already have.
-MarkM-
|
|
|
|
|
I dunno then.
Maybe diff the source code against the source code you used before?
-MarkM-
|
|
|
|
|
Do VMs automagically get access to all port numbers?
Or is it trying to warn you that the VM doesn't "really" have such a port at all?
Also do VMs start with firewall activated?
-MarkM-
|
|
|
|
|
When you stop trusting Pirate his IOUs you hold are not automagically traded away. You need to trade them away yourself by looking for offers, or over time as others happen to Ripple through you, assuming anyone actually does Ripple through you, they should gradually get exchanged away / used.
-MarkM-
|
|
|
|
|
Weird, is that the same error it gives if something is already using the port?
Because some coins take a while to die when you tell them to stop, and some just don't die from being told to stop (or take so frakkin long one thinks they aren't going to anyway) so have to be killed with kill command.
Does ps or top show the previous copy still running?
-MarkM-
|
|
|
|
|
Well I think "we" are "doing is ASAP" in the sense that until "we" have figured out exactly what hard-forking changes will be bundled together into the next hard-fork no hard-fork should be attempted.
Who the "we" is might be part of what is being discussed, of course.
-MarkM-
|
|
|
|
It is good to get it down pat, I was worried I really had messed up before, now I think the one I put before was fine too. This means we can trade IOUs on RIpple until some day when we want final settlement, on that day we settle on the blockchain, wait ten blocks or so to make sure our settlement is not orphaned, then can update checkpoint so we know our final settlement is really and truly final. -MarkM- |
|
|
|
|
Yes but look at the checkpoints.cpp for actual bitcoin for example. You will see the proof of work hash is what goes into the checkpoint, thus there are more and more zeros at the left as time goes on in the checkpoints list.
-MarkM-
|
|
|
|
There must be more than one chain maybe, and I am on one, you on the other? I wanted to try to figure out what had gone wrong before, so I scrolled back in my debug.log to see if I had managed to find a block (on some chains I often do not find a block in the timespan between cleaning away all the debug.log files of the various blockchains so wasn't even sure I would find what I was looking for at all). I found this in my debug.log: BitcoinMiner:
proof-of-work found
hash: 000000055630929f820ae426788290a5c0235c1f6d7d2d6675865ad757d342c2
target: 0000005441cf0000000000000000000000000000000000000000000000000000
CBlock(hash=6d7493ffc82a9553cf20, PoW=000000055630929f820a, ver=1, hashPrevBlock=09846e10a0b699bc95ea, hashMerkleRoot=9fbb3e71cf, nTime=1361624074, nBits=1d5441cf, nNonce=2147484914, vtx=1)
CTransaction(hash=9fbb3e71cf, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, -1), coinbase 040abc28510175062f503253482f)
CTxOut(nValue=42.00000000, scriptPubKey=03f08a64e5b6b78eb63d94081aca98)
vMerkleTree: 9fbb3e71cf
generated 42.00
keypool keep 262248
AddToWallet 9fbb3e71cf new
SetBestChain: new best=6d7493ffc82a9553cf20 height=303403 work=918117143380
ProcessBlock: ACCEPTED
That is what I grabbed the numbers from tohave another try at making a checkpoint. Maybe I am simply getting so many orphans that both times I tried to find a hash of a block in my debug.log I happened to be finding an orphan? -MarkM- EDIT: Whoa! getblockhash!! I never even knew there was such a command! All these years I have always gone scrolling through debug.log to find a block to get its height and hash! EDIT2: No! getblockhash is returning a different hash than the one that is used for proof of work; the hash used in the checkpoints is the work proof hash, that is why you see they have more and more zeroes at the left as difficulty goes up. |
|
|
|
|
I'll sell 2 pizzas for only 8000 bitcoins!
-MarkM-
|
|
|
|
|
You want to arbitrarily make a not-yet-needed change that could break the network just so you will feel confident that it is politically easy to make not-needed changes???
-MarkM-
|
|
|
|
Just wondering how this ripple will help BBQcoin and protect it?
Hmm I don't know that it would protect BBQcoin. It would let us trade off the chain though, using IOUs, until some day when the chain is secure enough by enough hashing that people feel confident transactions they do on the chain will not be reversed by a 51% attack. Mostly it just seemed a convenient coin to use for playing with Ripple and testing the IOUs-to-blockchains code. -MarkM- |
|
|
|
|
We can use them "by proxy" as it were in Ripple.
Basically if you trust my claim that I have mined some blocks of the coin way long time ago, long enough ago that there is more then one hard-coded checkpoint in the code now, so that even a 51%-plus attacker cannot undo those coins, you could consider trusting me for some number of IOUs, denominated in what I guess I will be listing as BBQ not as BQC since I think ordinary folk are far more likely to figure out at a glance the name of the coin if they see BBQ than they are likely to "intuitively know" what "BQC" stands for.
If you have told Ripple you trust me for X number of BBQ IOUs, presto I will be able to send you up to that many such IOUs, and presto BBQ will be useable in Ripple by proxy of these IOUs.
Once I get hold of source code for the Ripple server, I plan to get a Ripple server running so I can flag a Ripple account as the type of account used by Ripple gateways, which will let me start trying to get their example web-based app for transfers between blockchains and IOUs adapted to work with the BBQ blockchain; until then there is no automated way to turn the IOUs back into actual coins on the blockchain.
We'd be playing with our fun coin in Ripple as a fun way to check out Ripple, basically.
I also would prefer not to actually dig out those virgin coins because once moved there would be no hardcoded checkpoints protecting them. So I would not be redeeming IOUs with ancient coins, unless of course I had no more-recently-moved coins to redeem them with.
Thus I will be operating at at least 100% reserve and usually more than 100% reserve.
-MarkM-
|
|
|
|
|
Unfortunately in some jurisdictions debt is a magic word, so that you always have to accept fiat instead of whatever is actually owed, or something like that?
So if you held, say five million bitcoin-IOUs, someone could, on some day when bitcoins happen to hit a dip in value on some exchange some jurisdiction uses to decide how much of their fiat bitcoins are "worth", send you fiat of that jurisdiction to cancel the five million bitcoin "debt".
Good luck buying five million bitcoins with that fiat...
-MarkM-
|
|
|
|
|
Yet there do seem to be people who have a vested interest of some kind in increasing the maximum block size beyond what current nodes are comfortable with yet are seemingly also not willing or able to even come up with enough paying transactions per day to demonstrate a real need* and simultaneously demonstrate the network can even handle the current maximum.
* Some economist wrote that demand and want, or demand and desire, are totally different creatures. Want and desire are subjective, demand is objective, it is quantifiable, it is an actual number of units of some unit of account, actual dollars and cents or actual bitcoins, that kind of thing. Would it be reasonable to suggest that "need" should be measurable, like "demand", rather than being just some lobby group or chatty geek in Botswana's wish or desire or dream or hope type of thing?
-MarkM-
|
|
|
|
|
Presumably Terracoin probably has a one-megabyte max block size, like Bitcoin?
Litecoin too has more blocks per span of time, and probably also has one-megabyte max block size.
The fact that there has not yet been a mass exodus of capital to such chains seems to indicate that unproven, theoretical ability to handle more transactions per span of time, even along with faster confirmation times, is not a big enough deal to even be worth speculating serious amounts of capital on.
-MarkM-
|
|
|
|
|
Show Posts
