|
SlipperySlope (OP)
|
 |
May 21, 2014, 06:39:07 PM |
|
A comment from the bitcoin-development email list . . .
I'm doing a hard fork, too. In my version 78% of the wealth will go to me, which I will redistribute on based on personal preferences. Come and join me into a new and obviously superior system.
More seriously though: the paper is not bad, but I can guarantee you that Bitcoin will never change that drastically. That's the whole point. It has an indestructible kernel (think DNA). Rather it will do a slow death, probably in 5-10 years. If you care for PoS than just launch your own.
The bitcoin core code only has perhaps 30% of Satoshi's code remaining. It can change. The proposed system takes pains to preserve as much as the Satoshi Social Contract as possible. That is what users see. For them nothing much should change, and what does change should be much better. Full nodes are the foundation of Satoshi's Bitcoin. My proposal pays for upgrades so that they may process all the world's transactions. The response was . . . Bitcoin is not a democracy. It's a micro-government, but where those with the hashing-power are for ever the rulers of Bitcointopia. There is no necessity to preserve the existing wealth. If the system is superior it will earn it of the market. And so we have a market of competing currencies. The incentives are high enough for people to make a better invention. Starting from scratch in software is often a good thing. |
|
|
|
|
bitcoinbeliever
Newbie
 Offline
Activity: 54
Merit: 0
|
|
May 22, 2014, 12:20:37 AM |
|
Enterprise-class would be a major downgrade from bitcoin's current class. Bitcoin is AT LEAST solar-system-class.
|
|
|
|
|
|
SlipperySlope (OP)
|
|
May 22, 2014, 02:43:34 AM |
|
Enterprise-class would be a major downgrade from bitcoin's current class. Bitcoin is AT LEAST solar-system-class.
If we are going to drive Visa and bank wire transfers out of business, then our network needs to be better than theirs. It cannot depend on part-time laptops and ADSL connections. It can be supplemented by those sort of home computers, but the network needs to be non-stop, redundant, and robust in case of power failure and Internet connection outages. Enterprise class servers and networks are a solved problem. All it takes is money. Each day block creation rewards total about $1.6 million. There is plenty of money to give Bitcoin the hardware it deserves and to pay people around the world to run full nodes - if and when CPoS replaces PoW. |
|
|
|
|
bitcoinbeliever
Newbie
Offline
Activity: 54
Merit: 0
|
|
May 22, 2014, 02:57:20 AM |
|
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. |
|
|
|
|
|
SlipperySlope (OP)
|
|
May 22, 2014, 03:04:14 AM |
|
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? |
|
|
|
|
bitcoinbeliever
Newbie
Offline
Activity: 54
Merit: 0
|
|
May 22, 2014, 03:51:07 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 (OP)
|
|
May 22, 2014, 05:52:51 PM
Last edit: May 22, 2014, 06:09:50 PM by SlipperySlope |
|
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. |
|
|
|
|
|
SlipperySlope (OP)
|
|
May 22, 2014, 06:06:10 PM |
|
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 (OP)
|
|
May 23, 2014, 03:27:07 PM |
|
GitHub notes . . . Bitcoin GitHub repository ========================= $ git clone git@github.com:StephenLReed/bitcoin.git
$ cd bitcoin
Synchronizing the my bitcoin branch with the origin bitcoin repository https://help.github.com/articles/syncing-a-fork# initialize my local bitcoin branch repository
$ git clone git@github.com: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 git@github.com:StephenLReed/bitcoin.git (fetch)
origin git@github.com:StephenLReed/bitcoin.git (push)
# add the upstream remote repository
$ git remote add upstream https://github.com/bitcoin/bitcoin.git
# verify the current remotes
origin git@github.com:StephenLReed/bitcoin.git (fetch)
origin git@github.com: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/bitcoin_ca@valencia.ts | 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/bitcoin_uz@Cyrl.ts | 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 git@github.com:StephenLReed/bitcoin.git
4765b8c..97b53b5 master -> master
To make a change to the bitcoin repository . . . How to create a PULL request$ git checkout -b niftynewfeature # Create a feature branch
... edit, test, re-edit, re-test...
$ git commit -a
$ git push git@github.com: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 . |
|
|
|
|
|
bybitcoin
|
|
May 23, 2014, 07:50:10 PM
Last edit: May 24, 2014, 06:10:45 PM by bybitcoin |
|
Your idea-work becomes more and more interesting everyday... watching this thread closely!
|
|
|
|
|
|
SlipperySlope (OP)
|
|
May 25, 2014, 04:45:21 AM |
|
I presented my whitepaper today and engaged contributors to the Bitshares project on the Beyond Bitcoin podcast . . . https://bitsharestalk.org/index.php?topic=4713.0I 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. |
|
|
|
|
rpietila
Donator
Legendary
Offline
Activity: 1722
Merit: 1036
|
|
May 25, 2014, 07:58:41 AM |
|
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. |
HIM TVA Dragon, AOK-GM, Emperor of the Earth, Creator of the World, King of Crypto Kingdom, Lord of Malla, AOD-GEN, SA-GEN5, Ministry of Plenty (Join NOW!), Professor of Economics and Theology, Ph.D, AM, Chairman, Treasurer, Founder, CEO, 3*MG-2, 82*OHK, NKP, WTF, FFF, etc(x3)
|
|
|
|
SlipperySlope (OP)
|
|
May 25, 2014, 08:51:46 AM |
|
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. |
|
|
|
|
|
delulo
|
|
May 25, 2014, 10:48:18 AM
Last edit: May 25, 2014, 11:00:02 AM by delulo |
|
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! |
|
|
|
|
bitbadgerPoS
Newbie
Offline
Activity: 7
Merit: 0
|
|
May 26, 2014, 05:12:48 AM |
|
Hi, I have come up with what I believe to be at least a partial solution to the PoS problem: https://bitcointalk.org/index.php?topic=553414.msg6025343#msg6025343The 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. |
|
|
|
|
|
SlipperySlope (OP)
|
|
May 26, 2014, 08:00:33 AM |
|
Hi, I have come up with what I believe to be at least a partial solution to the PoS problem: https://bitcointalk.org/index.php?topic=553414.msg6025343#msg6025343The 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. |
|
|
|
|
rpietila
Donator
Legendary
Offline
Activity: 1722
Merit: 1036
|
|
May 26, 2014, 12:18:44 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. |
HIM TVA Dragon, AOK-GM, Emperor of the Earth, Creator of the World, King of Crypto Kingdom, Lord of Malla, AOD-GEN, SA-GEN5, Ministry of Plenty (Join NOW!), Professor of Economics and Theology, Ph.D, AM, Chairman, Treasurer, Founder, CEO, 3*MG-2, 82*OHK, NKP, WTF, FFF, etc(x3)
|
|
|
|
Brangdon
|
|
May 26, 2014, 01:23:12 PM |
|
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? |
Bitcoin: 1BrangfWu2YGJ8W6xNM7u66K4YNj2mie3t Nxt: NXT-XZQ9-GRW7-7STD-ES4DB
|
|
|
jaekwon
Member
Offline
Activity: 70
Merit: 10
|
|
May 27, 2014, 09: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 |
|
|
|
|
|
SlipperySlope (OP)
|
|
May 27, 2014, 12:38:47 PM |
|
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.pdfI 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 |
|
|
|
|
|
