|
As I've said before, I agree that these stress test are nothing but destructive tendencies towards Bitcoin... I haven't been having issues with payments (did one yesterday for goods that got shipped straight away), but many services and nodes are simply crashing... Good luck on getting CryptoGraffiti up again, it's a pretty interesting service.
|
|
|
|
Bump.
Definitely a relevant one as it connects to the Mt Gox story... Many people learned what the OP is saying the hard way. |
|
|
|
|
Survey done, good luck on your work!
|
|
|
|
Can you post more of the log? The little bit you gave doesn't help us at all.
It's a bit big, so I'm having issues posting it here. Here's a direct link. Do you want me to post a hash of the file and a virus scan? EDIT: went ahead and did itThat is a large log file. There doesn't seem to be anything wrong with it. The only thing I can think of right now is that there are too many transactions which is causing the mempool to grow too big. Maybe try to change the settings to limit how large the mempool can get. Otherwise, the only other solution I can think of is to see if reinstalling and resyncing will help. Yeah, didn't even check, but it's probably one or two weeks long  Thanks for confirming. I also couldn't detect anything out of the ordinary, and the file just stops when the client closes, without any error messages... If the node shuts down again I'll search on how to adjust the mempool, thank you  I'll also be on the watch for a VPS deal with 8GB RAM... Thanks again for the help. |
|
|
|
Very good advice. I'm also surprised that many lenders take the risk of lending without collateral and many people requesting loans ask them without any collateral, or with the intent to scam straight away... That's one of the reasons I now rarely go to the lending section |
|
|
|
Your question has been answered a few times. As for the power involved in Bitcoin, you can check here |
|
|
|
|
He's getting what he deserves for being negligent with customers funds and having no security at all with the coins held...
Same old story: hope he doesn't misplace his soap in prison like he did with customers coins.
|
|
|
|
Can you post more of the log? The little bit you gave doesn't help us at all.
It's a bit big, so I'm having issues posting it here. Here's a direct link. Do you want me to post a hash of the file and a virus scan? EDIT: went ahead and did it |
|
|
|
Never came across this thread. Read the first two pages and I was shocked...
Pretty interesting to bump this today, as Mark was charged of embezzlement. I too wonder what would the reactions be today. I figure they'd be really different.
It's not so different today. During the brief August crash on Bitfinex down to $160 there were complaints that people's buy orders at $170 weren't filled. That's similar to Kevin's experience, although Bitfinex didn't let people have their lowball buy order coins then take them back. I'd be furious if I had $$170 buy orders on that didn't get filled. However, MtGox kept on trading afterwards, and likewise Bitfinex kept on trading afterwards. To start off my reply I'd like to say that our knowledge of Mt. Gox today is very different than what they had back then and that might influence each and every one of our posts in the forum. Both situations are a bit different as far as I can understand. Someone (hacker or not) put up a huge sell wall (of what were supposedly legit Bitcoins and not Goxcoins as later in time) that crashed the market. People had buy orders low, because you know, just in case (who doesn't have them?) and the user managed to put a low order just in time to get cheap coins. Why not? Trades were rolled back under the reasoning that it was a hacker who did it... But people had already bought the coins. I know that coins on exchanges aren't really ours, but people had legitimately put buy orders and bought the coins at the price they wanted. It's not the buyers and sellers fault that their systems were not secure enough, as we've been having proof of in the last few weeks, and it isn't the fault of the people who bought the coins that other users (might have) had weak passwords. As for Bitfinex's case, the orders weren't even filled to begin with, which was different (although also the exchange's fault: the system didn't correspond to what customers were expecting). I know it's hard to ask for these services to be 100% able to correspond to users demands... But we can't (yet) resort solely to face-to-face trading and we need online trading systems that are stable and correspond to the user's desires, and don't simply rollback trades on bad reasoning. The only legit rollback I recall (at least in near past) was that one where there was a 0.8 fork, and even that one might be questionable by some. That was an honest and serious bug related to incompatibility and was fixed quickly without a big harm to end users, as far as I recall. |
|
|
|
Just wanted to give some feedback for this last update. The notification center widget is just amazing! Pretty handy and works perfectly, thank you.
+1 ... Widget is really awesome! BTW: How is lock-screen notification suppose to look like? I only get badge number on top of breadwallet icon even though "Show on Lock Screen" is turned on. I never get any breadwallet message on lock screen. Can someone make a screenshot? Any idea what am i missing? Sorry for the late response. For now the app only shows a badge icon. If we show the amount of a transaction in a notification, that would be a privacy concern. I suppose we could have the option to display tx amounts in notifications but keep it off by default. It would be interesting if the app could see if iOS has "Private Notification" settings activated, and warn the user according to that, but I'm not sure if iOS tools and API's allow that. An option like the one you referred is simple and effective... "Show transaction amount on notification?". I'd definitely choose Yes. My phone is always with me, and I can simply see the notification privately on my Apple Watch and dismiss it, knowing the amount that entered on the wallet. Also, breadwallet has been throttling fees very nicely during this "stress test" Had to pay for some goods during the day and the transaction confirmed on the next block, with 123 bits fee (3 cents) |
|
|
|
The answer would be no, as online gambling isn't legal everywhere... Also, you'd probably get more luck posting in the Gambling section. |
|
|
|
|
Never came across this thread. Read the first two pages and I was shocked...
Pretty interesting to bump this today, as Mark was charged of embezzlement. I too wonder what would the reactions be today. I figure they'd be really different.
|
|
|
|
Well all is in our handy, no? People just need to turn off the greed and stop trying collecting those free coins! I haven't even tried or thought about trying. Why would I be pulling out the chair on which I sit on, I don't get it.
People just give it up and stop trying!!!
Either that or just try to spend all the funds on fees once and for all... Meanwhile, there are not even full blocks mined.
The usual  |
|
|
|
|
Has anyone tried dust-b-gone on these addresses?
|
|
|
|
I've set up a node recently (and have been improving it gradually, from time to time). But in the last few weeks, the node has been crashing on a 1 week interval, more or less... I've been seeing debug logs for the last two or three crashes and I haven't been seeing anything unusual. I'm running the node on a VM with 4GB RAM + 4GB vSWAP. I've tried raising/changing swap size, but it seems it's impossible with the host I'm using. I thought this would be enough to run a node, but apparently it is not, or the problem isn't RAM/SWAP, or I'm missing something. I've been seeing a temporary cover up solution to this, but I've been unsuccessful thus far trying to find something that monitors if the node is running or not and restarts it with the correct parameters... Here's a bit of the last crash debug: 2015-09-10 15:04:01 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:04:47 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:04:53 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:04:57 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=*****************, peerid=13394
2015-09-10 15:04:58 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:05:07 UpdateTip: new best=000000000000000004467163bbb85f7a043f7ec3ea641c429efb6668c569574d height=373885 log2_work=83.327898 tx=83074047 date=2015-09-10 15:03:44 progress=0.999999 cache=0.5MiB(0tx)
2015-09-10 15:05:12 ERROR: AcceptToMemoryPool: nonstandard transaction: dust
2015-09-10 15:05:15 receive version message: /getaddr.bitnodes.io:0.1/: version 70002, blocks=373884, us=*************, peerid=13395
2015-09-10 15:05:42 receive version message: /Snoopy:0.1/: version 60001, blocks=0, us=*************, peerid=13396
2015-09-10 15:06:02 ping timeout: 1200.013952s
2015-09-10 15:07:01 socket send error Connection timed out (110)
2015-09-10 15:07:18 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=***************, peerid=13397
2015-09-10 15:07:29 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=***************, peerid=13398
2015-09-10 15:07:33 receive version message: /Satoshi:0.9.3/: version 70002, blocks=373885, us=*******************, peerid=13399
Any clues? Anything bad on the Debug.log? I can provide more of the file if needed. |
|
|
|
Bitcoin user not affected because this has nothing to do with Bitcoin, even if you pay your fees in Bitcoin As for node running... It might impact you if you do heavy usage and you node is well connected. As for the plans themselves... We all knows that unlimited plans aren't unlimited for the most part. This is just an operator taking an extra advantage of limited "unlimited" plans... |
|
|
|
|
Unless something changed in the last few days, Slush is not running a XT pool. I wonder how much this list is trustworthy.
|
|
|
|
Very interesting! Thanks for the link. I also noticed this in the doc: For now, block pruning disables block relay. In the future, nodes with block pruning will at a minimum relay “new” blocks, meaning blocks that extend their active chain.
So it's good to know that in the future pruning nodes can still help to strengthen the network by distributing new blocks, and very interesting that for the moment, I guess running pruning mode is just leeching. I wouldn't say exactly leeching, but it's certainly not really useful at the moment. I have high hopes for the pruning functionality though |
|
|
|
|
I only have one thing to say about this: very good news.
|
|
|
|
|
Show Posts
