Segwit details? N + 2*numtxids + numvins > N, segwit uses more space than 2MB HF

[exstasie]

Why you always so angry CIYAM.. ? You were'nt always this way.. way back when..  

I imagine like many others around here, he's getting frustrated at the never-ending campaigns of disinformation used to attack Core devs.

Core devs rock. Period.

But there is a difference between attacking and disagreeing with.

That distinction seems to have been lost somewhere.. and it's an important one.

There is a difference between "honest debate" and "campaigns of disinformation." And it's an important distinction to make. Notice that I said disinformation to suggest the intentional and deliberate nature of the false information being spread. No matter how many times the unproven fear mongering/misinformation [about Segwit/soft fork capabilities, Blockstream control of bitcoin development, the catastrophic implications of "full blocks," the immediate threat of altcoins overtaking bitcoin, etc.] is refuted, there is a distinct group of shills that simply repeat it. Ad nauseum. All over bitcointalk, twitter, reddit. That includes Gavin Andresen and Brian Armstrong (Coinbase employees/executives pushing for shareholder interests).

Perhaps more importantly: I firmly believe that releasing an incompatible/adversarial client that intends to fork the network without consensus--and still call itself "bitcoin"--is an attack on the network. I think deliberately spreading disinformation--and it's become pretty clear to any intelligent person that this is what's happening--is an attack on bitcoin and the developers who maintain it. That's without taking into account the incessant personal attacks and accusations of "blocking development."

We can agree to disagree.

[2112]

It's obvious to anyone with half a brain jstolfi has a deep understanding of Bitcoin, and he is making some valid points. (Plus I like his clear un-emotional posts.. ) 

Deep understanding of Bitcoin? It was disproved few pages ago by knightdk. JorgeStolfi clearly has no elementary comprehension of the source code of Bitcoin.

Yet he continues to post trivialities like:

And, in that case, bitcoin is done for anyway: nothing will save it if malicious miners have a majority of the hashpower.

which was already stated in the original Satoshi's whitepaper. This isn't deep. This is as shallow as it gets.

CIYAM tends to think that JorgeStolfi is some sort of paid disinformation operative. From my personal experiences with peer-review I would venture to guess that he may be heavily medicated or have some sort of amnesia. Such people tend to have good recall of the recent facts and recently acquired knowledge but start to have problems with recall and application of facts and knowledge acquired years ago.

[JorgeStolfi]

The word "standardness" implies that someone is setting a standard that should be followed by all nodes; but it is known that different relay nodes are using different arbitrary criteria to censor transactions and blocks.

Again - a total misunderstanding of the terminology and how Bitcoin works.

If you are seriously at all interested in what Standard and Valid transactions are then you should read the code

I don't plan to read the code, and I should not have to. The payment system of the world cannot be defined by a (messy) program.   Bitcoin should be an implementation-independent protocol, like SMTP and HTML. Anyone with sufficient knowledge of algorithms and networking should be able to understand how it works without reading the code.

And there should not be "the" code, since the maintainers of that code would be a central authority.

Whatever "standard" means, you cannot assume that miners will not create non-standard blocks that are accepted as valid by other miners and clients.  You cannot assume that every miner will run unmodified Core software; and you cannot assume that non-mining relay nodes will do anything specific.

Indeed I have little love for the current Core devs, for a dozen separate reasons.  To stay on the technical ones, they include (1) claim that soft forks are safer than hard forks, (2) the "fee market" and its paraphernalia, (3) SegWit, (4) reliance and encouragement of non-mining relays, (5) modifying bitcoin as if the Lightning Network is a certain thing.  Not me, but some very competent people (who also have read the code) have objectively pointed out the faults in those items; but their criticisms have never been answered.

[CIYAM]

I don't plan to read the code, and I should not have to. The payment system of the world cannot be defined by a (messy) program.   Bitcoin should be an implementation-independent protocol, like SMTP and HTML. Anyone with sufficient knowledge of algorithms and networking should be able to understand how it works without reading the code.

That is something that even Mike Hearn knew is *simply impossible* for Bitcoin (I remember a topic about this from around 3 years ago in which I had actually argued for the creation of such a protocol specification and he convinced me otherwise).

It is fine for something like SMTP to have implementation faults as about the worst thing that might happen is you miss an email - but if you make any implementation fault with Bitcoin then people will lose money.

The C++ code IS the specification and if you refuse to read it then I'm sorry but you are NEVER going to understand Bitcoin (and it isn't up to us to educate you).

There are non-node implementations written in other languages so maybe you might be able to read the code of one of those (am guessing C++ is perhaps too difficult for you) but you need to understand that only "libconsensus" (written in C++) holds the key to Bitcoin (other language implementations are not used for mining but only for wallets).

The very language C++ itself would need to form a part of any such specification (as every single little C++ nuance is relevant) which would make any such document ridiculously large (which is why you are never going to see that).

You could of course take a look at Mastering Bitcoin (which I believe can even be found online).

[amaclin]

Anyone with sufficient knowledge of algorithms and networking should be able to understand how it works without reading the code.
And there should not be "the" code, since the maintainers of that code would be a central authority.

Is there a reason to explain C++ code in any other [human or computer] language?

[Jet Cash]

Have any conclusions about SegWit come out of this thread?

[2112]

Anyone with sufficient knowledge of algorithms and networking should be able to understand how it works without reading the code.
And there should not be "the" code, since the maintainers of that code would be a central authority.

Is there a reason to explain C++ code in any other [human or computer] language?

Of course. Machine verification. It could be even a subset of C++ like SystemC. But the proper definition of consensus-critical portion should be machine-verifiable.

I'm pretty sure that at least gmaxwell understands the importance of that. He's an advocate of zk-SNARKs and those have a synthesis of logic circuit equivalent to the given program as one of the intermediate steps.

The zk-SNARK people in Israel designed and implemented some subset of C (not C++) to facilitate logic synthesis. It is a key step to machine verification of the code.

[amaclin]

Of course. Machine verification. It could be even a subset of C++ like SystemC.
But the proper definition of consensus-critical portion should be machine-verifiable.

It is not possible to create an algorithm for verifying turing-complete structures.

In other words.
Imagine that you have a tool which produces '1' if the realization matches consensus and '0' if the realization is wrong and can produce hard-forks and earthquakes.
Who is responsible for bugs in this tool?   How would you check it? With another tool?

And the second objection.
We do not need to 'stone' the consensus code. The majority always has a right to change anything in consensus.

[2112]

It is not possible to create an algorithm for verifying turing-complete structures.

In other words.
Imagine that you have a tool which produces '1' if the realization matches consensus and '0' if the realization is wrong and can produce hard-forks and earthquakes.
Who is responsible for bugs in this tool?   How would you check it? With another tool?

And the second objection.
We do not need to 'stone' the consensus code. The majority always has a right to change anything in consensus.

From the past experience talking with you I think you are just pretending to be a dumbass. But it is also possible that you don't understand the difference between the old stopping problem and the automated logical equivalency verification like the one used by ARM to verify the implementations of their namesake architectures.

Every CAD/EDA tool vendor has tools to do automated verification and automated test vector generation. The obvious problems are:

1) those tools are closed source
2) those tools are very expensive
3) the input languages are hardware oriented: Verilog & VHDL mostly, with only recent additions of SystemC or similar high-level-synthesis tools.

That isn't even anything new like zk-SNARKs. Those tools were in use and on the market for more than 10 years. I had used some early prototypes of those tools (based on LISP) in school back in 20th century.

[amaclin]

But it is also possible that you don't understand the difference between the old stopping problem
and the automated logical equivalency verification like the one used by ARM to verify the
implementations of their namesake architectures.

Of course, I understand the difference between turing-complete and non-turing-complete structures.

[2112]

Of course, I understand the difference between turing-complete and non-turing-complete structures.

Good. For those unfamiliar with that area of science here are good links to start their research:

https://en.wikipedia.org/wiki/High-level_synthesis
https://en.wikipedia.org/wiki/High-level_verification

[jl777]

But it is also possible that you don't understand the difference between the old stopping problem
and the automated logical equivalency verification like the one used by ARM to verify the
implementations of their namesake architectures.

Of course, I understand the difference between turing-complete and non-turing-complete structures.

is bitcoin turing complete?

[CIYAM]

is bitcoin turing complete?

If you supposedly know anything about Bitcoin then of course you would know the answer to that - wouldn't you?

(btw - are you still using binary floating point for monetary calculations?)

[amaclin]

is bitcoin turing complete?

What do you mean? Bitcoin script language is not turing complete today.
But we are discussing not about scripts themselves, but a program which can validate script-processor and say is it consensus-compatible (equal to current c++ reference code) or not

(btw - are you still using binary floating point for monetary calculations?)

Har du slutat dricka konjak på förmiddagarna?

[jl777]

is uᴉoɔʇᴉq turing complete?

If you supposedly know anything about uᴉoɔʇᴉq then of course you would know the answer to that - wouldn't you?

(btw - are you still using binary floating point for monetary calculations?)

my question was to point out that since bitcoin is not turing complete, amalcin's claim that it is impossible to verify bitcoin due to halting problem was not making sense.

I only use floating point when it is not needing to obtain consensus and where using floating point makes sense to use. I dont dogmatically avoid usage of something all the time just because there are times where it isnt correct to use it.

James

[CIYAM]

my question was to point out that since bitcoin is not turing complete, amalcin's claim that it is impossible to verify bitcoin due to halting problem was not making sense.

Apples and oranges - what @amaclin was referring to was the Bitcoin source code itself (not Bitcoin's scripting language).

[pri3oner]

I can't understand it. anyone can explain it to me

[amaclin]

I can't understand it. anyone can explain it to me

How much are you able to pay for this study? 

[TooDumbForBitcoin]

I can't understand it. anyone can explain it to me

How much are you able to pay for this study? 

Keep in mind that Amaclin values BTC at $10 each.  So if you settle on a $500 fee, he'll want 50 BTC.

[2112]

I am not sure if I understood your comment.  Miners cannot apply old semantics when the transaction has an old version field, because that field can be faked by the clients to sabotage the change.  E.g., suppose that the change imposed a mininum output amount of 0.0001 BTC as a way to reduce spam attacks on the UTXO database.  An attacker could frustrate that measure by issuing transactions with the pre-fork version tag.   Does that answer your comment?

I don't buy the argument about "frustrating that measure". It is very easy to verify that the "old style" transactions use only "old coins", the coins that were confirmed no later than the effective time of the new transaction format.

Theoretically someone could try to launch the attack using only the "old coins", pretending to have a pre-signed transaction with some rather large n-lock-time. I think that type of attack would be self-extinguishing, it could be launched only once for each "old" UTxO entry.