Running A Full Node - Bitcoin

Fun with low fee TXNs on Mainnet

Here's a 0.493 sat/vB TXN I put on mainnet today. You'll have to use the SoChain block explorer to see it though. I give it a 3% chance of getting confirmed, but we'll wait and see. The TXN is a donation to [email protected] since I use their seeder for my network herder.
So last month, I voiced the unpopular opinion that node operators should lower the minrelaytxfee setting to allow low-fee TXNs to propagate more freely throughout the network. Then I asked why miners weren't mining 0.999 sat/vB TXNs during idle periods since it should be more profitable than mining no TXNs at all. Finally I wrote a node herder to walk the network looking for node operators that were running minrelaytxfee below the default (1000 sat). After walking about 26% of the network, turns out about 5% of nodes are allowing low fee TXNs.
So in that vein of discussion, I decided to just sign some low-fee TXNs and send them to the 5% of nodes I found and see what happens. To my surprise it showed up on one of the 23 block explorers I tried after broadcasting it. Surprisingly, that comes out to about 5% of explorers accepting low fee TXNs as well. So hopefully 5% or so of the miners will confirm low fee TXNs. We'll see.
BTW, to do this, this is what I did.
  1. Pair my HW wallet to Electrum
  2. Use the paytomany Electrum API to craft a TXN below 1 sat/vB
  3. Import the TXN to sign in Electrum
  4. Ran a full node with minrelaytxfee set to 1 sat (0.001 sat/vB)
  5. Walked the network to find a good number of low-fee peers
  6. Use bitcoin addnode API to herd my node to the low-fee peers I discovered.
  7. Use bitcoin sendrawtransaction API to broadcast TXN
Wait and see if it can propagate to a miner and if a miner will accept it.
BTW, there is a PR to lower the minrelaytxfee in core, but it's dragged on for years. The setting was lowered about every year or so in the early days, but hasn't been touched for many years now.
submitted by brianddk to Bitcoin [link] [comments]

[ANN][ANDROID MINING][AIRDROP] NewEnglandcoin: Scrypt RandomSpike

New England
New England 6 States Songs: https://www.reddit.com/newengland/comments/er8wxd/new_england_6_states_songs/
NewEnglandcoin
Symbol: NENG
NewEnglandcoin is a clone of Bitcoin using scrypt as a proof-of-work algorithm with enhanced features to protect against 51% attack and decentralize on mining to allow diversified mining rigs across CPUs, GPUs, ASICs and Android phones.
Mining Algorithm: Scrypt with RandomSpike. RandomSpike is 3rd generation of Dynamic Difficulty (DynDiff) algorithm on top of scrypt.
1 minute block targets base difficulty reset: every 1440 blocks subsidy halves in 2.1m blocks (~ 2 to 4 years) 84,000,000,000 total maximum NENG 20000 NENG per block Pre-mine: 1% - reserved for dev fund ICO: None RPCPort: 6376 Port: 6377
NewEnglandcoin has dogecoin like supply at 84 billion maximum NENG. This huge supply insures that NENG is suitable for retail transactions and daily use. The inflation schedule of NengEnglandcoin is actually identical to that of Litecoin. Bitcoin and Litecoin are already proven to be great long term store of value. The Litecoin-like NENG inflation schedule will make NewEnglandcoin ideal for long term investment appreciation as the supply is limited and capped at a fixed number
Bitcoin Fork - Suitable for Home Hobbyists
NewEnglandcoin core wallet continues to maintain version tag of "Satoshi v0.8.7.5" because NewEnglandcoin is very much an exact clone of bitcoin plus some mining feature changes with DynDiff algorithm. NewEnglandcoin is very suitable as lite version of bitcoin for educational purpose on desktop mining, full node running and bitcoin programming using bitcoin-json APIs.
The NewEnglandcoin (NENG) mining algorithm original upgrade ideas were mainly designed for decentralization of mining rigs on scrypt, which is same algo as litecoin/dogecoin. The way it is going now is that NENG is very suitable for bitcoin/litecoin/dogecoin hobbyists who can not , will not spend huge money to run noisy ASIC/GPU mining equipments, but still want to mine NENG at home with quiet simple CPU/GPU or with a cheap ASIC like FutureBit Moonlander 2 USB or Apollo pod on solo mining setup to obtain very decent profitable results. NENG allows bitcoin litecoin hobbyists to experience full node running, solo mining, CPU/GPU/ASIC for a fun experience at home at cheap cost without breaking bank on equipment or electricity.
MIT Free Course - 23 lectures about Bitcoin, Blockchain and Finance (Fall,2018)
https://www.youtube.com/playlist?list=PLUl4u3cNGP63UUkfL0onkxF6MYgVa04Fn
CPU Minable Coin Because of dynamic difficulty algorithm on top of scrypt, NewEnglandcoin is CPU Minable. Users can easily set up full node for mining at Home PC or Mac using our dedicated cheetah software.
Research on the first forked 50 blocks on v1.2.0 core confirmed that ASIC/GPU miners mined 66% of 50 blocks, CPU miners mined the remaining 34%.
NENG v1.4.0 release enabled CPU mining inside android phones.
Youtube Video Tutorial
How to CPU Mine NewEnglandcoin (NENG) in Windows 10 Part 1 https://www.youtube.com/watch?v=sdOoPvAjzlE How to CPU Mine NewEnglandcoin (NENG) in Windows 10 Part 2 https://www.youtube.com/watch?v=nHnRJvJRzZg
How to CPU Mine NewEnglandcoin (NENG) in macOS https://www.youtube.com/watch?v=Zj7NLMeNSOQ
Decentralization and Community Driven NewEnglandcoin is a decentralized coin just like bitcoin. There is no boss on NewEnglandcoin. Nobody nor the dev owns NENG.
We know a coin is worth nothing if there is no backing from community. Therefore, we as dev do not intend to make decision on this coin solely by ourselves. It is our expectation that NewEnglandcoin community will make majority of decisions on direction of this coin from now on. We as dev merely view our-self as coin creater and technical support of this coin while providing NENG a permanent home at ShorelineCrypto Exchange.
Twitter Airdrop
Follow NENG twitter and receive 100,000 NENG on Twitter Airdrop to up to 1000 winners
Graphic Redesign Bounty
Top one award: 90.9 million NENG Top 10 Winners: 500,000 NENG / person Event Timing: March 25, 2019 - Present Event Address: NewEnglandcoin DISCORD at: https://discord.gg/UPeBwgs
Please complete above Twitter Bounty requirement first. Then follow Below Steps to qualify for the Bounty: (1) Required: submit your own designed NENG logo picture in gif, png jpg or any other common graphic file format into DISCORD "bounty-submission" board (2) Optional: submit a second graphic for logo or any other marketing purposes into "bounty-submission" board. (3) Complete below form.
Please limit your submission to no more than two total. Delete any wrongly submitted or undesired graphics in the board. Contact DISCORD u/honglu69#5911 or u/krypton#6139 if you have any issues.
Twitter Airdrop/Graphic Redesign bounty sign up: https://goo.gl/forms/L0vcwmVi8c76cR7m1
Milestones
Roadmap
NENG v1.4.0 Android Mining, randomSpike Evaluation https://github.com/ShorelineCrypto/NewEnglandCoin/releases/download/NENG_2020_Q3_report/NENG_2020_Q3_report.pdf
RandomSpike - NENG core v1.3.0 Hardfork Upgrade Proposal https://github.com/ShorelineCrypto/NewEnglandCoin/releases/download/2020Q1_Report/Scrypt_RandomSpike_NENGv1.3.0_Hardfork_Proposal.pdf
NENG Security, Decentralization & Valuation
https://github.com/ShorelineCrypto/NewEnglandCoin/releases/download/2019Q2_report/NENG_Security_Decentralization_Value.pdf
Whitepaper v1.0 https://github.com/ShorelineCrypto/NewEnglandCoin/releases/download/whitepaper_v1.0/NENG_WhitePaper.pdf
DISCORD https://discord.gg/UPeBwgs
Explorer
http://www.findblocks.com/exploreNENG http://86.100.49.209/exploreNENG http://nengexplorer.mooo.com:3001/
Step by step guide on how to setup an explorer: https://github.com/ShorelineCrypto/nengexplorer
Github https://github.com/ShorelineCrypto/NewEnglandCoin
Wallet
Android with UserLand App (arm64/armhf), Chromebook (x64/arm64/armhf): https://github.com/ShorelineCrypto/NewEnglandCoin/releases/tag/v1.4.0.5
Linux Wallet (Ubuntu/Linux Mint, Debian/MX Linux, Arch/Manjaro, Fedora, openSUSE): https://github.com/ShorelineCrypto/NewEnglandCoin/releases/tag/v1.4.0.3
MacOS Wallet (10.11 El Capitan or higher): https://github.com/ShorelineCrypto/NewEnglandCoin/releases/tag/v1.4.0.2
Android with GNUroot on 32 bits old Phones (alpha release) wallet: https://github.com/ShorelineCrypto/NewEnglandCoin/releases/tag/v1.4.0
Windows wallet: https://github.com/ShorelineCrypto/NewEnglandCoin/releases/tag/v1.3.0.1
addnode ip address for the wallet to sync faster, frequently updated conf file: https://github.com/ShorelineCrypto/cheetah_cpumineblob/mastenewenglandcoin.conf-example
How to Sync Full Node Desktop Wallet https://www.reddit.com/NewEnglandCoin/comments/er6f0q/how_to_sync_full_node_desktop_wallet/
TWITTER https://twitter.com/newenglandcoin
REDDIT https://www.reddit.com/NewEnglandCoin/
Cheetah CPU Miner Software https://github.com/ShorelineCrypto/cheetah_cpuminer
Solo Mining with GPU or ASIC https://bitcointalk.org/index.php?topic=5027091.msg52187727#msg52187727
How to Run Two Full Node in Same Desktop PC https://bitcointalk.org/index.php?topic=5027091.msg53581449#msg53581449
ASIC/GPU Mining Pools Warning to Big ASIC Miners Due to DynDiff Algo on top of Scrypt, solo mining is recommended for ASIC/GPU miners. Further more, even for mining pools, small mining pool will generate better performance than big NENG mining pool because of new algo v1.2.x post hard fork.
The set up configuration of NENG for scrypt pool mining is same as a typical normal scrypt coin. In other word, DynDiff on Scrypt algo is backward compatible with Scrypt algo. Because ASIC/GPU miners rely on CPU miners for smooth blockchain movement, checkout bottom of "Latest News" section for A WARNING to All ASIC miners before you decide to dump big ASIC hash rate into NENG mining.
(1) Original DynDiff Warning: https://bitcointalk.org/index.php?topic=5027091.msg48324708#msg48324708 (2) New Warning on RandomSpike Spike difficulty (244k) introduced in RandomSpike served as roadblocks to instant mining and provide security against 51% attack risk. However, this spike difficulty like a roadblock that makes big ASIC mining less profitable. In case of spike block to be mined, the spike difficulty immediately serve as base difficulty, which will block GPU/ASIC miners effectively and leave CPU cheetah solo miners dominating mining almost 100% until next base difficulty reset.
FindBlocks http://findblocks.com/
CRpool http://crpool.xyz/
Cminors' Pool http://newenglandcoin.cminors-pool.com/
SPOOL https://spools.online/
Exchange
📷
https://shorelinecrypto.com/
Features: anonymous sign up and trading. No restriction or limit on deposit or withdraw.
The trading pairs available: NewEnglandcoin (NENG) / Dogecoin (DOGE)
Trading commission: A round trip trading will incur 0.10% trading fees in average. Fees are paid only on buyer side. buy fee: 0.2% / sell fee: 0% Deposit fees: free for all coins Withdraw fees: ZERO per withdraw. Mining fees are appointed by each coin blockchain. To cover the blockchain mining fees, there is minimum balance per coin per account: * Dogecoin 2 DOGE * NewEnglandcoin 1 NENG
Latest News Aug 30, 2020 - NENG v1.4.0.5 Released for Android/Chromebook Upgrade with armhf, better hardware support https://bitcointalk.org/index.php?topic=5027091.msg55098029#msg55098029
Aug 11, 2020 - NENG v1.4.0.4 Released for Android arm64 Upgrade / Chromebook Support https://bitcointalk.org/index.php?topic=5027091.msg54977437#msg54977437
Jul 30, 2020 - NENG v1.4.0.3 Released for Linux Wallet Upgrade with 8 Distros https://bitcointalk.org/index.php?topic=5027091.msg54898540#msg54898540
Jul 21, 2020 - NENG v1.4.0.2 Released for MacOS Upgrade with Catalina https://bitcointalk.org/index.php?topic=5027091.msg54839522#msg54839522
Jul 19, 2020 - NENG v1.4.0.1 Released for MacOS Wallet Upgrade https://bitcointalk.org/index.php?topic=5027091.msg54830333#msg54830333
Jul 15, 2020 - NENG v1.4.0 Released for Android Mining, Ubuntu 20.04 support https://bitcointalk.org/index.php?topic=5027091.msg54803639#msg54803639
Jul 11, 2020 - NENG v1.4.0 Android Mining, randomSpike Evaluation https://bitcointalk.org/index.php?topic=5027091.msg54777222#msg54777222
Jun 27, 2020 - Pre-Announce: NENG v1.4.0 Proposal for Mobile Miner Upgrade, Android Mining Start in July 2020 https://bitcointalk.org/index.php?topic=5027091.msg54694233#msg54694233
Jun 19, 2020 - Best Practice for Futurebit Moonlander2 USB ASIC on solo mining mode https://bitcointalk.org/index.php?topic=5027091.msg54645726#msg54645726
Mar 15, 2020 - Scrypt RandomSpike - NENG v1.3.0.1 Released for better wallet syncing https://bitcointalk.org/index.php?topic=5027091.msg54030923#msg54030923
Feb 23, 2020 - Scrypt RandomSpike - NENG Core v1.3.0 Relased, Hardfork on Mar 1 https://bitcointalk.org/index.php?topic=5027091.msg53900926#msg53900926
Feb 1, 2020 - Scrypt RandomSpike Proposal Published- NENG 1.3.0 Hardfork https://bitcointalk.org/index.php?topic=5027091.msg53735458#msg53735458
Jan 15, 2020 - NewEnglandcoin Dev Team Expanded with New Kickoff https://bitcointalk.org/index.php?topic=5027091.msg53617358#msg53617358
Jan 12, 2020 - Explanation of Base Diff Reset and Effect of Supply https://www.reddit.com/NewEnglandCoin/comments/envmo1/explanation_of_base_diff_reset_and_effect_of/
Dec 19, 2019 - Shoreline_tradingbot version 1.0 is released https://bitcointalk.org/index.php?topic=5121953.msg53391184#msg53391184
Sept 1, 2019 - NewEnglandcoin (NENG) is Selected as Shoreline Tradingbot First Supported Coin https://bitcointalk.org/index.php?topic=5027091.msg52331201#msg52331201
Aug 15, 2019 - Mining Update on Effect of Base Difficulty Reset, GPU vs ASIC https://bitcointalk.org/index.php?topic=5027091.msg52169572#msg52169572
Jul 7, 2019 - CPU Mining on macOS Mojave is supported under latest Cheetah_Cpuminer Release https://bitcointalk.org/index.php?topic=5027091.msg51745839#msg51745839
Jun 1, 2019 - NENG Fiat project is stopped by Square, Inc https://bitcointalk.org/index.php?topic=5027091.msg51312291#msg51312291
Apr 21, 2019 - NENG Fiat Project is Launched by ShorelineCrypto https://bitcointalk.org/index.php?topic=5027091.msg50714764#msg50714764
Apr 7, 2019 - Announcement of Fiat Project for all U.S. Residents & Mobile Miner Project Initiation https://bitcointalk.org/index.php?topic=5027091.msg50506585#msg50506585
Apr 1, 2019 - Disclosure on Large Buying on NENG at ShorelineCrypto Exchange https://bitcointalk.org/index.php?topic=5027091.msg50417196#msg50417196
Mar 27, 2019 - Disclosure on Large Buying on NENG at ShorelineCrypto Exchange https://bitcointalk.org/index.php?topic=5027091.msg50332097#msg50332097
Mar 17, 2019 - Disclosure on Large Buying on NENG at ShorelineCrypto Exchange https://bitcointalk.org/index.php?topic=5027091.msg50208194#msg50208194
Feb 26, 2019 - Community Project - NewEnglandcoin Graphic Redesign Bounty Initiated https://bitcointalk.org/index.php?topic=5027091.msg49931305#msg49931305
Feb 22, 2019 - Dev Policy on Checkpoints on NewEnglandcoin https://bitcointalk.org/index.php?topic=5027091.msg49875242#msg49875242
Feb 20, 2019 - NewEnglandCoin v1.2.1 Released to Secure the Hard Kork https://bitcointalk.org/index.php?topic=5027091.msg49831059#msg49831059
Feb 11, 2019 - NewEnglandCoin v1.2.0 Released, Anti-51% Attack, Anti-instant Mining after Hard Fork https://bitcointalk.org/index.php?topic=5027091.msg49685389#msg49685389
Jan 13, 2019 - Cheetah_CpuMiner added support for CPU Mining on Mac https://bitcointalk.org/index.php?topic=5027091.msg49218760#msg49218760
Jan 12, 2019 - NENG Core v1.1.2 Released to support MacOS OSX Wallet https://bitcointalk.org/index.php?topic=5027091.msg49202088#msg49202088
Jan 2, 2019 - Cheetah_Cpuminer v1.1.0 is released for both Linux and Windows https://bitcointalk.org/index.php?topic=5027091.msg49004345#msg49004345
Dec 31, 2018 - Technical Whitepaper is Released https://bitcointalk.org/index.php?topic=5027091.msg48990334#msg48990334
Dec 28, 2018 - Cheetah_Cpuminer v1.0.0 is released for Linux https://bitcointalk.org/index.php?topic=5027091.msg48935135#msg48935135
Update on Dec 14, 2018 - NENG Blockchain Stuck Issue https://bitcointalk.org/index.php?topic=5027091.msg48668375#msg48668375
Nov 27, 2018 - Exclusive for PC CPU Miners - How to Steal a Block from ASIC Miners https://bitcointalk.org/index.php?topic=5027091.msg48258465#msg48258465
Nov 28, 2018 - How to CPU Mine a NENG block with window/linux PC https://bitcointalk.org/index.php?topic=5027091.msg48298311#msg48298311
Nov 29, 2018 - A Warning to ASIC Miners https://bitcointalk.org/index.php?topic=5027091.msg48324708#msg48324708
Disclosure: Dev Team Came from ShorelineCrypto, a US based Informatics Service Business offering Fee for service for Coin Creation, Coin Exchange Listing, Blockchain Consulting, etc.
submitted by honglu69 to NewEnglandCoin [link] [comments]

A tour of the Gridcoin wallet

Hey guys, I thought I would put together an in-depth tour of the Gridcoin wallet software for all of our recent newcomers. Here I'll be outlining all the features and functions the windows GUI wallet has to offer, along with some basic RPC command usage. I'll be using the windows wallet as an example, but both linux and macOS should be rather similar. I'll be including as many pictures as I can as embedded hyperlinks.
Edit: Note that since I originally made this there has been a UI update, so your client will be different colors but all the button locations are in the same place.
This is my first post like this, so please forgive me if this appears a little scatter-brained.
This will not cover the mining setup process for pool or solo miners.
When you launch the wallet software for the first time you should be greeted with this screen.

OVERVIEW TAB

After that prompt, you should be left sitting on the main overview tab with several fields on it.
From top to bottom:

SEND TAB

Now onto the other tabs on the left side. Currently we're on the Overview tab, lets move down to the Send tab. This tab it pretty self-explanatory, you use it if you want to send coins, but I'll go over the fields here:
  • Pay To: Enter a valid gridcoin address to send coins too. Gridcoin addresses always start with an S or and R.
  • Label: Enter a label here and it will put that address in your "address book" under that label for later use. You can leave it blank if you don't want it in your address book.
  • Message: Enter a message here if you want it attached to your transaction.
  • Amount: How many coins you want to send.
  • Add Attachment: Leave this alone, it is broken.
  • Track Coins: This doesn't do anything.

RECEIVE TAB

Now down to the Receive tab. Here you should have a single address listed. If you double click on the label field, you can edit it's label.
  • New: Generate a new address.
If you click on an address, the rest of the options should be clickable.
  • Copy: Copy the selected address to your clipboard.
  • Show QR Code: Show a scan-able QR code for the selected address.
  • Sign Message: Cryptographically sign a message using the selected address.

TRANSACTIONS TAB

The Transactions tab is pretty boring considering we have no transactions yet. But as you can see there are some sorting tools at the top for when you do have transactions listed.

ADDRESS BOOK TAB

The Address Book is where all the addresses you've labeled (that aren't yours) will show up.
  • Verify Message: Verifies a message was signed by the selected address.
The rest of the functions are similar to the functions on the Receive tab.

VOTING TAB

Onto the Voting tab. There wont be any polls because we aren't in sync yet.
  • Reload Polls: Pretty self-explanatory, I've never had to use this.
  • Load History: By default, the wallet will only display active polls. If you want to view past polls you can use this.
  • Create Poll: You can create a network-wide poll. You must have 100,000 coins as a requirement to make a poll. (Creating a poll does not consume the coins)
Here's what the Voting tab will look like once you're in sync

CONTEXT BAR

Now onto the context bar menus on the top.
Under File you have:
  • Backup Wallet/Config: This lets you backup your wallet configuration file just in case.
  • Export: You can export your Transactions tab or Address Book in CSV format.
  • Sign message: Does the same thing as on the Receive tab.
  • Verify message: Does the same thing as on the Address Book tab.
  • Exit: Close the wallet.
Under Settings you have:
  • Encrypt Wallet: Encrypts your wallet with a password. (we'll come back to this)
  • Change Passphrase: Allows you to change your encryption password.
  • Options: Opens the options menu. (We'll come back to this)
Under Community you have:
Under Advanced you have:
  • Advanced Configuration: Opens the Advanced Configuration menu. (Not so advanced if you ask me)
  • Neural Network: Allows you to view solo miners project statistics. It will be largely blank if you're not in sync yet.
  • FAQ: Don't touch this, It is broken.
  • Foundation: Don't touch this, It is broken.
  • Rebuild Block Chain: Starts the client syncing from 0. Don't worry, using this will not make you lose coins.
  • Download Blocks: Downloads the latest official snapshot, can help speed up syncing. The download progress tends to sit at 99.99% for a long time, don't worry, it's working.
Under Help you have:
  • Debug window: Opens the debug window. (We'll come back to this)
  • Diagnostics: Don't touch this, it is broken. This has since been fixed. You can use this to see if there is anything wrong with your setup.
  • About Gridcoin: Opens the About Dialog. This gives you your client version and other information.

OPTIONS

Now back to the options menu under Settings > Options.
Here we have the options menu main tab:
  • Pay transaction fee: The transaction fee that will be automatically paid when you make a transaction.
  • Reserve: You can reserve an amount so that it will always be available for spending.
  • Start Gridcoin on system login: Pretty self-explanatory
  • Detach databases at shutdown: Speeds up shutdown, but causes your blockchain file to no longer be portable.
On the Network tab:
  • Map port using UPnP: Attempts to connect to nodes through UPnP.
  • Connect through SOCKS proxy: Allows you to connect through a proxy.
The window tab is pretty self-explanatory.
The Display tab is also pretty self-explanatory, with the exception of:
  • Display coin control features (experts only!): This allows you to have a great deal of control over the coins in your wallet, check this for now and I'll explain how to use it further down. Don't forget to click "Apply".

ENCRYPTING YOUR WALLET

Now that all of that is out of the way. The first thing you'll want to do is encrypt your wallet. This prevents anybody with access to your computer from sending coins. This is something I would recommend everyone do.
Go to Settings > Encrypt Wallet and create a password. YOU CANNOT RECOVER YOUR COINS IF YOU FORGET YOUR PASSWORD.
Your wallet will close and you will have to start it up again. This time when it opens up, you should have a new button in the bottom left. Now if you want to stake you will have to unlock your wallet. Notice the "For staking only" box that is checked by default. If you want to send a beacon for solo mining or vote, you will need to uncheck this box.

GETTING IN SYNC AND ICONS

Before we continue, Let's wait until we're in sync. Depending on your internet speeds, this could take from several hours to over a day or 2. This can be sped up by using Advanced > Download Blocks, but this can still take several hours.
This is what an in-sync client should look like. Notice the green check to the right of the Receive tab. All of these icons give you information when you hover your mouse over them.
The lock
The arrow tells you if you're staking. If you aren't staking, it will tell you why you're not staking. If you are staking it will give you an estimated staking time. Staking is a very random process and this is only an estimate, not a countdown.
The connection bars tell you how many connections to the network you have.
The check tells you if you're in sync.

WHAT IS STAKING?

Now I've said "stake" about a million times so far and haven't explained it. Gridcoin is a Proof of Stake (PoS) coin.
Unlike bitcoins Proof of Work (PoW), PoS uses little system resources, so you can use those resources for scientific work. PoS works by users "Staking" with their balance. The higher the balance, the higher the chance to create, or "stake" a block. This means you need to have a positive balance in order to stake. Theoretically, you can stake with any amount over 0.0125 coins, but in practice it's recommended to have at least 2000 coins to reliably stake.
Staking is important for solo miners, because they get paid when they stake. Pool miners don't need to stake in order to get paid however. So if you want to solo mine, you'll need to buy some coins from an exchange or start in the pool first and move to solo when you have enough coins.
In addition to Research Rewards for miners, anyone who holds coins (solo miners, pool miners, and investors) gets 1.5% interest annually on top of your coins. So it can be beneficial for pool miners to stake as well.
Here is a snippet of what a research rewards transaction looks like from my personal wallet. I have a label on that address of "Payout address" as you can see here.

UTXOS AND COIN CONTROL

At this point you'll need some coins. You can use one of our faucets like this one or this one to test coin control out.
First let me explain what a UTXO is. UTXO stands for Unspent Transaction Output. Say you have an address with 0 coins in it, and someone sends you 10 coins like I've done here. Those 10 coins are added to that address in the form of a UTXO, so we have an address with one 10 coin UTXO in it.
Now we receive another 5 coins at the same address, like so. Now we have an address with one 10 coin UTXO and one 5 coin UTXO. But how do we view how our addresses are split up into different UTXOs?
Earlier we checked the "Display coin control features" box in Settings > Options > Display. Once that's checked you'll notice there's another section in the Send tab labeled "Coin Control Features". If you click the "Inputs" button, you'll get a new window. And look, there's our 2 UTXOs.
All UTXOs try to stake separately from each other, and remember that the chance a UTXO has to stake is proportional to it's size. So in this situation, my 10 coin UTXO has twice the chance to stake as my 5 coin UTXO. Now wallets, especially ones that make a lot of transactions, can get very fragmented over time. I've fragmented my wallet a little so I can show you what I'm talking about.
How do we clean this up? We can consolidate all this into one UTXO by checking all the boxes on the left and selecting OK.
Now pay attention to the fields on the top:
  • Quantity: The total amount of UTXOs we have selected.
  • Amount: The total amount of coins we have selected.
  • Fee: How much it would cost in fees to send all those UTXOs (more UTXOs = more transaction data = more fees)
  • After Fee: Amount - Fees.
  • Bytes: How large the transaction is in bytes.
  • Priority: How your client would prioritize making a transaction with this specific set of UTXOs selected had you not used coin control.
  • Low Output: If your transaction is less than 0.01 coins (I think).
  • Change: What you will get back in change.
  • custom change address: You can set the address you get your change back at, by default it will generate a new address.
So let's fill out our transaction so we end up with 1 UTXO at the end.
In "Pay To:" Just put any address in your wallet, and for the amount put what it has listed in the "After Fee" Field. Just like this.
Notice how we get no change back.
Now click "Send", we'll be prompted to enter our passphrase and we're asked if we want to pay the fee, go ahead and click "Yes".
Now if we go back to the Overview tab we get this funky icon. If you hover your mouse over it, it says "Payment to yourself", and the -0.0002 GRC is the network transaction fee.
(Ignore the first one, that was me fragmenting my wallet)
Now if we look at the Coin Control menu, we can see that we've slimmed our wallet down from 7 UTXOs to 1.
Now why would you want to use coin control?
2 Situations:
  1. UTXOs less than 0.0125 coins cannot stake. So you can combine a lot of tiny, useless UTXOs into 1 bigger one that can stake.
  2. After a UTXO stakes, it cannot stake for another 16 hours. So if you have 1 large UTXO that is big enough to stake more than once every 16 hours, you can split it into smaller UTXOs which can allow you to stake slightly more often.
  3. By default, the wallet will always generate a new address for change, which can make your wallet get very messy if you're sending lots of transactions. Keep in mind that more UTXOs = larger transactions = more fees.
Sidenote - When you stake, you will earn all research rewards owed reguardless of which UTXO staked. However, you'll earn the 1.5% interest for that UTXO. Not your whole wallet.

FORKING

A fork is when the network splits into multiple chains, with part of the network on each chain. A fork can happen when 2 blocks are staked by different clients at the same time or very close to the same time, or when your client rejects a block that should have been accepted due to a bug in the code or through some other unique circumstance.
How do I know if I'm on a fork?
Generally you can spot a fork by looking at the difficulty on your Overview tab. With current network conditions, if your difficulty is below 0.1, then you're probably on a fork.
You can confirm this by comparing your blockhash with someone elses, like a block explorer.
Go to [Help > Debug Window > Console]. This is the RPC console, we can use to do a lot of things. You can type help to get a list of commands, and you can type help [command you need help with] (without the brackets) to get information on a command. We'll be using the getblockhash [block number] command.
Type getblockhash [block number] in the console, but replace [block number] with the number listed next to the "Blocks:" field on the Overview tab.
This will spit out a crazy string of characters, this is the "blockhash" of that block.
Now head over to your favorite block explorer, I'll be using gridcoinstats. Find the block that you have the hash for, use the search bar or just find it in the list of blocks.
Now compare your hash with the one gridcoinstats gives you. Does it match?
If it matches, then you're probably good to go. If it matches but you still think you're on a fork, then you can try other block explorers, such as gridcoin.network or neuralminer.io.
If it doesn't match, then you need to try to get off that fork.
How do I get off a fork?
  1. Just wait for an hour or two. 95% of the time your client is able to recover itself from a fork given a little time.
  2. Restart the client, wait a few minutes to see if it fixes itself. If it doesn't restart again and wait. Repeat about 4 or 5 times.
  3. Find where the fork started. Using the getblockhash command, go back some blocks and compare hashes with that on a block explorer so you can narrow down what the last block you and the block explorer had in common. Then use reorganize [the last block hash you had in common]. Note that reorganize takes a blockhash, not a block number.
  4. Use Advanced > Download Blocks.
  5. If none of this works, you can take a look at social media (reddit/steemit) and see what other people are saying.

CONFIGURATION FILE

Your configuration file depends on your operation system:
  • On Windows: %appdata%\GridcoinResearch\
  • On Linux: ~/.GridcoinResearch/
  • On MacOS: /Users/USERNAME/Library/Application/Support/GridcoinResearch/
And it should look like this.
If you open up your gridcoinresearch.conf, you'll see the default one it generated. Note that if you entered your email earlier, the first line will have your email on it instead of "investor". If you decided you want to solo mine but didn't enter your email when you first started the wallet, go ahead and put your email on the first line in place of "investor". If you're a pool miner, just leave it as "investor".
Next, it's recommended that you use the addnodes on the gridcoin wiki. So our gridcoinresearch.conf will look like this.
A useful line for solo miners is PrimaryCPID=[YOUR CPID]. Sometimes your wallet can pick up on the wrong CPID so it's good to have that in there if you're solo mining.

RUNNING A LISTENING NODE

A listening node is a node that listens for blocks and transactions broadcasted from nodes and forwards them on to other nodes. For example, during the syncing process when you're getting your node running for the first time, you're downloading all the blocks from listening nodes. So running a listening node helps support the network.
Running a gridcoin listening node is simple. All you need to do is add listen=1 to your gridcoinresearch.conf and you need to forward port 32749 on your router.
If you don't know how to port forward, I'd suggest googling "How to port forward [your router manufacturer]".

QUICK LINKS

Gridcoin.us Official Website
Gridcoin.science Unofficial Website
Gridcoinstats.eu Block Explorer
NeuralMiner.io Block Explorer
Gridcoinstats.eu Faucet
Gridcoin.ch Faucet
Gridcoin Wiki
Gridcoin Github
GRCPool
Arikado Pool
And that's all I have for now!
I plan to keep this post up-to-date with changes in the client. So if anyone has any suggestions, have clarifications they want made, or maybe I got something wrong, then please feel free to leave a comment below or PM me!
submitted by Personthingman2 to gridcoin [link] [comments]

Non-propagating dust transaction creation by pools needs to stop!

This is an issue that has led to unnecessary clogging of the network for a long time, yet it seems to be one that has been overlooked for some time.
For those who don't know: BLOCK REWARD = 12.5BTC + (SUM OF ALL TRANSACTION FEES MINED ON THAT BLOCK)
Most of the largest pools keep the transaction fee part of the block reward for themselves (i.e. they do not pay that out to miners.)
Here's what I'm talking about:
This is done by pools that do not pay out transaction fees to miners (Antpool is by far the worst offender.) The practice is only profitable to pools which retain the transaction fee part of the block reward for themselves. The pool constantly creates a large number of minable but non-propagating transactions by creating transactions which violate the network "dust" rule. This rule prevents payments of less than 0.00001BTC from being broadcast throughout the network. As a result the transaction gets "stuck" in the pool's node and as such can only be mined by them. They will attach a large fee to the transaction, which in turn lowers the priority of transactions with lower fees attached. This ensures that only transactions with the highest fees are included in the block they mine- leaving the transactions with lower fees attached unconfirmed, driving up the necessary transaction fee, wasting mining power mining transactions that server no other purpose other than to drive up transaction fees and allowing the pool to, in essence, refuse to mine transactions with a fee below a certain amount attached. Since the pool will mine it's own transactions, they can create a virtually unlimited number of these transactions, with many unconfirmed descendants, to serve their purpose depending on the state of the mempool, and since they do not pay out transaction fees to the miners, they will get back all the transaction fees they used to attach to these transactions. Algorithms determine how much of the block-space to "waste" in order to maximize the profit- since the mempool can be analyzed at any time, it can be determined exactly how many transactions to create and what fee to attach in order to mine the transactions with the highest fee attached and drive up the necessary fee to have a transaction confirmed along with the "smart-fee," while ensuring low fee transactions are mined by the pools that do not practice this strategy. The strategy pays highest when the mempool is above 1MB (the size of a block) or has quickly filled. It also is most profitable when the fee distribution and queue-time in the mempool is highly divided/distributed- this strategy can prevent lower-fee transactions that have been waiting a long time to confirm from replacing new transactions that have a high fee attached on a block.
In Summary:
  1. Pool creates many "dust" transactions and attaches a high fee to each.
  2. Dust transactions (transactions below 0.00001BTC) do not broadcast, so the pool is guaranteed to mine its own transactions and re-collect the high fees they attached to the transaction.
  3. Pool now only mines outside transactions with the highest fees (per kB) attached, leaving the low-fee transactions to be mined by pools which do not practice this while simultaneously driving up the fee necessary to have a transaction confirmed.
Example:
https://www.blockchain.com/en/btc/tx/c57ea54104bbf160bac88b65b2edf465c5f8ac9253c42e391100fc31b028d645
If you click on the address, you can see this exact transaction is repeated exactly every hour (which sends a fixed amount back to itself and an address that cannot be decoded, due to the nature of the transaction, being sent 0BTC- which is what makes this a dust transaction.) If you go back to the block this transaction was originally confirmed (mined) on (by Antpool) you will see tons of similar transactions. In fact, Antpool has hundreds, if not thousands, of addresses used solely for this purpose. The practice is much more calculated and complex (in actual practice) than I summarized above. Eventually (or sometimes even on the same block) the divided outputs created by each transaction you see on that account would/will be concatenated into a single output over an additional series of combining, non-broadcasting, "dust" transactions.
Can it technically be considered a fair practice?
While their are plenty of valid reasons to create non-propagating transactions, such as to concatenate inputs left with dust amounts of bitcoin after valid transactions, without risking loosing the entire amount due to the minimum transaction fee being larger than the total amount, creating transactions like this with no other purpose than to increase a pools own profits is hard to argue as being a honorable one. Furthermore, since this practice is overall detrimental to the network (filling blocks with loads of unnecessary transactions, slowing confirmation times and artificially manipulating the necessary transaction fees) and in addition penalizes pools which pay the transaction fee part of the block reward to miners (since the practice cannot be performed by such pools, as it would cost the pool far too much,) as well as the fact that THE MINERS- THE ONES ACTUALLY CONTRIBUTING THE MINING POWER ARE NOT BENEFITING, I think it is safe to say that this practice is a deplorable one. Yes, one could argue that this is a loophole and exploiting it is going to be a natural occurrence, but I believe that since it encourages pools not to pay the transaction fee part of the block reward to miners, it is a practice that should not continue.
What to do about it?
There are a few options:
You can try if you run a full-node, but...: I for instance run a full node on a high bandwidth, fixed IP and allow incoming connections. I allow more connections in the command line options and maintain a few hundred connections at once. I noticed a few pools started automatically connecting to my node (I had to do some nmap scanning and some other testing to confirm they were indeed pool nodes, and who they belonged to, but was able to determine that- my first clue was multiple connections from bitcoinj nodes in the same subnet.) I was also able to find the addresses of other pool nodes and manually add them with the `addnode' command. So, with multiple pools connected (or the ability to connect to multiple pools upon restart,) I tweaked my node to allow for the broadcast of both zero-fee and dust transactions. My thinking was that I could serve as an unknowing "bridge" between pools- broadcasting one pools "dust" transactions to another, thereby removing the pool's ability to ensure that the transaction was not mined by another pool and making the practice unprofitable.
BUT... While this sounds good in theory, in practice it doesn't work for a few reasons. First of all, the pool nodes would not connect to me once I started broadcasting dust transactions. Second, I noticed my overall connection count way down, leading me to believe that broadcasting dust transactions was causing me to be labeled as a misbehaving node and finally, while this could work for some less advanced pools, Antpool, at least, designs its dust transactions in such a way that they violate more than just the "dust" rule- further tweaking would be required and this would need to be an action taken by a majority of nodes to work.
The only other option, I suppose, would be to appeal to the bitcoin dev team. Perhaps they could implement a way to prevent this practice, although I do not likely see it happening. The "dust" rule is in place to prevent clogging of the network with tiny transactions- to prevent anyone wishing to back-up the network from being able to do so without spending a large sum of money. The dust rule and the minimum transaction fee go hand in hand to prevent such occurrence- so anyone wishing to do harm to the network would soon find themselves spending very large amounts of BTC in an attempt to back it up- pools which retain the transaction fee however are not bound by these limitations.
The only real option to fight this, as a miner, is to mine on a pool that pays the transaction fee part of the block reward to the miners- you'll make more anyway, even if the overall fee may be slightly higher. An example of one of these pools is KANO, there are many others. I would just avoid antpool in general- but that's just me.
tl;dr
Pools which retain the transaction fee part of the block reward use a loophole is a network rule that allows them to only mine high fee transactions, which in turn hurts pools that pay the transaction fee part of the block reward to miners, clogs up the network- slowing confirmation times, and drives up transaction fees.
submitted by Mypassispass123 to Bitcoin [link] [comments]

Trying to salvage some coins from 2013. Core (bitcoin-qt.exe v0.8.1-beta on Windows 8.1) is taking weeks to DL the blockchain as expected but keeps crashing now. Can I upgrade to a newer version without losing what I've gotten already (about 75% complete)?

Currently there are 134305 blocks remaining. When I start it up it works pretty smoothly for a while but then slows down. I leave it running while I'm gone but the last several days when I've come back it has crashed and gives me an I/O error, and I have to hit OK then start it back up. It does appear to be further along when I start it back up but not by a whole lot. So this has really slowed my progress. It's reindexed about 75% though, and so I don't want to start over from the beginning.
The drive it is on has ~400gb of free space so that's not the issue. I have 8gb of memory, and the task manager says bitcoin is taking up about 500mb, but it's using 60-85% of my cpu at a time.
If I download a newer version of core, I can just copy/paste the old wallet.dat file, right? But wouldn't it have to start downloading the entire blockchain again from the beginning? If so, is there any quicker method?
While typing this, it crashed twice. It only runs for about 10 minutes.
The version I have doesn't have any settings I can change. I read that there's a db size limit you can change in later versions that could help. This one does have a "debug window" with a command line console but I don't really know what to do with it. Here is a list of available commands: 
addmultisigaddress <'["key","key"]'> [account]
addnode
backupwallet
createmultisig <'["key","key"]'>
createrawtransaction [{"txid":txid,"vout":n},...] {address:amount,...}
decoderawtransaction
dumpprivkey
encryptwallet
getaccount
getaccountaddress
getaddednodeinfo [node]
getaddressesbyaccount
getbalance [account] [minconf=1]
getblock
getblockcount
getblockhash
getblocktemplate [params]
getconnectioncount
getdifficulty
getgenerate
gethashespersec
getinfo
getmininginfo
getnewaddress [account]
getpeerinfo
getrawmempool
getrawtransaction [verbose=0]
getreceivedbyaccount [minconf=1]
getreceivedbyaddress [minconf=1]
gettransaction
gettxout [includemempool=true]
gettxoutsetinfo
getwork [data]
help [command]
importprivkey [label] [rescan=true]
keypoolrefill
listaccounts [minconf=1]
listaddressgroupings
listlockunspent
listreceivedbyaccount [minconf=1] [includeempty=false]
listreceivedbyaddress [minconf=1] [includeempty=false]
listsinceblock [blockhash] [target-confirmations]
listtransactions [account] [count=10] [from=0]
listunspent [minconf=1] [maxconf=9999999] ["address",...]
lockunspent unlock? [array-of-Objects]
move [minconf=1] [comment]
sendfrom [minconf=1] [comment] [comment-to]
sendmany {address:amount,...} [minconf=1] [comment]
sendrawtransaction
sendtoaddress [comment] [comment-to]
setaccount
setgenerate [genproclimit]
settxfee
signmessage
signrawtransaction [{"txid":txid,"vout":n,"scriptPubKey":hex,"redeemScript":hex},...] [,...] [sighashtype="ALL"]
stop
submitblock [optional-params-obj]
validateaddress
verifymessage

submitted by closer_to_the_flame to Bitcoin [link] [comments]

ANN - RENESIS - LTME (Long Term Mining Evolution)

ANN - RENESIS - LTME (Long Term Mining Evolution)
https://preview.redd.it/wulcw7lgbhb11.png?width=500&format=png&auto=webp&s=c3aca3a98e0b699d88e99acee4a5dc236c8b39e0
LTME ( Long Term Mining Evolution) With ASIC Resistance Promise hav0k, The Renesis Core

Renesis Specifications:

Algorithm: Renesis Ticker: RESS Whitepaper v1: https://github.com/renesisgroup/whitepapeblob/masteRENESIS-paper.pdf Block Time: 2 minutes Block Reward: Variable. Refer to whitepaper for reward structure. Halving: Yes Doubling: Yes Mined Confirmations PoW/PoS : 60 TX Confirmations: 10 Minimum RX confirmations to forward: 1 Total Coin Supply: 350M for Proof of Work PoS Cap: No PoS Stake Reward: 10% per year Pre-mine: Yes ( First 100 Blocks mined on low difficulty with CPUMiner) Bounties Available: Yes - From Premine Rewards Available for Community Developers: Yes, from Premine CPUMiner Available: Yes - Windows binary & source. NVIDIA GPUMiner Available: Yes ( Reward for fair release of GPUMiner is paid! 50,000 RESS ) AMD GPUMiner Available: No ( Reward for fair release of GPUMiner is > 12,000 RESS ) Renesis New Logo Design Competition: Yes ( Reward of 2000 RESS ) Renesis QT Wallet Theming Competition: Yes ( Reward of 5000 RESS ) Renesis V2 Static Website Design Competition: Yes ( Reward of 7000 RESS ) Renesis public Pool addition reward: Yes (10000 RESS) - First 3 Pools. Renesis Node Hosting: Yes ( Reward of 1000 RESS offered for 1 month of hosting ) Translation Bounties: Yes ( Reward of 500 RESS per translation posted ) Social Media Bounties: Yes ( Connect with us on our channels for information ) ICO: No - Bitcoin Talk ANN for everyone to mine starting 101 block Masternodes: Planned MainNet P2P port: 9775 MainNet RPC port: 9774 TestNet P2P port: 19775 TestNet RPC port: 19774
Renesis Development Team : hav0k - 2 developers Group : The Renesis Group ( Visit www.renesis.io for profiles ) - 7 members Web Site: http://www.renesis.io Block Explorers: http://tx.renesis.io - https://protopool.net/exploreRESS Reddit: https://www.reddit.com/Renesis/ Connections: Discord, Telegram, Slack ( Visit www.renesis.io to connect ) Will have web wallet: No - We believe coins should be safe in your wallets not online. Pools: To be announced after announcement. Exchanges: To be announced.

Pools:

https://cryptopool.party 10000 RESS Reward TX : http://tx.renesis.io/address/RVMNvHD3DFH1CZ9JVijFxiZgKcPLBpteYh
https://protopool.net 10000 RESS Reward TX: http://tx.renesis.io/address/RATQNUpMH7puoByrkBBUWiBVJowno6bGPz
http://www.tera.tn/ 10000 RESS Reward TX: http://tx.renesis.io/address/RFUkDC5dyRQZhH3GkrAhnAUNNQ2tZbTt7w

Nodes:

addnode node1.renesis.io addnode node2.renesis.io addnode node3.renesis.io addnode node4.renesis.io addnode node5.renesis.io ( Node by CryptoHobo. 1K RESS every month . TXID : 1e7a332788bceb23438b783dac172c853804d51443f43a1d68b378447981059f - 22 July 2018 addnode i.crashed.online addnode he.crashed.online addnode it.crashed.online addnode she.crashed.online addnode renesisckko455xx.onion add ( Tor Node )
Terms & Conditions for GPUMiner Releases : Developers must release the mining software + source after brief testing to Renesis Group to claim their reward. The group will immediately upload the GPUMiner with sources on github after mining 2 test blocks and will provide proof to community. If GPUMiner software is released directly to the community then it would fair but there will be no reward for software developers.

Mining:

At the time of announcement, you can mine solo until pools become available. Download the CPUMiner binary or source from github with a wallet https://github.com/renesisgroup/cpuminer-release. Place the renesis.conf in your wallet data directory and (re) start wallet. Run start.bat file inside CPUMiner bin folder to mine Renesis. You can edit the start.bat file to edit the number of threads for mining. If you wish to mine on a pool then use the poolmine.bat file.
Note: Please be advised that the cpuminer.exe can show up as a virus on Windows just like almost all mining software. You can be assured it is not and is labelled as coin miner, CpuMiner (PUA) or malware. Refer to virustotal report here https://www.virustotal.com/#/file/1c90ca293dc016f0d8663f7bab55b5def8f484c21b3dac3dae6f81d0166cc99e/detection . You can safely verify your Claymore and EWBF CUDA miners at virustotal and they will give similar results. If you feel that it has a virus then please do not mine. Virustotal scan for Windows wallet is : https://www.virustotal.com/#/file/4cc5d6977566fc7e254744626d0783b1fc2d1aab15d72a5137c99ef0e91eee46/detection .For questions related to GPUMiner releases, please ask fellow miners or their respective developers when their releases become available for download.
UPDATE: CCMINER Download : https://github.com/renesisgroup/ccminer-renesis Reward of 50000 RESS paid to user A1 on Discord : http://tx.renesis.io/address/RVmFpemzMtbjhG16bjQTGEWv3sTgRVuzWm
Special thanks to mrM4D for his guidelines on CPUMiner build. Cheers to ocminer, mrM4D and Epsylon3 Greets to: SCRIV, RavenCoin for their game changing innovations and ASIC resistance commitments.

Roadmap:

Phase 1
Renesis Release Development - done CPUMiner Development - done Generate the premine - done Announcement - Underway Community Developers - 3 required and backed by funding from premine. Update: 1st Dev joined the dev team GPUMiners for AMD - Awaited and backed by rewards for fair release by developers. Masternodes Solution - TBA by developers and community consensus and backed by rewards from premine. ASIC Survey - Planned Rensis Hash Enhancement - Planned. TBA under phase 2 or after ASIC Survey Renesis Holdings Fund - Planned
Phase 2 - Next
Good things coming here =) Real use case 1 - Planned Real use case 2 - Planned To be announced after completion of Phase 1
Phase 3 - Planned
Online Gaming - Planned
Phase 4 - Planned
To be announced after completion of Phase 3
submitted by dev_hav0k to Renesis [link] [comments]

Bitcoin cash blockchain craziness (missing BCC)

Before doing anything with BCC, I transferred my BTC from one bitcoin address (old address) to another (new address), a total of 2.05 BTC. I only had one address in my wallet (old address) when I started.
So, I installed the Bitcoin ABC client and completely synched with the Bitcoin Cash blockchain, after copying my blockchain data from the core data directory, addnode'ng the Bitcoin Cash nodes to the .conf file, starting with a brand spanking new fresh wallet, and issuing the following command to pick up the correct blocks after the fork:
invalidateblock 00000000000000000019f112ec0a9982926f1258cdcc558dd7c3b7e5dc7fa148 
I then proceeded to import my (old address) private key:
importprivkey ... 
..., into Bitcoin ABC and waited (patiently) for the rescan to complete.
The crazy part: I was 1 BCC short - it showed 1.05 BCC instead of 2.05 BCC. So, I went back into my core wallet, copied the entire list of transactions to a spreadsheet and compared them to the list of transactions in the ABC client to see what the heck happened.
The ABC client transaction list shows two 0.5 BTC withdrawals (from the old address) circa 2016, that never happened and this is the reason that I am 1 BCC short in the end.
I don't know how this is possible. The withdrawals were all from around mid to late 2016, way before this fork happened, and that part of the blockchain is common to both. Since I was able to transfer the entire 2.05 BTC from my old BTC address to a new BTC address before I started, with >10 confirmations, I definitely know that I had 2.05 BTC at the old address, the only address I used until after the fork.
If anybody has any ideas on how this is possible, or what steps I should take next to reconcile my BCC amount with my BTC amount pre-fork, I am all ears.
submitted by mikegold10 to BitcoinABC [link] [comments]

Why you should mine with replace-by-fee, a decentralized Bitundo

tl;dr: If you mine solo, run a pool, or mine on p2pool, you should get my replace-by-fee code from https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1 and install it. As for why, read on:
Out of the the rather heated discussion about the Bitundo service one comment really stuck out for me:
I think there's an interesting legal liability question here - if someone buys a product and then uses your service to Finney attack the merchant, are you part of a conspiracy to defraud the seller?
-Mike Hearn
What Mike is saying is that even though the Bitcoin protocol allows miners total freedom to put any valid transaction they want to in their blocks, the legal system may be used to try to restrict that freedom and punish miners to don't the de facto practice of only mining the first valid transactions broadcast to the network. It's easy to see the legal case playing out: suppose insecure hacks like Mycelium's transaction radar catch on. We'll have a lot of people doing transactions that depend on miners all following the same mining rules, and eventually someone is going to get hurt. They're going to want to find someone to sue, and what better than the mining pool who mined the double-spend transaction?
What's wrong with that? Of course, first and foremost by encouraging people to use Bitcoin insecurely we invite heavy handed regulation when things go wrong. We're already seeing regulators cite the hundreds of millions of dollars lost by MtGox as evidence of the need for legal regulation, rather than technological measures like multisig. Why make the exact same mistake all over again with unconfirmed transactions?
There's a deeper reason too: relying on unconfirmed transactions is only possible by making Bitcoin more centralized at the mining level, at the network level, and at the development team level. Every Bitcoin release accepts a slightly different set of transactions as valid - do you want to be worried about legal liability if your mining operation allows an attacker to rip off someone because you upgraded sooner or later than the rest of the network? Or just were using a different client all together? Like it or not, if one miner accepts a different set of transaction types than another, that's an opportunity to double-spend.
At the network level transactions simply do not and never will propagate through the network instantly. At the same time until a transaction is confirmed there isn't any proof that the transaction propagated to any hashing power at all - the proof that a transaction was succesfully published is in the form of PoW only. Again, the only way to make unconfirmed transactions even close to safe is to make the network of miners smaller - do you want to be exposed to legal liability just because your small mining pool had a worse network connection than the biggest pool? You could even be in a situation where you've been sybil attacked, preventing you from seeing some transactions at all. You won't have any proof of that fact - instead it'll look like you participated in an attempt to rip someone off.
Finally it's been proposed multiple times that merchants pay for security directly with insurance contracts with major minering pools. The miners agree not to double-spend, and the merchants pay extra for that. Of course, if you're a small miner you're not going to get these contracts - you're much too small to bother talking to. The major mining pools wind up earning more BTC/hash than you, and on top of that, if you ever do end up including a double-spend in one of your blocks it's quite likely those contracts will have those pools just kill off your blocks in a re-organization.
The fact is Bitcoin by itself just isn't suited to instant confirmations: if you want decentralization, you have to give everyone time to come to consensus securely. Fortunately we have lots of technologies that can be used in conjunction with Bitcoin for the times when 10 minutes isn't good enough, but if we don't use them we'll end up with a less secure and less decentralized Bitcoin.
What you should do if you're a pool operator, solo miner, or mine on p2pool
Replace-by-fee simply means that rather than only accepting the first transaction you see to your mempool, you accept whatever one pays the most fees. It's a simple rule that results in the most profit per block, lets users re-issue transactions with higher fees if needed, and most importantly, makes it clear to everyone that relying on unconfirmed transactions by themselves is insecure.
I've written a simple replace-by-fee patch based directly on the v0.9.1 codebase. Installation is just a matter of getting my replace-by-fee-v0.9.1 branch from https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.1 and compiling it; you run the code just like you would normally.
Unlike BitUndo it's an entirely decentralized system where the 100% of the profits for replacing one unconfirmed transaction with another goes directly to miners. The patch implements preferential peering, which means it seeks out other nodes supporting replace-by-fee to ensure you'll always be connected to like-minded peers; you don't need to -addnode a central server.
While I wouldn't recommend a pool like ghash.io to install it right off the bat, if you're a miner on, say, p2pool, installing the patch carries no risk to you, and will help keep Bitcoin decentralized in the future.
submitted by petertodd to Bitcoin [link] [comments]

Bitcoin Core 0.10.0 released | Wladimir | Feb 16 2015

Wladimir on Feb 16 2015:
Bitcoin Core version 0.10.0 is now available from:
https://bitcoin.org/bin/0.10.0/
This is a new major version release, bringing both new features and
bug fixes.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
The whole distribution is also available as torrent:
https://bitcoin.org/bin/0.10.0/bitcoin-0.10.0.torrent
magnet:?xt=urn:btih:170c61fe09dafecfbb97cb4dccd32173383f4e68&dn;=0.10.0&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Fopen.demonii.com%3A1337&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
Upgrading and downgrading

How to Upgrade
If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).
Downgrading warning
Because release 0.10.0 makes use of headers-first synchronization and parallel
block download (see further), the block files and databases are not
backwards-compatible with older versions of Bitcoin Core or other software:
  • Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.
  • The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.
If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.
This does not affect wallet forward or backward compatibility.
Notable changes

Faster synchronization
Bitcoin Core now uses 'headers-first synchronization'. This means that we first
ask peers for block headers (a total of 27 megabytes, as of December 2014) and
validate those. In a second stage, when the headers have been discovered, we
download the blocks. However, as we already know about the whole chain in
advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On
recent hardware with a decent network link, it can be as little as 3 hours
for an initial full synchronization. You may notice a slower progress in the
very first few minutes, when headers are still being fetched and verified, but
it should gain speed afterwards.
A few RPCs were added/updated as a result of this:
  • getblockchaininfo now returns the number of validated headers in addition to
the number of validated blocks.
  • getpeerinfo lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we
have requested from peers (but haven't received yet) are also listed as
'inflight'.
  • A new RPC getchaintips lists all known branches of the block chain,
including those we only have headers for.
Transaction fee changes
This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
settings will create transactions that confirm quickly; see the new
'txconfirmtarget' setting to control the tradeoff between fees and
confirmation times. Fees are added by default unless the 'sendfreetransactions'
setting is enabled.
Prior releases used hard-coded fees (and priorities), and would
sometimes create transactions that took a very long time to confirm.
Statistics used to estimate fees and priorities are saved in the
data directory in the fee_estimates.dat file just before
program shutdown, and are read in at startup.
New command line options for transaction fee changes:
  • -txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to begin confirmation within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.
  • -sendfreetransactions : Send transactions as zero-fee transactions if possible
(default: 0)
New RPC commands for fee estimation:
  • estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to begin confirmation within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.
  • estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to begin confirmation within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
estimate.
RPC access control changes
Subnet matching for the purpose of access control is now done
by matching the binary network address, instead of with string wildcard matching.
For the user this means that -rpcallowip takes a subnet specification, which can be
  • a single IP address (e.g. 1.2.3.4 or fe80::0012:3456:789a:bcde)
  • a network/CIDR (e.g. 1.2.3.0/24 or fe80::0000/64)
  • a network/netmask (e.g. 1.2.3.4/255.255.255.0 or fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff)
An arbitrary number of -rpcallow arguments can be given. An incoming connection will be accepted if its origin address
matches one of them.
For example:
| 0.9.x and before | 0.10.x |
|--------------------------------------------|---------------------------------------|
| -rpcallowip=192.168.1.1 | -rpcallowip=192.168.1.1 (unchanged) |
| -rpcallowip=192.168.1.* | -rpcallowip=192.168.1.0/24 |
| -rpcallowip=192.168.* | -rpcallowip=192.168.0.0/16 |
| -rpcallowip=* (dangerous!) | -rpcallowip=::/0 (still dangerous!) |
Using wildcards will result in the rule being rejected with the following error in debug.log:
 Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). 
REST interface
A new HTTP API is exposed when running with the -rest flag, which allows
unauthenticated access to public node data.
It is served on the same port as RPC, but does not need a password, and uses
plain HTTP instead of JSON-RPC.
Assuming a local RPC server running on port 8332, it is possible to request:
In every case, EXT can be bin (for raw binary data), hex (for hex-encoded
binary) or json.
For more details, see the doc/REST-interface.md document in the repository.
RPC Server "Warm-Up" Mode
The RPC server is started earlier now, before most of the expensive
intialisations like loading the block index. It is available now almost
immediately after starting the process. However, until all initialisations
are done, it always returns an immediate error with code -28 to all calls.
This new behaviour can be useful for clients to know that a server is already
started and will be available soon (for instance, so that they do not
have to start it themselves).
Improved signing security
For 0.10 the security of signing against unusual attacks has been
improved by making the signatures constant time and deterministic.
This change is a result of switching signing to use libsecp256k1
instead of OpenSSL. Libsecp256k1 is a cryptographic library
optimized for the curve Bitcoin uses which was created by Bitcoin
Core developer Pieter Wuille.
There exist attacks[1] against most ECC implementations where an
attacker on shared virtual machine hardware could extract a private
key if they could cause a target to sign using the same key hundreds
of times. While using shared hosts and reusing keys are inadvisable
for other reasons, it's a better practice to avoid the exposure.
OpenSSL has code in their source repository for derandomization
and reduction in timing leaks that we've eagerly wanted to use for a
long time, but this functionality has still not made its
way into a released version of OpenSSL. Libsecp256k1 achieves
significantly stronger protection: As far as we're aware this is
the only deployed implementation of constant time signing for
the curve Bitcoin uses and we have reason to believe that
libsecp256k1 is better tested and more thoroughly reviewed
than the implementation in OpenSSL.
[1] https://eprint.iacr.org/2014/161.pdf
Watch-only wallet support
The wallet can now track transactions to and from wallets for which you know
all addresses (or scripts), even without the private keys.
This can be used to track payments without needing the private keys online on a
possibly vulnerable system. In addition, it can help for (manual) construction
of multisig transactions where you are only one of the signers.
One new RPC, importaddress, is added which functions similarly to
importprivkey, but instead takes an address or script (in hexadecimal) as
argument. After using it, outputs credited to this address or script are
considered to be received, and transactions consuming these outputs will be
considered to be sent.
The following RPCs have optional support for watch-only:
getbalance, listreceivedbyaddress, listreceivedbyaccount,
listtransactions, listaccounts, listsinceblock, gettransaction. See the
RPC documentation for those methods for more information.
Compared to using getrawtransaction, this mechanism does not require
-txindex, scales better, integrates better with the wallet, and is compatible
with future block chain pruning functionality. It does mean that all relevant
addresses need to added to the wallet before the payment, though.
Consensus library
Starting from 0.10.0, the Bitcoin Core distribution includes a consensus library.
The purpose of this library is to make the verification functionality that is
critical to Bitcoin's consensus available to other applications, e.g. to language
bindings such as [python-bitcoinlib](https://pypi.python.org/pypi/python-bitcoinlib) or
alternative node implementations.
This library is called libbitcoinconsensus.so (or, .dll for Windows).
Its interface is defined in the C header [bitcoinconsensus.h](https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h).
In its initial version the API includes two functions:
  • bitcoinconsensus_verify_script verifies a script. It returns whether the indicated input of the provided serialized transaction
correctly spends the passed scriptPubKey under additional constraints indicated by flags
  • bitcoinconsensus_version returns the API version, currently at an experimental 0
The functionality is planned to be extended to e.g. UTXO management in upcoming releases, but the interface
for existing methods should remain stable.
Standard script rules relaxed for P2SH addresses
The IsStandard() rules have been almost completely removed for P2SH
redemption scripts, allowing applications to make use of any valid
script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
While the Bitcoin protocol has always supported these types of script,
actually using them on mainnet has been previously inconvenient as
standard Bitcoin Core nodes wouldn't relay them to miners, nor would
most miners include them in blocks they mined.
bitcoin-tx
It has been observed that many of the RPC functions offered by bitcoind are
"pure functions", and operate independently of the bitcoind wallet. This
included many of the RPC "raw transaction" API functions, such as
createrawtransaction.
bitcoin-tx is a newly introduced command line utility designed to enable easy
manipulation of bitcoin transactions. A summary of its operation may be
obtained via "bitcoin-tx --help" Transactions may be created or signed in a
manner similar to the RPC raw tx API. Transactions may be updated, deleting
inputs or outputs, or appending new inputs and outputs. Custom scripts may be
easily composed using a simple text notation, borrowed from the bitcoin test
suite.
This tool may be used for experimenting with new transaction types, signing
multi-party transactions, and many other uses. Long term, the goal is to
deprecate and remove "pure function" RPC API calls, as those do not require a
server round-trip to execute.
Other utilities "bitcoin-key" and "bitcoin-script" have been proposed, making
key and script operations easily accessible via command line.
Mining and relay policy enhancements
Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its getblocktemplate must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.
The prioritisetransaction RPC method has been added to enable miners to
manipulate the priority of transactions on an individual basis.
Bitcoin Core now supports BIP 22 long polling, so mining software can be
notified immediately of new templates rather than having to poll periodically.
Support for BIP 23 block proposals is now available in Bitcoin Core's
getblocktemplate method. This enables miners to check the basic validity of
their next block before expending work on it, reducing risks of accidental
hardforks or mining invalid blocks.
Two new options to control mining policy:
  • -datacarrier=0/1 : Relay and mine "data carrier" (OP_RETURN) transactions
if this is 1.
  • -datacarriersize=n : Maximum size, in bytes, we consider acceptable for
"data carrier" outputs.
The relay policy has changed to more properly implement the desired behavior of not
relaying free (or very low fee) transactions unless they have a priority above the
AllowFreeThreshold(), in which case they are relayed subject to the rate limiter.
BIP 66: strict DER encoding for signatures
Bitcoin Core 0.10 implements BIP 66, which introduces block version 3, and a new
consensus rule, which prohibits non-DER signatures. Such transactions have been
non-standard since Bitcoin v0.8.0 (released in February 2013), but were
technically still permitted inside blocks.
This change breaks the dependency on OpenSSL's signature parsing, and is
required if implementations would want to remove all of OpenSSL from the
consensus code.
The same miner-voting mechanism as in BIP 34 is used: when 751 out of a
sequence of 1001 blocks have version number 3 or higher, the new consensus
rule becomes active for those blocks. When 951 out of a sequence of 1001
blocks have version number 3 or higher, it becomes mandatory for all blocks.
Backward compatibility with current mining software is NOT provided, thus miners
should read the first paragraph of "Mining and relay policy enhancements" above.
0.10.0 Change log

Detailed release notes follow. This overview includes changes that affect external
behavior, not code moves, refactors or string updates.
RPC:
  • f923c07 Support IPv6 lookup in bitcoin-cli even when IPv6 only bound on localhost
  • b641c9c Fix addnode "onetry": Connect with OpenNetworkConnection
  • 171ca77 estimatefee / estimatepriority RPC methods
  • b750cf1 Remove cli functionality from bitcoind
  • f6984e8 Add "chain" to getmininginfo, improve help in getblockchaininfo
  • 99ddc6c Add nLocalServices info to RPC getinfo
  • cf0c47b Remove getwork() RPC call
  • 2a72d45 prioritisetransaction
  • e44fea5 Add an option -datacarrier to allow users to disable relaying/mining data carrier transactions
  • 2ec5a3d Prevent easy RPC memory exhaustion attack
  • d4640d7 Added argument to getbalance to include watchonly addresses and fixed errors in balance calculation
  • 83f3543 Added argument to listaccounts to include watchonly addresses
  • 952877e Showing 'involvesWatchonly' property for transactions returned by 'listtransactions' and 'listsinceblock'. It is only appended when the transaction involves a watchonly address
  • d7d5d23 Added argument to listtransactions and listsinceblock to include watchonly addresses
  • f87ba3d added includeWatchonly argument to 'gettransaction' because it affects balance calculation
  • 0fa2f88 added includedWatchonly argument to listreceivedbyaddress/...account
  • 6c37f7f getrawchangeaddress: fail when keypool exhausted and wallet locked
  • ff6a7af getblocktemplate: longpolling support
  • c4a321f Add peerid to getpeerinfo to allow correlation with the logs
  • 1b4568c Add vout to ListTransactions output
  • b33bd7a Implement "getchaintips" RPC command to monitor blockchain forks
  • 733177e Remove size limit in RPC client, keep it in server
  • 6b5b7cb Categorize rpc help overview
  • 6f2c26a Closely track mempool byte total. Add "getmempoolinfo" RPC
  • aa82795 Add detailed network info to getnetworkinfo RPC
  • 01094bd Don't reveal whether password is <20 or >20 characters in RPC
  • 57153d4 rpc: Compute number of confirmations of a block from block height
  • ff36cbe getnetworkinfo: export local node's client sub-version string
  • d14d7de SanitizeString: allow '(' and ')'
  • 31d6390 Fixed setaccount accepting foreign address
  • b5ec5fe update getnetworkinfo help with subversion
  • ad6e601 RPC additions after headers-first
  • 33dfbf5 rpc: Fix leveldb iterator leak, and flush before gettxoutsetinfo
  • 2aa6329 Enable customising node policy for datacarrier data size with a -datacarriersize option
  • f877aaa submitblock: Use a temporary CValidationState to determine accurately the outcome of ProcessBlock
  • e69a587 submitblock: Support for returning specific rejection reasons
  • af82884 Add "warmup mode" for RPC server
  • e2655e0 Add unauthenticated HTTP REST interface to public blockchain data
  • 683dc40 Disable SSLv3 (in favor of TLS) for the RPC client and server
  • 44b4c0d signrawtransaction: validate private key
  • 9765a50 Implement BIP 23 Block Proposal
  • f9de17e Add warning comment to getinfo
Command-line options:
  • ee21912 Use netmasks instead of wildcards for IP address matching
  • deb3572 Add -rpcbind option to allow binding RPC port on a specific interface
  • 96b733e Add -version option to get just the version
  • 1569353 Add -stopafterblockimport option
  • 77cbd46 Let -zapwallettxes recover transaction meta data
  • 1c750db remove -tor compatibility code (only allow -onion)
  • 4aaa017 rework help messages for fee-related options
  • 4278b1d Clarify error message when invalid -rpcallowip
  • 6b407e4 -datadir is now allowed in config files
  • bdd5b58 Add option -sysperms to disable 077 umask (create new files with system default umask)
  • cbe39a3 Add "bitcoin-tx" command line utility and supporting modules
  • dbca89b Trigger -alertnotify if network is upgrading without you
  • ad96e7c Make -reindex cope with out-of-order blocks
  • 16d5194 Skip reindexed blocks individually
  • ec01243 --tracerpc option for regression tests
  • f654f00 Change -genproclimit default to 1
  • 3c77714 Make -proxy set all network types, avoiding a connect leak
  • 57be955 Remove -printblock, -printblocktree, and -printblockindex
  • ad3d208 remove -maxorphanblocks config parameter since it is no longer functional
Block and transaction handling:
  • 7a0e84d ProcessGetData(): abort if a block file is missing from disk
  • 8c93bf4 LoadBlockIndexDB(): Require block db reindex if any blk*.dat files are missing
  • 77339e5 Get rid of the static chainMostWork (optimization)
  • 4e0eed8 Allow ActivateBestChain to release its lock on cs_main
  • 18e7216 Push cs_mains down in ProcessBlock
  • fa126ef Avoid undefined behavior using CFlatData in CScript serialization
  • 7f3b4e9 Relax IsStandard rules for pay-to-script-hash transactions
  • c9a0918 Add a skiplist to the CBlockIndex structure
  • bc42503 Use unordered_map for CCoinsViewCache with salted hash (optimization)
  • d4d3fbd Do not flush the cache after every block outside of IBD (optimization)
  • ad08d0b Bugfix: make CCoinsViewMemPool support pruned entries in underlying cache
  • 5734d4d Only remove actualy failed blocks from setBlockIndexValid
  • d70bc52 Rework block processing benchmark code
  • 714a3e6 Only keep setBlockIndexValid entries that are possible improvements
  • ea100c7 Reduce maximum coinscache size during verification (reduce memory usage)
  • 4fad8e6 Reject transactions with excessive numbers of sigops
  • b0875eb Allow BatchWrite to destroy its input, reducing copying (optimization)
  • 92bb6f2 Bypass reloading blocks from disk (optimization)
  • 2e28031 Perform CVerifyDB on pcoinsdbview instead of pcoinsTip (reduce memory usage)
  • ab15b2e Avoid copying undo data (optimization)
  • 341735e Headers-first synchronization
  • afc32c5 Fix rebuild-chainstate feature and improve its performance
  • e11b2ce Fix large reorgs
  • ed6d1a2 Keep information about all block files in memory
  • a48f2d6 Abstract context-dependent block checking from acceptance
  • 7e615f5 Fixed mempool sync after sending a transaction
  • 51ce901 Improve chainstate/blockindex disk writing policy
  • a206950 Introduce separate flushing modes
  • 9ec75c5 Add a locking mechanism to IsInitialBlockDownload to ensure it never goes from false to true
  • 868d041 Remove coinbase-dependant transactions during reorg
  • 723d12c Remove txn which are invalidated by coinbase maturity during reorg
  • 0cb8763 Check against MANDATORY flags prior to accepting to mempool
  • 8446262 Reject headers that build on an invalid parent
  • 008138c Bugfix: only track UTXO modification after lookup
P2P protocol and network code:
  • f80cffa Do not trigger a DoS ban if SCRIPT_VERIFY_NULLDUMMY fails
  • c30329a Add testnet DNS seed of Alex Kotenko
  • 45a4baf Add testnet DNS seed of Andreas Schildbach
  • f1920e8 Ping automatically every 2 minutes (unconditionally)
  • 806fd19 Allocate receive buffers in on the fly
  • 6ecf3ed Display unknown commands received
  • aa81564 Track peers' available blocks
  • caf6150 Use async name resolving to improve net thread responsiveness
  • 9f4da19 Use pong receive time rather than processing time
  • 0127a9b remove SOCKS4 support from core and GUI, use SOCKS5
  • 40f5cb8 Send rejects and apply DoS scoring for errors in direct block validation
  • dc942e6 Introduce whitelisted peers
  • c994d2e prevent SOCKET leak in BindListenPort()
  • a60120e Add built-in seeds for .onion
  • 60dc8e4 Allow -onlynet=onion to be used
  • 3a56de7 addrman: Do not propagate obviously poor addresses onto the network
  • 6050ab6 netbase: Make SOCKS5 negotiation interruptible
  • 604ee2a Remove tx from AlreadyAskedFor list once we receive it, not when we process it
  • efad808 Avoid reject message feedback loops
  • 71697f9 Separate protocol versioning from clientversion
  • 20a5f61 Don't relay alerts to peers before version negotiation
  • b4ee0bd Introduce preferred download peers
  • 845c86d Do not use third party services for IP detection
  • 12a49ca Limit the number of new addressses to accumulate
  • 35e408f Regard connection failures as attempt for addrman
  • a3a7317 Introduce 10 minute block download timeout
  • 3022e7d Require sufficent priority for relay of free transactions
  • 58fda4d Update seed IPs, based on bitcoin.sipa.be crawler data
  • 18021d0 Remove bitnodes.io from dnsseeds.
Validation:
  • 6fd7ef2 Also switch the (unused) verification code to low-s instead of even-s
  • 584a358 Do merkle root and txid duplicates check simultaneously
  • 217a5c9 When transaction outputs exceed inputs, show the offending amounts so as to aid debugging
  • f74fc9b Print input index when signature validation fails, to aid debugging
  • 6fd59ee script.h: set_vch() should shift a >32 bit value
  • d752ba8 Add SCRIPT_VERIFY_SIGPUSHONLY (BIP62 rule 2) (test only)
  • 698c6ab Add SCRIPT_VERIFY_MINIMALDATA (BIP62 rules 3 and 4) (test only)
  • ab9edbd script: create sane error return codes for script validation and remove logging
  • 219a147 script: check ScriptError values in script tests
  • 0391423 Discourage NOPs reserved for soft-fork upgrades
  • 98b135f Make STRICTENC invalid pubkeys fail the script rather than the opcode
  • 307f7d4 Report script evaluation failures in log and reject messages
  • ace39db consensus: guard against openssl's new strict DER checks
  • 12b7c44 Improve robustness of DER recoding code
  • 76ce5c8 fail immediately on an empty signature
Build system:
  • f25e3ad Fix build in OS X 10.9
  • 65e8ba4 build: Switch to non-recursive make
  • 460b32d build: fix broken boost chrono check on some platforms
  • 9ce0774 build: Fix windows configure when using --with-qt-libdir
  • ea96475 build: Add mention of --disable-wallet to bdb48 error messages
  • 1dec09b depends: add shared dependency builder
  • c101c76 build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix
  • e432a5f build: add option for reducing exports (v2)
  • 6134b43 Fixing condition 'sabotaging' MSVC build
  • af0bd5e osx: fix signing to make Gatekeeper happy (again)
  • a7d1f03 build: fix dynamic boost check when --with-boost= is used
  • d5fd094 build: fix qt test build when libprotobuf is in a non-standard path
  • 2cf5f16 Add libbitcoinconsensus library
  • 914868a build: add a deterministic dmg signer
  • 2d375fe depends: bump openssl to 1.0.1k
  • b7a4ecc Build: Only check for boost when building code that requires it
Wallet:
  • b33d1f5 Use fee/priority estimates in wallet CreateTransaction
  • 4b7b1bb Sanity checks for estimates
  • c898846 Add support for watch-only addresses
  • d5087d1 Use script matching rather than destination matching for watch-only
  • d88af56 Fee fixes
  • a35b55b Dont run full check every time we decrypt wallet
  • 3a7c348 Fix make_change to not create half-satoshis
  • f606bb9 fix a possible memory leak in CWalletDB::Recover
  • 870da77 fix possible memory leaks in CWallet::EncryptWallet
  • ccca27a Watch-only fixes
  • 9b1627d [Wallet] Reduce minTxFee for transaction creation to 1000 satoshis
  • a53fd41 Deterministic signing
  • 15ad0b5 Apply AreSane() checks to the fees from the network
  • 11855c1 Enforce minRelayTxFee on wallet created tx and add a maxtxfee option
GUI:
  • c21c74b osx: Fix missing dock menu with qt5
  • b90711c Fix Transaction details shows wrong To:
  • 516053c Make links in 'About Bitcoin Core' clickable
  • bdc83e8 Ensure payment request network matches client network
  • 65f78a1 Add GUI view of peer information
  • 06a91d9 VerifyDB progress reporting
  • fe6bff2 Add BerkeleyDB version info to RPCConsole
  • b917555 PeerTableModel: Fix potential deadlock. #4296
  • dff0e3b Improve rpc console history behavior
  • 95a9383 Remove CENT-fee-rule from coin control completely
  • 56b07d2 Allow setting listen via GUI
  • d95ba75 Log messages with type>QtDebugMsg as non-debug
  • 8969828 New status bar Unit Display Control and related changes
  • 674c070 seed OpenSSL PNRG with Windows event data
  • 509f926 Payment request parsing on startup now only changes network if a valid network name is specified
  • acd432b Prevent balloon-spam after rescan
  • 7007402 Implement SI-style (thin space) thoudands separator
  • 91cce17 Use fixed-point arithmetic in amount spinbox
  • bdba2dd Remove an obscure option no-one cares about
  • bd0aa10 Replace the temporary file hack currently used to change Bitcoin-Qt's dock icon (OS X) with a buffer-based solution
  • 94e1b9e Re-work overviewpage UI
  • 8bfdc9a Better looking trayicon
  • b197bf3 disable tray interactions when client model set to 0
  • 1c5f0af Add column Watch-only to transactions list
  • 21f139b Fix tablet crash. closes #4854
  • e84843c Broken addresses on command line no longer trigger testnet
  • a49f11d Change splash screen to normal window
  • 1f9be98 Disable App Nap on OSX 10.9+
  • 27c3e91 Add proxy to options overridden if necessary
  • 4bd1185 Allow "emergency" shutdown during startup
  • d52f072 Don't show wallet options in the preferences menu when running with -disablewallet
  • 6093aa1 Qt: QProgressBar CPU-Issue workaround
  • 0ed9675 [Wallet] Add global boolean whether to send free transactions (default=true)
  • ed3e5e4 [Wallet] Add global boolean whether to pay at least the custom fee (default=true)
  • e7876b2 [Wallet] Prevent user from paying a non-sense fee
  • c1c9d5b Add Smartfee to GUI
  • e0a25c5 Make askpassphrase dialog behave more sanely
  • 94b362d On close of splashscreen interrupt verifyDB
  • b790d13 English translation update
  • 8543b0d Correct tooltip on address book page
Tests:
  • b41e594 Fix script test handling of empty scripts
  • d3a33fc Test CHECKMULTISIG with m == 0 and n == 0
  • 29c1749 Let tx (in)valid tests use any SCRIPT_VERIFY flag
  • 6380180 Add rejection of non-null CHECKMULTISIG dummy values
  • 21bf3d2 Add tests for BoostAsioToCNetAddr
  • b5ad5e7 Add Python test for -rpcbind and -rpcallowip
  • 9ec0306 Add CODESEPARATOFindAndDelete() tests
  • 75ebced Added many rpc wallet tests
  • 0193fb8 Allow multiple regression tests to run at once
  • 92a6220 Hook up sanity checks
  • 3820e01 Extend and move all crypto tests to crypto_tests.cpp
  • 3f9a019 added list/get received by address/ account tests
  • a90689f Remove timing-based signature cache unit test
  • 236982c Add skiplist unit tests
  • f4b00be Add CChain::GetLocator() unit test
  • b45a6e8 Add test for getblocktemplate longpolling
  • cdf305e Set -discover=0 in regtest framework
  • ed02282 additional test for OP_SIZE in script_valid.json
  • 0072d98 script tests: BOOLAND, BOOLOR decode to integer
  • 833ff16 script tests: values that overflow to 0 are true
  • 4cac5db script tests: value with trailing 0x00 is true
  • 89101c6 script test: test case for 5-byte bools
  • d2d9dc0 script tests: add tests for CHECKMULTISIG limits
  • d789386 Add "it works" test for bitcoin-tx
  • df4d61e Add bitcoin-tx tests
  • aa41ac2 Test IsPushOnly() with invalid push
  • 6022b5d Make script_{valid,invalid}.json validation flags configurable
  • 8138cbe Add automatic script test generation, and actual checksig tests
  • ed27e53 Add coins_tests with a large randomized CCoinViewCache test
  • 9df9cf5 Make SCRIPT_VERIFY_STRICTENC compatible with BIP62
  • dcb9846 Extend getchaintips RPC test
  • 554147a Ensure MINIMALDATA invalid tests can only fail one way
  • dfeec18 Test every numeric-accepting opcode for correct handling of the numeric minimal encoding rule
  • 2b62e17 Clearly separate PUSHDATA and numeric argument MINIMALDATA tests
  • 16d78bd Add valid invert of invalid every numeric opcode tests
  • f635269 tests: enable alertnotify test for Windows
  • 7a41614 tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli from the environment
  • 5122ea7 tests: fix forknotify.py on windows
  • fa7f8cd tests: remove old pull-tester scripts
  • 7667850 tests: replace the old (unused since Travis) tests with new rpc test scripts
  • f4e0aef Do signature-s negation inside the tests
  • 1837987 Optimize -regtest setgenerate block generation
  • 2db4c8a Fix node ranges in the test framework
  • a8b2ce5 regression test only setmocktime RPC call
  • daf03e7 RPC tests: create initial chain with specific timestamps
  • 8656dbb Port/fix txnmall.sh regression test
  • ca81587 Test the exact order of CHECKMULTISIG sig/pubkey evaluation
  • 7357893 Prioritize and display -testsafemode status in UI
  • f321d6b Add key generation/verification to ECC sanity check
  • 132ea9b miner_tests: Disable checkpoints so they don't fail the subsidy-change test
  • bc6cb41 QA RPC tests: Add tests block block proposals
  • f67a9ce Use deterministically generated script tests
  • 11d7a7d [RPC] add rpc-test for http keep-alive (persistent connections)
  • 34318d7 RPC-test based on invalidateblock for mempool coinbase spends
  • 76ec867 Use actually valid transactions for script tests
  • c8589bf Add actual signature tests
  • e2677d7 Fix smartfees test for change to relay policy
  • 263b65e tests: run sanity checks in tests too
Miscellaneous:
  • 122549f Fix incorrect checkpoint data for testnet3
  • 5bd02cf Log used config file to debug.log on startup
  • 68ba85f Updated Debian example bitcoin.conf with config from wiki + removed some cruft and updated comments
  • e5ee8f0 Remove -beta suffix
  • 38405ac Add comment regarding experimental-use service bits
  • be873f6 Issue warning if collecting RandSeed data failed
  • 8ae973c Allocate more space if necessary in RandSeedAddPerfMon
  • 675bcd5 Correct comment for 15-of-15 p2sh script size
  • fda3fed libsecp256k1 integration
  • 2e36866 Show nodeid instead of addresses in log (for anonymity) unless otherwise requested
  • cd01a5e Enable paranoid corruption checks in LevelDB >= 1.16
  • 9365937 Add comment about never updating nTimeOffset past 199 samples
  • 403c1bf contrib: remove getwork-based pyminer (as getwork API call has been removed)
  • 0c3e101 contrib: Added systemd .service file in order to help distributions integrate bitcoind
  • 0a0878d doc: Add new DNSseed policy
  • 2887bff Update coding style and add .clang-format
  • 5cbda4f Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope
  • b4a72a7 contrib/linearize: split output files based on new-timestamp-year or max-file-size
  • e982b57 Use explicit fflush() instead of setvbuf()
  • 234bfbf contrib: Add init scripts and docs for Upstart and OpenRC
  • 01c2807 Add warning about the merkle-tree algorithm duplicate txid flaw
  • d6712db Also create pid file in non-daemon mode
  • 772ab0e contrib: use batched JSON-RPC in linarize-hashes (optimization)
  • 7ab4358 Update bash-completion for v0.10
  • 6e6a36c contrib: show pull # in prompt for github-merge script
  • 5b9f842 Upgrade leveldb to 1.18, make chainstate databases compatible between ARM and x86 (issue #2293)
  • 4e7c219 Catch UTXO set read errors and shutdown
  • 867c600 Catch LevelDB errors during flush
  • 06ca065 Fix CScriptID(const CScript& in) in empty script case
Credits

Thanks to everyone who contributed to this release:
  • 21E14
  • Adam Weiss
  • Aitor Pazos
  • Alexander Jeng
  • Alex Morcos
  • Alon Muroch
  • Andreas Schildbach
  • Andrew Poelstra
  • Andy Alness
  • Ashley Holman
  • Benedict Chan
  • Ben Holden-Crowther
  • Bryan Bishop
  • BtcDrak
  • Christian von Roques
  • Clinton Christian
  • Cory Fields
  • Cozz Lovan
  • daniel
  • Daniel Kraft
  • David Hill
  • Derek701
  • dexX7
  • dllud
  • Dominyk Tiller
  • Doug
  • elichai
  • elkingtowa
  • ENikS
  • Eric Shaw
  • Federico Bond
  • Francis GASCHET
  • Gavin Andresen
  • Giuseppe Mazzotta
  • Glenn Willen
  • Gregory Maxwell
  • gubatron
  • HarryWu
  • himynameismartin
  • Huang Le
  • Ian Carroll
  • imharrywu
  • Jameson Lopp
  • Janusz Lenar
  • JaSK
  • Jeff Garzik
  • JL2035
  • Johnathan Corgan
  • Jonas Schnelli
  • jtimon
  • Julian Haight
  • Kamil Domanski
  • kazcw
  • kevin
  • kiwigb
  • Kosta Zertsekel
  • LongShao007
  • Luke Dashjr
  • Mark Friedenbach
  • Mathy Vanvoorden
  • Matt Corallo
  • Matthew Bogosian
  • Micha
  • Michael Ford
  • Mike Hearn
  • mrbandrews
  • mruddy
  • ntrgn
  • Otto Allmendinger
  • paveljanik
  • Pavel Vasin
  • Peter Todd
  • phantomcircuit
  • Philip Kaufmann
  • Pieter Wuille
  • pryds
  • randy-waterhouse
  • R E Broadley
  • Rose Toomey
  • Ross Nicoll
  • Roy Badami
  • Ruben Dario Ponticelli
  • Rune K. Svendsen
  • Ryan X. Charles
  • Saivann
  • sandakersmann
  • SergioDemianLerner
  • shshshsh
  • sinetek
  • Stuart Cardall
  • Suhas Daftuar
  • Tawanda Kembo
  • Teran McKinney
  • tm314159
  • Tom Harding
  • Trevin Hofmann
  • Whit J
  • Wladimir J. van der Laan
  • Yoichi Hirai
  • Zak Wilcox
As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Also lots of thanks to the bitcoin.org website team David A. Harding and Saivann Carignan.
Wladimir
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007480.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

BCT Coin - Dedicated to BitCoinTalk.org

What is BCT Coin?
A revolutionary crypto currency, the BCT Coin is developed chiefly to support the much deserved charitable institutions, reward ever helpful Bitcoin Talk community members and facilitate others in need of financial aid to earn impartially through crypto currency mining.
[Special note to our dear BitCoin Talk community members: BCT Coin is your incentive for being part of the best and the most supportive crypto currency forum on the World Wide Web. BCT Coin is your much deserved reward for shaping the prolific and unbiased online fiscal alternatives compared to the irrational ‘only rich get richer’ real-world paper economy. Thank You!]
How is BCT Coin different from other crypto currencies?
• Developed to aid charitable institutions
• Part of premine to be gifted to BitCoin Talk community members
• All the charitable donations will be on BitCoin Talk community name
• Offer you an option to ‘Mine, Earn & Share your Profits with a Charity’
Coin Specifications
Only 51,26,423 Million Total Coins
49% Premined
60 Seconds Block Time
120 Blocks Transaction Confirmations
Utilizes SHA3 Keccak Proof-Of-Work
Difficulty Retargeted Based on KGW Every 4 Minutes
Block Information
1-10 Blocks 2,50,000 Coins Per Block ( Premine )
11-2000 Blocks 2 Coins Per Block to Control Mine Strom
2001 – 100000 Blocks 9 Coins Per Block
100001 – 200000 Blocks 7 Coins Per Block
200001 – 300000 Blocks 6 Coins Per Block
300001 – 400000 Blocks 3 Coins Per Block
400001 – 414048 Blocks 1 Coin Per Block
Config File
BctCoin.conf
server=1
rpcuser=bctcoin
rpcpassword=bctcoin
rpcport=2456
p2pport=2455
addnode= 208.167.233.222
addnode= 76.74.178.182
addnode= 69.90.132.171
addnode= 66.172.11.153
Premined Coin Breakup
70% Premine Coins Goes to World Wide Selected Charities
25% Premine Coins Will be insenteved to BitCoinTalk.org Forum 5000 active users above 100 Posts.
3% Premine Coins Given to Bounties
2% Premine Coins Dedicated to Development & Promotions
submitted by bctcoin to bctcoin [link] [comments]

Tutorial User Authentication System with NodeJS - Email confirmation prelude Coin Decrypt: How to turn Bitcoin (BTC) into a passive income - Paxex Masternode Setup Guide! ADDING NODES TO DEV WALLET FOR FASTER SYNCING What Are Bitcoin Blocks and Bitcoin Confirmations ? What happens when you send bitcoins to someone else? - George Levy

One confirmation is enough for small Bitcoin payments less than $1,000. 3. Enough for payments $1,000 - $10,000. Most exchanges require 3 confirmations for deposits. 6. Enough for large payments between $10,000 - $1,000,000. Six is standard for most transactions to be considered secure. 60. Suggested for large payments greater than $1,000,000. Less is likely fine, but this is to be safe! How ... Once bitcoin sent to bitcoin address you will see unconfirmed transaction appear with pending confirmation on transaction history page. It will be fully confirmed and available for trade with 3 bitcoin network confirmation. It can take around 30 minutes or more time depending on bitcoin network so do not worry and wait quietly. Cold Wallet: A Bitcoin wallet that is in cold storage (not connected to the internet). Confirmations: A bitcoin transaction is considered unconfirmed until it has been included in a block on the blockchain, at which point it has one confirmation. Each additional block is another confirmation. Coinbase requires 3 confirmations to consider a ... Click the large blue Download Bitcoin Core button to download the Bitcoin Core installer to your Downloads folder. Optional: Verify the release signatures. If you know how to use PGP, you should also click the Verify Release Signatures link on the download page to download a signed list of SHA256 file hashes. The 0.11 and later releases are signed by Wladimir J. van der Laan’s releases key w What is a confirmation? A confirmation is when a transaction makes its way from the transaction pool in to the blockchain. Or in other words, it's when a bitcoin transaction becomes irreversable. Easy. How does it work? Okay... When you make a bitcoin transaction, you're basically inserting a line of data in to the bitcoin network. This transaction data then gets relayed from node to node ...

[index] [49055] [32396] [19615] [40566] [30914] [27337] [35877] [24701] [21219] [41143]

Tutorial User Authentication System with NodeJS - Email confirmation prelude

The Bitcoin Fake Transaction by RBF method is a software that uses the double expense method to send false bitcoin transactions. The btc sent by this method is not confirmed, it is false ... In this video I talk about what are the next step. This is not a coding video, more a talk :) Ben Awad link How to Send an Email in Node.js: https://www.yout... George Levy is an instructor at Blockchain Institute of Technology, and the author of the best selling online courses Blockchain and Bitcoin Fundamentals, Cryptocurrency Fundamentals, Bitcoin ... This video is unavailable. Watch Queue Queue. Watch Queue Queue Queue THIS IS NOT INVESTMENT ADVICE When looking for projects to put our earned BTC into, we want projects with active Dev(s), positive community, and a working product. Paxex meets these requirements ...

#