excerpt from my headers:

this is about the worst possible spam-score. pretty weak attempt.

i think this shows us that in any complex codebase at some point you can't simply rule out errors just by a human looking at it. therefore you need to rely on as much automated error checking as possible.
maybe its different for you, but in my experience this tells me:

• use a statically compiled, strongly typed language with good IDE support
• stay away from dynamic programming like bytecode manipulation or metaprogramming
• use as many automated tools as possible for error checking (compiler, IDE inspections, findbugs..)
• when dealing with threads a whole new class of errors are possible that are not easy to detect for tools, so be extra careful. avoid threading where it makes sense, use proven platform tools where it is neccesary. if possible, stick to an actor library.
• garbage collection is your friend. except when writing a 3d shooter.
• unit test things wich are critical but are not run often in production, and possibly more
• only use libs where you can access the source code to be able to understand and debug them

again, i will certainly not force anyone to adopt this methodology. i'm just saying those are the principles i use to avoid a vast range of errors, including memory issues, buffer overflows, bad macro behavior.
for very simple problems or problems with very specific performance requirements you have to be pragmatic and drop some of those restrictions.

i am very happy that there is a very good implementation of Bitcoin in Java. Any developer who agrees with the issues i raised should consider using BitcoinJ instead of a c++ based Bitcoind. It is not perfect but at the moment the safest choice.

testnet rules from bitcoin-QT (satoshi client) have changed and those rules are only in 0.5-SNAPSHOT or in one of the upcoming 0.5 releases

i just recieved this as well. wording sounds simple-minded like the one from http://cryptocoin.info/

In welchem Umfang sollte dieser Beitrag sein? Vortrag? Paper? Poster? Muss es einen "wissenschaftlichen" Ansprüche haben, d.h. neue Forschung oder reicht sowas wir ein State of the Art Report, oder auch Vorstellung von experimeteller Software?

i wonder - is it ok to sell public domain audio for a fee? from a legal perspective it should be ok, but what does the TOS of coindl say about this?

i have noticed that there was at least one upload of librivox.

to get a nice starting inventory for coindl, someone could gather, catalogue, keyword, proper ID3 tag public domain work, and offer them for minimal fees (say 0.1 BTC)

also, one more suggestion that might involve some serious programming: when downloading multiple files the site should offer a consolidated QR code where you can pay for all items at once, and multiple files should come as a download simultanously

your error message means that

Propably you have the wrong BouncyCastle lib installed. the version used in BitcoinJ is 1.46 (see pom.xml)

not yet. currently there is basically no ease of use. in the two demo apps if you want to pay someone you have to download a ValueRequestMessage which is a file minimum 200 bytes (can be even larger) then the user has to import it to his MitChip App and generate a signed response. send the file over to the merchant. merchant imports it.

of course in practice this will be significantly easier (NFC, QR Code, URL, callbacks), if all MintChip standardize on a way to exchange ValueRequestMessage+ValueMessage but right now Bitcoin usability is OK-ish and MintChip is abysmal.

just downloaded the java examples (which come compiled only)
i decompiled all jar/class files using JAD to get a quick overview how it works in detail. this info may not be 100% correct since i only took a quick look and i do not have the hardware

in depth it looks like it works like that:
1) a service decides it wants to get paid. it issues a IValueRequestMessage which contains
amount
currency
payer ID (looks like its sort of customer number/or user definable number)
annotation (msg to go along with payment)
challenge which may be generated at random? from Hardware
response-address; base64coded from ASN-serialized/DER encoded binary message which is basically an equivalent of an Tx Output

2) the payer replys with a IValueMessage containing
amount
currency
payeeId
payerid
payercertificate
challenge
min-version ??
generation time
annotation
ASN-serialized/DER encoded data which comes from the hardware-chip that encodes a set of Tx Inputs. It looks like to handle "change" money the payer may first split existing outputs into multiple child nodes. this splitting occurs also on hardware.

so the hardware not only stores private keys, it also stores all relevant previous transactions.

the API supports both debit and also credit transactions, they seem to be two distinct crypto chains. so you can also pay someone without having a positive balance. the credit can be paid off by receiving valuemessage
according to error codes - for credit there seems to be a limit stored in the HW.


what looks like unspecified is how payee+payer communicate their data. in the android demo application you have to load the message from SD card. i'm not sure if it may be possible to encode all this ASN/DER encoded payment graph into a QR Code.

i noticed that when downloading, the "Content-Length" is not set in the http response header. this leads to the browser not displaying a progress bar.

of course, this all depends on the perspective. from a plain'ol merchants POV this is positive, since they will not have any legal hassle.

NOOOOOOOOOOOOOOOOOO!
i'd really, really like to get that physical kit for playing around with it.

Also, I find it funny that David Birch, the Bitcoin nemesis is one of the judges in the challenge.

yes, it totally reminds me of that. somebody tried to pitch it to Eric Schmidt recently.

exiting times! this thingie looks like bitcoins handicapped brother.

on the negative side:
- obviously double spends will be possible
- requires special hardware
- is still fiat money whose value always goes to zero

on the plus side:
 - has gov. backing
 - is tied to the CAD which might be better than USD or EUR in the mid-term future.
 - is already an currency, more clear legal status
 - the whole website seems to be targeted to developers with actual code and is not just slapped-together powerpoint slides

i'm going to study the code samples etc ASAP.

pathetic. both the article and the comments. this quote tells me more about the writer of this comment then he is aware.

well, i have heard there are some alternative app stores which have trouble finding a paypment processor and have to deal with chargebacks all the time.
for example, http://www.mikandi.com

good find!
this was the first time i learned something new about bitcoin that came from an MSM Article and not from the community.

you might think twice about that one.
see: http://www.theatlantic.com/magazine/archive/1982/02/have-you-ever-tried-to-sell-a-diamond/4575/

did he just add that?

slowpoke moved to this thread

Bitcoin is a fine word.

it is debt-free money. (so no credit)
it is like gold - so its like a gold COIN
it works digitally and over the internet - BIT

when i describe it very briefly i tell people: its like gold that you can send anywhere over the internet instantly to anybody for free.

typically they want to know more and ask back and get a 15-30 minute introduction.