Latest posts of: CIYAM

Show Posts
Pages: « 1 ... 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 [254] 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 ... 334 »

5061

Other / Off-topic / Re: Any postfix gurus around here?

on: June 07, 2013, 11:32:10 AM

Quote from: OnkelPaul on June 07, 2013, 11:23:57 AM Thanks, that's generous - forum advice is normally free :-) IMO this is the Bitcoin way (you saved me the time and effort and so I am happy to reward that). This is one of things I really love about Bitcoin. Quote from: OnkelPaul on June 07, 2013, 11:23:57 AM If a command expects a multi-line response, the server sends a line containing just a single period as the last line. The client should check the first character of each received line, if it is a period but there's more stuff in the line it should drop the initial period (the server can use this to escape lines containing a single period). This is basically the reverse of what SMTP does in the DATA command. Aha - yes I do already have some stuff to do with the period in my POP3 code (will have to take another look and yes I have the RFCs it just takes a bit of time to focus which I rarely have unfortunately). BTW - if you have any interest in other contributions to the CIYAM project then let me know (there are many things that need improvement in any such large project as this).

5062

Other / Off-topic / Re: Any postfix gurus around here?

on: June 07, 2013, 10:41:27 AM

Per your advice: https://github.com/ciyam/ciyam/commit/915db2388ef3b1d76ae30bbd572133f5e71f9fdd Nice how open source can grow this way.

5063

Other / Beginners & Help / Re: How exactly is the time logged in working...?

on: June 07, 2013, 10:22:15 AM

Quote from: t.o.m. on June 06, 2013, 07:09:13 PM You need to refresh the page every 5 (?) minutes. I think you'll find it's only every 15 minutes.

5064

Other / Off-topic / Re: Any postfix gurus around here?

on: June 07, 2013, 09:45:42 AM

I am not sure which code you are referring to that is reading into a fixed length buffer - can you point it out for me (all the socket reads use a std::string)? I like the "defensive post-hoc reasoning" bit and so yes I guess I should be less lazy and do the SMTP properly. BTW - thanks for the info about the space or hyphen after the 3 digit code (I clearly missed that). Sent you a 0.1 BTC tip for that (is it similar with POP3 btw?).

5065

Other / Off-topic / Re: Any postfix gurus around here?

on: June 07, 2013, 09:24:03 AM

Quote from: OnkelPaul on June 07, 2013, 09:16:06 AM Well now you have unnecessary 1.5 seconds per SMTP command instead of unnecessary 5 seconds... Yes - I did consider whether I could just remove the extra reads (and will re-read up on SMTP again when I have the spare time). I think the problem is knowing exactly when to expect multiple line responses from the SMTP server (am sure I could probably do a better job of that than I currently am). It is rather low priority for me though as the benefit of putting in the delays (even though most are probably unnecessary) does help make sure that the application server can't be abused for sending spam (nearly 1 minute per email was too slow but now that it takes around 15 seconds I am not unhappy).

5066

Bitcoin / Bitcoin Discussion / New "progress" behaviour - what happened to the spinning wheel?

on: June 07, 2013, 09:16:03 AM

I've just noticed that normal "spinning" wheel icon next to the # of active connections "strength" indicator now only seems to make each step of its "spin" when a new block is downloaded (maybe it will change back to spinning after it is up to date). Was this the intention (at first I thought something was jammed up with the client)?

5067

Other / Off-topic / Re: Any postfix gurus around here?

on: June 07, 2013, 09:07:46 AM

Lucky I had paid attention to the 5 seconds - then after carefully checked my SMTP source code: https://github.com/ciyam/ciyam/commit/bfa8f2ffd54be314f78c73138aae63e5cc92010c Doh!

5068

Other / Off-topic / Any postfix gurus around here?

on: June 07, 2013, 07:34:42 AM

For some reason sending SMTP from my server (i.e. locally sending an email using SMTP) is extraordinarily slow (nearly a minute).

From (edited for brevity and security) logging the SMTP session within my application server I see the following:

Code:

[2013-06-07 07:10:48] [000160] [mail_op] (connected now reading greeting)
[2013-06-07 07:10:53] [000160] [mail_op] 220 server1.ciyam.org ESMTP
[2013-06-07 07:10:53] [000160] [mail_op] EHLO localhost
[2013-06-07 07:10:58] [000160] [mail_op] 250-server1.ciyam.org
[2013-06-07 07:11:03] [000160] [mail_op] 334 VXNlcm5hbWU6
[2013-06-07 07:11:08] [000160] [mail_op] 334 UGFzc3dvcmQ6
[2013-06-07 07:11:13] [000160] [mail_op] 235 2.7.0 Authentication successful
[2013-06-07 07:11:18] [000160] [mail_op] 250 2.1.0 Ok
[2013-06-07 07:11:18] [000160] [mail_op] RCPT TO:<ian@who.net>^M
[2013-06-07 07:11:23] [000160] [mail_op] 250 2.1.5 Ok
[2013-06-07 07:11:23] [000160] [mail_op] DATA^M
[2013-06-07 07:11:28] [000160] [mail_op] 354 End data with <CR><LF>.<CR><LF>
[2013-06-07 07:11:28] [000160] [mail_op] From: "CIYAM Open" <notifier@ciyam.org>^M
[2013-06-07 07:11:33] [000160] [mail_op] 250 2.0.0 Ok: queued as 977A4FB8396
[2013-06-07 07:11:33] [000160] [mail_op] QUIT^M
[2013-06-07 07:11:33] [000160] [mail_op] 221 2.0.0 Bye

The OS is OpenSUSE 12.2 and postfix version is 2.8.11.

The relevant thing to notice is that there is a 5 second delay before every server response (*exactly* 5 seconds) - so is there some setting that would be causing this?

5069

Bitcoin / Development & Technical Discussion / Re: bitcoin-qt transaction fees.

on: June 06, 2013, 03:52:11 PM

Quote from: lch on June 06, 2013, 03:49:24 PM But I would argue, transaction will not reduce a great deal because large transactions are few are far between. Unfortunately large transactions (not in BTC amount but in KB) are now more and more common due to things like SatoshiDice and various faucets filling up peoples wallets with dust (uselessly small amounts of BTC). This is why there have been quite a few posts recently about transactions "not being processed".

5070

Bitcoin / Project Development / Re: Holy Grail BOUNTY

on: June 06, 2013, 03:07:25 PM

Quote from: cbeast on June 06, 2013, 03:05:04 PM I understand that OT is open source like Ripple, Currently Ripple is not open source (and it needs XRP which OT does not).

5071

Bitcoin / Development & Technical Discussion / Re: Paper wallets and change addresses. Please help me understand a warning

on: June 05, 2013, 12:08:03 PM

Quote from: Remember remember the 5th of November on June 05, 2013, 11:49:51 AM LOL, lucky he says. Nothing lucky here, we all know that 99.99% of the times, it's a pool that will get it. True - although luckily for me when I accidentally paid the biggest fee ever paid (I think the record still stands at 111 BTC) the pool that mined it was kind enough to send most of it back to me.

5072

Bitcoin / Development & Technical Discussion / Re: Paper wallets and change addresses. Please help me understand a warning

on: June 05, 2013, 10:34:03 AM

If you are importing the private key into a bitcoin client such as bitcoin-qt or even into a blockchain.info wallet then you will have no problem (as the tx will be generated for you and a change address automatically created in your wallet). The warning is for those that are going to do a "raw tx" (in which case a "change" output needs to be included if you are not going to transfer all the BTC). If you fail to specify a change address and don't transfer all the funds to the destination address then what remains is the fee (so not lost forever but instead gifted to the lucky miner).

5073

Bitcoin / Project Development / Re: Holy Grail BOUNTY

on: June 05, 2013, 09:56:25 AM

I would be happy to host this (and personally help manage it) on CIYAM Open free of charge (http://ciyam.org/open). Note that CIYAM Open is a system that only locks in one dev for an agreed period of time to deliver (and accepted delivery would be determined by a merged git pull request). If desired this could be divided up into several smaller tasks each of which would be a potion of the overall bounty (rather than having the whole thing be a "all or nothing" bounty).

5074

Bitcoin / Bitcoin Discussion / Re: wait for one confirmation before accept the payment?

on: June 05, 2013, 04:34:18 AM

You would be advised to wait for at least 1 confirmation to be safe from a double spend. But even 1 confirmation isn't a guarantee as a re-org can (and frequently does) occur in which case a double spend could still occur (although this is not very likely). The best advice would be to determine the # of confirmations based upon what you are selling. If it is some sort of internet service (such as a VPS or VPN) then there is basically no risk (as you can always just switch it off if the payment doesn't finally confirm) and if it is small goods (such as a cup of coffee) then the very small risk of a double spend after 1 confirmation would be worth it, however, it is a house that you are selling then I would be waiting for the recommended 6 confirmations just to be sure.

5075

Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess

on: June 05, 2013, 03:24:20 AM

Quote from: sickpig on June 04, 2013, 04:57:27 PM Linux kernel use goto quite extensively Am pretty sure that it is C not C++ (and yes they are two very different languages).

5076

Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess

on: June 04, 2013, 03:11:14 PM

Quote from: piotr_n on June 04, 2013, 03:08:16 PM Close enough to have a working goto... Hmm... am not really sure about that (and no C++ guru would ever recommend using it) - the problem is that the compiler needs to handle all the object dtors correctly (the reason why it is not easier for the compiler). I am not sure that g++ (or other major compilers) give such a guarantee. It's a bit like using void pointers (another common C idiom that is bad in C++).

5077

Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess

on: June 04, 2013, 02:39:22 PM

Quote from: piotr_n on June 04, 2013, 02:35:17 PM Really? Well, then I was wrong all my life, believing that C++ was backward compatible with C... You are wrong - C++ is not backwards compatible with C only as close as possible.

5078

Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess

on: June 04, 2013, 02:33:45 PM

Quote from: piotr_n on June 04, 2013, 02:28:10 PM Coding in C and never using goto, is like driving a car and never using its last gear. Safe for poor drivers... Bitcoin is written in C++ (which is not even close to C as any C++ programmer knows).

5079

Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess

on: June 04, 2013, 02:15:31 PM

Quote from: oleganza on June 04, 2013, 02:12:19 PM 2. Excessive use of C++ subclasses and operators makes it hard to read code. You see a << b, but it actually goes to a very specific place which is not entirely obvious where. Streaming operators << and >> have always been the standard way of doing I/O in C++ so are you saying these operators are being used for something other than streaming?

5080

Bitcoin / Development & Technical Discussion / Re: Bitcoin source code is a giant mess

on: June 04, 2013, 01:48:38 PM

Quote from: misterbigg on June 04, 2013, 01:47:04 PM It's doable but it needs to be a design criteria from the beginning. Indeed - I did it with an Object Database I created (the error string buffers are pre-allocated before the ODB instance is even created) - it is a little tricky though as you end up using "non-standard" exceptions (although you can make it enough like a std::exception to be useful).

Pages: « 1 ... 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 [254] 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 ... 334 »