bitcoinclassic / bitcoinclassic

Bitcoin Classic integration/staging tree

Bitcoin Classic integration/staging tree

https://bitcoinclassic.com

What is Bitcoin?

Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network.

For more information, as well as an immediately useable, binary version of the Bitcoin Classic software, see https://bitcoinclassic.com.

License

Bitcoin Classic is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The classic team uses two branches, a stable and an develop branch (called master). The stable is one that has only tested code on it and this is where releases are made from. The 'master' branch is used for actual development and that branch should be used with caution.

The contribution workflow is described in CONTRIBUTING.md.

Community

• Primary Website: https://bitcoinclassic.com/
• Reddit: https://www.reddit.com/r/Bitcoin_Classic/
• GitHub: https://github.com/bitcoinclassic/

bitcoinclassic's Issues

configure: error: libprotobuf not found - installing on OSx

After running ./configure --with-gui=qt5 I am getting the following error.

configure: error: libprotobuf not found

Any ideas?

Potential Deadlock?

While debugging #97 I noticed this in gdb:

bitcoin-qt: sync.cpp:112: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const LockStack&): Assertion `onlyMaybeDeadlock' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffa67fc700 (LWP 10780)]
0x00007ffff312f067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Any idea if this is relevant? It makes debugging for the crash harder, at least.

Commit 6cebccd (v0.12)

Setup TeamCity as CI / Build Server

This is a task list for setting up TeamCity.

Docs and scripts are added to the following branch (WIP): https://github.com/keo/bitcoin/tree/setup-buildserver

• Install Ubuntu Trusty
• Install Postgresql
• Setup postgresql
• Install TeamCity
• Install apt-cacher-ng Mirrors look like fast enough
• Configure TeamCity memory usage
• Setup sharing of artifacts & caching
• Build Config for PRs (no gitian, build with cached dependencies, run tests)
• Build Config for Gitian base VM
• Build Config for nightlies (gitian full build from scratch, run tests, pgp sign artifacts)
• Report build results to GitHub
• Slack notification?
• Match TeamCity username with GitHub usernames
• Run multiple agents in LXC containers
• Server security checkup / lockdown
• TeamCity security checkup / lockdown
• Setup domain and SSL
• Docs: finish missing parts in contrib/ci-scripts/README.md so anyone can setup their own server and agents
• Setup regular backup of TeamCity config so we can kickstart a new server in less than a day in case of a disaster
• Dashboard (outside of TeamCity) with recent build logs
• Setup personal builds for devs?

Release -win.zip big and redundant content

It is ~116MB and has -win(32|64)-setup-unsigned.exe and -win-usigned.tar.gz that in turn seem to contain the same .exe files.

The -win(32|64).zip files should be published separately to make it easy for people to use it as a drop in replacement for core files without running the setup, or if anyone wants to run them as "portable"

bitcoin-qt shuts down after resuming PC from suspend

I run bitcoin-qt v0.11.2.cl1 on Debian Stable x86_64. Before I used a recent Bitcoin XT version without any issue.

I often suspend my computer (with bitcoin-qt running), and resume it the next day. After resuming I see a few regular log lines (shown below), but after that bitcoin stops working (crashes?). Restarting the application (as soon as I notice it is gone) works without any issue.

Could it be that Bitcoin does not like the jumps in time caused by suspend+resume?

2016-02-16 22:42:32 receive version message: /bitcoinseeder:0.01/: version 60000, blocks=230000, us=77.177.XXX.YYY:8333, peer=163
2016-02-16 22:42:50 ERROR: AcceptToMemoryPool: free transaction rejected by rate limiter
2016-02-17 19:13:32 socket receive timeout: 73823s
2016-02-17 19:13:32 socket receive timeout: 73823s
2016-02-17 19:13:32 socket receive timeout: 73823s
2016-02-17 19:13:32 socket sending timeout: 73823s
2016-02-17 19:13:32 socket receive timeout: 73823s
2016-02-17 19:13:32 socket sending timeout: 73823s
2016-02-17 19:13:32 socket receive timeout: 73827s
2016-02-17 19:13:32 socket receive timeout: 73828s
2016-02-17 19:13:32 socket receive timeout: 73868s
2016-02-17 19:13:32 socket receive timeout: 73928s
2016-02-17 19:13:32 socket receive timeout: 73823s
2016-02-17 19:13:32 socket receive timeout: 73856s
2016-02-17 19:13:32 socket sending timeout: 73823s
2016-02-17 19:13:32 socket receive timeout: 73829s
2016-02-17 19:13:32 socket sending timeout: 73823s
2016-02-17 19:13:35 connect() to 137.226.34.42:8333 failed after select(): Connection refused (111)
2016-02-17 19:13:35 connect() to 84.247.131.56:8333 failed after select(): Connection refused (111)
2016-02-17 19:13:36 UPnP Port Mapping successful.
2016-02-17 19:13:41 receive version message: /Satoshi:0.10.2/: version 70002, blocks=398881, us=89.12.78.79:42924, peer=164
2016-02-17 19:13:41 Added time data, samples 37, offset +13 (+0 minutes)
2016-02-17 19:13:41 nTimeOffset = +12  (+0 minutes)
2016-02-17 19:13:42 connect() to 95.114.120.194:8333 failed after select(): No route to host (113)
2016-02-17 19:13:42 connect() to 84.46.21.171:8333 failed after select(): No route to host (113)
2016-02-17 19:13:48 UpdateTip: new best=00000000000000000163676cd3203a698366b09b936cd5ccacae916815c60852  height=398760  log2_work=84.127005  tx=110530018  date=2016-02-16 23:02:33 progress=0.999380  cache=0.5MiB(0tx)
2016-02-17 19:13:49 connect() to 174.25.90.235:8333 failed after select(): Connection refused (111)

OSX: "make deploy" doesn't work

I have successfully compiled bitcoind/-cli from source on OSX, but I am have having problems compiling the qt client, as well as making the install disk image. In short, the make procedure listed below does not make the bitcoin-qt client (which is usually in src/qt), and when I type make deploy (which used to work fine before), I get the following errors

% make deploy
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src qt/bitcoin-qt
  OBJCXXLD qt/bitcoin-qt
clang: warning: argument unused during compilation: '-pie'
Undefined symbols for architecture x86_64:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [qt/bitcoin-qt] Error 1
make: *** [src/qt/bitcoin-qt] Error 2

For info, here is I how I compiled everything: I really wish that the devs would include this info in the osx_build docs! I have never been able to get bitcoin to compile using brew!

./autogen.sh
cd depends/
./config.guess
make HOST=x86_64-apple-darwin15.4.0
cd ..
./configure --prefix=`pwd`/depends/x86_64-apple-darwin15.4.0
make HOST=x86_64-apple-darwin15.4.0
make deploy

Restore password solution

Many users do not have acccess to their bitcoins because they have forgotten their password,it would be a good idea to have a option forgot password that will remind us the password ?

README.md needs updating to remove references to Bitcoin Core

README.md needs updating to remove references to Bitcoin Core

Add Satoshi Nakamoto's white paper to doc directory

Andreas made a good case here bitcoin#7443 for adding the original white paper to the repo. Thoughts?

README.md Suggested Updates

Here is a first crack at updating README.md, wanted to keep it in my own fork until I got some feedback...

https://github.com/ChainQuery/bitcoinclassic/blob/Readme-Update/README.md

Leave opt-in RBF code in, but disabled by default

Related #4

Httplib.badstatusline

http://www.multichain.com/qa/751/bitcoinrpc-python-wrapper-returns-httplib-badstatusline

I'm seeing this same issue in classic 0.12.1

Detect / support chainstate obfuscation

Apply backport bitcoin#7259 from core. Without this, users who are moving from core 0.12 to classic will get a failure on launch. A reindex fixes it, but that is not obvious to the user.

new block download does sometimes stall in v0.12?

I can't produce a real test case, but I experienced this a few times now during the last days, running v0.12 classic from this git repo.
I have a datacenter internet connection and about 25 peers connected. Enough disk space and 10GB of RAM, about 40% of it free. Normally blocks show up in the printconsole log shortly before/after being visible on blockchain.info.

Block 399886 was mined at about 23:08 UTC.
It simply doesn't show up in the bitcoind console log of my node. (It got my attention because my p2pool node starts complaining thoroughly about block-stale shares.)
After some minutes of waiting I do a "getpeerinfo" and the "synced_headers" entry of some peers already show this block.
It then takes a full 20 minutes, until first a "Timeout downloading block from peer, disconnecting" occurs and immediately afterwards the new block shows up.

Can anybody confirm/dismiss this problem? I'm a bit lost providing a more solid bug report for this, sorry.

Full printconsole log of my incident: http://pastebin.com/bfRY9e7q

"getpeerinfo" around 23:20 UTC does show the peer in question as:
{
"id": 722,
"addr": "45.59.67.242:48842",
"services": "0000000000000001",
"relaytxes": false,
"lastsend": 1456355777,
"lastrecv": 1456355778,
"bytessent": 5956,
"bytesrecv": 3964,
"conntime": 1456350375,
"timeoffset": -67218,
"pingtime": 0.125517,
"minping": 0.125333,
"version": 70002,
"subver": "/Satoshi:0.11.2/",
"inbound": true,
"startingheight": 398961,
"banscore": 0,
"synced_headers": 399886,
"synced_blocks": 399885,
"inflight": [
],
"whitelisted": false
},

Why not added support Thinblock?

With all the advantages of this technology, I do not understand why it is still not supported in Bitcoin Classic.

Compile Warning

main.cpp: In function 'bool FindBlockPos(CValidationState&, CDiskBlockPos&, unsigned int, unsigned int, uint64_t, bool)': main.cpp:2707:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (nFile != nLastBlockFile) {

CreateNewBlock doesn't check sighash or new sigops in 0.12

CreateNewBlock still needs some work in the 0.12 branch to enforce the sighash limit and the properly-counted sigops limit. It's probably impossible to violate the sighash limit without specially-crafted attack transactions that bypass AcceptToMemoryPool (i.e. submitted by RPC), but it should still be checked for. The current code only tests for that in the TestBlockValidity check at the end; if that is violated, then the node will crash entirely, which isn't exactly graceful.

The approach to this that makes the most sense to me is to add two new properties to the CTxMempoolEntry class for bytes hashed and for true sigops, and use those precomputed values during CreateNewBlock to make sure that they are not exceeded by a transaction. This approach requires that every code path by which a transaction can enter the mempool be modified in order to ensure that bytes hashed and true sigops are computed, which is a task that I began but did not finish.

I started those changes here: jtoomim@6759614

This version includes significant differences written by jtoomim
compared to the commit made for 0.11.2 by Gavin due to the massive
changes made to CreateNewBlock in Core 0.12. Since transactions are
no longer validated inside CreateNewBlock in 0.12, the bytes hashed
and sigops for each transaction cannot be calculated inside
CreateNewBlock. Instead, they must be precomputed and stored inside
the CTxMempoolEntry object. This commit is a partial implementation of
that process. It records the sigops and sighash when transactions enter
the mempool through AcceptToMemoryPool. However, it does not yet
do so for transactions that enter via reorgs or via the wallet.

In addition, the changes made in this code breaks the
miner_tests.cpp stuff, since that code expects an exception to
be raised, but this code will simply refuse to include transactions
that would exceed the sigops/sighash limit. This behavior is okay,
but it does mean that the unit tests need to be rewritten to
check for whether the naughty transaction was included in the block
or not.

The relevant changes are in AcceptToMemoryPool (main.cpp), CreateNewBlock (miner.cpp), and everything in txmempool.h and txmempool.cpp.

This code was based on a slightly different 0.12 branch than the one that is currently in Classic's repository, since I did most of this work before there was a 0.12 branch in Classic's repo. It might not merge well.

make deploy does not work on OSX

I've successfully compiled the unix binaries from the master branch on OSX, however, I was not able to compile the OSX application via make deploy. I previously had no problems doing this either with core or XT

make deploy
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src qt/bitcoin-qt
  OBJCXXLD qt/bitcoin-qt
Undefined symbols for architecture x86_64:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [qt/bitcoin-qt] Error 1
make: *** [src/qt/bitcoin-qt] Error 2

Change Alert Keys

Wont be changed in first release.
May be changed in future releases.

What is the threshold for deployment?

Previous BIPs for bitcoin had Supermajority at 95% XT introduced 75% + short grace period. Such a low threshold opens up a 51% style attack where a lucky streak could occur... i.e. BC is running 40% of hash rate but clear 750 blocks... The BC chain would activate with only 40% on board essentially splitting the network 60/40 with Bitcoin Classic on the lower %

Fix our Continuous Integration

I edited the Readme.md file and got:

https://travis-ci.org/bitcoinclassic/bitcoinclassic/builds/103527281

Rebase on Bitcoin Core 0.12.0

Hi!

Bitcoin Core 0.12.0 is out: https://github.com/bitcoin/bitcoin/tree/0.12

It could be nice to benefit from the new improvements.

How hard is it to rebase Classic work on it?

I'm no C++ developer, but I can give it a try today if no one else is working on it.

Splash screen copyright reads 2009-2015 Core Developers

Remove libsecp from validation.

Bitcoin Core recently added dangerous home-brew cryptographic code developed by BlockStream to the heart of the Bitcoin protocol without any public consensus. This change has been highly controversial because the claimed performance is not possible without dangerous, speculative, and unreviewed algorithms which may contain serious flaws or intentional back-doors.

The claimed performance increase is both dubious and unimportant. Using the standard cryptographic software that 0.11 used even low performing hardware can handle blocks of hundreds of megabytes in size, so there is no need to switch off of widely reviewed software which has been used by millions of people for years except to entrench BlockStream control of the Bitcoin protocol.

Concept for block scaling ( principal + extension )

Suppose a max block size of 100MB.
Miner solves a block and propagates 2MB( the principal ) plus an extension of 98MB in the sequence. The 2MB one is always sent first.

Nodes start the block (principal+extension) validating process, by then the principal is already fully known and possibly at least the extension's header is also already known by receiving the extension's first bytes. No need to wait the full extension for the block to be known. No hypothetical increased risks due to the block size?

Is something like this possible?

Segregated Witness as hard fork

SegWit got deleted from bitcoin classic #8.
Is anyone already working on SegWit as a hard fork?
Since we are forking hard anyway why not integrate it now?

Windows x64 Executable Installer Creates Firewall Rules That Block Inbound TCP/UDP

Build ARMv7 binaries

I'm running half a dozen Classic nodes on Raspberry Pi 2 Model B single-board computers, I wrote a small guide detailing the process of setting one up[1]. Currently the most tedious part of the process for a user wishing to bring up a node on a Pi is the compilation which takes a few hours. It would be great to have official binaries, since running binaries supplied by a third party is not ideal.

With official binaries we could provide users a simple bash script that turns a Pi into a full node in less than a minute.

[1] https://jz.bz/tar.jz/bitcoin-node/

DEFAULT_BLOCK_MAX_SIZE

This is still set to 750kB in Classic, despite the problems. Should Classic also consider raising it to 1MB?

Enable the IRC gateway on the slack interface

Slack is a closed-source third-party, unfortunately trusted commercial platform on which nearly all of the actually important collaborative communication is happening for Bitcoin Classic.

Slack requires either a continuously-open browser window, or running a third-party untrusted GUI application to run unless the IRC gateway is enabled.

There is a much smaller, individually-auditable security surface for a text-only IRC interface. It is therefore for some individuals who are capable of doing this, more secure to use IRC to participate in the Slack community in general, and in Bitcoin Classic in particular.

Transparency in development is absolutely crucial to the success of a project like Bitcoin. Increasing possible access methods increases transparency and reduces the barrier to participation for people who want to continue using IRC for other ahem projects.

Please enable the IRC gateway for the important channels in the Slack interface.

Cannot un-minimize from the Cinnamon system tray

I am on Linux Mint 17.3 64-bit, using your bitcoin-0.11.2-linux64.tar.gz.
After minimizing bitcoin-qt to the system tray, the appearing icon does not react on any mouse clicks to make the bitcoin-qt window reappear.

0.11.2.cl1.b2 build problem (boost) on Debian 7

I was trying to build using the sources released in bitcoinclassic-0.11.2.cl1.b2.tar.gz on a Debian 7 (Wheezy) 64 bit system.

I use a slightly non-standard configuration to do my builds, which has so far worked for Core, XT, Unlimited etc. I don't think it matters, it's just because I have compiled BDB myself. My configure command looks like:

./configure --prefix=/home/ftrader --with-gui=qt4 --with-pic --disable-shared --enable-cxx LDFLAGS=-L/usr/local/BerkeleyDB.4.8/lib/ CPPFLAGS=-I/usr/local/BerkeleyDB.4.8/include/

On to the actual problem:

When I run 'make', it fails with:

CXX bitcoind-bitcoind.o
In file included from bitcoind.cpp:9:0:
main.h:38:28: fatal error: boost/atomic.hpp: No such file or directory
#include <boost/atomic.hpp>
^
compilation terminated.

I suspect my Debian 7 Boost version (1.49) is too old.
The build-unix.md only mentions to install libboost-all-dev without specifying a minimum version, and the configure process did not flag my Boost as inadequate.

does not work when trying to mine with bfgminer

when trying to mine on bitcoin classic with bfgminer, i get the following error:

blktmpl error: Unrecognized block version, and not allowed to reduce or force it

and it never connects to the node via gbt.

I have worked around this by putting ckpool as standalone proxy mode in between.

Also, this is more likely something that needs to be changed in bfgminer or libblkmaker depending if classic HAS to advertise a new block version. Alternatively, luke-jr provided the following input on bitcointalk.org official bfgminer thread:

If it isn't Classic-specific (ie, generalised), doesn't affect libblkmaker itself, and doesn't degrade Bitcoin support in any way.

But a more practical way would be to have Classic's bitcoind simply set sizelimit to 2 MB and use the version/force mutation in BIP 23.
I think that would result in something that actually works with unmodified BFGMiner/libblkmaker.

full discussion here: https://bitcointalk.org/index.php?topic=877081.msg13758739#msg13758739

License and Attribution

What is the plan for attribution regarding places where it currently says "Bitcoin Core Developers"?

• is there going to be a new group name like "Bitcoin Classic Developers" which is appended to the source files giving 3 author attributions (Satoshi, Core, and the new group)
• What should the About dialog display? Right now it says "Bitcoin Core Developers"

Another user started a reddit post about this topic.

ERROR: Read: Failed to open file banlist.dat

Issue appears to have been introduced between v0.11.2 and v0.12.0rc1 and is still present in v0.12.0.

2016-03-08 10:11:57 ERROR: Read: Failed to open file /home/bitcoin/.bitcoin/banlist.dat
2016-03-08 10:11:57 Invalid or missing banlist.dat; recreating

The file is not created, and the error reoccurs on next restart. Installation on this server was fresh, and the .bitcoin directory has the correct owner and permissions.

Issue appears to be in this code snippet. The code for this is different in the master branch. Assuming nothing else has changed with how this is initialized, it seems that the following needs to be changed.

if (!bandb.Read(banmap))
    LogPrintf("Invalid or missing banlist.dat; recreating\n");

to

if (!bandb.Read(banmap)) {
    LogPrintf("Invalid or missing banlist.dat; recreating\n");
    CNode::SetBannedSetDirty(true); // force write
    DumpBanlist();
}

copyright headers to Bitcoin classic

Change copyright headers to // Copyright (c) year-year The Bitcoin Classic developers,

Warning: This version is obsolete; upgrade required!

I guess a new release (merge with Core?) is necessary.

Bitcoin Classic warning after resuming from suspend (S3)

I'm using Bitcoin Classic v0.12.0cl1 on Linux and when I wake up the system from S3 (suspend), Bitcoin Classic gives me the warning:

WARNING: check your network connection, 0 blocks received in the last 4 hours (24 expected)

But the blocks are downloaded without problems and the warning remains displayed.

Ps: with Bitcoin Core it doesn't happen.

Remove or change Core download link

problem

i used bitcoin classic
a guy moved me money to my bitcoin and i dont see it
https://blockchain.info/address/1C5HF53wBkuG38BGnY56HjQUDd9uPfgd5w

Lets do it Wright, it's time to stand with Satoshi

Dr. Craig Wright, previously known as to our community as "Satoshi" has returned to set things right and put Bitcoin back on the path of his original vision. Gavin has confirmed the identity beyond doubt.

It is time for us to stand behind Wright and the Original Vision. He should be appointed head of classic governance and ownership of the github. This will distinguish classic from the Core Cowards and help get the Bitcoin price back on track.

Commandline parsing fails to produce errors

Almost all professional software on unix uses a similar user interface when it comes to the commandline.

All of the executables that bitcoinclassic ships, however, do their own thing. This works Ok for most cases, but many of the common user errors are not detected and will not be reported. Causing the usability of the software to be lower.

Specifically;

• when a user passes in an argument that doesn't exist, no warning is give. For instance if a user types '-deamon' instead of '-daemon', the argument is ignored and nothing is reported to the user.
• required arguments are not required.
  for instance when you use the argument -rpcuser=<user> and you pass in --rpcuser without any arguments, no complaints are generated.

I suggest checking for command line parsing libraries like getopt.

Policy option to autoblock/ban peers that aren't relaying the blockchain, and mask user agent until peer is trusted.

I've noticed my node has many peers which aren't actually nodes and consume connection slots.

Many node operators have no interest in subsidizing blockchain hosting for peers that don't return the favor.

Additionally, such peers tend to have no direct value as they tend to not relay transactions.

Sometimes peers are malicious crawlers (as in the recent Classic DDoS scripts), or just actors indexing nodes for their own private gain without returning anything to the network.

IMO we should have the option to "raise the bar" with respect to these peers.

Here are some possible policy settings:

Policy 1: If a peer is not white-listed and doesn't advertise NETWORK, it is disconnected immediately

Policy 1a: If a peer is advertises NETWORK and is not white-listed, request $NUMBER random known block headers, if any of these fail the peer is disconnected immediately, if this succeeds the peer is white-listed for $POLICY time.

Policy 1b: If a peer is advertises NETWORK and is not white-listed, request a random known block, if this fails the peer is disconnected immediately. If a peer succeeds the peer is white-listed for $POLICY time.

Policy 2: If a transaction is sent, and a peer does not request it or store it in its mempool, disconnect the peer immediately. After the peer requests the transaction, periodically request the transaction from the peer to confirm it is relaying the transaction until the transaction is confirmed. If the peer evicts the transaction and is not re-requesting the transaction when re-advertised, disconnect the peer as it is providing no value.

Policy 3: If a peer is not white-listed, reply with the same user-agent as the peer. Once the peer is white-listed, upon re-connect verack responds with the "true" user-agent; alternately a newer verack2 message might be appropriate to disclose the user agent.
*Note: implementation details are just ideas on this one, but the intent is to not reveal the user-agent until the peer is trusted"

Control network usage

There had been some discussion of implementing bandwidth throttling in the past (bitcoin#273). This might encourage more individuals to run a full node if they can easily project their maximum bandwidth consumption.

I am also curious to hear any thoughts on whether rate limiting would have any impact in the case of a DDoS attack on a node. Late last year while running Bitcoin XT one of my nodes downloaded 300+ GB of data in a night while not uploading more than it would under normal load, it was not a big deal but I imagine users on slower connections with monthly caps would not be happy.

Decide on & document the governance model for this repo

The community needs to understand how decisions are made in Bitcoin Classic.

The owners & developers of this repository should agree on a decision making / governance model.

Add SweepDust RPC Call

Add a command which:

• Gets the top dust inputs and 1 non-dust input
• Combines them together into a tx
• Sends them to the specified address
• Reduces number of UTXO's in an easy to use fashion

lookahead priority for chainTXs

details: https://www.reddit.com/r/btc/comments/4h1rmd/23k_transaction_stuck_despite_paying_the/d2ncsxk

tl;dr if a transaction depends on another transaction, its priority should go to that transaction.

Debian packages

I'd love to have a Debian package, possibly with a repository for (security) updates. I liked the Bitcoin XT approach very much.

What are the rules for protocol changes?

Are they the same as Core? I.e.:

Where a patch set proposes to change the Bitcoin consensus, it must have been discussed extensively on the mailing list and IRC, be accompanied by a widely discussed BIP and have a generally widely perceived technical consensus of being a worthwhile change based on the judgement of the maintainers.

And will Classic adopt (or has it already decided to use) a rough consensus model for protocol changes?

And if so, where are protocol changes discussed? (Core uses a mailing list but I can't find one for Classic.)

Official Amazon AWS AMI + Docker images

I believe @jgarzik had floated the possibility[1] that there could be official AMI images produced. This, along with an official Docker image would be a great way of lowering the barrier for setting up a full node. Especially if the blockchain is bootstrapped so each new instance that gets spun up is not required to sync from scratch.

[1] https://twitter.com/jgarzik/status/688355566478032897