As the comments in this PR have been locked, I'd like to move the discussion here.

Apparently I present a "misunderstanding of the Bitcoin system"

Well, please help me to understand it, then.

I would like the supporters of this change to answer my question:

Who, how and why defines (and guards) the consensus rules?

Can you try to give me a "technical" answer?
(as opposed to a "political" answer)

What I have seen by monitoring the network is that 0.14.x software has been (so far) the fastest to relay blocks.
Which is understandable as it relays blocks before verifying it.

What is not understandable for me, though...
Why pre 0.13.0 software is faster in relaying transactions?

I know 0.12 got secp256k1, but 0.13 and 0.14 also had it...
So why is 0.12.x faster in relaying txs than any version that came later?

It is actually even more weird: it seems that even 0.10.x and 0.11.x are quicker in relying transactions than 0.13+
And these still used openssl for EC operations.

It's not an issue, but I find in intriguing and would like to understand the reason.

When I draw a chart for each block that presents a fee (in SPB), in relation to how far the tx was placed inside the block, it almost always looks somehow like this:



What I mean is that the chart in general goes form the highest SPB to the lowest one. - which is understandable.
But what is strange for me is that it isn't smooth.
There are spikes - in some places inside the block you have a tx whose fee is "too high" for that place, but that is sort of compensated by a tx placed next to it whose fee is to low to end up there.

So what is the reason for placing the txs like this?

Is it because of the Child Pays for Parent feature, or is it something else?

Sorry, I know I can figure it out by reading the code, but hope that someone can just help me here.
I mean, by referring me to the specific code that is responsible for this behaviour.

Not sure if it is on any interest for anyone here, but I remember once, when a BU node mined an invalid block, people were shitting themselves all over the internet.

Well, not sure that kind of software 1hash pool uses, but they have just mined their second invalid block.

It's easy to find them these days, because nodes relay them before fully verifying.

The first invalid block they mined was #474294, with hash 00000000000000000182acdf5657c93a0769dc6f9004047496b2e15efc6a4232
The second one, just a few hours ago #477115, with hash 0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b

You can download both of them from here:
http://gocoin.pl/1hash/474294-00000000000000000182acdf5657c93a0769dc6f9004047496b2e15efc6a4232.bin
http://gocoin.pl/1hash/477115-0000000000000000013ee4a86822d37a061732e04ee5f41fb77168f193363d1b.bin

I haven't checked yet why exactly they are invalid, but I think the order of the transactions inside the block is screwed up.
They use an input from a tx that is only created later in the block.

I'm thinking they must be using come customised mining software which (sometimes) assembles the block incorrectly.
So I thought I'd let them know, before they mine the third broken block, still without anyone noticing

A number of nodes ran from the amazon cloud (all representing themselves as "UASF/SegWit/BIP148/whatever") are wrongly reporting connecting node's IP, putting own in it's place.

I imagine there is a purpose in doing that.

Whoever does it, I just want him to know that he might suffer from some serious issues and maybe it isn't too late yet to consult a doctor.

Below some example IPs.

Code:

34.203.31.60 from /Satoshi:0.14.1(UASF-SegWit-BIP148)/
34.203.31.60 from /Satoshi:0.14.0(UASF-SegWit-BIP148)/
52.60.155.242 from /Satoshi:0.14.1(BIP8; UASF-SegWit-BIP149; UASF-SegWit-BIP148)/
54.194.206.222 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
35.154.110.140 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
34.209.234.16 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
54.250.162.133 from /Satoshi:0.14.1(UASF-SegWit-BIP148)/
54.171.65.204 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/
54.93.250.167 from /Satoshi:0.14.1/UASF-Segwit:0.3(BIP148)/

What does network protocol version 70015 indicate, as comparing to previous 70014?

Can you please refer me to a BIP number or something.

["In the name of Wu, this post shall not pass."]

I remember Gavin Andresen saying that the serious bitcoin development debate is at the mailing list now, because the bitcointalk.org forum turned into something he didn't like anymore.

Personally I like bitcointalk forum. It was started by Satoshi himself and there is practically zero censorship here, even if you say to the mod that he's an idiot.
It's definitely my favourite bitcoin forum.

Anyway, I sometimes read the mailing list. Now they have this thread there, about the user activated soft fork:
http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg04774.html
 
USAF against the miners majority - for anyone who knows about how bitcoin works, it's obviously a crazy idea.
But it's ok - kids should also have their time to speak and feel important, I really don't mind.
Except that the kids seem to be establishing some kind of cartel, where they don't want to listen to the adults anymore...

So here is the story from today.
This topic I mentioned before, there was this man saying:

Code:

There isn't a flag day to set. If the major economic organs like exchanges run
the BIP, non-signalling miners simply wont get paid (starting October 1st) and
their blocks will be rejected. Miners will have the choice to signal, or find
something else profitable to mine. In turn, this will trigger the existing
segwit deployment for everyone who has already upgraded to segwit compatible
node software (currently Bitcoin Core 0.13.1, 0.13.2, 0.14.0, Bitcoin Knots
0.13.1+, and bcoin) regardless of whether they run this BIP or not.

But yes, it goes without saying that this BIP would need to have buy-in from
major economic organs, especially fiat egress points, before being deployed.
Failing that, a second deployment of segwit with a flag day, or preferably
using the bip-uaversionbits-strong BIP9/flagday hybrid would be required.

So then I tried to answer:

Code:

You're insane, man.

If miners had to 'find something else profitable to mine', they'd just start mining
double spends depositing BTC to the exchanges that are trying to fuck them up.

There is absolutely no way the UASF can work.
Exchanges would be insane to even raise their support for it.
Stop wasting your time, for your own sake.

Few minutes later I got the message from the mailing list:

Code:

Your request to the bitcoin-dev mailing list

    Posting of your message titled "Re: [bitcoin-dev] Flag day activation of segwit"

has been rejected by the list moderator.  The moderator gave the following reason for rejecting your request:

"[No reason given]"

Any questions or comments should be directed to the list administrator at:

    bitcoin-dev-owner@lists.linuxfoundation.org

OK... maybe he didn't like me swearing... lets try again with a more kids friendly syntax:

Code:

I think you don't realize what you are talking about.

If miners had to 'find something else profitable to mine', they'd just start mining
double spends depositing BTC to the exchanges that are trying to remove them from the business.

There is absolutely no way the UASF can work against the miners majority.

... few minutes later:

Code:

Your request to the bitcoin-dev mailing list

    Posting of your message titled "Re: [bitcoin-dev] Flag day activation of segwit"

has been rejected by the list moderator.  The moderator gave the following reason for rejecting your request:

"In the name of Wu, this post shall not pass."

In case you missed it: "In the name of Wu, this post shall not pass."

Which brings me to the question:

Who moderates bitcoin-dev mailing list?
Why are the actual serious developers using this mailing list?
What is so special about it and who do I have to fuck to get my messages through?

Recently I see more and more nodes, introducing themselves as "/Satoshi:0.13.1/" but sending me sendcmpct message that is only 5 bytes long.

Can anyone say if they are legitimate bitcoin core nodes, or just some other stuff pretending to be the latest release of core?

What shall I do with sendcmpct message that carry only 5 bytes of data?

Some example logs below

Code:

42314 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42314 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42453 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42453 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42454 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42454 46.101.99.121:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42698 138.68.66.47:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42698 138.68.66.47:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42866 139.59.209.199:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42866 139.59.209.199:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
42923 46.101.109.46:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
42923 46.101.109.46:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43048 139.59.157.246:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43048 139.59.157.246:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43513 138.68.64.28:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43513 138.68.64.28:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43788 46.101.228.246:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43788 46.101.228.246:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
43997 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
43997 139.59.208.241:8333 /Satoshi:0.13.1/ sendcmpct 0001000000
44088 188.166.161.228:8333 /Satoshi:0.13.1/ sendcmpct 0002000000
44088 188.166.161.228:8333 /Satoshi:0.13.1/ sendcmpct 0001000000

It's probably a known problem, so maybe someone could give me a hint before I start digging into the problem, trying to reinvent the wheel.

My client has no support for SegWit (yet).
When it parses new testnet blocks (ones that spend segwit outputs), it takes ages to process them...

Does anyone know what is going on?

[hash_serialized]

Recently I've read somewhere that the way hash_serialized gets calculated has changed, but I just want to ask about the last version (not yet released):

How exactly is it calculated?
Specifically, can someone please confirm that I need to have the utxo records sorted, in order to calculate it.
How are they sorted?

Also, are there any plans to make this hash more open and verifiable, for a purpose of setting up fresh nodes with a snapshots of an UTXO database?
I'd imagine setting up a node with a snapshot of the coinstate db, without the need to build it up from the blockchain.
That'd save shit loads of time, bandwidth and disk space.

As I learned only recently one of the steps in a new block's verification is counting a total number of sigops inside the block - if it'd exceed 20000, such block supposed ot be rejected.

So I've implemented this in my own software, but cannot find any reliable reference to make sure that I'm counting these numbers properly.

Does anyone know any block explorer that would show number of sigops in each block?

Or if not, can anyone confirm whether I've counted these numbers properly:

Code:

Block#  Block Hash                                                            Sigops
403908 0000000000000000067549f6a6a4590405161bd6773166cd00518f121e6961b5 5600
403907 0000000000000000019955303142ecd05a374a0657945b8b2d1b89fd10cb9f17 2635
403906 0000000000000000060d52b13b0cd892dbf986177c8f2d7fe3f652e9574fce04 4527
403905 0000000000000000026031da9dc81b633bf3c566ddfc85bef72216a33c2166ec 1516
403904 000000000000000004f2b65476bcf0b72d9846283b87b488dd6be0c5c8423d39 930
403903 000000000000000001ee250b7132b41ed068ab443465b1d2954350c2e034b93a 1170
403902 000000000000000004a983db2a27e573b2aa2501a904440a8a7a00058eabdbb9 1708
403901 000000000000000002f5b6d90cff1f4083271f5dfc607c72cc99b80355de01d3 723
403900 000000000000000001e5e0c849184c832968f220456731820107acde3c91ed6a 5709
403899 000000000000000001bf70c02bc4bc1c962e808d411b0a3a627a0acdabb7d4ba 3311
403898 00000000000000000388e1db2b93eb338a48eec7f5c554e7f25c5a260c164ffb 3733
403897 0000000000000000017bf7996829ac5939d24e5c23c50b14d5cc94e131a1d43a 4603
403896 000000000000000006670bd2ec8902308ac712eca9421538b631471b6b18e110 7197
403895 0000000000000000024767f99ac1028162b728debebde0864b5aa3d932855c69 8951
403894 000000000000000002b6b8f7de6485c5829622306197af41aa338f59b56d38eb 3049
403893 000000000000000000520b20ac8dfc6388e8afa071d55e8e8f338645cf3db7a3 2380
403892 000000000000000001f3b14dcbc09dfce73c77890f82f935dc5e90b9cea1f69a 1809
403891 000000000000000000c52f273c7382616fbc72ae9cd080bb4a2b52d8deb70d2f 2791
403890 0000000000000000022bb622accabc0b8739adafa425ed4a605b0164c5d81b7d 3029
403889 00000000000000000313a13e433822d39c9f7226bff7230f3d92e971faf1f46c 4483
403888 000000000000000004a4388ca15be3d5a49ef66960972e3baf9a9ed27a27ff20 5372
403887 000000000000000003dc28c943e06f97809194b0d5460d58267c92152c03fc70 5728
403886 00000000000000000453bf07533a0a66bb164571759d5cd289b1bea250be758d 6282
403885 000000000000000006675fdbd01884e44bb8a4c4636209709ee768d9990c3609 1094
403884 000000000000000003e477a5f58893daa99578a1dd87014661d7e85df8370ebe 602
403883 0000000000000000037398599c10b434976d5825244f3dfafda8dd851e9313cf 2682
403882 000000000000000002a7161e6ad70e45ca8eaaa97c9821e0edc51612e977119f 6604

No, I don't have one

I was just wondering, because I know the UTXO db is a very important component of the bitcoin system and it is obviously going to be somehow profitable in a future to have it well performing.

How would you imagine a database engine designed specifically for bitcoins UTXO db?

I think it's very important to be able to browse through all the records in a shortest possible time.

It used to be very easy to build it using mingw, but there have been some changes and now I cannot build it anymore.
At least not out of the box, as it requires "autoreconf" command, which my mingw+msys don't have.

Does anyone know an easy way to build the lib on Windows host, using msys/mingw?

It's probably something I'm missing, but I haven't been able to figure out why certain test vectors with MINIMALDATA flag are expected to return FAIL, in the test suite.

I mean, I assume that all the script inside script_invalid.json are a failing ones - aren't they?

Because if so, can someone please explain me why e.g. these ones are supposed to fail:

Code:

["0x01 0x81", "DROP 1", "MINIMALDATA", "-1 minimally represented by OP_1NEGATE"],
["0x01 0x01", "DROP 1", "MINIMALDATA", "1 to 16 minimally represented by OP_1 to OP_16"],
["0x01 0x02", "DROP 1", "MINIMALDATA"],

Code:

["0x4c 0x48 0x111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111", "DROP 1", "MINIMALDATA",
 "PUSHDATA1 of 72 bytes minimally represented by direct push"],

Which specific code triggers these failures?

IMHO, each specific functionality of a node (maybe even each message type), should have its own bit in the services field.
I'm talking about the 64-bit field that currently is always set to 1.

Using the "version" filed to indicate whether a node supports things like "getheaders", "ping", "mempool", "reject" or bloom filters - this is a mistake.
Currently you basically get to choose between version 6000x and 7000x, but the reality is never that simple.

For instance: the node I use does not support bloom filters (probably never will), but it does support things like "getheaders" or "ping".
And I wish my node could be honest about which commands it will reply or act upon, and which it won't, but with the current protocol this is just impossible to be honest about it.
All I can tell you is version 60002, 70001 or 70002 - and none of them will actually be correct.

My point is: if the folks developing the core could get advantage of the services field (which shall not be a hassle), I believe the protocol itself (and thus the network as a whole) would have benefited from it.


EDIT:
Also I'd like to point out that the service field (unlike the version filed) is sent along with IP inside the addr message.
So for instance if you have an SVP client, then you could just ignore all the nodes that are not going to serve the bloom filtering for you and never connect to them.

Fee discovery, the way for you to figure out how much fee you need to pay so your transaction would be mined withing the next N hours - this is going to be a useful thing in a future.
We don't know how far future, but probably we will get to see it.

I heard that they work on something like this in the bitcoin core, but obviously their solution isn't going to work.
Because they don't use the bitcoin community to solve the problem.

I was thinking how to solve it and I think the most efficient way is to ask miners (mining pools) to include their transaction queue statistics into the blocks they mine.
So nodes could figure out how much they have to pay to be mined, just by looking into the headers of past blocks.

I think this is the easiest solution, and putting such info inside the coinbase's payload, makes it totally backward compatible.

BTW, I am really surprised that miners don't yet use the extra space, inside the coinbases, as advertising space.
for all we know its going to last longer than piramids

I'm kind of bored recently and even though I was never very enthusiastic about the stealth addresses, it still seems to be the most exciting feature to add to my wallet software.
I know that there are all kind of mailing lists with less and more outdated specs flying around, but since I don't monitor them, could anyone please update me on the most recent status?

Today I have been playing with DarkWallet a bit and from what I see each wallet there has by default one stealth address assigned to it.
I also figured out what this address represents.
For all I know, there are two public keys - one is to encrypt the message (nonce or whatever it is called), while the other one is there to calculate the actual destination for the coins that are being spent.

So, for instance, I got an address vJmyoyfHgvkW2fRbqpANQircWiWDFMHtzyUxbcGsnUCX6z1jEjfArypDBNMeQdmsczkLVoSwYRZ5pS8 YAxxQY7Q2m8SUXB2sZWjB6q - it decodes to:

Code:

2a - version
00 - options
03b5ca63d7bda5b8f70a68864fafa0587e446c52be23150da2b95ad9d6f3e6f71f - scan_pubkey
01 - number of spend keys
0351bec154c01c4f26794da8b0a3019b163b633ea933387f48288ed35cbc833f53 - spend pubkey 1
01 - number sigs
00 - prefix_length
b3fe7b1a - standard checksum of the address

Now, I want to extend my wallet so it would be able to send coins to such an address.
How do I build the transaction?

Is there any spec that I can read?
Any actually working code that makes a transaction which sends money to such an address?

Coinjoin will be worthless in court.  Your case is not going to prosecution when the sole evidence is a bitcoin transaction.  Instead, that transaction is going to be used as the basis for collecting gobs and gobs of further evidence.  At that point, the coinjoin isn't going to help you in court, it is going to hurt you, since it will be evidence that you knew what you were doing was wrong and tried to bury the evidence.

What???

Aaaa, sorry - I forgot that you guys are form US.
In your courts words like "wrong" or "evil" are the daily bread

Since yesterday there have been like a few txs, committed into the blockchain, which IMO are literally broken.
This broke my client BTW, but I fixed it already, and I know this cannot be reverted anymore, so I only wonder..

From what I understand using SIGHASH_SINGLE that has more outputs than inputs does not make any sense - so the code even prints an error then:

Code:

unsigned int nOut = nIn;                                           
if (nOut >= txTmp.vout.size())                                     
{                                                                   
    printf("ERROR: SignatureHash() : nOut=%d out of range\n", nOut);
    return 1;                                                       
}                                                                   

Normally when there is an error somewhere when executing a script, it just fails - but here, despite of printing the error, it still accepts the transaction, using a hash value of 1 and then verifying the signature for such a hash.

So what is up with it?
Is it like someone just overlooked this piece of code - or is it "error => hash=1" by design?

EDIT:
If you don't know what I am talking about, checks these three txs:

Code:

315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f
dbf38261224ebff0c455c405e2435cfc69adb6b8a42d7b10674d9a4eb0464dca
de744408e4198c0a39310c8106d1830206e8d8a5392bcf715c9b5ec97d784edd

All the time there are like 20KB, but sometimes even 99KB txs that are going across the network - and they are just a spam.

I know it's not an issue, but believe me, that if someone will decide to use it as a DoS attack method and will bother to implement this method, it will quickly become an issue. And how are you going to solve it then - how many days/weeks/months will you need in order to adopt a protocol to this specific threat?

It's quite amazing that after finding recently that node's memory can be attacked by sending him big txs, nobody has even bothered to try thinking of if, instead of just "oh, as long as it's the same size as it is, I'm fine with downloading processing, storing and even routing forward, all this spam".