what, all exchanges are down  Seems unlikely. I recently made some changes to the filenames I use to make it more friendly for sharing (which I hope to get around to soon). Seems likely there's some kind of bug in there since this happened at 12am (Though that was 12 central and ChartBuddy operates on UTC). Edit: Oh, I think I may have an idea. Though that would have made it happen more than once... Edit2: I see what happened. Now to work out how to extricate myself. |
|
|
|
Instead, I listened to others again.
Yeah, that can be a costly lesson. |
|
|
|
I hadn't thought of asking my friends to pay for the meal then pay them in bitcoins. I usually have enough cash from localbitcoins for that.
That's not really living on bitcoins though. It's not really different from what you're doing with localbitcoins and may piss friends off. |
|
|
|
Another possibility, with a little creativity (and reasonable planning) there could be an attempt to maintain the approximate same level of investment into BTC versus fiat within about 5% and then buy BTC on the way down and sell on the way up, which if played properly and systematically (maybe a big "if"?) would likely increase BTC and fiat holdings over time and make the overall
portfolio a bit less risky.
This is what I would be thinking. Aim for 60% in BTC and diversify the other 40 into other things. Though it's difficult to know what these days. If Bitcoin rises a lot, however, might want to consider letting that sit somewhere above 60% though. |
|
|
|
$ bitcoin-cli getmempoolinfo { "size" : 3929, "bytes" : 38421374 } *shrug*. Perhaps they have more restrictive relaying rules. |
|
|
|
... it all depends on what mempool you are looking at, each one is shaped by the individual node's user-selectable relay policies.
True. But the indication is that there are plenty of transactions out there if miners cared to include them. Interesting to see that a patch to expire transactions was added back in October. I didn't realize they never expired otherwise. |
|
|
|
Chartbuddy widget progressing along nicely. Thanks Richy_T
It's kind-of interesting that there are so many transactions in the mempool but blocks are far from full. I'm not sure but I think that may mean that most miners are already being selective about what they include in a block which might indicate that worries about increasing the block size limit are largely unfounded. |
|
|
|
Dat's a lot of blocks.  In case anyone is wondering about the new bits, white squares are blocks, red squares are blocks >990000 bytes, black empty squares are 1-transaction blocks. The green goo now represents average fullness not including 1 transaction blocks, the red line is inclusive of 1 transaction blocks. |
|
|
|
It is me or the images from the ChartBuddy are not appearing?
Blame it on the *unlimited* sized image. Disk is filling up with book data. I moved a bunch off. I need to zip it up really. I have 240G worth not including the stuff I already archived off. |
|
|
|
"Oh my Satooooshiii!!! We're Bearning!!!!"
#feelthebearn |
|
|
|
Sorry I was too terse. I was agreeing with you. I previously supported them, too. And for the same reason. But would you do it now is the question of the hour.
I was always skeptical. I was willing to give them the benefit of the doubt though (but not my money) |
|
|
|
Typical. I walk away from the forum for an hour and it all goes to shit. |
|
|
|
It looks like rebuilder answered it already. You create an encrypted volume with VeraCrypt (or something else, do your own research as taking suggestions blindly from this forum is a bad idea), then upload that to a host (or 3) of your choosing. The data would be worthless to anyone that isn't able to decrypt it. The problem with that is that you'll be paying for unused space on the veracrypt partition as well. |
|
|
|
|
You might want to look at Amazon Glacier. In exchange for that it might take a while for you to get your data back, prices are very cheap. $0.007 per GB (I think that's per month)
Always go for local encryption if you value your security too. There's been reports of some file stores not being as secure as you'd think.
|
|
|
|
Lots of "deleted" there. Brief summary? |
|
|
|
what does this mean? i never understood it BTH is the number of blocks until the next halving (in July). The cube and the percentage of fullness is the amount of blockspace used in the past hour without taking any empty blocks into account. We're still doing the empty blocks. I haven't got around to changing it yet. |
|
|
|
Small blockers are so edgy and cool. I bet they smoke behind the bike sheds at lunchtime too. |
|
|
|
I think you are wrong but don't have time or inclination to go into the gory details of mining strategies and the reasons for empty blocks arising ... basically if the fee levels are "profitable enough", i.e. near to the level of reward/1MByte, then the miner who found the most recent block will most likely not mine an empty block, if there are such TX still queued in the mempool (this miner has all the information needed to build a valid block from mempool and is the one most likely to be mining empty blocks right now).
Absolutely. But other miners cannot start mining new blocks with transactions until they have the new block and know which transactions in their mempool are no longer supposed to be there. In the meantime, there is a bunch of hashpower going to waste so they just throw in an empty block which will be valid since it will only contain the coinbase transaction since that is the only transaction that they know will be valid (though they could also generate other transactions that they would know to be valid so detecting this can be worked around). Ideally, they'll also validate the block they have received as well. Some miners have not in the recent past which has meant they have mined on invalid blocks (which made their block invalid also). http://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-waThat was f2pool there too... |
|
|
|
It seems that you are attempting to tweak to make it more accurate, but in the end, your tweaking may cause it to be a little bit less accurate.
As is often the case, it's less about the answer than "What question do I want to ask". The question I want to ask is how much of the available block space is being utilized. Since empty blocks are blocks which be definition cannot be utilized... Now, if we were only having a few transactions per hour and empty blocks were being mined because there were simply no transactions to mine, that would be a totally different question. Aside to fatman: I'm not sure that mempool size will be a totally useful number since mine will be different from everybody else and there's no telling where we will be between blocks. It might be worth having as a rough indicator though. |
|
|
|
Stupid question: Why are miners including 0-fee transactions in blocks at all? AFAIK, they can refuse to do so regardless of max blocksize.
Absolutely correct. Though the default client allows for some zero fee transactions and miners may choose to keep doing so because they feel it's good for Bitcoin at this stage. Including in Blocks
This section describes how the reference implementation selects which transactions to put into new blocks, with default settings. All of the settings may be changed if a miner wants to create larger or smaller blocks containing more or fewer free transactions.
50,000 bytes in the block are set aside for the highest-priority transactions, regardless of transaction fee. Transactions are added highest-priority-first to this section of the block.
Then transactions that pay a fee of at least 0.00001 BTC/kb are added to the block, highest-fee-per-kilobyte transactions first, until the block is not more than 750,000 bytes big.
The remaining transactions remain in the miner's "memory pool", and may be included in later blocks if their priority or fee is large enough. |
|
|
|
|
Show Posts
