AI Coin Development Diary - page 11.

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Communication with the BlackCoin Foundation

BlackCoin is the number 8 cryptocurrency when ranked by market capitalization. Today I corresponded with Adam Krykow, from the BlackCoin Foundation.

Quote

Hi Stephen,

I am a member of the BlackCoin Foundation and I had called a week or so ago looking to talk about the article you posted about CPoS. Basically, I am looking to open up some dialogue with you to see if you have any interest in bringing some of your technical expertise to the altcoin realm.

Here at BlackCoin we have been attempting to tackle the mining problem of bitcoin with a fast, decentralized, PoS system but it is quite a difficult process. We are still in the early stages of our development, relying on centralized checkpoints currently, but we have been discussing plans for a multinode network within our system. When we stumbled across your whitepaper, it was like reading a fully developed version of our internal discussions.

I don’t know how far along you are with your current BitCoin startup, but at BlackCoin we can offer you a community of adopters and a real desire to perfect a system very similar (but not identical there are some differences of opinions to be hashed out) to your CPoS.

Thanks for your time and your whitepaper. At the very least I believe we will be citing it frequently as we move forward!

Adam Kryskow
Public Relations Director for the Americas
BlackCoin Foundation
[email protected]
www.blkfoundation.org
www.blackcoin.co

I responded . . .

Quote

Hi Adam,

I am excited about the opportunity to collaborate with your team. Indeed my focus is on Bitcoin, but my plan for 2015 involves demonstrating cooperating proof-of-stake agents with one or more Altcoins, before hard-forking Bitcoin in early 2016. Previously I was informally contacted by a Bytecoin developer who offered to run my code when ready. I have participated in a podcast with Dan Larimer's Delegated Proof-Of-Stake project, and will continue a periodic sharing of ideas.

My design is evolving towards an agent based framework that can support multiple cryptocurrencies. Supposing that altcoins follow the Bitcoin coding convention of deploying an executable similar to bitcoind, then a full node in the CPoS system could operate multiple bitcoind instances, each belonging to a different cryptocurrency. The full node operator would be compensated by each such currency via their respective block creation reward policies. This leads to economies of scale, and significant benefits to lower capitalization altcoins. Message traffic on the CPoS network, e.g. transactions and blocks, would be tagged as to which cryptocurrency they belonged.

See: Bitcoin Cooperating Agent illustration

I completed the CPoS whitepaper in May. I plan to complete the public high level design in June, and enough of the public message workflow specifications to begin open-source coding in July. I have bitcoind compiling in my C++ NetBeans IDE now. The agent message passing architecture will be adapted from a very similar one that I wrote in Java for my now-postponed AI project. My plan is to have significant elements of the CPoS architecture running in the late fall, with public system testing and altcoin deployment scheduled throughout 2015.

My GitHub repository is currently a Bitcoin clone. I periodically synchronize it with the core developer's repository. For CPoS, I will establish a new public repository. The code that talks to the local bitcoind instances, I will adapt from existing core code. The networking code, the tamper-evident logs, and agent framework will be new code. As I mentioned, the agent framework will be a simplified version of Java code that I wrote some years ago. The agents will each extend a C++ class and provide specialized behavior. Each agent will be simply enough for its peers to easily verify. There may therefore be many agents in total to provide all the required behavior. A testing framework will be specified and completed that enables robust regression testing of the agent network.

I look forward to continuing discussion with your group, especially regarding our respective development schedules and what components are needed first.

-Steve

Stephen L. Reed
Austin, Texas, USA
512.791.7860

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Bitcoin Cooperating Agent Design

Here is the first portion of the project specifications . . .

Bitcoin Cooperating Agent Design

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Bitcoin Cooperating Agent

Nothing that the core developers maintain will be touched. The agent code, in this case a Relay Agent, will run the non-generating bitcoind instance. Bitcoind communicates with the reference wallet, bitcoin-qt, and also with the optional command line interface. Simplified Payment Verification wallets communicate with the listening bitcoind.

The notable change is that the bitcoind instance is configured to communicate with other full nodes only via the Relay agent.

-Stephen Reed

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

CPoS Network Proxy

I have been thinking about a way to deploy CPoS in a way that minimally impacts Bitcoin Core, and their pull request regime.

The idea is to have CPoS code execute as a network proxy for bitcoind - the Bitcoin Core program. A paid CPoS full node operator would launch the CPoS program - preferably automatically upon start of the server, The CPoS proxy would configure its bitcoind to have a single peer, namely the collocated proxy. That bitcoind, by default, would have generation turned off. The CPoS proxy would connect to other such proxies forming the super peer network described in my whitepaper. All the agent related code would be implemented in the proxy. The proxy-to-bitcoind communication protocol code would be adapted from bitcoind source code for complete compatibility. The proxy-to-proxy communication protocol would be inspired by FIPA agent-to-agent protocol.

The single nomadic mint would launch bitcoind every 10 minutes, and configure it to generate the new block. After creating the new block, the mint would shut down its bitcoind. Alternatively if the bitcoind RPC (remote procedure call) interface permits sufficiently robust dynamic control of block generation, then that would be preferable.

Bitcoind would verify transactions received from the proxy and build the blockchain replica with new blocks provided by the single nomadic mint agent via the proxy. The full-node's tamper-evident log would be maintained by the proxy. The bitcoind instance would listen on its standard Internet port for SPV nodes, e.g. mobile wallets, and process their requests. For full nodes desiring local Bitcoin-QT wallets, the proxy would launch the wallet after launching bitcoind. The wallet would communicate with bitcoind directly, and not the proxy.

If and when the blockchain hard fork planned for early 2016 succeeds, the proxy code I write can be merged into the bitcoind code for a single program by willing core developers. This possibility constrains me to write the proxy in the language of bitcoind, which is C++ and the Boost library.

-Stephen Reed

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Quote from: jaekwon on May 27, 2014, 04:04:12 AM

Hi SlipperySlope,

You have two links of mine on the original post, but the first (Venetian Bankers Problem) is deprecated in favor of TenderMint.
Also, the TenderMint link is broken due to a trailing slash. The link should be: http://tendermint.com/docs/tendermint_v04.pdf

I removed the Venetian Bankers Problem link and fixed the TenderMint link. Thanks for pointing out my errors.

Its interesting that defenders of Bitcoin proof-of-work believe Satoshi's Bitcoin to be the solution to the Byzantine General's Problem, or more generally the only working solution to achieving concensus in a distributed system.

But the academic field of Byzantine Fault Tolerance does not mention bitcoin with the notable exception of Andrew Miller's paper whose only citation is from me. Even when granted that the bulk of such papers were issued before 2009, Satoshi did not reference any in his defining Bitcoin paper nor stimulate much discussion of BFT algorithms when posting to this forum.

Google Scholar search for Byzantine Fault Tolerance

-Stephen Reed

jaekwon

member

Activity: 70

Merit: 10

Hi SlipperySlope,

You have two links of mine on the original post, but the first (Venetian Bankers Problem) is deprecated in favor of TenderMint.
Also, the TenderMint link is broken due to a trailing slash. The link should be: http://tendermint.com/docs/tendermint_v04.pdf

Brangdon

sr. member

Activity: 365

Merit: 251

Quote from: bitbadgerPoS on May 26, 2014, 12:12:48 AM

This effectively puts an upper limit on the amount of Stake that any one address could reasonably accumulate.

So, you're encouraging people to split their stakes between many addresses? Does that help?

rpietila

donator

Activity: 1722

Merit: 1036

Quote from: SlipperySlope on May 25, 2014, 03:51:46 AM

Quote from: rpietila on May 25, 2014, 02:58:41 AM

Quote from: SlipperySlope on May 24, 2014, 11:45:21 PM

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.

OK. That idea is not going to gain wide acceptance in the Bitcoin community. A proof-of-stake altcoin startup might try paying for order flow.

I suggest that Bitcoin full node owners have an annual convention to tweak the reward allocation policy executed in code by what I call the Reward Agent. I would not change the Satoshi block reward schedule, that cuts the reward in half in the summer of 2016 and again in 2020. But I desire that the reward be rationally spent on facilitating the adoption of Bitcoin via superior infrastructure.

I think "full node owners" is a very flexible entity. Anyone can set up unlimited number of full nodes for voting purposes in the convention, and then scale down after he has voted. This way the outcome of the vote does not necessarily represent the interests of the economic majority of:
a) "actual" full nodes
b) miners
c) bitcoin holders
d) bitcoin users.

I see that the current decision making needs improving, but on the other hand I am very satisfied with the results how we have progressed in this system also (mainly in the relentless rise of BTC price, I mean). This has been possible because the contract is unchangeable, and making it changeable might cause more damage due to the loss in trust, than the changes can make it better.

If things are to be decided by any majority, I believe the only majority that is legitimate is the majority of coin holders, one vote per coin. Everything else represents a power void.

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Quote from: bitbadgerPoS on May 26, 2014, 12:12:48 AM

Hi,

I have come up with what I believe to be at least a partial solution to the PoS problem:

https://bitcointalksearch.org/topic/m.6025343

The gist of it is that everybody's Stake is reduced to 0 on a frequent and random basis. If the node is provably connected to the network at the time that it is randomly called up, it will receive its proportional distribution for its Stake. If it does not prove itself to be connected to the network at such time, its Stake is still reset to 0, but it does not receive any payment. For this reason, I call it Proof-of-Connection.

This effectively puts an upper limit on the amount of Stake that any one address could reasonably accumulate. Presumably, this would prevent against the "if you have enough Stake, you can cheaply re-write history" attack.

Interesting,

In CPoS, I would pay full nodes to upgrade to 24/7 dedicated symmetric business class Internet connections. The full nodes would be expected to be permanently connected and executing the current version of the reference Bitcoin Core software. Their share of the block creation reward, paid daily, would be decreased if not always connected.

The daily bitcoin creation reward is now $2,124,360. I would allocate $30 daily to each full-time full node.

bitbadgerPoS

newbie

Activity: 7

Merit: 0

Hi,

I have come up with what I believe to be at least a partial solution to the PoS problem:

https://bitcointalksearch.org/topic/m.6025343

The gist of it is that everybody's Stake is reduced to 0 on a frequent and random basis. If the node is provably connected to the network at the time that it is randomly called up, it will receive its proportional distribution for its Stake. If it does not prove itself to be connected to the network at such time, its Stake is still reset to 0, but it does not receive any payment. For this reason, I call it Proof-of-Connection.

This effectively puts an upper limit on the amount of Stake that any one address could reasonably accumulate. Presumably, this would prevent against the "if you have enough Stake, you can cheaply re-write history" attack.

delulo

sr. member

Activity: 441

Merit: 250

Quote from: SlipperySlope on May 25, 2014, 03:51:46 AM

Quote from: rpietila on May 25, 2014, 02:58:41 AM

Quote from: SlipperySlope on May 24, 2014, 11:45:21 PM

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.

OK. That idea is not going to gain wide acceptance in the Bitcoin community. A proof-of-stake altcoin startup might try paying for order flow.

I suggest that Bitcoin full node owners have an annual convention to tweak the reward allocation policy executed in code by what I call the Reward Agent. I would not change the Satoshi block reward schedule, that cuts the reward in half in the summer of 2016 and again in 2020. But I desire that the reward be rationally spent on facilitating the adoption of Bitcoin via superior infrastructure.

This is an interesting discussion.
The first thing to realize is that money and company shares are not contradictory. Everything can be money. What you maybe meant was currency vs. company shares, that can not be the same thing.

So, are bitcoins currency units or shares in a company? Whether we decide for one or the other here doesn't make it any different from what is and what is possible to do with it. Currency and company shares are just metaphors/analogies and those words have no truth in itself. But it is more or less appropriate to describe bitcoins in one of those ways. I describe Bitcoin as a "payment network" and bitcoins as the tokens necessary to use it. That is the most neutral description I can make. If I had to decide between currency and company shares I would go with company shares because analogous to a company there can be competition (Bitcoin and altcoins) whereas there by definition can not be competition between currencies within the area that the state that issues the currency controls.

Apart from that I am certain that Stephen's interests lie in the success of Bitcoin not matter how it is categorized. It is a great proposal!

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Quote from: rpietila on May 25, 2014, 02:58:41 AM

Quote from: SlipperySlope on May 24, 2014, 11:45:21 PM

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.

OK. That idea is not going to gain wide acceptance in the Bitcoin community. A proof-of-stake altcoin startup might try paying for order flow.

I suggest that Bitcoin full node owners have an annual convention to tweak the reward allocation policy executed in code by what I call the Reward Agent. I would not change the Satoshi block reward schedule, that cuts the reward in half in the summer of 2016 and again in 2020. But I desire that the reward be rationally spent on facilitating the adoption of Bitcoin via superior infrastructure.

rpietila

donator

Activity: 1722

Merit: 1036

Quote from: SlipperySlope on May 24, 2014, 11:45:21 PM

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

Who gets to make these decisions? This sounds more and more like a startup willing to corner marketshare than a monetary system...

Shares are not money.

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

I presented my whitepaper today and engaged contributors to the Bitshares project on the Beyond Bitcoin podcast . . .

https://bitsharestalk.org/index.php?topic=4713.0

I was invited back for a more technical discussion after I have a chance to re-study Dan Larimer's Delegated Proof-of-Stake (DPOS)

I introduced a new thought that is not in the whitepaper and that is that the block creation reward, in addition to funding infrastructure and developers, could also subsidize transactions to the extent of negative transaction fees, should the abuse problem be addressed. Imaging paying Amazon or any other global Internet retailer a week's worth of block creation rewards, i.e. $13 million to get them to accept bitcoins as payment. I call this notion paying for order flow.

bybitcoin

hero member

Activity: 672

Merit: 500

Your idea-work becomes more and more interesting everyday... watching this thread closely!

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

GitHub notes . . .

Bitcoin GitHub repository
=========================

Code:

$ git clone [email protected]:StephenLReed/bitcoin.git
$ cd bitcoin

Synchronizing the my bitcoin branch with the origin bitcoin repository
https://help.github.com/articles/syncing-a-fork

Code:

# initialize my local bitcoin branch repository
$ git clone [email protected]:StephenLReed/bitcoin.git
Cloning into 'bitcoin'...
Warning: Permanently added the RSA host key for IP address '192.30.252.130' to the list of known hosts.
remote: Counting objects: 36043, done.
remote: Compressing objects: 100% (9795/9795), done.
remote: Total 36043 (delta 26003), reused 36043 (delta 26003)
Receiving objects: 100% (36043/36043), 28.65 MiB | 611.00 KiB/s, done.
Resolving deltas: 100% (26003/26003), done.
Checking connectivity... done

$ cd bitcoin

# list the current remotes
$ git remote -v 
origin	[email protected]:StephenLReed/bitcoin.git (fetch)
origin	[email protected]:StephenLReed/bitcoin.git (push)

# add the upstream remote repository
$ git remote add upstream https://github.com/bitcoin/bitcoin.git

# verify the current remotes
origin	[email protected]:StephenLReed/bitcoin.git (fetch)
origin	[email protected]:StephenLReed/bitcoin.git (push)
upstream	https://github.com/bitcoin/bitcoin.git (fetch)
upstream	https://github.com/bitcoin/bitcoin.git (push)

# Grab the upstream remote's branches
$ git fetch upstream
remote: Counting objects: 1142, done.
remote: Compressing objects: 100% (587/587), done.
remote: Total 1142 (delta 758), reused 805 (delta 553)
Receiving objects: 100% (1142/1142), 2.70 MiB | 569.00 KiB/s, done.
Resolving deltas: 100% (758/758), done.
From https://github.com/bitcoin/bitcoin
 * [new branch]      0.6.2      -> upstream/0.6.2
 * [new branch]      0.6.3      -> upstream/0.6.3
 * [new branch]      0.7.2      -> upstream/0.7.2
 * [new branch]      0.8.1      -> upstream/0.8.1
 * [new branch]      0.8.3      -> upstream/0.8.3
 * [new branch]      0.8.4      -> upstream/0.8.4
 * [new branch]      0.8.5      -> upstream/0.8.5
 * [new branch]      0.8.6      -> upstream/0.8.6
 * [new branch]      0.9.0      -> upstream/0.9.0
 * [new branch]      0.9.1      -> upstream/0.9.1
 * [new branch]      0.9.2      -> upstream/0.9.2
 * [new branch]      blockheaders -> upstream/blockheaders
 * [new branch]      freenode-verf -> upstream/freenode-verf
 * [new branch]      master     -> upstream/master

# List all local and remote-tracking branches
git branch -va
* master                         4765b8c Merge pull request #4087
  remotes/origin/0.6.2           40fd689 Bump version to 0.6.2.2 for osx-special build
  remotes/origin/0.6.3           6e0c5e3 Revert "Update gitian descriptors to point at stable git repo"
  remotes/origin/0.7.2           32a928e Use github for final 0.7.2 release
  remotes/origin/0.8.1           34d62a8 Set version numbers for 0.8.1 release
  remotes/origin/0.8.3           40809ae Bump version numbers for 0.8.3 release
  remotes/origin/0.8.4           839c7d1 Update the bloom state on the real object, not the temporary one.
  remotes/origin/0.8.5           ef14a26 Bump version numbers for 0.8.5 release
  remotes/origin/0.8.6           03a7d67 Release notes for 0.8.6
  remotes/origin/0.9.0           92d25e4 build: fix explicit --disable-qt-dbus
  remotes/origin/0.9.1           026a939 gitian: Version bump for Qt dependency
  remotes/origin/HEAD            -> origin/master
  remotes/origin/blockheaders    b24aa4a Saving work...
  remotes/origin/freenode-verf   7612e72 FreeNode verification
  remotes/origin/master          4765b8c Merge pull request #4087
  remotes/upstream/0.6.2         40fd689 Bump version to 0.6.2.2 for osx-special build
  remotes/upstream/0.6.3         6e0c5e3 Revert "Update gitian descriptors to point at stable git repo"
  remotes/upstream/0.7.2         32a928e Use github for final 0.7.2 release
  remotes/upstream/0.8.1         34d62a8 Set version numbers for 0.8.1 release
  remotes/upstream/0.8.3         40809ae Bump version numbers for 0.8.3 release
  remotes/upstream/0.8.4         839c7d1 Update the bloom state on the real object, not the temporary one.
  remotes/upstream/0.8.5         ef14a26 Bump version numbers for 0.8.5 release
  remotes/upstream/0.8.6         03a7d67 Release notes for 0.8.6
  remotes/upstream/0.9.0         92d25e4 build: fix explicit --disable-qt-dbus
  remotes/upstream/0.9.1         026a939 gitian: Version bump for Qt dependency
  remotes/upstream/0.9.2         2585310 Add missing LOCK(cs_main)
  remotes/upstream/blockheaders  b24aa4a Saving work...
  remotes/upstream/freenode-verf 7612e72 FreeNode verification
  remotes/upstream/master        97b53b5 Merge pull request #4152

# Check out our local master branch
$ git checkout master
Already on 'master'

# Merge upstream's master into our own
$ git merge upstream/master
Updating 4765b8c..97b53b5
Fast-forward
 .tx/config                                        |    7 +
 Makefile.am                                       |    4 +-
 configure.ac                                      |   47 +-
 contrib/debian/bitcoin-qt.install                 |    2 +-
 contrib/debian/bitcoind.install                   |    3 +-
 contrib/debian/changelog                          |   13 +
 contrib/debian/control                            |    8 +-
 contrib/debian/manpages/bitcoin.conf.5            |    3 -
 contrib/debian/rules                              |   21 +-
 contrib/devtools/README.md                        |   40 +-
 contrib/devtools/symbol-check.py                  |  113 +++
 contrib/devtools/update-translations.py           |   66 ++
 contrib/gitian-descriptors/gitian-linux.yml       |   22 +-
 contrib/gitian-descriptors/gitian-osx-bitcoin.yml |   65 ++
 contrib/gitian-descriptors/gitian-osx-depends.yml |  160 ++++
 contrib/gitian-descriptors/gitian-osx-native.yml  |  179 ++++
 contrib/gitian-descriptors/gitian-osx-qt.yml      |  192 ++++
 contrib/gitian-descriptors/qt-linux.yml           |  263 +++++
 contrib/macdeploy/macdeployqtplus                 |    4 +-
 doc/README_osx.txt                                |   71 ++
 doc/bootstrap.md                                  |    7 +-
 doc/build-unix.md                                 |   43 +-
 doc/release-process.md                            |   54 +-
 doc/translation_process.md                        |   29 +-
 qa/pull-tester/pull-tester.sh                     |    3 +
 qa/rpc-tests/README.md                            |   29 +-
 qa/rpc-tests/netutil.py                           |  134 +++
 qa/rpc-tests/rpcbind_test.py                      |  152 +++
 qa/rpc-tests/util.py                              |   32 +-
 share/genbuild.sh                                 |    2 +-
 share/qt/Info.plist.in                            |    6 +-
 src/Makefile.am                                   |    2 +-
 src/Makefile.include                              |   12 +-
 src/base58.cpp                                    |  183 ++++
 src/base58.h                                      |  259 +----
 src/bignum.h                                      |  595 ------------
 src/bitcoin-cli.cpp                               |    2 +
 src/bitcoind.cpp                                  |    9 +-
 src/chainparams.cpp                               |    6 +-
 src/chainparams.h                                 |    5 +-
 src/compat.h                                      |   10 +-
 src/core.cpp                                      |    4 +-
 src/init.cpp                                      |   26 +-
 src/json/json_spirit_reader_template.h            |   12 +-
 src/json/json_spirit_value.h                      |   32 +-
 src/key.cpp                                       |   72 +-
 src/key.h                                         |    3 +
 src/keystore.cpp                                  |    3 +
 src/leveldb/Makefile                              |   11 +-
 src/leveldb/db/filename.cc                        |    9 +-
 src/leveldb/db/log_reader.cc                      |   23 +-
 src/leveldb/db/log_test.cc                        |   40 +-
 src/leveldb/db/repair.cc                          |    1 -
 src/leveldb/db/version_set.cc                     |   14 -
 src/leveldb/include/leveldb/c.h                   |    1 -
 src/leveldb/include/leveldb/db.h                  |    2 +-
 src/leveldb/include/leveldb/slice.h               |    2 +-
 src/m4/ax_boost_base.m4                           |    5 +-
 src/main.cpp                                      |  453 +++++----
 src/main.h                                        |   51 +-
 src/miner.cpp                                     |   15 +-
 src/net.cpp                                       |   67 +-
 src/net.h                                         |    8 +
 src/netbase.cpp                                   |  198 +++-
 src/netbase.h                                     |   36 +-
 src/protocol.h                                    |    1 +
 src/qt/Makefile.am                                |   11 +-
 src/qt/bitcoin.cpp                                |   24 +-
 src/qt/bitcoin.qrc                                |    1 +
 src/qt/bitcoingui.cpp                             |   17 +-
 src/qt/bitcoingui.h                               |    2 +-
 src/qt/bitcoinstrings.cpp                         |    1 +
 src/qt/clientmodel.cpp                            |   14 +-
 src/qt/clientmodel.h                              |    5 +-
 src/qt/forms/optionsdialog.ui                     |   24 +
 src/qt/forms/rpcconsole.ui                        |   33 +-
 src/qt/locale/bitcoin_ach.ts                      | 1053 ++++----------------
 src/qt/locale/bitcoin_af_ZA.ts                    | 1055 ++++-----------------
 src/qt/locale/bitcoin_ar.ts                       | 1492 ++++++++---------------------
 src/qt/locale/bitcoin_be_BY.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_bg.ts                       | 1271 ++++++-------------------
 src/qt/locale/bitcoin_bs.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_ca.ts                       | 1053 ++++----------------
 src/qt/locale/[email protected]              | 1096 +++++----------------
 src/qt/locale/bitcoin_ca_ES.ts                    | 1059 ++++-----------------
 src/qt/locale/bitcoin_cmn.ts                      | 1096 +++++----------------
 src/qt/locale/bitcoin_cs.ts                       | 1509 ++++++++---------------------
 src/qt/locale/bitcoin_cy.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_da.ts                       | 1175 +++++------------------
 src/qt/locale/bitcoin_de.ts                       | 1200 +++++------------------
 src/qt/locale/bitcoin_el_GR.ts                    | 1101 ++++-----------------
 src/qt/locale/bitcoin_en.ts                       |  123 ++-
 src/qt/locale/bitcoin_eo.ts                       | 1061 ++++-----------------
 src/qt/locale/bitcoin_es.ts                       | 1082 ++++-----------------
 src/qt/locale/bitcoin_es_CL.ts                    | 1108 +++++-----------------
 src/qt/locale/bitcoin_es_DO.ts                    | 1030 +++-----------------
 src/qt/locale/bitcoin_es_MX.ts                    | 1055 ++++-----------------
 src/qt/locale/bitcoin_es_UY.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_et.ts                       | 1057 ++++-----------------
 src/qt/locale/bitcoin_eu_ES.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_fa.ts                       | 1065 ++++-----------------
 src/qt/locale/bitcoin_fa_IR.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_fi.ts                       | 1713 ++++++++++-----------------------
 src/qt/locale/bitcoin_fr.ts                       | 1069 ++++-----------------
 src/qt/locale/bitcoin_fr_CA.ts                    | 1099 ++++-----------------
 src/qt/locale/bitcoin_gl.ts                       | 1120 +++++-----------------
 src/qt/locale/bitcoin_gu_IN.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_he.ts                       | 1096 ++++-----------------
 src/qt/locale/bitcoin_hi_IN.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_hr.ts                       | 1063 ++++-----------------
 src/qt/locale/bitcoin_hu.ts                       | 1067 ++++-----------------
 src/qt/locale/bitcoin_id_ID.ts                    | 1795 +++++++++++------------------------
 src/qt/locale/bitcoin_it.ts                       | 1468 ++++++++--------------------
 src/qt/locale/bitcoin_ja.ts                       | 1263 ++++++------------------
 src/qt/locale/bitcoin_ka.ts                       | 1122 +++++-----------------
 src/qt/locale/bitcoin_kk_KZ.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_ko_KR.ts                    | 1145 +++++-----------------
 src/qt/locale/bitcoin_ky.ts                       | 1100 +++++----------------
 src/qt/locale/bitcoin_la.ts                       | 1059 ++++-----------------
 src/qt/locale/bitcoin_lt.ts                       | 1061 ++++-----------------
 src/qt/locale/bitcoin_lv_LV.ts                    | 1718 ++++++++++-----------------------
 src/qt/locale/bitcoin_mn.ts                       | 3375 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/qt/locale/bitcoin_ms_MY.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_nb.ts                       | 1034 +++-----------------
 src/qt/locale/bitcoin_nl.ts                       | 1216 ++++++------------------
 src/qt/locale/bitcoin_pam.ts                      | 1053 ++++----------------
 src/qt/locale/bitcoin_pl.ts                       | 1042 +++-----------------
 src/qt/locale/bitcoin_pt_BR.ts                    | 1143 +++++-----------------
 src/qt/locale/bitcoin_pt_PT.ts                    | 1564 ++++++++----------------------
 src/qt/locale/bitcoin_ro_RO.ts                    | 1032 +++-----------------
 src/qt/locale/bitcoin_ru.ts                       | 1077 ++++-----------------
 src/qt/locale/bitcoin_sah.ts                      | 1096 +++++----------------
 src/qt/locale/bitcoin_sk.ts                       | 1545 +++++++++---------------------
 src/qt/locale/bitcoin_sl_SI.ts                    | 1073 ++++-----------------
 src/qt/locale/bitcoin_sq.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_sr.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_sv.ts                       | 1489 ++++++++---------------------
 src/qt/locale/bitcoin_th_TH.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_tr.ts                       | 1073 ++++-----------------
 src/qt/locale/bitcoin_uk.ts                       | 1061 ++++-----------------
 src/qt/locale/bitcoin_ur_PK.ts                    | 1096 +++++----------------
 src/qt/locale/[email protected]                  | 1096 +++++----------------
 src/qt/locale/bitcoin_vi.ts                       | 1053 ++++----------------
 src/qt/locale/bitcoin_vi_VN.ts                    | 1053 ++++----------------
 src/qt/locale/bitcoin_zh_CN.ts                    | 1073 ++++-----------------
 src/qt/locale/bitcoin_zh_HK.ts                    | 1096 +++++----------------
 src/qt/locale/bitcoin_zh_TW.ts                    | 1180 +++++------------------
 src/qt/optionsdialog.cpp                          |    5 +
 src/qt/optionsmodel.cpp                           |   15 +-
 src/qt/optionsmodel.h                             |    3 +
 src/qt/receivecoinsdialog.cpp                     |   19 +-
 src/qt/receivecoinsdialog.h                       |    8 +-
 src/qt/receiverequestdialog.cpp                   |   25 +-
 src/qt/receiverequestdialog.h                     |    7 +
 src/qt/rpcconsole.cpp                             |    8 +-
 src/qt/rpcconsole.h                               |    2 +-
 src/qt/test/test_main.cpp                         |    1 -
 src/qt/transactiontablemodel.cpp                  |    2 +
 src/qt/transactiontablemodel.h                    |    2 +
 src/qt/transactionview.cpp                        |   35 +
 src/qt/transactionview.h                          |    3 +
 src/qt/winshutdownmonitor.cpp                     |   57 ++
 src/qt/winshutdownmonitor.h                       |   29 +
 src/rpcblockchain.cpp                             |   50 +-
 src/rpcclient.cpp                                 |   52 +-
 src/rpcmining.cpp                                 |   10 +-
 src/rpcmisc.cpp                                   |   17 +-
 src/rpcnet.cpp                                    |   69 +-
 src/rpcprotocol.cpp                               |   12 +-
 src/rpcprotocol.h                                 |   24 +-
 src/rpcrawtransaction.cpp                         |   23 +-
 src/rpcserver.cpp                                 |  192 ++--
 src/rpcserver.h                                   |    6 +
 src/rpcwallet.cpp                                 |   18 +-
 src/script.cpp                                    |   72 +-
 src/script.h                                      |  220 ++++-
 src/test/DoS_tests.cpp                            |    5 +-
 src/test/Makefile.am                              |    3 +-
 src/test/{README => README.md}                    |    4 +-
 src/test/base58_tests.cpp                         |    4 +-
 src/test/bignum.h                                 |  180 ++++
 src/test/bignum_tests.cpp                         |  224 -----
 src/test/canonical_tests.cpp                      |   17 +
 src/test/data/script_invalid.json                 |   29 +
 src/test/data/script_valid.json                   |   89 ++
 src/test/data/tx_invalid.json                     |   63 +-
 src/test/data/tx_valid.json                       |   68 +-
 src/test/netbase_tests.cpp                        |   37 +
 src/test/rpc_tests.cpp                            |   16 +
 src/test/script_tests.cpp                         |    6 +-
 src/test/scriptnum_tests.cpp                      |  196 ++++
 src/test/transaction_tests.cpp                    |   50 +-
 src/test/uint256_tests.cpp                        |  210 +++-
 src/test/util_tests.cpp                           |   49 +-
 src/txdb.cpp                                      |   10 +-
 src/txdb.h                                        |    2 -
 src/uint256.h                                     |  528 +++++------
 src/util.cpp                                      |   99 +-
 src/util.h                                        |   39 +-
 src/wallet.cpp                                    |    6 +-
 src/wallet.h                                      |    2 +
 src/walletdb.cpp                                  |    2 +-
 202 files changed, 23277 insertions(+), 66633 deletions(-)
 create mode 100644 .tx/config
 create mode 100755 contrib/devtools/symbol-check.py
 create mode 100755 contrib/devtools/update-translations.py
 create mode 100644 contrib/gitian-descriptors/gitian-osx-bitcoin.yml
 create mode 100644 contrib/gitian-descriptors/gitian-osx-depends.yml
 create mode 100644 contrib/gitian-descriptors/gitian-osx-native.yml
 create mode 100644 contrib/gitian-descriptors/gitian-osx-qt.yml
 create mode 100644 contrib/gitian-descriptors/qt-linux.yml
 create mode 100644 doc/README_osx.txt
 create mode 100644 qa/rpc-tests/netutil.py
 create mode 100755 qa/rpc-tests/rpcbind_test.py
 delete mode 100644 src/bignum.h
 create mode 100644 src/qt/locale/bitcoin_mn.ts
 create mode 100644 src/qt/winshutdownmonitor.cpp
 create mode 100644 src/qt/winshutdownmonitor.h
 rename src/test/{README => README.md} (87%)
 create mode 100644 src/test/bignum.h
 delete mode 100644 src/test/bignum_tests.cpp
 create mode 100644 src/test/scriptnum_tests.cpp

# push my local bitcoin branch to my branch repository at GitHub
$ git push origin master
Counting objects: 1460, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (361/361), done.
Writing objects: 100% (1065/1065), 2.03 MiB | 112.00 KiB/s, done.
Total 1065 (delta 880), reused 887 (delta 702)
To [email protected]:StephenLReed/bitcoin.git
   4765b8c..97b53b5  master -> master

To make a change to the bitcoin repository . . .
How to create a PULL request

Code:

$ git checkout -b niftynewfeature # Create a feature branch
 ... edit, test, re-edit, re-test...
$ git commit -a
$ git push [email protected]:StephenLReed/bitcoin.git niftynewfeature:niftynewfeature

Gavin: Submit a PULL request by going to your fork's GitHub page, selecting the branch containing the changes you want pulled ("niftynewfeature" in the above example), and then poking the "Pull Request" button. Enter a good description of what your changes do and why they're a good idea and how everybody and their brother is already using them to make the world a better place .

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Today I am working on my first bitcoin pull request. Following Gavin's instructions How to create a PULL request.

I am using the NetBeans C++ IDE on Ubuntu, which is not what most core devs use apparently. They use tools from decades ago, and depend on clear thinking, not the intelligent abilities of modern Integrated Development Environments.

The core devs mostly ignore compiler warnings as long as the code builds and tests OK. NetBeans dynamically parses the code in its editor and warnings are highlighted. I messaged sipa on #bitcoin-dev about some cruft in main.h and he is fixing that. Now I want to fix another warning/bug in main.h myself.

I am using Gavin's procedure for a pull request to fix just one line of code that will not really make any difference at all in how Bitcoin works. My plan for the next few days is to fix all the warnings that are easily fixed in the source code as revealed by NetBeans.

Then I need to get a couple of bitcoind instances running in a single machine testnet.

And I will begin to document how to write the tamper-evident log that is a key component of this project. The core devs have been helpful and have encouraged me, as is right, to explore an idea as an easily revised document, rather than as blind-alley coding.

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Quote from: bitcoinbeliever on May 22, 2014, 10:51:07 AM

Quote from: SlipperySlope on May 21, 2014, 10:04:14 PM

I do not understand the irony.

You are endeavoring to reinvent money. Money is not an enterprise. There is no general name for what it actually is, but as just one of its many functions, it mediates interactions between ALL enterprises. Therefore the solution needs to be far beyond enterprise-class, and far beyond sovereign-class.

Your plan is to explicitly co-opt bitcoin via a blockchain fork, using by your own words, rhetorical as they may be, only a large accumulation of (fiat) money as the tool. You imply that the global cryptocurrency franchise is something that can be bought. That is an uninspired enterprise-level business plan. If it actually worked, you'd better watch out for the next guy's fork. He might have an even bigger pile of fiat.

Have you considered that even fiat money issuers do not go so far as to pay dividends on cash?

As world-class institutions I offer 2 examples. One is the adversarial legal system. Is presuming people innocent of criminal charges the most cost-effective approach? Well, no, but only the adversarial system, where the state must confront and defeat every hare-brained defense, repeatedly ad nauseum, has left society feeling the remotest tinge of justice.

The adversarial system is also what works in nature. In the open ocean, every creature has to ruthlessly protect and defend its genome. There is almost no trust across genomes. And yet, a beautiful, balanced ecosystem emerges.

In this context, I think you underestimate the design of the mining function.

Your project will have its chance in the wild, and I will be disappointed in the universe if you succeed.

Thanks for responding. I need very much to continue listening if there is any hope of achieving the wide approval this project needs to launch in early 2016. I am now downplaying the payment of dividends to those who offer hot-wallet stakes. I think that needs to happen to the extent required to prevent an attacker creating many controlled puppet full nodes and out-voting the correct nodes when a detected inconsistency requires correction. The bitcoin core developers are skeptical yet awaiting "neat technology".

The daily mining reward has risen to $1.8 million. I suggest that a well funded team of say 200 programmers can easily be paid from this sum to out-compete subsequent forks.

The system I am presenting has a one-time opportunity to re-engineer the network, while preserving the Satoshi Social Contract. The reward schedule, the blockchain format, the fixed number of bitcoins, and the decentralized, trustless protocol are untouched. The system remains a global distributed database, with additions to the database by consent of the majority, based on a set of transparent rules they follow.

bitcoinbeliever

newbie

Activity: 54

Merit: 0

Quote from: SlipperySlope on May 21, 2014, 10:04:14 PM

I do not understand the irony.

You are endeavoring to reinvent money. Money is not an enterprise. There is no general name for what it actually is, but as just one of its many functions, it mediates interactions between ALL enterprises. Therefore the solution needs to be far beyond enterprise-class, and far beyond sovereign-class.

Your plan is to explicitly co-opt bitcoin via a blockchain fork, using by your own words, rhetorical as they may be, only a large accumulation of (fiat) money as the tool. You imply that the global cryptocurrency franchise is something that can be bought. That is an uninspired enterprise-level business plan. If it actually worked, you'd better watch out for the next guy's fork. He might have an even bigger pile of fiat.

Have you considered that even fiat money issuers do not go so far as to pay dividends on cash?

As world-class institutions I offer 2 examples. One is the adversarial legal system. Is presuming people innocent of criminal charges the most cost-effective approach? Well, no, but only the adversarial system, where the state must confront and defeat every hare-brained defense, repeatedly ad nauseum, has left society feeling the remotest tinge of justice.

The adversarial system is also what works in nature. In the open ocean, every creature has to ruthlessly protect and defend its genome. There is almost no trust across genomes. And yet, a beautiful, balanced ecosystem emerges.

In this context, I think you underestimate the design of the mining function.

Your project will have its chance in the wild, and I will be disappointed in the universe if you succeed.

SlipperySlope

hero member

Activity: 686

Merit: 501

Stephen Reed

Quote from: bitcoinbeliever on May 21, 2014, 09:57:20 PM

Quote from: SlipperySlope on May 21, 2014, 09:43:34 PM

Enterprise class servers and networks are a solved problem. All it takes is money.

I don't think you quite appreciate the irony of that statement.

Respectfully, I do not understand the irony.

Could you please elaborate on your reasoning that allows an interpretation the opposite of what I perhaps poorly wrote?

Topic: AI Coin Development Diary - page 11. (Read 49308 times)