|
Puddinpop's pool used to do something like that. It would give you the full block from time to time, which allowed you to verify that you were scheduled for payout (since it paid out directly like Eligius).
|
|
|
|
|
This was initially going to be in the first version of Bitcoin Block Explorer, but I decided that it would have no real use for detecting "dirty" coins. The scammer would just send all of the coins to MtGox or something and withdraw clean coins. Only innocent people would be hurt unless the scammer is really stupid.
|
|
|
|
I think that what you are saying is that Elgius will validate transactions with syntactically valid output scripts, but that it wouldn't be able to validate any transaction which then used that output as an input. That's not what I'm saying. Even if Eligius doesn't know how to create that OP_1ADD... example of yours, it can easily see that the scriptSig+scriptPubKey pair validate. That's the point of script. All valid scripts are universally recognized as valid, even if you don't understand how the script was created. |
|
|
|
|
You can verify non-standard transactions without being able to understand how they would be redeemed. That's the whole point of script. One pool (Eligius) already accepts all non-standard transactions, even though it can't understand how to accept all non-standard payments. Blocks produced by Eligius will be accepted by the entire network, since everyone understands script.
|
|
|
|
Can the "scriptSig" (which looks to be just source code nomenclature for a chunk of input script) contain any and all of the same opcodes as a "scriptPubKey"? Yes. Also, why are the names for input script and output script segments so strange They're named after the most simple type of transaction: scriptSig contains a single signature, and scriptPubKey contains a single public key (plus an OP_CHECKSIG). Since scripts can be of arbitrary complexity, how can a bitcoin client tell when a transaction has outputs that the end-user could successfully claim? It knows how to solve the two common scripts. Other scripts will be ignored. The receiving client must be changed to recognize any non-standard scripts. |
|
|
|
|
Un modérateur est certainement nécessaire. S'il vous plaît de partager vos opinions sur qui serait un bon modérateur.
|
|
|
|
Is there any way to detect a double spend with the current client then?
I don't think so. |
|
|
|
1. When you get the details of a transaction (gettransaction), is the timestamp that bitcoin reports the timestamp of the transaction itself, or the time when bitcoin received the transaction?
It's the timestamp of the block the transaction is in if it is in a block, or the time you received it if it has 0 confirmations. Transactions don't have timestamps themselves. 2. If a transaction is received, but later determined to be invalid (ie. a double spend), will bitcoin still report those transactions in listtransactions but give an indication that it's invalid (I would think that is desirable since it would be important to detect an invalid transaction)? It will just stay 0/unconfirmed forever. |
|
|
|
How can I verify if I'm using data=ordered or data=journal? This is my partition on archlinux:
/dev/sda4 /home ext4 defaults,noatime 0 2
@bcearl: I assume you don't use shred right? If so then how can you securely use GPG encryption? It sounds useless to me if I'm leaving traces behind in my disk whenever I decrypt to use my wallet.
dumpe2fs -h /dev/sda4 |grep 'Default mount options' Using journal=data really hurts performance. It's useful mostly for home users, who have low reliability. Most other file systems (NTFS, ReiserFS, XFS, etc.) don't even support data journaling. |
|
|
|
|
It was deleted by Sirius. Probably because it was one of the low-quality "SELL SELL SELL" topics that have been flooding the forum over the last few weeks. It received many reports.
|
|
|
|
|
I removed it (maybe temporarily) because I believe many forum accounts will be compromised due to the MtGox leak, and I don't want thousands of posts to disappear.
Feel free to report your posts if you need them deleted for some reason. (Previously SMF would not allow you to do this, but I fixed it.)
|
|
|
|
How are the passwords stored? What hashing algorithm is used?
It seems to be SHA-1 salted with the username, though I'm not totally sure. Who has access to the database? Gavin, Sirius, and me. Slicehost (and maybe Rackspace) also has access, since they host the server Is the forum vulnerable to attacks? Has it been tested for security holes? It uses SMF plus some mods and a small handful of custom changes. Hopefully SMF is well-tested and able to contain poorly-programmed mods I did a cursory examination of all mods before installing them, but I certainly don't understand SMF enough to judge their security well. Is there anything the users community can do to help? Tell me privately if there are any security problems. I will fix them ASAP. |
|
|
|
|
You're using Tor. You must expect to hit banned IP addresses from time to time.
|
|
|
|
This is radical... can't such restriction be applied to newbies only?
Like I said, SMF doesn't support this. If someone wants to contribute code that would exempt certain membergroups from certain bans, I will use it. |
|
|
|
|
It's disappointing, but I kind of expected it to happen.
|
|
|
|
|
I'm certainly never using MtGox again. Who uses MD5 for password hashing nowadays?
|
|
|
|
|
It always applied to posts.
Tor changes your exit node every 10 minutes, so you just stumbled onto a banned one. Several are banned, and more will be added as they are abused.
|
|
|
|
|
As I've mentioned a few times before, permissions will take up to 10 minutes to update after you meet the requirements.
|
|
|
|
That page indicates that coins were combined from three different addresses to be received by 15aU... |
|
|
|
|
Show Posts
