Firma o GTFO.

Is it a case that, everytime the price dips, the bitcoin community switches into a cripto-anarchist sect?

Define Apple in 23 words or less.

That's true: domestic transfers are still authorized manually in most countries and banks, while SEPA transfers are completely automatic.

Wall is being chomped slowly but steadly, around 100 btc/min. At this rate it will be bought in a couple of hours.

EDIT: Scratch that, rate's going up dramatically. It won't last another hour.

That's much simpler actually. Big downward pressure -> Big downward motion.

Meanwhile at stamp's HQ

The ~1M$ sell wall on stamp has been broken.

Corretto.


Ipotizzando che il tentativo di doppia spesa (perchè di questo si tratta) venga fatto come si deve, ovvero creando transazioni valide, ritrasmissibili e mandandole a nodi diversi, succede che una parte dei nodi della rete bitcoin avrà nel proprio pool di transazioni in attesa di essere incluse nel blocco la transazione "A", e altri la transazione "B". Questo perchè il client reference rifiuta la transazione B se ha già in pool la transazione A e viceversa, indipendentemente dalla fee. Tuttavia è relativamente semplice modificare il software affinchè, nel caso venga ricevuta una transazione valida con lo stesso input ma fee più alto, questa sostituisca la prima nel pool. E' opinione diffusa che diverse pool implementino un sistema del genere, di conseguenza è lecito affermare che la transazione con fee maggiore avrà più probabilità di essere quella che finirà nella blockchain.

Con un attacco ben svolto è possibile che chi dobbiamo pagare riceva la transazione onesta, ma che quella che finisce nella block chain sia una che rigira i bitcoin su uno dei nostri conti.

Ovviamente, appena una delle due transazioni viene inclusa in un blocco, l'altra diventa non valida e viene cancellata dai pool di tutti i nodi che accettano quel blocco, e la doppia spesa scompare. Questo è il motivo per cui accettare transazioni con 0 conferme è una cosa delicata da evitare se non c'è nessuna forma di garanzia.

Non sono io a decidere ma direi di no, non sarebbe corretto nei confronti di chi si è iscritto al corso.

Dipende da cosa verrà fuori! Non per nulla uno dei punti in programma è quello che ci aspetta il futuro, lo spazio non è tantissimo ma vedrò di introdurre le cose più interessanti e con maggiore potenziale.

Beh, se con "leggere guide dettagliate" intendi passare mesi o, più verosimilmente, anni ad approfondire, studiare, sperimentare e sviscerare l'argomento sotto aspetti completamente diversi tra di loro allora, in effetti, nessuno  

Seriamente, se veramente pensi che basti leggere qualche howto su un forum per approfondire un argomento complicato, poliedrico e in rapidissima evoluzione come quello delle criptomonete, ti posso assicurare che sei fuori strada. E' un'argomento talmente multidisciplinare da richiedere specialisti aggiornati sugli ultimissimi sviluppi in campi molto diversi l'uno dall'altro per essere affrontato con un minimo di completezza, cosa che non può essere fatta in modo sistematico se non con una organizzazione professionale.

In molti si sono improvvisati esperti di bitcoin creando attività e servizi basandosi su howto, tutorial e frammenti di informazioni copincollati qua e la, uno su tutti MagicalTux con il suo mtGox. Raramente è finita bene  

Il primo corso professionale sui Bitcoin appoggiato ufficialmente dalla Bitcoin Foundation Italia, per di più  

Io sarò il docente sugli aspetti tecnici/informatici. Come detto da Stemby il corso è rivolto a chiunque voglia formarsi in modo professionale per l'uso del bitcoin in modo completo e cosciente sotto tutti i suoi aspetti, da quelli più "da geek" a quelli economici, finanziari e (cosa fondamentale in ambito professionale) fiscali.

Chi seguirà questi corsi avrà tutti gli strumenti necessari per impiegare il bitcoin in qualunque attività conduca e, ci auguriamo, ad idearne di nuove basate sulle enormi potenzialità dalle cryptomonete.

Ovvero: scegliete una moneta da generare e sperate di aver scelto quella giusta che vi farà vincere più bitcoin delle altre. In caso contrario ne perderete.

Io sto parlando di ritorno sull'investimento, tu di scommesse sui cavalli.

I plan to make another one or two rounds next week. I'll set them up in the upcoming weekend!

Solution for the 2nd stage

Please read the solution for the 1st stage if you haven't already

As before, the first thing to do is to understand what the scriptPubKey requires in order to be reclaimed. Let's see it:


So, the first thing it does is OP_DEPTH, that returns the number of entries in the stack and put it in the stack itself. that plus OP_1 and OP_NUMEQUAL make a test that returns true if the scriptSig (which get executed before) yelds a single value, false otherwise. The If....Else...End if block after tell us that this scriptPubKey can work in 2 different ways: the second one is a standard pay-to-address transaction script, which gets executed when the scriptSig gives the two variables needed by a signature verification: sig and pubkey. As the address associated with this method is the same used to fund the contest, it's safe to assume that the private key isn't pubblicly available, so this method isn't the one we'll use. Let's focus on the other verification subscript:


So this script starts with some data that gets pushed in the stack over the one provided by the scriptSig, only to be dropped right after by that OP_DROP. After that, the scriptSig gets hashed two times by RIPEMD160 and compared with a given hash. So, this script is asking for some data that, when double hashed with RIPEMD160, gives 9c864b8bb110c05cb9c77381ad5d6868f0fd9f9f. Now, back to the 6e616d... discarded data: why would someone add and drop random data to a transaction? Couldn't be that the hint we need to solve this? Why yes! I guess that anybody who ever worked with string and hexadecimal representation immediately noticed that all those bytes are in the 0x60-0x7A range, which are the a-z charaters in the ASCII table. By decoding it you get "name of nakakamoto". No, that "kaka" is just a typo of mine, no hidden messages. As we all know, the obvious solution to this riddle is "satoshi". To test this, we just have to hash that string two times with RIPEMD160 and check the hash. Be careful! Do not simply hash the string, then copy/paste the resulting hash and rehash it the same way, because you'd be doing an hash of the string representation, and not the hash of the actual binary data. To do this you need a tool that makes a difference between string and hexadecimal input data, like this one. Hashing first time gives this, and the second time gives this. Notice that the second RIPEMD160 hash is the same as in the scriptPubKey.

Now, since we know how to create a transaction with a custom scriptSig from the previous stage, the rest is trivial. Just build a transaction that spends the output ab149362ea4e119d2bc5211b35083c23ec41842af6bbc2ff3c5f1e55941199cc n=0 , and as scriptSig you just have to put the hexadecimal ASCII representation of the string "satoshi" which is "7361746f736869".

This script shows that it's possibile to have a txout reedemed by one out of different methods, leaving the claiming user the freedom to choose which one to use. It's even possibile to set up the script so that it automatically knows which method to use for the verification, basing on the format of the scriptSig.

Looks like we have a winner! 

There's only one way to correctly perform a double hash. You must keep in mind that what you get from an hash of a string is just binary data, usually in the form of an hexadecimal number.

Hint: use this service http://www.fileformat.info/tool/hash.htm

Yep, I noticed the typo. I just re-checked the solution, and it's fine. the encoding? Why do you think I put there an hint?  

@norbertVC

2 errors in your analysis: one is that, as pointed out by frisco, OP_NUMEQUAL removes the checked items. The other one is that OP_DROP is for that 6e616d... number, not for the 1 which doesn't even exist.