In theory, existing users should be able to invite new users.
But yeah, I mailed dwdollar about a week ago, without a response.
I would love to have an invite, is there someone that can invite me? Otherwise is there an alternative to sell bitcoins for paypal? |
|
|
|
|
So what's the current situation? It's been a while since the last update and when trying to get a tester account I never get an answer. I would love to see the market be opened to the public again.
|
|
|
|
Actually there are currently 3 things called Bitcoin: - Bitcoin the client
- Bitcoin the currency unit
- Bitcoin the communication protocol
The article needs a clear distinction  |
|
|
|
|
Great job, I love XKCD :-)
|
|
|
|
I opensource BitDroid-Network, but once [mike]'s implementation hit there wasn't much interest in it so I stopped developing it. One of the main advantages is that I do in fact allow multiple connections and splitting the requests over multiple connections is a simple matter of implementing an actionlistener. Did I mention it uses non-blocking IO which allows for several hundred connections on a computer or dozens on an android phone? |
|
|
|
|
That's the main idea, but the addresses may have been used for change too. It's worth a try.
If you already had that address before the crash you'll definitely get your coins back, I myself used a deleted block chain several times, and I always got my coins ^^
Let us know what happens.
|
|
|
|
Sounds like the cards overheated, the driver tried a GPU restart, and failed.... which GPU restarts on Linux ALWAYS fail, and theres no way to shut it off. Just leave your GPU fans at full speed.
Just improved my ventilation, got it 15 degrees colder (from ~83C to ~70C) will check back if anything changes. |
|
|
|
I had two complete lock ups of my system (probably due to me using aticonfig to adjust the fan speeds in a cronjob) at 30 hours between each other (100'000 seconds ~= 30 hours). I was wondering whether this is a known bug or one of my cards is dying on me: [109453.772] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[109453.905]
Backtrace:
[109454.293] 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80ef31b]
[109454.293] 1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80ecb5b]
[109454.293] 2: /usr/bin/X (xf86PostMotionEventP+0xd2) [0x80bd662]
[109454.330] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x684000+0x4961) [0x688961]
[109454.330] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x684000+0x4a56) [0x688a56]
[109454.330] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0x684000+0x5296) [0x689296]
[109454.330] 6: /usr/bin/X (0x8048000+0x62e7f) [0x80aae7f]
[109454.330] 7: /usr/bin/X (0x8048000+0x121b4e) [0x8169b4e]
[109454.330] 8: (vdso) (__kernel_sigreturn+0x0) [0xdaa400]
[109454.365] 9: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (ulReadMmRegisterUlong+0xd7) [0x12f90b7]
[109454.368] 10: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x351733) [0x12da733]
[109454.368] 11: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x351691) [0x12da691]
[109454.368] 12: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x35163a) [0x12da63a]
[109454.368] 13: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (MCIL_WaitFor+0x99) [0x12b4a29]
[109454.368] 14: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (Cail_MCILWaitFor+0xc8) [0x12da4f8]
[109454.368] 15: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (Cail_WaitForMCIdle_Internal+0x77) [0x12ccd37]
[109454.368] 16: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (CAIL_WaitForMCIdle+0x3e) [0x12c50ee]
[109454.368] 17: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (swlCailWaitForMCIdle+0x1f) [0x12ab25f]
[109454.369] 18: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (MCIL_WaitForMCIdle+0x22) [0x12b4b52]
[109454.369] 19: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (swlPPLibCwddepm+0x67) [0x12bb787]
[109454.369] 20: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x2f3cbb) [0x127ccbb]
[109454.369] 21: /usr/lib/xorg/extra-modules/modules/drivers/fglrx_drv.so (0xf89000+0x2f151c) [0x127a51c]
[109454.369] 22: /usr/bin/X (0x8048000+0x26ee7) [0x806eee7]
[109454.369] 23: /usr/bin/X (0x8048000+0x1a5da) [0x80625da]
[109454.369] 24: /lib/libc.so.6 (__libc_start_main+0xe7) [0x28ace7]
[109454.369] 25: /usr/bin/X (0x8048000+0x1a1b1) [0x80621b1] |
|
|
|
Also gegen Zurich fuer das naechste Meeting haett ich nichts, bin momentan etwas Ortsgebunden |
|
|
|
I prefer Munin as it works more out of the box, but I'll give it a try |
|
|
|
I'll integrate Disqus. How easy is it to do?
Otherwise I can just slap on comments (it's not hard to do).
If it's as easy as IntenseDebate's API it is just a matter of putting a JavaScript where you want the comments. |
|
|
|
I don't think these "Satoshi is the reincarnation of Jesus" rumors will ever end, unless Satoshi comes forward. But I find them quite amusing |
|
|
|
Small update today. I added JSON API for profile page and token mechanism to authenticate against it without need of login/password in your scripts. I see that many of you are downloading profile page and parse it periodically. This API is now preferred way to check your account balance. For API interface instructions, follow the link on top of your profile page. This is great, I was one of the guys scraping the page (5 minutes, I figured what's the harm), but this makes it so much easier. For those of you using Munin, now you can monitor the pools like I do: #!/bin/bash
case $1 in
config)
echo "graph_title Pool reward"
echo "graph_vlabel BTC"
echo "confirmed_reward.label Confirmed Reward"
echo "total_reward.label Total Reward"
echo "graph_category Bitcoin"
exit 0;;
esac
CURL_OPTS="-b /tmp/cookies.txt -c /tmp/cookies.txt -L -s --max-time 3 -k"
URL="https://mining.bitcoin.cz/accounts/profile/json/YOUR_TOKEN_HERE"
PROFILE=`curl $CURL_OPTS $URL`
CONFIRMED=`echo $PROFILE | grep -E '"confirmed_reward": "[0-9\.]+"' -o | awk '{print $2}' | sed 's/"//g'`
UNCONFIRMED=`echo $PROFILE | grep -E '"unconfirmed_reward": "[0-9\.]+"' -o | awk '{print $2}' | sed 's/"//g'`
TOTAL=`echo "scale=8; $CONFIRMED + $UNCONFIRMED" | bc`
echo total_reward.value $TOTAL
echo confirmed_reward.value $CONFIRMED Just add your token and drop it into /etc/munin/plugins/ ^^ The graphs look like this:  |
|
|
|
actually I think thats why satoshi wanted competing block chains . maybe they should be decentralized too as creating one central block chain could be vulnerable....
Having many smaller chains actually weakens both the bitcoin economy (many incompatible flavours of Bitcoin) and the network as an attacker could just go through them and destabilize each one after another using less computing power than he'd need for a single big one. |
|
|
|
...theoretically if this happens, could it happen again after the difficulty reset? What would stop it from happening again and again... Good eye. My thoughts exactly. The attacker could easily sit quiet for a few years while we struggled to solve the problem. (Literally). Or if we ever did manage to convince the entire world to accept our new difficulty rate... the attacker could spring again in an instant. (I'm sure they'd be watching...) Eventually, the general public would become tired of this "nonsense". And bitcoin would die. Well as long as the super computer stays it's all ok because the protocol still works and transactions can be processed, the scenario where he leaves is unlikely because he has an incentive to stay (Bitcoin generation). Beowulf? Why couldn't Bitcoin have started earlier, I had access to the ETH Zurich/EPFL Beowulf cluster, damn |
|
|
|
|
Well, yes, but this is a catastrophic scenario where it would be easy to get all developers of all clients to agree on resetting the difficulty to the last known good value. As long as we can get 50%+ to use a client we can do whatever we want with Bitcoin ^^
|
|
|
|
I think the best way to make progress with this issue would be for somebody to look at the impact of using much faster block generation times. 10 minutes was chosen on the assumption of really large networks, really large blocks and thus potentially large propagation times. It's a tradeoff between convenience and avoiding wastage of mining effort. But 10 minutes for block propagation is pretty huge. BGP updates propagate across the whole internet in less than one minute, as far as I can tell. And BitCoin is nowhere near large enough to see 10 minute propagation times today. It'd probably be possible to have one minute confirmations on todays network. The questions to ask are: - Is 1 minute really better than 10? I think suspect there's really only two speeds that matter, "<5 seconds" and ">5 seconds".
- Can floating transactions be made low-risk enough that it doesn't matter if they aren't included in a block right away?
I think we can actually have a tradeoff between fast confirmations and network size. Right now every single node gets all transactions, but what if we segment the network? The network would be segmented into a hypercube with variable degree. Each vertex is a cluster of nodes (mini-networks) which gets assigned there by hashing their IP (forcing nodes into a specific position of the overall network) and they'd take care of small amounts of outgoing addresses (to mark spent inputs), achieving consensus with a much faster block chain construction (micro-tick if you will). The miners still compute the usual proof of work, but if they find a lower difficulty block, they report it to their cluster to advance the local block chain. If a miner finds a global block it starts collecting transactions from all other vertices and announces the block. I proposed this first way back while arguing that it would allow the network to scale better, but the micro-ticks look a lot like the block creation speedup you guys are looking for |
|
|
|
Yes the blockchain handling in BitCoinJ needs a lot of work. It's not just storage. It's handling of chain splits (reorgs). I'm working on reorgs first before storage because the chance of encountering a reorg gets much higher when you're keeping a permanent record of the chain.
I'm surprised an Android client came out so fast, but it's great to see anyway, even if it's still early days. If people could work together on it that'd be even better. I was looking into the chain storage and as far as I see it you'd just need a few recent blocks to track transactions you're interested in. I'd keep them in a stubbed "quarantine" chain as long as I'm not satisfied that they were confirmed, and then stub them off at ~10 confirmations, and just store the potential inputs for transactions I'm going to send. It's just that right now I'm swamped with 2 theses, and I wont be able to actually implement it for some time... |
|
|
|
Little Endian is a pain, and I've said it often enough. Then the protocol version should evolve independently of the client version. Consolidate some stuff, like "do we really need size fields that can have a length of UINT64?". It's just a cheap trick to optimize the length of the messages, but each message has a fixed header field for the command that is never used fully, why start hacking exceptions in? And then finally comes my argument for structuring the network topology, in order to scale better and detect partitions (think dynamic degree hypercube). Edit: nearly forgot my old capabilities proposal: http://bitcointalk.org/index.php?topic=894.0 |
|
|
|
|
Show Posts
