1. I am not advocating buying at the top of the rally, I am advocating buying right now. When it goes past $500, you are probably too late.
2. $10 million is nothing to hedge funds, retirement funds, etc. There will be be buying pressure right after the auction and long after.
3. People are going to be sick that they missed out on buying bitcoin at these prices. My advice is to buy what you can afford or forever regret. You are lucky to even know what it is at this point.
Well, the price being 252$, it means that everybody who who owns bitcoin thinks that they are worth more than 245$; but, on the other hand, everybody in the world who has some money to spare thinks that 1 BTC is not worth 255$. The latter think that the changes of it being worth more than 1300$ anytime in the next few years are much less than 20%. You're forgetting the large group of people who do not think about Bitcoin price at all. Like the folks on r/bitcoin who scream "to the moon" during pumps but argue that "price doesn't matter" during dumps? No, the people that are just not interested enough to care about Bitcoin at this point. |
|
|
|
1. I am not advocating buying at the top of the rally, I am advocating buying right now. When it goes past $500, you are probably too late.
2. $10 million is nothing to hedge funds, retirement funds, etc. There will be be buying pressure right after the auction and long after.
3. People are going to be sick that they missed out on buying bitcoin at these prices. My advice is to buy what you can afford or forever regret. You are lucky to even know what it is at this point.
Well, the price being 252$, it means that everybody who who owns bitcoin thinks that they are worth more than 245$; but, on the other hand, everybody in the world who has some money to spare thinks that 1 BTC is not worth 255$. The latter think that the changes of it being worth more than 1300$ anytime in the next few years are much less than 20%. You're forgetting the large group of people who do not think about Bitcoin price at all. |
|
|
|
not sure how easy it would be to use as drop-in replacement. But when we need to hard-fork anyway to burn the premine, it could maybe be done in one swoop. Or go merge-mining? Thoughts?
Good grief. KGW was to fix one problem and just opens up another. I say we merge-mine with BTC and be done with this issue. We don't know an attack on our KGW is actually happening. And if it is, it might be mitigated with a higher hashrate? Does anybody have the means to record take an aur node and record the local system time of block arrivals? This would probably give us a good idea as to wether we're being attacked or if we have some other problem. Hmm, actually I just had an idea of how to do this in a hackish, but probably effective way...I tried this, but when I started analyzing the data I noticed I screwed up the marking of block with arrival time and had to reset the data collection process. I was accidentally marking the blocks in 0:30 second intervals, which is not fine enough for this purpose. I had set arrival time marking to a 1 second interval but forgot that the bitcoin-abe block insertion process interval was 30 seconds ;(. While doing that I determined the orphan rate to be ~1% recently (last 10000 blocks). I'm not sure if the way I do this is reliable, though. I think that's an indication against an attack. I'm assuming a timewarp attack would generate quite a few orphans. |
|
|
|
a) I think that the only random event is creating "master seed".
b) Then there is not more random events and everything is deterministic. (or can be done using SHA-256)
=> I hope (I do not use it) you can import any "master seed" into trezor.
that is all correct. If you're paranoid, you can use dice to determine the seed and restore it to your trezor. Make sure you check for hidden cameras (don't forget laptops, smartphones, tablets, the fridge, microwave, toaster and smoke detectors) and pull down the shades ;-) |
|
|
|
molecular, what is the source of randomness inside the Trezor?
Done more digging and asked satoshilabs for hints. Relevant info is on page 533 of http://www.st.com/web/en/resource/technical/document/reference_manual/CD00225773.pdfThe RNG processor is a random number generator, based on a continuous analog noise, that provides a random 32-bit value to the host when read.
and more specifically: The random number generator implements an analog circuit. This circuit generates seeds
that feed a linear feedback shift register (RNG_LFSR) in order to produce 32-bit random
numbers.
The analog circuit is made of several ring oscillators whose outputs are XORed to generate
the seeds.
I'm not a physicist or electronics guy, but I'm guessing those ring oscillators and their operational output are influenced my many factors, like impurities in the matierials on the die, variance in the amount of material and probably external factors like magnetic / electric fields, temperature, maybe even gravitational or more esoteric quantum effects? If you look at the wikipedia article about ring osciallators, there's a section on jitter which attributes the variance in oscillation period to temperature only: Jitter: Period of ring oscillator vibrates in a random manner T=T+T' where T' is a random value. In high-quality circuits, the range of T' is relatively small compared to T. This variation in oscillator period is called jitter.[3] Local temperature effects cause the period of a ring oscillator to wander above and below the long-term average period:[4] When the local silicon is cold, the propagation delay is slightly shorter, causing the ring oscillator to run at a slightly higher frequency, which eventually raises the local temperature. When the local silicon is hot, the propagation delay is slightly longer, causing the ring oscillator to run at a slightly lower frequency, which eventually lowers the local temperature.
caveat regarding above bolded sentence: often 'random' just means 'unknown to the observer' or 'unpredictable with available information', but that's leading up to a philosophical discussion. EDIT: as a side-note: I quite trust the combination of the hw rng and the random source on my cpu to be sufficiently random and above all unkowable to anyone. EDIT2: you can get entropy from your trezor using python-trezor: localhost (master) ~/bitcoin/python-trezor\> ./cmdtr.py get_entropy 32
b5ad64d05241aa1cbbb8d62cdd12542749dd008a23817b71e703d6f9b905665a
that way you can at least check it's not doing this:  (courtesy xkcd)EDIT3: if you want your mind fucked, check On the security of oscillator-based random number generators |
|
|
|
reading those links and not fully understanding the code, those links don't answer my question. is the hardware drawing from a entropy source, like static electricity? or is it algorithmically generated? I don't know. I've been searching for info for the hardware RNG on the cortex m3 (used on trezor) but failed. All I could find was this: Random Number Generator (RNG) is supported by the AES API and passes the
following tests:
– diehard
– FIPS_140-1
– NIST
In general a "true hardware random number generator" indeed uses some sort of hardware entropy source. I'd be quite interested in the specifics regarding trezor myself, so if anyone can find any info, I'd be thankful for a post. |
|
|
|
I love this part: Yanis Varoufakis, Greece’s new Finance Minister, agrees that because it is deflationary, bitcoin would be bad for Greece. But he goes on to say that bitcoin is a flawed currency because it is deflationary. This misses the point. Bitcoin is not a currency for a government; it is a global currency for the people.
It's spot on. |
|
|
|
Einige Pastafaris hier im Forum  *waves noodly appendage* |
|
|
|
Everybody is saying Bitcoin is the like TCP/IP layer protocol for internet money, what if the blockchain tech. is more analogous to the firmware level (assembly, microcode, etc) and we haven't even imagined the eventual value transport routing protocol layer developments yet??
bitcoin - the transistor of money? |
|
|
|
Ps: i recently moved my blockchain files from my 128GB SSD to an HDD, and was shocked how much longer loading bitcoin-qt took. It went from being about 40-60 second loadtime to 3-4 minutes. SSD drives are the future, and will make read/write/storage of the blockchain quick and simple
But most of the blockchain is static, unused data, making it a poor candidate for SSD. And I wonder it Bitcoin is SSD friendly. Does it do a lot of read/writes or is that mostly when a block comes in? I wonder if it would make sense to have the client split the blockchain to use the appropriate device for the appropriate use case. Maybe this could be done with symlinks on *nix. Regardless I would choose SSD over HDD for any application. You simply can't go back after using them. Plus you get hardware level drive encryption.You also get hardware level drive encryption with any recent cpu (there are benchmarking tools to ease selection of the correct stream cipher (or block cipher?) that is acellerated on your cpu). Privacy-wise, I'm not sure where I'd rather have the hw encryption stuff, in the cpu or in the hd controller. example: #> cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 498372 iterations per second
PBKDF2-sha256 248242 iterations per second
PBKDF2-sha512 164250 iterations per second
PBKDF2-ripemd160 375027 iterations per second
PBKDF2-whirlpool 204161 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 562.4 MiB/s 1891.0 MiB/s
serpent-cbc 128b N/A N/A
twofish-cbc 128b N/A N/A
aes-cbc 256b 415.0 MiB/s 1453.0 MiB/s
serpent-cbc 256b N/A N/A
twofish-cbc 256b N/A N/A
aes-xts 256b 1642.0 MiB/s 1648.0 MiB/s
serpent-xts 256b N/A N/A
twofish-xts 256b N/A N/A
aes-xts 512b 1281.0 MiB/s 1284.7 MiB/s
serpent-xts 512b N/A N/A
twofish-xts 512b N/A N/A
|
|
|
|
What about the fiat credit bubble that's been going on for decades? How do you think that's gonna end?
I'm no economic expert but I heard most countries are heavily in debt. Exactly who do they owe the money to and do they just print more money if they can't pay? Whoever they borrow the money off must have a shitload of cash. Dude, debt IS money. Fiat money is CREATED when a bank issues credit . So yes, they have an infinite shitload of cash. I know it's hard to grasp, but it's well worth understanding this. |
|
|
|
What about the fiat credit bubble that's been going on for decades? How do you think that's gonna end?
nuclear winter |
|
|
|
is there any aur working faucet?
Yes. You can get 636 AUR. You must be from iceland, though. |
|
|
|
|
what's up with the chinese exchanges... no data to bitcoinwisdom (huobi, okcoin).
|
|
|
|
Die reichen Superprofis wollen an unser Geld.
this. |
|
|
|
|
ok, it's realitively good news.
|
|
|
|
We have lots of shorts once again
BTC 24,405.44 BTC
That's actually good news  |
|
|
|
not sure how easy it would be to use as drop-in replacement. But when we need to hard-fork anyway to burn the premine, it could maybe be done in one swoop. Or go merge-mining? Thoughts?
Good grief. KGW was to fix one problem and just opens up another. I say we merge-mine with BTC and be done with this issue. We don't know an attack on our KGW is actually happening. And if it is, it might be mitigated with a higher hashrate? Does anybody have the means to record take an aur node and record the local system time of block arrivals? This would probably give us a good idea as to wether we're being attacked or if we have some other problem. Hmm, actually I just had an idea of how to do this in a hackish, but probably effective way... |
|
|
|
It's always next year... ...until it's NOW. |
|
|
|
asked around on irc: <molec> hey guys. does anyone know stuff about kimoto gravity well difficulty adjustment and how an attack would look like? <kittan_> If blaksmith were around, he could probably talk about that a bit. <kittan_> I haven't looked into that sort of math, but the last time I heard the term was in conversation with him over PID diff calculations. <molec> some strange stuff going on with auroracoin chain. http://blockexplorer.auroracoin.eu/chain/AuroraCoin?count=500&hi=101266 difficulty just jumped from 96 to 545 after no block was found for 2.5 hours. <molec> I don't know what to make of this. <molec> and right before that, block were found way too quickly without the diff adjusting in a meaningful way... at least that's the story the timestamps on the block tell. <molec> s/block/blocks <Blaksmith> don't know what an attack would look like, but I know KGW has the possibilty of a time-warp exploit
<Blaksmith> where blocks are generated in the future, and then submitted back to back
<Blaksmith> reading more, yes, that sounds like someone is using the time-warp exploit
<Blaksmith> that's why most that have used KGW have moved on to Dark Gravity Wave 3 (DGW) which closes the hole on the time-warp exploit
<Blaksmith> molec, ^^ <molec> thanks a lot, blaksmith. that's valuable info. <Blaksmith> np here's info on DGW, developed by Evan Duffield: https://bitcointalk.org/index.php?topic=522235.msg5931948#msg5931948it's an adaption of KGW (used by AUR) that fixes some exploits. not sure how easy it would be to use as drop-in replacement. But when we need to hard-fork anyway to burn the premine, it could maybe be done in one swoop. Or go merge-mining? Thoughts? |
|
|
|
|
Show Posts
