Current state: Slots BTC person 1 5 c0ffer 2 5 Andrew Bitcoiner 2 5 Goat 2 5 Coinabul 1 5 macintosh264
|
|
|
Probably there are many posts more deserving, but the first post that comes to mind is Satoshi's first real post on the forum... I left the admin account set to the original SMF theme so if I somehow completely wedge the custom theme I can still get in to fix it.
I've got a neat little 12x12 coin image to replace those pip stars with. Should look nice. Also some nice button images to try.
The registration page has "hide your e-mail address" unchecked by default. I must fix that in php before we can open up.
The Announcements forum is currently moderator access only.
It amuses me how Satoshi writes in this really light, casual tone while overseeing the creation of Bitcoin and its community.
|
|
|
Ben Wallace was clearly familiar with Bruce's scandal when he interviewed me, so I'm not sure why he's still giving Bruce any attention. benwallace: Do think the Bruce thing will have any significant fallout? Do you expect him to step back from his frontman role? Or that the community will pay less attention to him? Or neither?
|
|
|
OK, it seems to be working pretty well.
|
|
|
Actually, the "censored words" functionality might be sufficient. I set up something (probably broken), and I'll do proper testing in a few hours.
|
|
|
I don't want to modify the text of any old posts. I'd rather the links be converted during display. Probably best to do it in the same place where linkification happens.
Maybe I'll take a look later if no one else provides the code.
|
|
|
It's a script op that pushes 0x41 bytes onto the stack.
|
|
|
It's not something that an average PHP developer wouldn't be able to handle within an hour.
Are you volunteering?
|
|
|
I've had really bad results with BTC fundamental analysis in the past, but I feel pretty positive about this, so I'm doing a bit of buying. Probably I'll regret it...
I don't expect prices to rise until at least business hours on Monday.
|
|
|
I see the source of your confusion now. I had accidentally written that the auction ended on the 22nd, but it actually ends on the 30th. The time was correct in the countdown.
Sorry about that. I edited the post.
|
|
|
Yeah, there are about two days left.
|
|
|
Current state: Slots BTC person 1 5 c0ffer 2 5 Andrew Bitcoiner 2 4.5 darbsllim 3 4 Goat
|
|
|
How would that work? The act of inserting sigA or sigB changes the hash of the transaction containing the output, invalidating the other signature.
I was thinking in terms of a "full" concatenated script, but I've found that pbegincodehash is not preserved between scriptSig and scriptPubKey, so that kind of thing isn't going to work. Is having two checksig/checkmultisig commands in the same script actually even a problem? I'm now thinking that maybe scriptSigs are not even part of the sig hash, which would eliminate the problem entirely.
|
|
|
That's the opposite. A transaction starts out invalid and then becomes valid. You can't make a valid transaction become invalid in the current protocol.
|
|
|
Some of the statements I've bet on will have no losers. Do you still take a fee in this case?
|
|
|
Hmm... I was thinking you'd use it like this to avoid having signatures depend on one another: <sigA> <pubkeyA> OP_CHECKSIGVERIFY OP_CODESEPARATOR <sigB> <pubkeyB> OP_CHECKSIG
|
|
|
I think this is the accurate hex: 01000000 0000000000000000000000000000000000000000000000000000000000000000 3ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a 29ab5f49 ffff001d 1dac2b7c 01 01000000 01 0000000000000000000000000000000000000000000000000000000000000000 ffffffff 4d 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 ffffffff 01 00f2052a01000000 43 4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac 00000000
|
|
|
I'm not sure I want to use SMF again. 1.1.x has a generally insecure architecture. For example, the 0-day bug that affected the forum happened because all POST input is escaped early in the code, then partially unescaped before processing, and escaped again (or not...) before inserting into the database. It is very easy for a programmer to introduce a security problem in this mess.
It's better to avoid the necessity of manually escaping wherever possible by using prepared statements and other library functions that handle it themselves.
Does 2.0 improve this situation much?
|
|
|
Noticed that this user was placed under 'List of Donators'.
Whoops. I fixed it. Sorry.
|
|
|
Interesting article. Rather negative, but it's an exciting story. I was interviewed for this article several months ago, so I've been waiting to read it.
|
|
|
|