Sorry to bump this thread without delivering.   I just wanted to post a link to my unfinished code: https://github.com/scintill/ti8x-bitcoin .  I may take it up later, but for now I've hit a pretty big obstacle with the size of the compiled code being too large to put in an app for the calculator.

It may be useful to port to other small systems.  It probably ought to be licensed under GNU Affero GPL due to linking with MIRACL.  I haven't officially put in a license yet, as I am not sure what I have the rights to do with rmd160.c, which is derived from the reference implementation of RIPEMD-160.  I'll try to clear that up soon.

Just as a point of information, I bought a 1-year Netflix code on 30th January and received an email from them on 28th April: "Our records indicate that a Netflix Gift Subscription you redeemed was disputed and the payment for it was denied to Netflix. Due to non-payment, this account has been cancelled."

Yeah, I figured there are hairy problems about scripts depending on arbitrary other transactions.  Maybe Satoshi gave up on making script really work because he didn't know if he could do it right.  Best to get a solid foundation first.

Just having more information about the transaction itself and a bit of global state could be useful.  E.g., maybe locktime could be implemented in script, if the script could know the time.  A script could check that its inputs are evenly distributed N ways across its outputs, for fair splitting of funds between partners or something.  I guess multisig and other collaborative tx signing allows the key holders to mediate these kinds of things themselves.

I have thought about scripts being able to "call" prior transactions' scripts, to recycle useful but complex behavior, if the reference and some optional "patching" is shorter than duplicating the script itself.  But as you say, this kind of thing would be a nightmare of inefficiency and DoS attack surface even at merely today's blockchain size.

Yeah, a more apt name would be OP_DO_BITCOIN or something, since it rolls so much core functionality into one inflexible "opcode."  The rest of Script seems like pointless toys, since not even the most trivial inspections of the transaction or blockchain is possible.  It is cool to see the hash collision bounties that have been published using some of the other Script opcodes.  (I'd be interested to see other novel uses, too. Maybe smarter people have found that Script is not as useless as I think.)

It is a little surprising, but doesn't sound terribly unfair.  IANAL, but I think of it as, they had a little trial with the judge who signed the forfeiture order.  They presented evidence that the server was running SR and had some coins on it.  That's a pretty slam-dunk case, so they can take the coins.  They haven't yet finished the trial to see whether Ulbricht ran SR, so he can keep his personal coins.

I got a chuckle out of this too (can't be too haughty because I'm no expert myself.)  I'm not sure exactly what crabel was saying here*, but a peer-to-peer proof-of-work hash chain that incorporates timestamps that are supposed to be within some bounds to be part of the winning chain, IS A "way of resolving the timestamp in a decentralized manner."

If you think the clock is wrong, or not monotonic enough, take it up with the entire bitcoin network.  They effectively approve each timestamp as it comes in, by starting another block on top.  Sorry, but I don't think they care much about your analytics.  I started this thought as a joke, but seriously, if you think it's a big deal and think everyone will agree, the window could be made stricter.  But I am pretty sure keeping an accurate clock is pretty much the last thing anybody is going to risk orphaning their mined coins for, or having their transactions reversed or delayed over.  The bitcoin network does not have accurate timestamps as a design goal.

*It sounded like he may have been describing a way he normalizes the timestamp for his purpose, but I'm not sure.

I was respecting privacy, but on second thought I don't think he would mind.  His name is Gregor Volkmann and his site is at http://gregor.volkmann.me/ .  He contacted me by email so I don't have a username, and I couldn't find one with search.  I haven't heard from him since telling him I posted, so I guess he hasn't registered.  He probably only would have posted the link, but looking at his home page he seems open to being contacted, if people have questions or whatnot.

OP, got an update?  I checked the linked status page and it says they are still processing.  I understand they are supposed to respond by a deadline, and surely it has passed by now!

IMO (having last read it a few months ago) the paper is not that great of an academic paper.  I felt it left quite a few ideas undeveloped and glossed-over.  We know Satoshi had answers to the things he left unfinished in the paper based on his source code, and the community has filled in gaps over the years, but the paper, while briefly introducing some revolutionary ideas, is fairly basic.

Even from a computer science perspective, it is not a rigorous specification of the protocol, tx construction, script language, etc.  The source code has served that purpose.

I get the impression he wrote the paper to give people something to chew on, while writing the code which he considered more interesting or important ("I'm better with code than with words").  If you were "there", feel free to correct any of this.

I've been asked by someone in newbie jail, or unable to register, to post here this online signature verification tool he created: coinig.com.  (Some CYA: this is not an endorsement of the correct functionality, security, privacy, etc. of the tool, just sharing a link.)

I removed it, for being embarrassed about its weak key generation (!), and not wanting to enable people to unwittingly generate weak keys.  Also, someone has made a more flexible fork called PHPCoinAddress, but I would recommend at least applying my patch here, in addition to ideally studying secure key generation for your configuration/platform (at least if you are doing something high-risk/high-value in production.)  Feedback on my pull requests to PHPCoinAddress is welcome.  Thanks.

Sure, I meant the probability skews a bit.  In practice maybe it doesn't help much.

In a typical two-output tx created before ~2013-01-30, there's a good chance the first output is the change address.  Maybe even longer, depending on how long until the fix was widely deployed.

I'm trying not to be too hostile here, but I'm really skeptical and feel like you're deliberately being vague.  What "issue"?  All you've really done is claim there's an infection, speculate on its motives, and give some sort of log without much description of what it is.

So, at least could you say what the log is?  Something has blocked outgoing connections from chrome.exe to bitcointalk.org (109.201.133.195)?  What do the columns mean?  What software produced this log?  Are the port numbers listed from your side or bitcointalk's?  It would indeed be unusual for Chrome to be connecting to high-numbered ports of bitcointalk, but not unusual for high-numbered ports to be the originating port from Chrome as a client.

Sounds like theymos has debunked the log as an overactive general blacklist, not an indication of a new, specific infection on bitcointalk.

Yeah, I see nothing about where it is supposedly "inserted into Bitcointalk", how users can protect themselves, how the forum can clean it...

There's this:


Could be regulatory issues involved too.

I've got some barebones C code that generates privkey+address and works on Linux.  I was working on compiling it for the TI with the sdcc compiler.  I may also have to rewrite the input/output to use the calculator's system calls.  There could still be pretty big obstacles as far as what the compiler supports and device constraints.  I haven't had time to work on it in the last week.

To be honest I will probably do it without a bounty, but would like one and can justify working more if there is one.

How about 1.5 BTC?

I assume since it's on this board, you are willing to pay.  Did you forget to say how much, or maybe you are looking for bids?

I am interested and have a TI-84+ (seems to be backwards-compatible with 83+), but realistically would probably only get around to it if there's some money to be earned (or at least several people who would appreciate it ).  I'd prefer to release it as open-source.  I'd need to look at the specifications closer and do some estimating on whether it can fit in the space requirements and won't be painfully slow, before I devote too much time.  I also wonder if a bitcoin QR code can be reliably scanned from that low of a resolution.

Another case of cracked brainwallet where the funds were returned: http://www.reddit.com/r/Bitcoin/comments/1j9p2d/blockchaininfo_unauthorized_transactionhow_could/ .  The cracker said he's the same guy from this thread, only this time it was around 3 BTC.

This time the passphrase was quite a bit longer, but was a song title, so the rainbow table is pretty big.  Be smart and careful, people!