There aren't any fewer transactions, but six months ago the service you were using likely didn't implement fee estimation.  Without sane fee handling flood attacks can create big delays for otherwise ordinary transactions.

There is no 'value zero' address. A secret key of zero results in a public key which cannot be represented at all.

The only way to destroy bitcoins in an absolutely sure manner is the OP_RETURN advice given.   Bitcoin Core provides no facility for this, because destroying coin is something most users would only ever do by mistake.  I'm sure that for a small percentage of that 65000 btc someone will happily implement it for you.

They've even previously reset the numbers for all transactions on their site. You shouldn't be using that information for anything.

Univalue should be _strictly_ compatible: strictly producing and strictly enforcing.

Many things that produce JSON produce incorrect encodings, and many things that consume JSON will accept incorrect encodings. That may be the case here, or there could be a bug in univalue.  Without seeing your software, its hard to say.

A huge lumbering bureaucracy?    How about-- take over the Bitcoin Foundation and then find themselves surprised when it doesn't control Bitcoin.

A number of big classic promoters were also big Wright-fighters.

I find myself wondering which way the causal arrow goes? Did Wright, as part of his general deception, convince some of these folks that he created Bitcoin and then spun them up on blocksize because it was his own poorly informed view of the future... or did Wright see their block-size mania as a juicy cognitive vulnerability and exploit it to gain their trust? Maybe a bit of both in a mutually amplifying cycle?

In any case, a strong relationship there would do a lot to explain a number of rather perplexing things-- including the absolute, yet wildly unjustified, confidence in the XT and Classic's forks when they lacked so much, including a productive and experienced set of people supporting them. As extreme as that confidence was in public, what I've seen in  in private is magnitudes worse. "No worries, the Creator will come and save the day."

The constant leaking "satoshi's vision" from that camp might also be connected here.

I'm interested in getting further data points on exactly how this scam was spreading in the Bitcoin space. I have some dates and some people, but a lot I don't know.

But perhaps I'm just being hopeful, -- since if this is true, the worst of this drama may be finally over.

probability of one out of the group order exactly (roughly 1:2^256, or one bit less assuming that both signature were from low-S enforcing signers). The only way two them to be identical is to pick the same k.

We're aware. (Though thank you, we could have not been as well).  In general I prefer prefixing-- without it the signature is not really a proof of knowledge--, and the libsecp256k1 "test schnorr" construction goes out of its way to enable things like compact signature key recovery while also using prefixing.

There are rigid coding standards in core now, no one writes code there like they would on their own.

Left to my own devices, with no constraints I write code that looks like https://people.xiph.org/~greg/binomial_codec.c

...but you'd never see code that looked like that in Bitcoin Core.

It's quite easy to hide coding style in any case-- any senior developer has experience working in projects where they must adopt other people's preferred style.

& vs &&  means that the commands are running in parallel in his script, instead of sequentially.

This creates a race condition where the input is decoded to a file after the next step has already read it.

The misspelling of signature in the script also makes his script read from the wrong file (whatever file is referenced by the misspelled environment variable).

Most remarkable is that these scripts were not Wright's creation: https://gist.github.com/ezimuel/3cb601853db6ebc4ee49  They were plagiarized from the web but modified to insert these bugs.

The net effect of these modified scripts is that the modifications would allow you to use them to fake a signature.

No he couldn't-- the comment betrays a misunderstanding of how Bitcoin and open source development works.  "Lead dev" is not a position of authority, and if he wanted to push in a direction the contributors didn't agree with, he'd find himself where he is now, regardless of what happened there...

A "merkle tree" is what you need to cryptographically harden a tree. The words "merkle tree" do not say much about the particular tree construction being used.

Most efficient for what?  For simply showing membership, which is all it's used for in Bitcoin, it's very hard to even match a plain binary tree (we do not use a trie) with anything else.

For doing other things, many other kinds of data structure have been proposed at various times.

Perhaps you were looking for the ethereum blog? Please don't waste our time here by asking about random semi-relevant collections of technical terms. ("Hey guys, have you considered using a post-quatum NoSQL skip-list?!? I hear it has webscale!")

You still must have the block commit to the signature, or otherwise the signatures use in the network can be changed. (e.g. I could go add 200 GB to the size of the chain I give you by adding a megabyte of padding to the signatures in the first 200k blocks).  You also need all transaction relay to be changed to be in terms of a new ID which is the hash of the whole transaction, not the txid. (Otherwise I can take a transaction, corrupt the signature, and relay it to everyone fast to block the real transaction from the network.)

And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha).  But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).

Exactly, thats why we were unable to go forward with the original segwit design that we used in elements alpha: It's nearly impossible to deploy. The improved design is just simply better and a big part of that-- though far from all of it-- is that it's actually deployable.

On two geographically separated nodes.


2016-04-29 12:17:38.592289 got inv: tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  new peer=47
2016-04-29 12:17:38.592342 askfor tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  0 (00:00:00) peer=47
2016-04-29 12:17:38.741549 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a from peer=47 was not accepted: mempool min fee not met, 0 < 306 (code 66)


2016-04-29 12:17:38.692177 got inv: tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  new peer=8180
2016-04-29 12:17:38.692226 askfor tx 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a  0 (00:00:00) peer=8180
2016-04-29 12:17:38.887028 566f0c015a25adf9a29452b29ae7959013b53cc9091566026b14e35ea30ecf8a from peer=8180 was not accepted: mempool min fee not met, 0 < 326 (code 66)

(Timestamps are UTC)

Because the fee was so low it was instantly dropped-- the Bitcoin Core 0.13 CPFP wouldn't have helped.

If you modify or delete the file you may lose the settings in it.. thats it.

You can increase the keypool at any time. Additional keys will be added the next time you unlock it if it's encrypted.

This was not the case. My node had the transaction for over three minutes before the block. It also heard from of the transaction from more than two dozen peers before the block, If you have logging turned up enough to see it-- you'll see you did too.

Not irrelevant, the 'carryless multiply' is useful for characteristic-2 ECC, which only crazy people would use.

There are also some newer "regular" instructions that might be useful for speedups (mulcx, adcx, adox): http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-large-integer-arithmetic-paper.pdf

Yes, these are somewhat useful... but are only in very new processors. E.g. I just got broadwell-ep chips that support ADCX a couple weeks ago (release april 1st). But they don't let us do things efficiently with SIMD, they just would likely make the existing approach somewhat faster if we use them.

You lose the 64,64->128 widening multiplies. The net result appears to be a loss of performance.

If someone was able to get the field arithmetic to operate usefully in parallel there wouldn't be a need to perform multiple verification at once to get performance gains; fwiw.

But actually getting it to be faster while losing the wide multiplies appears to be elusive. Even in the AVX-512 integer stuff I do not see a quadword multiply.

Yes it does. A 'smart contract' that never interacts with anything outside the network (including users) is pointless. The smart contract itself may not set the history rewrite, but the possibility of them must be accounted for in the design of the contract.

Writing smart contracts is inherently not 'natural' software development similar to how writing legal contracts are not 'natural' prose. The requirements and implications are quite different.

The kinds of data the software works with is different. The resource costs are radically different. The execution environment is necessarily very different-- how often do you write ordinary programs whos execution gets rolled back in a reorg or could "run out of gas"? The implications of failure are typical fairly different. The interactions with privacy are very different than ordinary software development.

Often the "simply written" smart contracts are grievously insecure-- I guess you could say that they're not that smart.

There can be cases for wanting to use legacy software in a smart contract context, for interoperability or rapid prototyping-- but the ethereum model isn't particular good for that either (it imposes enormous overheads on software compiled from traditional languages).

Effectively, when you create a de novo smart contract you are designing a cryptographic protocol. It turns out that it's fiendishly hard to do this, even for experts, and the science of creating good tools for it is yet unsolved. (Though it's one of the long term problem areas that I'm funding people to work on.)

I think the Bitcoin technical community has some good starting premises about what kinds of constructs facilitate making tools that make it more feasible to construct new smart contracts with less than super-human effort-- things like having top level building blocks that work like monotone boolean functions, so that you can safely compose standardized parts without understanding the internals and your software can reliably analyze the space of possible outcomes.