Feature request: Show date/time on transactions.
The problem with this is transactions don't have a time associated with them when sent. So there are two options: - Record the time my client receives the transaction (which would mean no times for old transactions) - Use the timestamp from the block the transaction was included in (no times for unconfirmed transactions) Which do you think would be best? Just put the timestamp from the block. That makes more sense because we would get transaction times for all the transactions. Also, a transaction isn't really verified until it has been included in a block. Maybe just make a note about the time being that of the block instead of the transaction itself. Actually, with a well-connected node, the time that the transaction came in would be the most accurate and important, so you should show that anyway. Perhaps an additional field? And while we're at it, do the same for blocks. It'd be great to be able to see what the differences are in the timestamps as we are designing defenses to timejacking. This isn't an either/or situation. It's merely adding more precision to the timestamps which will allow us to have much better data to work with in the future. You show unconfirmed transactions already, so I suspect that adding a timestamp will be trivial. |
|
|
|
|
Guys, stop this off-topic trolling. I really don't want to fix up this thread.
|
|
|
|
I'd be very interested in some statistics on how long it takes transactions and blocks to propagate across the bitcoin network. Could you collect some data on these times? I.E. Measure when you receive a particular tx or block from different nodes, and track something like the 95% percentile of the delay.
Having good data on this (especially for blocks) is relevant to any discussion of changing the blocktime to less than the current 10 minutes.
It's not exactly what you're looking for, but the guy who runs this might be able to more easily add that information: http://transactionradar.com/ |
|
|
|
Autolocking of old threads should be considered a thread that's been inactive for a period (no new posts and less than x views in x days) that gets bumped for no real reason is irritating at best
This forum is in the unique position where a great deal of old threads are still relevant today. Although, maybe this can bet done for every board other than dev. I don't know. |
|
|
|
|
Apparently the information was already released somewhere. You'll have to do a search to find it.
|
|
|
|
Past versions of an edited post being available to mod/admins (or maybe even just admins) with the ability to revert a post to a previous version would be extremely helpful. Also, the ability for a mod or admin to prevent someone with lower rank (including the original poster) from editing a specific post. This would mostly be used after a mod has to edit a post for some reason, and would likely be a checkbox on the edit page. No embedded images
Due to problems with "cookie stuffing" and other attacks, let's just disallow embedded images all together. Transform old embedded images into links. Avatars will still be allowed, but they will be hosted by the server.
One thing I've started seeing custom forums do is have the server cache external images. We can charge for this image mirroring if we want or just give it to donators. This can even be outsourced to a different company. Real-world example: [img]http://cdn101.iofferphoto.com/img2/item/131/025/265/5EQT.jpg[/img] becomes: <img src="http://imagecache.w00t.com?url=http://cdn101.iofferphoto.com/img2/item/131/025/265/5EQT.jpg" border="0"> which redirects to: http://image.w00t.com/8EpApz69bXWXyvoZYgJZdnl7pd8_?Expires=1316794098&Signature=Vh0Rnvsy07zjvt8yDN45TDBWM5LCrXLeH6smkJh6-NlCObKpLrtesjtnht8~GD4QLU5jTmxRZBweXpDtO0hNuMSZub1AJwDLC8PViBJvHLq8MWCa6IuFVRdm2ZR5nK0tlA3SbHyRlNDMzyFVIcxq8bpEAsnpJMtW8oA7saHmVjI_&Key-Pair-Id=APKAIHX2P6GWWRFXYETQ |
|
|
|
|
What would we spend the money on? Our hosting is being freely provided by Mark of MtGox, and the donations are enough to pay for new forum modifications.
|
|
|
|
Er sorry, I haven't kept up with everything. How does the screenshot he provided prove his guilt?
I don't see it off hand, but I'm super curious how he's managed to stick foot in his mouth, yet again.
Notice that there is a transaction missing. Where's the transaction from his fiance? |
|
|
|
Had to get this from my fience who thinks the whole thing was a headache in the making.. but what's your account and I'll send it.
Hmm... It was almost a sure fire thing though. Cablepair needed a card and I was so sure I could get it. I did in fact order the card. I just snapped this from my wallet.  The red box is what I just paid Cablepair. The blue box is the address I was gaven from spendbitcoins to pay for the $10 card, thus proving I paid for it. I'm out for a bit, fience's grandma needs help with some stuff over at her place. That screenshot changes things. It appears that logansryche has been lying this entire time. I was going to redact his personal information from this thread, but now I cannot. This scammer investigation just got reopened (I've been watching and gathering information this entire time). It will remain open until we get information from spendbitcoins. However, nothing will be redacted afterwards, regardless of the outcome. |
|
|
|
Again, this can be achieved by using a password to seed a deterministic wallet. It's literally the same thing you're trying to do, except that the "wallet" is stored directly in the blockchain. (more precisely, the wallet would no longer exist, or need to exist, since it's generated by a password)
Of course, it would be incredibly insecure unless your password was as long as an address and had a good amount of entropy.
Yeah, we're splitting hairs. I was just thinking about how to use the current system with a wallet. It maytake more dev work to do it your way, and its less robust. On the contrary, deterministic wallets are already on the roadmap to be added to the Bitcoin client (don't quote me on that, since I'm not completely sure that's true), so this would require significantly less work than your idea. With your idea, we need to implement a side-channel for distributing and storing encrypted wallets. With my idea (well, it's not really my idea...), the password is the wallet. Also, your 'deterministic' way requires you to remember every password/address. On the contrary, a single password can generate a large number of addresses. Do a forum search for "deterministic wallet" and be prepared to have your mind blown. I know mine was. encrypting the current wallet lets you maintain lots of addresses and reduces the chances that some one will target you . Remember blockexplorer will tell every one which address should target for a big payoff. It would be harder to find the "fat" addresses along with the specific wallet to attack. B/c username is not associated with an address, just a an encrypted wallet file that can access unkown addresses. While it's somewhat true that you would more likely be targeted under the deterministic wallet system, under your idea, you are also more vulnerable to untargeted attacks since attackers would know that most encrypted wallets would contain at least some bitcoins. I do concede, though, that bruteforcing all deterministic wallet at once would be easier, since you just need to check if an address exists for each password instead of testing each encrypted wallet. Maybe your idea of using usernames as a salt might fix that, though. That being said, it would be hard to actually target a deterministic wallet. The reason for this is that you can only know what addresses you cracked after you crack them, not before. As far as entropy. I propose doing it the wallet way b/c you can control the complexity of the encryption perhaps with a bit more granularity. Sha256 followed by blowfish, then aes etc... You can do that same thing for deterministic wallets. Your password can go through encryption before being hashed by encrypting it with itself. After you hash it, you can again encrypt it with either the password, the encrypted password, or the hash of the encrypted password, and then hash it again just for the hell of it. As you would anytime you are dealing with passwords, the user could set the strength of the key by requiring any part of the process to run more times (they'd need to remember what they set the strength to, though). They could make it so that it'd take 10 minutes for an average computer today to generate their master private key if they wanted to, regardless of what the password is. Of course, the same can be done in your idea. If we use a username as a salt (eg like paypayl), require 9+ character pws with punctuation, and tack on a special date (Dec 25 0000). It would be very hard for an attacker to break it. We lost hashes on this site. the pws were salted by username. I bet even a simple 123456 password got broken. Salting destroys the rainbow attack.
Sound about right? That would likely be secure enough, yes. Whichever way you do it, though (either encrypting the wallet and sending it off or using seeded deterministic wallets), I still wouldn't trust my life's savings in it. |
|
|
|
Or should I just try to submit a claim with just the password, email address and IP used?
Your claim will need more than just that. Did you ever deposit/withdraw from MtGox using something other than Bitcoin? If so, include that in the claim. As for your balance, you'll need to figure out what your deposits and withdrawals were, as well as any trades you've done. You need to be within a few bitcoins if you have more than 15 BTC (I believe) in your account. Otherwise, just talk with MagicalTux in IRC. |
|
|
|
yes what we're describing is some kind of Cloud-based RAID. A swarm, just like bittorrent. Infact since there are so many open sourced BT clients, i suggest copy and paste.
The real trick is encrypting the wallet so that every one can see/copy it but not penetrate it. I'm no cryptographic expert, but between a user name/passphrase and and maybe a 3rd piece like a date, the wallet can be secured and then stored in the open by the client.
This solves all kinds of problems. 1) losing a wallet 2) transporting wallet to new machine 3) wallet trojans to steal wallet.dat
Again, this can be achieved by using a password to seed a deterministic wallet. It's literally the same thing you're trying to do, except that the "wallet" is stored directly in the blockchain. (more precisely, the wallet would no longer exist, or need to exist, since it's generated by a password) Of course, it would be incredibly insecure unless your password was as long as an address and had a good amount of entropy. |
|
|
|
|
You don't even need to store the wallet in the cloud - the addresses that coins are sent to can be based directly off of a password. That being said, what is your suggestion for making it SIGNIFICANTLY less profitable to crack these deterministic addresses than it is to mine?
|
|
|
|
The whole alt cryptocurrency section seems to be a troll den... I try to moderate it, but usually when I see a report the thread is full of crap and I don't have the time to go through it all. Seems to help keep the rest of the forum a little cleaner.
It's because of this that I've had to moderate much more harshly over there. The weird part is that it seems to work... for about a day. Prior to today, the posts there were great the last two days. I had almost never received as few post reports as I had the last few days (other than today, of course). That makes it clear to me that the problem is just a few users. We need to find them and ban them. |
|
|
|
As this thread pertains directly to the market subforum this is not a bad place for it, as far as posting things here post count should be avoided in favor of some kind of review system i've bought things from people with less than 200 posts and recived the goods as expected, perhaps the marketplace actually needs it's own moderator(not me i sell things and am therfore biased) to keep it clean
The problem I see is that it's easy to make multiple accounts and give yourself positive reviews. Yes, that's been a large problem recently. We recently took down a large false web of trust. |
|
|
|
okay, I got a few reports that they do in fact possibly alter the odds for much larger bets. So I ran a very expensive experiment and found that yeah, they use horribly unfair odds at higher amounts. After a high enough volume to accurately measure it, it's around 80-90% they win at amounts above 0.5 BTC. So don't bother with these assholes.
So, where are your detailed results for this like you used in your first post? |
|
|
|
are posts and replies able to be read by everyone?
Yes. If you are able to post somewhere, it will appear immediately to everyone once you post it. |
|
|
|
scammers get banned from here all the time man, so.............................. it already doesnt exist.
Huh? I think you are confusing s cammers with s pammers, because we don't ban scammers. Sure, we flag their account and prevent them from editing their posts, but that's it. BCX would only have been banned if it was discovered that he was trolling, and I have it on good authority that he wasn't. Otherwise, it's better for everyone if we let someone attack a chain out in the open rather than completely in secret. Besides, the exchanges closed because they were contacted directly by BCX, not because of anything on this forum, so banning him would have literally changed nothing. |
|
|
|
|
Show Posts
