BTC Address ms6HYbv1YGKbxgQEEHa7TZBQvKRTcSQmtZ BlockCypher

Drop Zone - A Decentralized Marketplace Built on Bitcoin

An anonymous decentralized local marketplace built on Bitcoin.
[link]

IoTeX.io

IoTeX is the next generation IoT-oriented blockchain platform with strong scalability, privacy, isolatability and developability for incubating new IoT applications and ecosystems.
[link]

03-12 21:45 - 'Please Send Testnet3 BTC <3 (address in body)' (self.Bitcoin) by /u/eolszewski removed from /r/Bitcoin within 34-44min

'''
2NBMEXKnqAaj318G8pHzaAjj4aC9DEXLvE9
'''
Please Send Testnet3 BTC <3 (address in body)
Go1dfish undelete link
unreddit undelete link
Author: eolszewski
submitted by removalbot to removalbot [link] [comments]

Scalenet and Testnet4 are online and open for business

Over the years, some people have made use of testnet3 to test out scaling performance, and have spammed testnet3 with 32 MB blocks. This has caused testnet3 to get kinda bloated; the blockchain now takes an hour or so to sync, which slows down development. Other people have wanted to do stress testing, but have specifically wanted to avoid inconveniencing other people by spamming testnet3, and have therefore not done so. This slows down development too. To address this issue, I created two new networks: testnet4 and scalenet.
Testnet4 is intended to be a low-volume quick-syncing blockchain which is ideal for testing out new transaction formats or applications. It has a 2 MB default block size limit, and comes with aserti3 parameters that make the difficulty recover quickly to CPU-mineable levels. It should remain easy to sync on a low-end VPS or old laptop.
Scalenet is intended to be a high-volume blockchain which is ideal for spamming and stress testing software. It comes with a 256 MB initial default block size limit, and uses aserti3 parameters that make it more suitable for accurately simulating mainnet mining difficulty (though it retains the 20-minute difficulty rule). In order to prevent storage costs from getting unreasonable for a testnet, scalenet will be reset every 6-12 months by invalidating the block at height 10,001 and adding a new checkpoint. Scalenet is intended to be feasible to run on a mid-range desktop computer with some strain.
Testnet4 and scalenet are now online and essentially complete. The code for both has been merged into BCHN and Electron Cash. Testnet4 has also been successfully synced to by Knuth, Bitcoin Unlimited, and libbitcoincashj. Block explorers for both are available, thanks to Axel Gembe (who runs the code) and sickpig (who wrote the code):
http://tbch4.loping.net:3002/
http://sbch.loping.net:3003/
The testnet4 and scalenet MRs were opened on Aug 19th and Aug 27th, and both were merged on Sep 17th. Scalenet reached height 10,000 on October 3rd.
Testnet4 and Scalenet support are present in the master branch of BCHN, and will be included in the next release of BCHN. Some other software (e.g. Electron Cash) already has support in their latest release, but most is still pending.
See also: https://bitcoincashresearch.org/t/testnet4-and-scalenet/148/7
submitted by jtoomim to btc [link] [comments]

[DEVELOPMENT] Bitcoind IPV4 testnet port (18332) is failing to bind

[SOLVED] Thanks for everyone that have helped!


Hello everyone, this is a development problem that I'm currently having. Since the BTC Development sub is kind of inactive and I couldn't find any rule contraty to posting about BTC Development, I'll try my luck in here as I'm hopeless already. I've posted on BTC Stack Exchange but no answers also. Please, don't get me wrong, I'm trying to solve this problem for many days now, I've looked up everywhere for this.
I'm new to Bitcoin development and I'm currently having difficulties trying to make RPC calls from a Docker Container to a Bitcoin-Core daemon running in a SSH server. I suppose that the problem may be with Firewall or closed ports, but I also do not know much about Network settings.
I'm using nbobtc/bitcoind-php package to make the RPC calls with HTTP requests, and it is running in a Docker container. I'm sure the container is functional and is not the problem.
So here's what happening: when I run bitcoind in root user (but normal also won't work) in my SSH server, the IPV4 testnet port seems to be not opened. This message goes up when I run bitcoind:
Binding RPC on address 0.0.0.0 port 18332 failed.
Here's what my bitcoin.conf looks like (I want to use testnet in here). I'm using Bitcoin-Core "subversion": "Satoshi:0.17.1".
server=1 debug=net txindex=1 testnet=1 rpcuser=userb rpcpassword=test test.rpcport=18332 # I've already tried allowing the IP these 3 ways: # rpcallowip=192.168.xx.xx # My machine's IP # rpcallowip=172.19.x.x/xx # Docker's NBOBTC container IP # rpcallowip=0.0.0.0/0 # Allowing all IP datadir=/home/bitcoin-dev/.bitcoin debuglogfile=/home/bitcoin-dev/.bitcoin/debug.log 
Here's what appears in debug.log right after I run Bitcoind:
2019-05-06T14:43:10Z Bitcoin Core version v0.17.1 (release build) 2019-05-06T14:43:10Z InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1 2019-05-06T14:43:10Z Assuming ancestors of block 0000000000000037a8cd3e06cd5edbfe9dd1dbcc5dacab279376ef7cfc2b4c75 have valid signatures. 2019-05-06T14:43:10Z Setting nMinimumChainWork=00000000000000000000000000000000000000000000007dbe94253893cbd463 2019-05-06T14:43:10Z Using the 'sse4(1way),sse41(4way)' SHA256 implementation 2019-05-06T14:43:10Z Default data directory /root/.bitcoin 2019-05-06T14:43:10Z Using data directory /home/bitcoin-dev/.bitcoin/testnet3 2019-05-06T14:43:10Z Using config file /home/bitcoin-dev/.bitcoin/bitcoin.conf 2019-05-06T14:43:10Z Using at most 125 automatic connections (1024 file descriptors available) 2019-05-06T14:43:10Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements 2019-05-06T14:43:10Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements 2019-05-06T14:43:10Z Using 4 threads for script verification 2019-05-06T14:43:10Z scheduler thread start 2019-05-06T14:43:10Z Binding RPC on address 0.0.0.0 port 18332 failed. 2019-05-06T14:43:10Z HTTP: creating work queue of depth 16 2019-05-06T14:43:10Z Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcauth for rpcauth auth generation. 2019-05-06T14:43:10Z HTTP: starting 4 worker threads 2019-05-06T14:43:10Z Using wallet directory /home/bitcoin-dev/.bitcoin/testnet3/wallets 2019-05-06T14:43:10Z init message: Verifying wallet(s)... 2019-05-06T14:43:10Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010) 2019-05-06T14:43:10Z Using wallet wallet.dat 2019-05-06T14:43:10Z BerkeleyEnvironment::Open: LogDir=/home/bitcoin-dev/.bitcoin/testnet3/wallets/database ErrorFile=/home/bitcoin-dev/.bitcoin/testnet3/wallets/db.log 2019-05-06T14:43:10Z net: setting try another outbound peer=false 2019-05-06T14:43:10Z Cache configuration: 2019-05-06T14:43:10Z * Using 2.0MiB for block index database 2019-05-06T14:43:10Z * Using 56.0MiB for transaction index database 2019-05-06T14:43:10Z * Using 8.0MiB for chain state database 2019-05-06T14:43:10Z * Using 384.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space) 2019-05-06T14:43:10Z init message: Loading block index... 2019-05-06T14:43:10Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/blocks/index 2019-05-06T14:43:10Z Opened LevelDB successfully 2019-05-06T14:43:10Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/blocks/index: 0000000000000000 2019-05-06T14:43:19Z LoadBlockIndexDB: last block file = 161 2019-05-06T14:43:19Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=755, size=30875345, heights=1513309...1514061, time=2019-04-29...2019-05-03) 2019-05-06T14:43:19Z Checking all blk files are present... 2019-05-06T14:43:20Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/chainstate 2019-05-06T14:43:20Z Opened LevelDB successfully 2019-05-06T14:43:20Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/chainstate: 2686d59caeb1917c 2019-05-06T14:43:20Z Loaded best chain: hashBestChain=00000000b3b6a5db140b6058b7abe5cb00d8af61afd2a237ae3468cd36e387fa height=927391 date=2016-09-08T15:04:00Z progress=0.311180 2019-05-06T14:43:20Z init message: Rewinding blocks... 2019-05-06T14:43:29Z init message: Verifying blocks... 2019-05-06T14:43:29Z Verifying last 6 blocks at level 3 2019-05-06T14:43:29Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE]. 2019-05-06T14:43:29Z No coin database inconsistencies in last 6 blocks (500 transactions) 2019-05-06T14:43:29Z block index 19450ms 2019-05-06T14:43:29Z Opening LevelDB in /home/bitcoin-dev/.bitcoin/testnet3/indexes/txindex 2019-05-06T14:43:30Z Opened LevelDB successfully 2019-05-06T14:43:30Z Using obfuscation key for /home/bitcoin-dev/.bitcoin/testnet3/indexes/txindex: 0000000000000000 2019-05-06T14:43:30Z init message: Loading wallet... 2019-05-06T14:43:30Z txindex thread start 2019-05-06T14:43:30Z [default wallet] nFileVersion = 170100 2019-05-06T14:43:30Z [default wallet] Keys: 2005 plaintext, 0 encrypted, 2005 w/ metadata, 2005 total. Unknown wallet records: 1 2019-05-06T14:43:30Z Syncing txindex with block chain from height 694205 2019-05-06T14:43:30Z [default wallet] Wallet completed loading in 123ms 2019-05-06T14:43:30Z [default wallet] setKeyPool.size() = 2000 2019-05-06T14:43:30Z [default wallet] mapWallet.size() = 7 2019-05-06T14:43:30Z [default wallet] mapAddressBook.size() = 4 2019-05-06T14:43:30Z mapBlockIndex.size() = 1515581 2019-05-06T14:43:30Z nBestHeight = 927391 2019-05-06T14:43:30Z torcontrol thread start 2019-05-06T14:43:30Z Bound to [::]:18333 2019-05-06T14:43:30Z Bound to 0.0.0.0:18333 2019-05-06T14:43:30Z init message: Loading P2P addresses... 2019-05-06T14:43:30Z Loaded 10420 addresses from peers.dat 36ms 2019-05-06T14:43:30Z init message: Loading banlist... 2019-05-06T14:43:30Z Loaded 0 banned node ips/subnets from banlist.dat 29ms 2019-05-06T14:43:30Z init message: Starting network threads... 2019-05-06T14:43:30Z net thread start 2019-05-06T14:43:30Z dnsseed thread start 2019-05-06T14:43:30Z addcon thread start 2019-05-06T14:43:30Z msghand thread start 2019-05-06T14:43:30Z init message: Done loading 2019-05-06T14:43:30Z opencon thread start 
After all that appears above, there are just "UpdateTip", "Requesting block", "received block" and "getdata" messages. (so the P2P port, 18333, works).

And here is when I netstat:

sudo netstat -nap|grep bitcoin|grep LISTEN
tcp 0 0 0.0.0.0:18333 0.0.0.0:* LISTEN 31185/bitcoind tcp6 0 0 :::18332 :::* LISTEN 31185/bitcoind tcp6 0 0 :::18333 :::* LISTEN 31185/bitcoind 
Thank you in advance!

PS: A few days ago I could make it work when running bitcoind with root user, but now even that won't solve the problem.
submitted by VicPietro to Bitcoin [link] [comments]

Decred Journal – August 2018

Note: you can read this on GitHub (link), Medium (link) or old Reddit (link) to see all the links.

Development

dcrd: Version 1.3.0 RC1 (Release Candidate 1) is out! The main features of this release are significant performance improvements, including some that benefit SPV clients. Full release notes and downloads are on GitHub.
The default minimum transaction fee rate was reduced from 0.001 to 0.0001 DCkB. Do not try to send such small fee transactions just yet, until the majority of the network upgrades.
Release process was changed to use release branches and bump version on the master branch at the beginning of a release cycle. Discussed in this chat.
The codebase is ready for the new Go 1.11 version. Migration to vgo module system is complete and the 1.4.0 release will be built using modules. The list of versioned modules and a hierarchy diagram are available here.
The testnet was reset and bumped to version 3.
Comments are welcome for the proposal to implement smart fee estimation, which is important for Lightning Network.
@matheusd recorded a code review video for new Decred developers that explains how tickets are selected for voting.
dcrwallet: Version 1.3.0 RC1 features new SPV sync mode, new ticket buyer, new APIs for Decrediton and a host of bug fixes. On the dev side, dcrwallet also migrated to the new module system.
Decrediton: Version 1.3.0 RC1 adds the new SPV sync mode that syncs roughly 5x faster. The feature is off by default while it receives more testing from experienced users. Other notable changes include a design polish and experimental Politeia integration.
Politeia: Proposal editing is being developed and has a short demo. This will allow proposal owners to edit their proposal in response to community feedback before voting begins. The challenges associated with this feature relate to updating censorship tokens and maintaining a clear history of which version comments were made on. @fernandoabolafio produced this architecture diagram which may be of interest to developers.
@degeri joined to perform security testing of Politeia and found several issues.
dcrdata: mainnet explorer upgraded to v2.1 with several new features. For users: credit/debit tx filter on address page, showing miner fees on coinbase transaction page, estimate yearly ticket rewards on main page, cool new hamburger menu and keyboard navigation. For developers: new chain parameters page, experimental Insight API support, endpoints for coin supply and block rewards, testnet3 support. Lots of minor API changes and frontend tweaks, many bug fixes and robustness improvements.
The upcoming v3.0 entered beta and is deployed on beta.dcrdata.org. Check out the new charts page. Feedback and bug reports are appreciated. Finally, the development version v3.1.0-pre is on alpha.dcrdata.org.
Android: updated to be compatible with the latest SPV code and is syncing, several performance issues are worked on. Details were posted in chat. Alpha testing has started, to participate please join #dev and ask for the APK.
iOS: backend is mostly complete, as well as the front end. Support for devices with smaller screens was improved. What works now: creating and recovering wallets, listing of transactions, receiving DCR, displaying and scanning QR codes, browsing account information, SPV connection to peers, downloading headers. Some bugs need fixing before making testable builds.
Ticket splitting: v0.6.0 beta released with improved fee calculation and multiple bug fixes.
docs: introduced new Governance section that grouped some old articles as well as the new Politeia page.
@Richard-Red created a concept repository sandbox with policy documents, to illustrate the kind of policies that could be approved and amended by Politeia proposals.
decred.org: 8 contributors added and 4 removed, including 2 advisors (discussion here).
decredmarketcap.com is a brand new website that shows the most accurate DCR market data. Clean design, mobile friendly, no javascript required.
Dev activity stats for August: 239 active PRs, 219 commits, 25k added and 11k deleted lines spread across 8 repositories. Contributions came from 2-10 developers per repository. (chart)

Network

Hashrate: went from 54 to 76 PH/s, the low was 50 and the new all-time high is 100 PH/s. BeePool share rose to ~50% while F2Pool shrank to 30%, followed by coinmine.pl at 5% and Luxor at 3%.
Staking: 30-day average ticket price is 95.6 DCR (+3.0) as of Sep 3. During the month, ticket price fluctuated between a low of 92.2 and high of 100.5 DCR. Locked DCR represented between 3.8 and 3.9 million or 46.3-46.9% of the supply.
Nodes: there are 217 public listening and 281 normal nodes per dcred.eu. Version distribution: 2% at v1.4.0(pre) (dev builds), 5% on v1.3.0 (RC1), 62% on v1.2.0 (-5%), 22% on v1.1.2 (-2%), 6% on v1.1.0 (-1%). Almost 69% of nodes are v.1.2.0 and higher and support client filters. Data snapshot of Aug 31.

ASICs

Obelisk posted 3 email updates in August. DCR1 units are reportedly shipping with 1 TH/s hashrate and will be upgraded with firmware to 1.5 TH/s. Batch 1 customers will receive compensation for missed shipment dates, but only after Batch 5 ships. Batch 2-5 customers will be receiving the updated slim design.
Innosilicon announced the new D9+ DecredMaster: 2.8 TH/s at 1,230 W priced $1,499. Specified shipping date was Aug 10-15.
FFMiner DS19 claims 3.1 TH/s for Blake256R14 at 680 W and simultaneously 1.55 TH/s for Blake2B at 410 W, the price is $1,299. Shipping Aug 20-25.
Another newly noticed miner offer is this unit that does 46 TH/s at 2,150 W at the price of $4,720. It is shipping Nov 2018 and the stats look very close to Pangolin Whatsminer DCR (which has now a page on asicminervalue).

Integrations

www.d1pool.com joined the list of stakepools for a total of 16.
Australian CoinTree added DCR trading. The platform supports fiat, there are some limitations during the upgrade to a new system but also no fees in the "Early access mode". On a related note, CoinTree is working on a feature to pay household bills with cryptocurrencies it supports.
Three new OTC desks were added to exchanges page at decred.org.
Two mobile wallets integrated Decred:
Reminder: do your best to understand the security and privacy model before using any wallet software. Points to consider: who controls the seed, does the wallet talk to the nodes directly or via middlemen, is it open source or not?

Adoption

Merchants:

Marketing

Targeted advertising report for August was posted by @timhebel. Facebook appeal is pending, some Google and Twitter campaigns were paused and some updated. Read more here.
Contribution to the @decredproject Twitter account has evolved over the past few months. A #twitter_ops channel is being used on Matrix to collaboratively draft and execute project account tweets (including retweets). Anyone with an interest in contributing to the Twitter account can ask for an invitation to the channel and can start contributing content and ideas there for evaluation by the Twitter group. As a result, no minority or unilateral veto over tweets is possible. (from GitHub)

Events

Attended:
For those willing to help with the events:
BAB: Hey all, we are gearing up for conference season. I have a list of places we hope to attend but need to know who besides @joshuam and @Haon are willing to do public speaking, willing to work booths, or help out at them? You will need to be well versed on not just what is Decred, but the history of Decred etc... DM me if you are interested. (#event_planning)
The Decred project is looking for ambassadors. If you are looking for a fun cryptocurrency to get involved in send me a DM or come talk to me on Decred slack. (@marco_peereboom, longer version here)

Media

Decred Assembly episode 21 is available. @jy-p and lead dcrwallet developer @jrick discussed SPV from Satoshi's whitepaper, how it can be improved upon and what's coming in Decred.
Decred Assembly episodes 1-21 are available in audio only format here.
New instructional articles on stakey.club: Decrediton setup, Deleting the wallet, Installing Go, Installing dcrd, dcrd as a Linux service. Available in both English and Portuguese.
Decred scored #32 in the August issue of Chinese CCID ratings. The evaluation model was explained in this interview.
Satis Group rated Decred highly in their cryptoasset valuation research report (PDF). This was featured by several large media outlets, but some did not link to or omitted Decred entirely, citing low market cap.
Featured articles:
Articles:
Videos:

Community Discussions

Community stats:
Comm systems news:
After another debate about chat systems more people began testing and using Matrix, leading to some gardening on that platform:
Highlights:
Reddit: substantive discussion about Decred cons; ecosystem fund; a thread about voter engagement, Politeia UX and trolling; idea of a social media system for Decred by @michae2xl; how profitable is the Obelisk DCR1.
Chats: cross-chain trading via LN; plans for contractor management system, lower-level decision making and contractor privacy vs transparency for stakeholders; measuring dev activity; what if the network stalls, multiple implementations of Decred for more resilience, long term vision behind those extensive tests and accurate comments in the codebase; ideas for process for policy documents, hosting them in Pi and approving with ticket voting; about SPV wallet disk size, how compact filters work; odds of a wallet fetching a wrong block in SPV; new module system in Go; security of allowing Android app backups; why PoW algo change proposal must be specified in great detail; thoughts about NIPoPoWs and SPV; prerequisites for shipping SPV by default (continued); Decred vs Dash treasury and marketing expenses, spending other people's money; why Decred should not invade a country, DAO and nation states, entangling with nation state is poor resource allocation; how winning tickets are determined and attack vectors; Politeia proposal moderation, contractor clearance, the scale of proposals and decision delegation, initial Politeia vote to approve Politeia itself; chat systems, Matrix/Slack/Discord/RocketChat/Keybase (continued); overview of Korean exchanges; no breaking changes in vgo; why project fund burn rate must keep low; asymptotic behavior of Decred and other ccs, tail emission; count of full nodes and incentives to run them; Politeia proposal translations and multilingual environment.
An unusual event was the chat about double negatives and other oddities in languages in #trading.

Markets

DCR started the month at USD 56 / BTC 0.0073 and had a two week decline. On Aug 14 the whole market took a huge drop and briefly went below USD 200 billion. Bitcoin went below USD 6,000 and top 100 cryptos lost 5-30%. The lowest point coincided with Bitcoin dominance peak at 54.5%. On that day Decred dived -17% and reached the bottom of USD 32 / BTC 0.00537. Since then it went sideways in the USD 35-45 / BTC 0.0054-0.0064 range. Around Aug 24, Huobi showed DCR trading volume above USD 5M and this coincided with a minor recovery.
@ImacallyouJawdy posted some creative analysis based on ticket data.

Relevant External

StopAndDecrypt published an extensive article "ASIC Resistance is Nothing but a Blockchain Buzzword" that is much in line with Decred's stance on ASICs.
The ongoing debates about the possible Sia fork yet again demonstrate the importance of a robust dispute resolution mechanism. Also, we are lucky to have the treasury.
Mark B Lundeberg, who found a vulnerability in atomicswap earlier, published a concept of more private peer-to-peer atomic swaps. (missed in July issue)
Medium took a cautious stance on cryptocurrencies and triggered at least one project to migrate to Ghost (that same project previously migrated away from Slack).
Regulation: Vietnam bans mining equipment imports, China halts crypto events and tightens control of crypto chat groups.
Reddit was hacked by intercepting 2FA codes sent via SMS. The announcement explains the impact. Yet another data breach suggests to think twice before sharing any data with any company and shift to more secure authentication systems.
Intel and x86 dumpsterfire keeps burning brighter. Seek more secure hardware and operating systems for your coins.
Finally, unrelated to Decred but good for a laugh: yetanotherico.com.

About This Issue

This is the 5th issue of Decred Journal. It is mirrored on GitHub, Medium and Reddit. Past issues are available here.
Most information from third parties is relayed directly from source after a minimal sanity check. The authors of Decred Journal have no ability to verify all claims. Please beware of scams and do your own research.
Feedback is appreciated: please comment on Reddit, GitHub or #writers_room on Matrix or Slack.
Contributions are welcome too. Some areas are collecting content, pre-release review or translations to other languages. Check out @Richard-Red's guide how to contribute to Decred using GitHub without writing code.
Credits (Slack names, alphabetical order): bee, Haon, jazzah, Richard-Red and thedecreddigest.
submitted by jet_user to decred [link] [comments]

TESTNET Preparation

Ravencoin was launched on January 3, 2018, as a free, open source platform forked from the Bitcoin codebase. Since that time, Ravencoin has operated as a fully functional network based on the Bitcoin UTXO model. All coins have been fairly mined by a decentralized network of miners using the ASIC-resistant X16r algorithm.
Since the launch, developers have been actively working to add additional asset creation functionality to the Ravencoin core wallet client, as contemplated by Phase 2 (asset support) of the Ravencoin roadmap here.
The Ravencoin community is now able to run the current core Ravencoin client in testnet mode, in order to generate addresses that will be able to receive testnet RVN. On July 30, new asset layer features will be added to the core wallet client for use on Ravencoin’s test network. These features are expected to include additional capabilities that will facilitate the native creation, issuance and transfer of asset tokens. A revised version of the core client software will be made available for download on GitHub. This will allow for rigorous community testing of the native asset layer functionality — including the creation and issuance of testnet assets — in contemplation of the anticipated launch of this functionality on the mainnet in October.
This testnet network will be a completely independent secondary blockchain for testing purposes only, in which all tokens will have no intrinsic value and will not be traded on exchanges. The purpose of a testnet is to test features and functionality before introducing those features and functionality to the main blockchain. It is a playground to experiment and test different features with almost no cost to transact or mine blocks. During this testing phase, the Ravencoin blockchain itself will continue to maintain the same operation and functionality it has today.
To run your current wallet in testnet mode:
  1. First shutdown your current full client wallet.
  2. Create a shortcut to your raven-qt.exe with this in the target field: C:\Users\Path\to\executable\raven-qt.exe" –testnet
  3. Open the wallet by clicking on the shortcut you just made, and let the blockchain sync fully
Don't worry, this will not interfere with your regular Raven wallet, just make sure both wallets are not running at the same time. For those who are technically inclined, running in testnet mode does not overwrite any of the blockchain data or wallet files of Ravencoin’s main network. Instead, it will create a subfolder named testnet3 inside your data folder where all testnet related data and wallets reside. If you would prefer to err on the side of caution, consider running your testnet wallet on a different computer.
There are currently a couple of tools available to assist you with testnet testing.
After this testing period, it is anticipated that the community will consider adoption of the new asset-aware code. Activation will occur through the BIP9 consensus mechanism. More information on the activation process can be found here.
submitted by Under_Dark_Skies to Ravencoin [link] [comments]

Factom Protocol Information

The Factom protocol is an open source general purpose data protocol built by an international group of technology companies that extends the security of blockchain to any type of data. Just as TCP / IP enables the WWW, the Factom Protocol enables countless applications to be built on top of it.
Factom is built from scratch and has novel design implementations that set it apart from all other blockchain protocols. We are confident these features will help propel Factom to become the internet's data integrity layer. You are invited to delve into our ecosystem and we look forward to answering any questions you have.
Token and Tokenomics
While the Factom Protocol is a two token system, only the Factoid (FCT) is transferable and able to be traded on exchanges. Entry Credits (EC) are obtained by burning FCT and are used to enter data into the Factom Protocol. Entry Credits are $.001 each and that price is fixed. Therefore, if FCT is worth $1.00 and you burn it, you receive 1,000 EC. If FCT is worth $10.00 each and you burn one, you receive 10,000 EC. This brilliant two token system allows for:
  1. The value of FCT to theoretically increase the more the Factom Protocol is utilized.
  2. Companies and governments can effectively budget for entering data onto the Protocol based upon their estimated usage.
  3. Subscription systems can be setup with 3rd parties where companies and governments don't have to hold cryptocurrency if they don't want to or can't for compliance reasons. FCT are still burned for EC by the 3rd party company but the subscriber is charged a small markup for the service.
Governance
Community Discussion
Development
Block Explorers
Tools
Testnet Resources
Top Exchanges (by volume)
Education
AMAs
Wallets
Authority Node Operators
Authority Node Operators are the coalition of companies that decentralize the Factom Protocol. .
Committees and Working Groups
As the Factom Protocol is one of the most decentralized blockchain projects in existence with no central authority, committees and working groups have been formed to deal with specific tasks.
Past Newsletters
submitted by DChapman77 to factom [link] [comments]

My bch pruned testnet servers suddenly stopped getting blocks

I have a few bch nodes running on bitcoin-abc v0.16 and v0.17, on my local machine and other servers. They all suddenly stopped getting new blocks at block 1231688. We are around block 1231718 now.
I have tried adding nodes I can find and restarting bitcoind and can't get them to download the newer blocks. My testnet nodes are useless at this point. Does anyone know a way to fix this?
Here are some of the debug.log entries. After the portion below, it says "connect() to failed after select()..." for eternity.
 2018-05-08 22:43:01 * Using 2.0MiB for block index database 2018-05-08 22:43:01 * Using 8.0MiB for chain state database 2018-05-08 22:43:01 * Using 502.0MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space) 2018-05-08 22:43:01 init message: Loading block index... 2018-05-08 22:43:01 Opening LevelDB in /blocks/bch/pruned/testnet3/blocks/index 2018-05-08 22:43:01 Opened LevelDB successfully 2018-05-08 22:43:01 Using obfuscation key for /blocks/bch/pruned/testnet3/blocks/index: 0000000000000000 2018-05-08 22:43:01 Opening LevelDB in /blocks/bch/pruned/testnet3/chainstate 2018-05-08 22:43:01 Opened LevelDB successfully 2018-05-08 22:43:01 Using obfuscation key for /blocks/bch/pruned/testnet3/chainstate: 9b825e057f1ab99c 2018-05-08 22:43:07 LoadBlockIndexDB: last block file = 67 2018-05-08 22:43:07 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=6859, size=91420704, heights=0...1231688, time=2011-02-02...2018-05-08) 2018-05-08 22:43:07 Checking all blk files are present... 2018-05-08 22:43:07 LoadBlockIndexDB(): Block files have previously been pruned 2018-05-08 22:43:07 LoadBlockIndexDB: transaction index disabled 2018-05-08 22:43:07 Initializing databases... 2018-05-08 22:43:07 Loaded best chain: hashBestChain=0000000000000c1717fbd726cc2cbeae5361a2ebfc3cb50a6d1ec96fe5af4092 height=1231688 date=2018-05-08 13:09:04 progress=0.999673 2018-05-08 22:43:07 init message: Rewinding blocks... 2018-05-08 22:43:10 init message: Verifying blocks... 2018-05-08 22:43:10 Verifying last 3 blocks at level 3 2018-05-08 22:43:10 [0%]...[33%]...[66%]...[99%]...[DONE]. 2018-05-08 22:43:10 No coin database inconsistencies in last 4 blocks (12 transactions) 2018-05-08 22:43:10 block index 8758ms 2018-05-08 22:43:10 No wallet support compiled in! 2018-05-08 22:43:10 Unsetting NODE_NETWORK on prune mode 2018-05-08 22:43:10 init message: Pruning blockstore... 2018-05-08 22:43:10 mapBlockIndex.size() = 1240116 2018-05-08 22:43:10 nBestHeight = 1231688 2018-05-08 22:43:10 torcontrol thread start 2018-05-08 22:43:10 AddLocal([2600:1700:8390:84c0:14c2:d10c:4e0f:f4a3]:18333,1) 2018-05-08 22:43:10 Discover: IPv6 en0: 2600:1700:8390:84c0:14c2:d10c:4e0f:f4a3 2018-05-08 22:43:10 AddLocal([2600:1700:8390:84c0:1c10:5990:e34:863c]:18333,1) 2018-05-08 22:43:10 Discover: IPv6 en0: 2600:1700:8390:84c0:1c10:5990:e34:863c 2018-05-08 22:43:10 init message: Loading addresses... 2018-05-08 22:43:10 Leaving InitialBlockDownload (latching to false) 2018-05-08 22:43:10 Loaded 5496 addresses from peers.dat 20ms 2018-05-08 22:43:10 init message: Loading banlist... 2018-05-08 22:43:10 init message: Starting network threads... 2018-05-08 22:43:10 net thread start 2018-05-08 22:43:10 dnsseed thread start 2018-05-08 22:43:10 addcon thread start 2018-05-08 22:43:10 opencon thread start 2018-05-08 22:43:10 msghand thread start 2018-05-08 22:43:10 init message: Done loading 2018-05-08 22:43:10 Loading addresses from DNS seeds (could take a while) 2018-05-08 22:43:10 Imported mempool transactions from disk: 142 successes, 0 failed, 0 expired 2018-05-08 22:43:11 receive version message: [191.235.87.191:18333] /BUCash:1.3.0.1(EB8; AD12)/: version 80003, blocks=1220312, us=99.44.100.147:54630, peer=1 2018-05-08 22:43:11 receive version message: [88.198.36.232:18333] /Bitcoin ABC:0.17.0(EB32.0)/: version 70015, blocks=1231816, us=99.44.100.147:54643, peer=2 2018-05-08 22:43:13 receive version message: [39.106.248.45:18333] /Bitcoin ABC:0.16.1(EB8.0)/: version 70015, blocks=1231715, us=99.44.100.147:54661, peer=4 2018-05-08 22:43:13 receive version message: [195.154.177.49:18333] /Bitcoin ABC:0.17.1(EB32.0)/: version 70015, blocks=1231715, us=99.44.100.147:54675, peer=5 2018-05-08 22:43:15 receive version message: [114.215.30.211:18333] /Bitcoin ABC:0.17.0(EB32.0)/: version 70015, blocks=1155875, us=99.44.100.147:54694, peer=7 2018-05-08 22:43:16 receive version message: [[2a01:4f9:2a:4dd::2]:18333] /Bitcoin ABC:0.16.2(EB8.0)/: version 70015, blocks=1231715, us=[2600:1700:8390:84c0:1c10:5990:e34:863c]:54706, peer=8 2018-05-08 22:43:16 receive version message: [52.25.222.97:18333] /Bitcoin ABC:0.16.2(EB8.0)/: version 70015, blocks=1231715, us=99.44.100.147:54715, peer=9 2018-05-08 22:43:17 receive version message: [[2a01:4f8:160:4062::2]:18333] /Bitcoin ABC:0.17.0(EB32.0)/: version 70015, blocks=1231816, us=[2600:1700:8390:84c0:1c10:5990:e34:863c]:54726, peer=10 2018-05-08 22:43:22 connect() to 76.84.97.254:18333 failed after select(): Connection refused (61) 2018-05-08 22:43:22 connect() to 62.210.93.229:18333 failed after select(): Connection refused (61) 2018-05-08 22:43:34 connect() to 198.100.148.71:18333 failed after select(): Connection refused (61) 2018-05-08 22:43:35 connect() to 88.198.33.214:18333 failed after select(): Connection refused (61) 2018-05-08 22:43:52 receive version message: [176.61.0.224:18333] /Bitcoin ABC:0.16.2(EB8.0)/: version 70015, blocks=1231715, us=99.44.100.147:55217, peer=11 2018-05-08 22:43:53 connect() to [2a01:4f8:13b:fa4::2]:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:11 23 addresses found from DNS seeds 2018-05-08 22:44:11 dnsseed thread exit 2018-05-08 22:44:26 connect() to 136.243.139.120:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:27 connect() to 136.243.139.120:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:28 connect() to [2a01:4f8:212:3b1f::2]:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:28 connect() to [2a01:4f8:212:3b1f::2]:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:34 connect() to 35.192.12.181:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:41 connect() to 163.172.219.62:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:41 connect() to 47.90.204.241:18333 failed after select(): Connection refused (61) 2018-05-08 22:44:53 connect() to 38.102.69.206:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:10 connect() to 144.76.154.138:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:22 connect() to 39.108.13.102:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:22 connect() to 5.44.97.110:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:29 connect() to 173.249.34.172:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:35 connect() to 212.224.113.118:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:41 connect() to 198.206.134.51:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:47 connect() to 54.39.17.74:18333 failed after select(): Connection refused (61) 2018-05-08 22:45:59 connect() to 195.242.93.189:18333 failed after select(): Connection refused (61) 
Update: they are caught up now. I am not sure what the exact cause of the delay was besides maybe having to find new nodes to connect to. They were behind for about 24 hours and now it's back to normal.
submitted by 0x760xa9 to btc [link] [comments]

[Bounties] Bug hunters wanted

Testnet.BitcoinReserve.ch is looking for a few good bug hunters.
Offering $75 in BTC for fatal bugs and a sliding scale all the way down to $2 for minor typos. The first round of testing (see /BitcoinReserve) paid out over $350 to various testers.
Bitcoin Reserve allows deposit and withdrawal of Bitcoin, conversion to/from dollars and payments to other members in USD or BTC. The system is currently running on Testnet3.
I am the final and only arbiter of bounty payouts. The first person to find and report a particular bug will be paid a bounty. Subsequent reports on the same issue are helpful but will be paid a partial bounty only if they add worthwhile information. Be sure to include the URL and any supporting information with your bug reports: Bugs must be reproducible or otherwise independently observable (i.e. reviewing server logs). Larger bounties will be paid to the address you send me through a reddit personal message, smaller bounties will be paid through changetip. If bounty payouts end up exceeding 3 BTC, the contest will be paused as we examine what the hell is going on.
Again, the website is https://testnet.bitcoinreserve.ch, Happy Hunting!
Notes:
submitted by ReportingThisHere to Jobs4Bitcoins [link] [comments]

Log of AMA with particl

boldninja
Let's all give a warm welcome to Particl.io team members - @umbrah, @dasource, @litebit, @rynomster, @imyb, @ludx, @synergy - you can start asking them questions. You know the drill - wait till they respond (not more than 3 questions of backlog) so they can catch up. (edited)
umbrah Thanks @boldninja , we're ready to answer questions anytime :slightly_smiling_face:
rynomster thanks @boldninja, thanks Ark for having us
macdac Hey guys, so Ill be the first to ask, where are we as far as the mainnet release?
litebit macdac: we are waiting for Particl foundation to be approved. Paperwork is in Swiss regulator's hands and we're waiting for them to approve so they can oversee us create PART tokens and distribute PART tokens
jeffjam Since Micah seems not to be present, is he still part of the team?
litebit jeffjam: micah is still a member of the team as an advisor. he has and will continue to contribute to the Particl project. On top of that, his fiance just said yes, so he's pretty busy :slightly_smiling_face:
litebit is it ok to answer in threads @boldninja or do we usually just do a long string?
tranzer welcome Particl - just learning about you guys looks promising and interesting concept. Can I ask how much did you guys raise and currentl holdings you have (mainly asking if you have enough for years to come) ?
litebit @macdac we are waiting for Particl foundation to be approved. Paperwork is in Swiss regulator's hands and we're waiting for them to approve so they can oversee us create PART tokens and distribute PART tokens
umbrah @jeffjam micah is still a member of the team as an advisor. he has and will continue to contribute to the Particl project. On top of that, his fiance just said yes, so he's pretty busy :slightly_smiling_face:
macdac @litebit, did they say anything as far as when they will approve like an approximate date or just when they get to it?
litebit macdac: once foundation is formed we'll use a couple days to do final prep for mainnet setup and then release the clients, source and tokens
litebit @macdac once foundation is formed we'll use a couple days to do final prep for mainnet setup and then release the clients, source and tokens
ryano What is particl
litebit ryano: to put it simply, Particl will be an anonymous, crypto-agnostic marketplace. this will be a self-governed decentralized system
commodore64 Hey Particl team, can you comment on whether or not the fact that it's taking the Swiss Regulator so long to approve has anything to do with any problems that have surfaced, and if so, what those problems are, or is it typical for it to take this long?
litebit commodore64: I know Zug is getting bombarded with cryptocurrency startups.
zedsix Hi there team at Particl, will the GUI be released alongside mainnet?
litebit zedsix: we have started testing the GUI internally. There will be a testnet with the GUI prior to mainnet
macdac @litebit, and you guys are 100% sure they will approve and is just a matter or time??
umbrah @ryano to put it simply, Particl will be an anonymous, crypto-agnostic marketplace. this will be a self-governed decentralized system
tranzer Who do you see as your biggest competitior in blockchain and in traditional sense of the way atm?
mgaruccio So if it's crypto agnostic where does the value of PART come from?
litebit mgaruccio: what's good about particl is that buyers can pay in whatever coin they want, provided it's available in shapeshift. it will automatically be converted to particl. it will be the receiver's choice to sell, hold or stake particl
mr_robot @rynomster When can we expect a working beta of the marketplace? Is the team focused on developing a mobile app version that can do staking on a mobile platform as well?
rynomster @zedsix, we have started testing the GUI internally. There will be a testnet with the GUI prior to mainnet
jarunik Why should i use it and how will you ensure a vivid marketplace?
macdac Are you guys sure of the Swiss foundation approval, that they will approve?
umbrah @mgaruccio what's good about particl is that buyers can pay in whatever coin they want, provided it's available in shapeshift. it will automatically be converted to particl. it will be the receiver's choice to sell, hold or stake particl
litebit @commodore64 I know Zug is getting bombarded with cryptocurrency startups.
zedsix Long time supporter for Shadowcash/Particl since the early days. The biggest gripe I have with the transparency and delays between the team and the community/supporters/investors. This has stemmed from the Shadowcash days - do you have any plans to change the way you address any delays? NB. Nothing against your team, I love the work produced - as a long term supporter I would like to see a company take a more proactive approach to issues that have stemmed in the past and not release hype/release dates until 100% certain.
rynomster @mr_robot, In terms of our timeline, we anticpate the beta to be out mid October, that's without the reputation system.
michaelthecryptoguy Can you explain your exchange mechanism somewhat? What exactly takes place in the background? Explain the client server side of that token being exchanged to the customer receiving that different coin :coinspin:
sacode Any plans to integrate fiat gateway? I don´t see how particl can go mainstream without this feature!
b.b.2k17 will Particl team implant feature similiar to delegatation (dPoS) in order for small staker to vote on propsoal without setting a node?
umbrah @zedsix as you can probably see on twitter, blogs, 3rd party media etc, we are actively informing the community about the status of particl. good or bad. you can see this on particl.news
litebit @macdac our legal counsel is Swiss based and have been through this process before so we're trusting they have all the right docs to get the job done. We were only told it takes 2 weeks to receive the answer once they have paperwork
rynomster @mr_robot, we intend to have the reputation system in place towards the end of October, at the same time we will have the protocols and codebase audited
umbrah @sacode
commodore64 @rynomster Hi there, long-term supporter. I bought SDC back in February of 2015 and have been following the project closely the whole time. One thing I have a problem with is that you have announced the marketplace launch a number of times. For the first half of 2015 you continually said that it would be ready by the end of the year, then the same message was communicated in 2016. The constant missed deadlines have caused me concern, and now I'm still not sure what to believe about the market launch.
So why now should we believe in the October date?
umbrah @sacode yes there is a plan. there are ideas but not limited to coordinating with companies like changelly, so buyers can use credit cards. but priority is still the marketplace
zedsix ^ That's currently how I feel, everytime we receive a release date it never happens - it gets concerning when a company keeps doing this and doesn't learn from the previous time it occurs that you shouldn't release a release date if you're not 100% certain that you'll meet the timeline, @umbrah - the announcements posted on social media primarily are related to delays. I won't go into detail - we'll leave it there. (edited)
rynomster @commodore64, back then we barely had a functioning team. In 2015 the SDC team pretty much fell apart. Funding dried up and there was no real teamwork.. People work working on what they wanted to work on, and there were constantly issues arising that would take priority over the MP. Particl has a team now, as well as funding, a project manager, and we are busy growing. (edited)
sacode How will you approach sellers to use particl market?
tranzer Posting questions again : Can I ask how much did you guys raise and currentl holdings you have (mainly asking if you have enough for years to come) ? Who do you see as your biggest competitior in blockchain and in traditional sense of the way atm?
macdac Will you guys release with ringCT due October?
rynomster @macdac, ringCT is currently in testnet 3
b.b.2k17 I quite like the delegate feature in ARK. Will Particl team implant feature similiar to delegatation (dPoS) in order for small staker to vote for their delegate on propsoal without setting a node?
umbrah @sacode there are a lot of upsides for sellers to use particl market. less paper works, tax breaks (depending on location), more security for seller, not to mention cheaper. we will approach them on more than 1 way. 1 st priority however will be existing crypto sellers
commodore64 @rynomster thank you.
throwplastic @umbrah what do you mean with "existing crypto sellers" as your 1st priority?
umbrah @b.b.2k17 currently there is no plan on changing the PoS structure. I agree dPoS has their upsides, but for the product that particl is setting up, PoS is the perfect choice currenctly
synergy @commodore64 there have been governance issues that have arisen that have delayed the project but now there is a dedicated team of 15 people of which 10 are working full time
commodore64 Another question for the particl team: Will the marketplace allow the ability to create a private market that would require either registration or invitation?
mr_robot Was this answered? I'm also curious on the details of how this works michaelthecryptoguy Can you explain your exchange mechanism somewhat? What exactly takes place in the background? Explain the client server side of that token being exchanged to the customer receiving that different coin :coinspin: Posted in #trading_altcoinsToday at 6:09 PM
macdac What will be the main differences between the Part wallet and the old Umbra?
umbrah @throwplastic sorry, let me clarify. currently, there are a lot of existing sellers who are also sellers on amazon/ebay etc, also people capitalizing on selling crypto merchandize, these will be our initial users and we'll work on that growth
b.b.2k17 (dont forget slack has reply to thread feature, easier to follow the questions and answer)
rynomster @macdac, Particl is being built on the bitcoin core 0.14 codebase. We are building the GUI from the ground up, using Angular (2), and electron. Umbra used QtWebkit, and native html5 + jquery. The UI is new, as well as a way healthier backend inherited from bitcoin core
macdac Is Crz here with a different username? if not can you guys tell us how the GUI of Part is going? What is he working on now?
b.b.2k17 macdac: here is a link to their GitHub, you can see the progress: https://github.com/particl/partgui
sherp Also curious about this tranzer Posting questions again : Can I ask how much did you guys raise and currentl holdings you have (mainly asking if you have enough for years to come) ? Who do you see as your biggest competitior in blockchain and in traditional sense of the way atm? Posted in #trading_altcoinsToday at 6:15 PM
litebit Particl in it's current state is a privacy platform, so we would be in competition with privacy coins. We are testing Confidential Transactions and RingCT on our TESTNET3 atm. Monero is the only other currency using RingCT and only a view others are using CT. Particl is the first to use this tech on Bitcoin codebase. We also have a decentralized voting mechanism so projects like Decred who are excelling at governance are projects we would also be similar too.
Once our market is out we'd have competition from other decentralized marketplaces like bitbay, OpenBazaar, Syscoin's blockmarket and a couple ethereum projects in early phases of development. We'd also be competing against ecommerce sites on clearnet that are strictly centralized models.
The cool thing with the market is it'll be crypto-agnostic so no crypto would be competition. OB also will offer a crypto-agnostic market and I don't recall if Syscoin's does at this time. tranzer Who do you see as your biggest competitior in blockchain and in traditional sense of the way atm? Posted in #trading_altcoinsToday at 6:06 PM
umbrah @mr_robot what we want for particl marketplace to be is a seamless system where buyer doesn't even know he's buying particl to transact. this will be beneficial to normal users who are not familiar with crypto
b.b.2k17 macdac: here is a link to their GitHub, you can see the progress: https://github.com/particl/partgui GitHub particl/partgui partgui - Particl Angular GUI - The source for the Particl GUI.
rynomster @macdac, crz is working on the GUI wireframes still, as well as the new website design. He will be helping out with the GUI as soon as he is finished with his current tasks, to give it some polish (edited)
throwplastic @umbrah thanks for clarifying, that makes sense. Will there be any mechanisms in place to ensure that no illegal products are sold?
umbrah @tranzer currently there is openbazaar (OB), but we believe we will have more features like anonymity, staking and others.
trixter- Particl team: Will their be a 3rd party Audit for RingCT feature before forking it, and do you have an idea how much time this audit could take?
zedsix When's Particl expected to reach exchanges?
michaelthecryptoguy Can you explain your exchange mechanism somewhat? What exactly takes place in the background? Explain the client server side of that token being exchanged to the customer receiving that different coin :coinspin: Does this take place with shapeshift?
macdac Cool, thanks for all the answers guys, Do you guys have an idea of when the new website will be released? which Domain will it be Particle.io still or what?
sacode In June 1st - blog update - you told us there was 3 new faces who joined to the team. Can you reveal who they are? What's their background?
umbrah @throwplastic yes, we will put in a governance model where stakers can vote whether they are ok with putting a product in. as there are grey areas for products, this will be based on votes
litebit The main difference is codebase. Umbra was built on bitcoin .08. Particl is built on bitcoin .14. So we'll have native segwit, malleability fixes, increased security, bip65, lightning network readiness.
The privacy is increased as well. Umbra used ring-sigs and Particl is using Confidential Transactions and is testing RingCT. macdac What will be the main differences between the Part wallet and the old Umbra? Posted in #trading_altcoinsToday at 6:18 PM
@umbrah can speak to this, we're catching up sorry :slightly_smiling_face: sherp Also curious about this Posted in #trading_altcoinsToday at 6:21 PM
mr_robot How does the governance feature work and what's stopping people from making multiple accounts to collude on voting? Is it based on the reputation or staking? (edited)
umbrah @tranzer the team has raised 591 btc and roughly 250k particl. this will last the team for an expected 9 months, which is more than what we need to come up with a working marketplace. there will be a 2nd crowdfunding early next year and we will be expecting particl to be self funding after that.
jeffjam Will mainet be released with implemented ringct?
litebit Yes, definitely. It was one of our funding milestones and it'll be around 3 months to audit and correct major bugs. TESTNET3 currently has RingCT on it but we'll probably remove it for TESTNET4 because it's so raw and we're focusing on mainnet. trixter- Particl team: Will their be a 3rd party Audit for RingCT feature before forking it, and do you have an idea how much time this audit could take? Posted in #trading_altcoinsToday at 6:22 PM
trixter- @litebit thanks
michaelthecryptoguy It seems the business side of particl (picking up more clients, instead of customers to use the service) is moving faster then the developers. Any explanation on this?
litebit michaelthecryptoguy: our dev team is working full steam ahead and making sure we are testing properly. We are in the final stages of the GUI development. The Blockchain and daemon are working and in public testing.
litebit by saying clients, do you mean contributors? if so, this is exactly what we expect, as this indicates speculations. same with other successful projects
umbrah @michaelthecryptoguy by saying clients, do you mean contributors? if so, this is exactly what we expect, as this indicates speculations. same with other successful projects
zedsix When's Particl expected to reach exchanges?
litebit zedsix: we are in ongoing conversations with majority of the exchanges, in an ideal scenario we would be listed on launch date, this is a work in progress and has been given priority by team
rynomster @michaelthecryptoguy, our dev team is working full steam ahead and making sure we are testing properly. We are in the final stages of the GUI development. The Blockchain and daemon are working and in public testing.
macdac Are you guys concerned of the competition? like Bitbay and others that have or plan to release a market
litebit macdac: there have been markets around for a while. We are focusing on anonymity and decentralised governance.
imyb @zedsix we are in ongoing conversations with majority of the exchanges, in an ideal scenario we would be listed on launch date, this is a work in progress and has been given priority by team
umbrah @zedsix we are waiting for foundation to be finalized first before we can release the mainnet, then exchange. same as other coins, it has to be the exchange's discretion when to add a coin, but we have already communicated with numerous exchanges to list this, and we are seeing positive replies
sdcpod How far are you with the Gui ? Will it be in Testnet 4 and if yes when is testnet 4 ?
zedsix Thanks @umbrah / @imyb
umbrah :slightly_smiling_face:
sacode There will be a marketplace app on app store or google play? If so, when?
rynomster @macdac, there have been markets around for a while. We are focusing on anonymity and decentralised governance.
molefish Will there be a way to run the wallet at launch on Mac OS X?
litebit Original mainnet (this first one) won't have ringct. We'll need to audit the code first jeffjam so it'll be on testnet for a while before going live. we haven't contracted any party yet to do this. I'd imagine a 3 month window to audit is to be expected jeffjam Will mainet be released with implemented ringct? Posted in #trading_altcoinsToday at 6:25 PM
michaelthecryptoguy So do you blame the advertising side of particl, for these announcements, or does the finger point mostly toward the developers for not meeting there timeline?
litebit Any mobile version of the marketplace will come after the second funding round. This first seed round is to get the MVP to market. Greater enhancements will come with additional funding and larger focused teams. sacode There will be a marketplace app on app store or google play? If so, when? Posted in #trading_altcoinsToday at 6:32 PM
Yes. molefish Will there be a way to run the wallet at launch on Mac OS X? Posted in #trading_altcoinsToday at 6:32 PM
rynomster @sdcpod, right now we are working towards getting the GUI ready for public testing. Based on our estimates we will have some GUI elements ready for testing next week.
michaelthecryptoguy What is causing the team to not work insync (as one) What improvements or changes have been made in this area?
throwplastic Will there be a browser-based market or do users always have to use a dedicated particl software to make purchases?
dasource throwplastic: Particl wallet will work both in browser and as an application .. to ensure privacy you require your own particld daemon running within the same network. Whilst it is possible for it to work with external/shared daemons that is not part of the current scope to effects it has on ones privacy
sdcpod What you mean with "some elements" you mean the gui like back in sdc but like say without widgets ?
rynomster @sdcpod, there will be basic functionality, but it won't be complete as its still in development.
michaelthecryptoguy Who do you see as your main customer base? Average people that use or work with Crypto Currencies?
litebit @michaelthecryptoguy i think it's a product of the fast paced crypto ecosystem. when people's money is on the line, deadlines and firm dates are expected and we want to be as transparent as possible so we try to accomadate, but roadbumps happen and deadlines sometimes get pushed
trixter- Particl Team: Will TOR, I2P be integrated in the wallet on release?
dasource trixter-: TOR - yes I2P - no
mike where can we buy Particl now?
umbrah @michaelthecryptoguy there certainly are challenges we are expecting like any other team/company, but we believe we are working better than an average team. now that the team is well funded, we can expect fster project and more deadlines to be met. as a matter of fact, the team has already contributed more thatn 100k lines on github
commodore64 I'll ask this question again: will users be able to create a 'private market' or is everything 100% public?
dasource commodore64: Yes there will be support for Private Markets
commodore64 @dasource thanks! Has this feature been fully fleshed-out in terms of development? Like will there be an integrated invitation system or ability to create user credential authentication information? And also, will the private market be subject to its own separate governance?
dasource conceptually it is not much different to the public market other than the key to access the private channel is a secret and shared by the creator with those he wishes to invite .. there will be no governance on the private market as its impossible to govern something you cannot access
imyb @mike you will need to wait until PART hits the exchanges
litebit To start it'll be trend setters so crypto users. Big picture we'll be reaching out to vendors, sellers and buyers in countries that don't have access to the ease of amazon or ebay due to political positioning and restrictions on where they live. That's the big goal of the market michaelthecryptoguy Who do you see as your main customer base? Average people that use or work with Crypto Currencies? Posted in #trading_altcoinsToday at 6:36 PM
umbrah @commodore64 particl platform itself is a private marketplace. no one will be able to know what anyone buys/sells, thanks to the CT, RingCT features and encrypted msgs
mike does Particl have a wallet available for OTC exchanges?
macdac Will you guys make a video showcasing the wallet GUI soon?
litebit The wallet will be on testnet soon so people can be hands on with it :slightly_smiling_face: much better than video macdac Will you guys make a video showcasing the wallet GUI soon? Posted in #trading_altcoinsToday at 6:40 PM
commodore64 @umbrah so the answer is no? People won't be able to create sub-markets within the main marketplace?
sacode May i set my favorite currency and language to navigate on marketplace?
umbrah @mike particl will have a very user-friendly wallet :slightly_smiling_face:
commodore64 like with authentication restriction
litebit CHANNEL: is this method of question answering helping or hurting? it seems a mess and hard to keep up. we want to make sure everyone is being heard. Could we answer using threads instead?
umbrah @commodore64 that is a feature-based question. i'll ask one of my colleagues to answer that
mr_robot Threads would make more sense it seems
umbrah @commodore64 dasourced has answered your question in threads. and the answer is yes :slightly_smiling_face:
rynomster Our new members are: Imran, our Commercial and Partner Strategy Pierre-Alexis Ciavaldini, Talented developer * experienced in C, AngularJS, Web development Jason Eybers, Junior developer * he is still studying, but he is adding valuable things like unit tests, linting, and little things that the seniors aren't currently focused on. sacode In June 1st - blog update - you told us there was 3 new faces who joined to the team. Can you reveal who they are? What's their background? Posted in #trading_altcoinsToday at 6:23 PM
michaelthecryptoguy How do you overcome a vendor that is brand new to Crypto Currencies, that can't pay for his supplies or merchandise in crypto? Will you be working directly with any banks? (edited)
umbrah michaelthecryptoguy: working with banks would not be a good strategy. as of the moment, we will make particl marketplace to be a decentralized marketplace free from paperwork etc.
imyb michaelthecryptoguy: we are in discussions with partners who should be able to provide us with the facility to entertain these types of transactions
sacode The fact that you guys met in Hong Kong in the past, has something to do with the possibility of establishing contacts in the Chinese market? (edited)
umbrah sacode: yes :slightly_smiling_face:
litebit sacode: Establishing a prescence in China is a major reason for this Particl pivot
mr_robot Private sub markets... What would prevent that developing into unfavorable things that would bypass the community governance voting?
dasource mr_robot: Private markets are precisely that, no governance.
throwplastic But there is a way of voting certain products out by stakers from what I've gathered?
litebit Private markets are just that private, who is in there, what is happening, what is selling is all private. the network is unable to tell what is going on. similar to how signal or whatsapp encrypts on client side
commodore64 @litebit @dasource what if someone gains access to a private market and it's determined that there are undesirable products being sold in there and they take some screenshots and post it up online like in reddit or bitcoin talk or something? Is there a governance model overseeing the private markets at all?
dasource There will be no governance on private markets .. it is impossible todo.
commodore64 @dasource @rynmos
commodore64 @dasource @rynomster rynomster indicated in the main thread here that 'the network will only be supported while it is being run cleanly'. is this concern not relevant within private markets?
litebit the only way to "gain access" is for 1 or both parties to "give access" by posting these images themselves. otherwise everything is encrypted with industry standard cryptography
commodore64 like why is it relevant within the main marketplace but not within private markets? particularly if it becomes publicly known through screenshots on public channels? Like I get into a private market and take some screenshots and put them on reddit, is that not concern about the market being run cleanly?
dasource this has already been answered in another question ... you cannot govern something you cannot access .. the whole point of a private market place is that it is private by the creator and shared with those he wishes to only.. I am not sure what is the misunderstanding here? (edited)
mr_robot I think the concern is that any private market would bypass the community governance and therefor allow any kinds of black market items that could be used to hurt particl's reputation for larger more legitimate things. Ie larger sellers on Amazon wouldn't want to have anything to do with a marketplace that had screenshots of nefarious things being sold... (edited)
dasource I see your point and understand it however let me give you another example ... If you and I use Signal and we decide to trade Cuban Cigars ... you post that on the internet. Should Signal be held liable because they provided a secure means for you to communicate and trade? Particls Private Markets are no different, we are providing a means for people to trade in 100% privacy (anything from cigars to private paintings etc) .. in that environment you cannot govern because it is encrypted for everyone else. Is it possible people may use this for nefarious items? Yes... but it is also possible for that to happen on Signal or any other good encrypted chat platform. Should we stop developing for the good because a few bad actors might use it?
2cuse What about the case where people just don't vote?
umbrah 2cuse: if people do not want to vote, we cannot force them to. this however, remains a feature in the particl
b.b.2k17 this is why i would love to see dPoS
2cuse Seems like you'd have to spend allot of time voting to stop bad stuff that may pop up
throwplastic Is there a legal risk of staking if illegal products are traded on the platform?
umbrah throwplastic: the reason why we are taking a lot of time with foundation is because we want to make sure there are no loopholes in terms of legality. i'm confident that we have this covered
throwplastic Good to know, thanks!
rynomster @2cuse, the required threshold will be set quite low at first, as failed governance will be very fatal for Particl. The network will only be supported while it is being run cleanly
2cuse Hmmm ok that sounds ominous
michaelthecryptoguy Is their a current partner that can re-distribute particl or another coin, back into my choice of monetary unit? (usd, eur, rupee, peso, etc) (edited)
imyb michaelthecryptoguy: yes
mr_robot Can you explain how the governance will work and what will prevent people from gaming the system with multiple accounts?
umbrah mr_robot: the governance will be based on a staking vote (not yet final) we will ensure that there are no duplications
litebit mr_robot: for the market we're still researching and developing models of governance. a seller will need to pay a fee to list which can become expensive if gaming a system. voting will be an incentive for the network so it would become expensive to gain a majority % to manipulate voting
2cuse I could see spammers testing the governance then worth illicit goods
litebit 2cuse: of course. there is no centralized control so the network affect will be in effect :slightly_smiling_face:
macdac Will the people who were gracious enough to donate 25% or more from their bonus receive any incentive outside of just having username be mentioned?
dasource macdac: How does early access to Market sound? Open to ideas
macdac That sounds good
macdac I donated a good amount of coins
umbrah we are actively thinking of ways to reward donators. if you can think of a reasonable reward let us know :slightly_smiling_face:
dasource Thank you .. I am sure the 100s of people who genuinely missed out on the conversion will be grateful
macdac Youre welcome, ive been supporting this project since day one
macdac Early access would be nice ill think of something else and let you know
macdac Hope you guys look at the number of coins donated too when considering because I know that many people had multiple accounts and could have chosen to donate from only 1 but not the rest, I only have one Particl.io accoutn
michaelthecryptoguy Would you be willing to introduce that partner to the :ark: team? (edited)
umbrah michaelthecryptoguy: i don't see any reason not to :slightly_smiling_face:
michaelthecryptoguy :partywizard::slightly_smiling_face::sun: (edited)
michaelthecryptoguy @mike This might be something you would be interested in pursuing.
mike thanks for bringing up.
mr_robot I understand that details of particl being on what exchanges at what time is not currently possible due to the unforseen events of the delays of the terms of service. But is there still open communication with the exchanges and are they responding positively to the idea of listing particl when it's released?
umbrah mr_robot: a lot of exchanges are responding positively. we are actually expecting to be listed a few days after mainnet release, but could not confirm any of exchanges of course
commodore64 litebit, commodore64, and mr_robot @litebit @dasource what if someone gains access to a private market and it's determined that there are undesirable products being sold in there and they take some screenshots and post it up online like in reddit or bitcoin talk or something? Is there a governance model overseeing the private markets at all?
trixter- Particl Team: How much % of wallets are created and how much has been donated to this day?
dasource trixter-: 83% are ready for genesis with 125k Donated
trixter- 125k does that include the teams donation of 40k or without?
dasource that is without .. and the team will match upto 40k based on 5:1 formula ... so 125+25k=150k ... well short of the 250k we are aiming for
trixter- nice Im rooting for the project to achieve this goal. This is a uniqum in crypto that people give away money to help out other people. I hope you guys will provide an address for people to donate their staking rewards to so we can achieve this goal
sdcpod Yea staking to address function would be nice but @dasource said wont be possible im near future due another feature in the pipeline ?
umbrah we will do what we can to stake, but the priority will stil be focused on producing a marketplace
dasource I said "it was unlikely" ... however we wont know until we get down to the nitty gritty on it ... best way to donate to the cause is the increase your donation % before the genesis block
trixter- im alreaddy on 100%
sacode About marketing? Are you doing it all by yourselves or are you going to work with a specialized company?
umbrah sacode: we have a few partners in terms of Pmarketing
umbrah you might have seen taizen and leon fu videos, we have hired PR firms as well
sacode Yep i saw leon fu videos
umbrah :+1::slightly_smiling_face:
litebit we have been ramping up and beginning contracts with professionals beginning in June. in prep for mainnet and PART tokens being live in the wild
sacode So I presume we will start seeing some marketing very soon
sacode :slightly_smiling_face:
sacode This PR firms have any kind experience in crypto world?
submitted by Jarunik to ArkEcosystem [link] [comments]

PART 1: Summary (transcript) of Wednesday's AMA given by the Particl Team - Thank you to all who participated!

Below is a summary (PART 1) of our AMA held Wednesday, 2017.06.28. Thank you for everyone who participated!
Please refer to /Particl/wiki/faq for our maintained collection of questions. We ask you make sure your question hasn't already been answered before submitting. Thank you.

QUESTIONS:

Where are we as far as the mainnet release?

we are waiting for Particl foundation to be approved. Paperwork is in Swiss regulator's hands and we're waiting for them to approve so they can oversee us create PART tokens and distribute PART tokens

Did they say anything as far as when they will approve like an approximate date or just when they get to it?

once foundation is formed we'll use a couple days to do final prep for mainnet setup and then release the clients, source and tokens

and you guys are 100% sure they will approve and is just a matter or time?? Are you guys sure of the Swiss foundation approval, that they will approve?

our legal counsel is Swiss based and have been through this process before so we're trusting they have all the right docs to get the job done. We were only told it takes 2 weeks to receive the answer once they have paperwork

Since Micah seems not to be present, is he still part of the team?

micah is still a member of the team as an adviser. he has and will continue to contribute to the Particl project. On top of that, his fiance just said yes, so he's pretty busy

Can I ask how much did you guys raise and currently holdings you have (mainly asking if you have enough for years to come) ?

the team has raised 591 btc and roughly 250k particl. this will last the team for an expected 9 months, which is more than what we need to come up with a working marketplace. there will be a 2nd crowdfunding early next year and we will be expecting particl to be self funding after that.

What is particl

to put it simply, Particl will be an anonymous, crypto-agnostic marketplace. this will be a self-governed decentralized system

Hey Particl team, can you comment on whether or not the fact that it's taking the Swiss Regulator so long to approve has anything to do with any problems that have surfaced, and if so, what those problems are, or is it typical for it to take this long?

I know Zug is getting bombarded with cryptocurrency startups.

Hi there team at Particl, will the GUI be released alongside mainnet?

we have started testing the GUI internally. There will be a testnet with the GUI prior to mainnet

Who do you see as your biggest competitor in blockchain and in traditional sense of the way atm?

there have been markets around for a while. We are focusing on anonymity and decentralized governance.
Particl in it's current state is a privacy platform, so we would be in competition with privacy coins. We are testing Confidential Transactions and RingCT on our TESTNET3 atm. Monero is the only other currency using RingCT and only a view others are using CT. Particl is the first to use this tech on Bitcoin codebase. We also have a decentralized voting mechanism so projects like Decred who are excelling at governance are projects we would also be similar too.
Once our market is out we'd have competition from other decentralized marketplaces like bitbay, OpenBazaar, Syscoin's blockmarket and a couple ethereum projects in early phases of development. We'd also be competing against ecommerce sites on clearnet that are strictly centralized models.
The cool thing with the market is it'll be crypto-agnostic so no crypto would be competition. OB also will offer a crypto-agnostic market and I don't recall if Syscoin's does at this time.

So if it's crypto agnostic where does the value of PART come from?

what's good about particl is that buyers can pay in whatever coin they want, provided it's available in shapeshift. it will automatically be converted to particl. it will be the receiver's choice to sell, hold or stake particl

When can we expect a working beta of the marketplace? Is the team focused on developing a mobile app version that can do staking on a mobile platform as well?

In terms of our timeline, we anticpate the beta to be out mid October, that's without the reputation system.
we intend to have the reputation system in place towards the end of October, at the same time we will have the protocols and codebase audited

Long time supporter for Shadowcash/Particl since the early days. The biggest gripe I have with the transparency and delays between the team and the community/supporters/investors. This has stemmed from the Shadowcash days - do you have any plans to change the way you address any delays? NB. Nothing against your team, I love the work produced - as a long term supporter I would like to see a company take a more proactive approach to issues that have stemmed in the past and not release hype/release dates until 100% certain.

as you can probably see on twitter, blogs, 3rd party media etc, we are actively informing the community about the status of particl. good or bad. you can see this on https://particl.news

Can you explain your exchange mechanism somewhat? What exactly takes place in the background? Explain the client server side of that token being exchanged to the customer receiving that different coin

what we want for particl marketplace to be is a seamless system where buyer doesn't even know he's buying particl to transact. this will be beneficial to normal users who are not familiar with crypto

Any plans to integrate fiat gateway? I don´t see how particl can go mainstream without this feature!

yes there is a plan. there are ideas but not limited to coordinating with companies like changelly, so buyers can use credit cards. but priority is still the marketplace

will Particl team implant feature similiar to delegatation (dPoS) in order for small staker to vote on propsoal without setting a node? I quite like the delegate feature in ARK. Will Particl team implant feature similiar to delegatation (dPoS) in order for small staker to vote for their delegate on propsoal without setting a node?

currently there is no plan on changing the PoS structure. I agree dPoS has their upsides, but for the product that particl is setting up, PoS is the perfect choice currenctly

Hi there, long-term supporter. I bought SDC back in February of 2015 and have been following the project closely the whole time. One thing I have a problem with is that you have announced the marketplace launch a number of times. For the first half of 2015 you continually said that it would be ready by the end of the year, then the same message was communicated in 2016. The constant missed deadlines have caused me concern, and now I'm still not sure what to believe about the market launch. So why now should we believe in the October date?

back then we barely had a functioning team. In 2015 the SDC team pretty much fell apart. Funding dried up and there was no real teamwork.. People work working on what they wanted to work on, and there were constantly issues arising that would take priority over the MP. Particl has a team now, as well as funding, a project manager, and we are busy growing.
there have been governance issues that have arisen that have delayed the project but now there is a dedicated team of 15 people of which 10 are working full time

How will you approach sellers to use particl market?

there are a lot of upsides for sellers to use particl market. less paper works, tax breaks (depending on location), more security for seller, not to mention cheaper. we will approach them on more than 1 way. 1 st priority however will be existing crypto sellers

what do you mean with "existing crypto sellers" as your 1st priority?

sorry, let me clarify. currently, there are a lot of existing sellers who are also sellers on amazon/ebay etc, also people capitalizing on selling crypto merchandize, these will be our initial users and we'll work on that growth

thanks for clarifying, that makes sense. Will there be any mechanisms in place to ensure that no illegal products are sold?

yes, we will put in a governance model where stakers can vote whether they are ok with putting a product in. as there are grey areas for products, this will be based on votes

Will you guys release with ringCT due October?

ringCT is currently in testnet 3

Will the marketplace allow the ability to create a private market that would require either registration or invitation?

will users be able to create a 'private market' or is everything 100% public? Yes there will be support for Private Markets

thanks! Has this feature been fully fleshed-out in terms of development? Like will there be an integrated invitation system or ability to create user credential authentication information? And also, will the private market be subject to its own separate governance?

conceptually it is not much different to the public market other than the key to access the private channel is a secret and shared by the creator with those he wishes to invite .. there will be no governance on the private market as its impossible to govern something you cannot access
particl platform itself is a private marketplace. no one will be able to know what anyone buys/sells, thanks to the CT, RingCT features and encrypted msgs

so the answer is no? People won't be able to create sub-markets within the main marketplace? like with authentication restriction

yes

What will be the main differences between the Part wallet and the old Umbra?

Particl is being built on the bitcoin core 0.14 codebase. We are building the GUI from the ground up, using Angular (2), and electron. Umbra used QtWebkit, and native html5 + jquery. The UI is new, as well as a way healthier backend inherited from bitcoin core
The main difference is codebase. Umbra was built on bitcoin .08. Particl is built on bitcoin .14. So we'll have native segwit, malleability fixes, increased security, bip65, lightning network readiness.
The privacy is increased as well. Umbra used ring-sigs and Particl is using Confidential Transactions and is testing RingCT.

Is Crz here with a different username? if not can you guys tell us how the GUI of Part is going? What is he working on now?

here is a link to their GitHub, you can see the progress: https://github.com/particl/partgui
crz is working on the GUI wireframes still, as well as the new website design. He will be helping out with the GUI as soon as he is finished with his current tasks, to give it some polish

Will their be a 3rd party Audit for RingCT feature before forking it, and do you have an idea how much time this audit could take?

Yes, definitely. It was one of our funding milestones and it'll be around 3 months to audit and correct major bugs. TESTNET3 currently has RingCT on it but we'll probably remove it for TESTNET4 because it's so raw and we're focusing on mainnet.

When's Particl expected to reach exchanges?

we are in ongoing conversations with majority of the exchanges, in an ideal scenario we would be listed on launch date, this is a work in progress and has been given priority by team
we are waiting for foundation to be finalized first before we can release the mainnet, then exchange. same as other coins, it has to be the exchange's discretion when to add a coin, but we have already communicated with numerous exchanges to list this, and we are seeing positive replies

Do you guys have an idea of when the new website will be released? which Domain will it be Particle.io still or what?

We’re working on it right now. It’ll be https://particl.io

In June 1st - blog update - you told us there was 3 new faces who joined to the team. Can you reveal who they are? What's their background?

Our new members are:

Will mainet be released with implemented ringct?

Original mainnet (this first one) won't have ringct. We'll need to audit the code first jeffjam so it'll be on testnet for a while before going live. we haven't contracted any party yet to do this. I'd imagine a 3 month window to audit is to be expected jeffjam Will mainet be released with implemented ringct?

It seems the business side of particl (picking up more clients, instead of customers to use the service) is moving faster then the developers. Any explanation on this?

by saying clients, do you mean contributors? if so, this is exactly what we expect, as this indicates speculations. same with other successful projects
our dev team is working full steam ahead and making sure we are testing properly. We are in the final stages of the GUI development. The Blockchain and daemon are working and in public testing.

So do you blame the advertising side of particl, for these announcements, or does the finger point mostly toward the developers for not meeting there timeline? What is causing the team to not work insync (as one) What improvements or changes have been made in this area?

i think it's a product of the fast paced crypto ecosystem. when people's money is on the line, deadlines and firm dates are expected and we want to be as transparent as possible so we try to accomadate, but roadbumps happen and deadlines sometimes get pushed
there certainly are challenges we are expecting like any other team/company, but we believe we are working better than an average team. now that the team is well funded, we can expect faster project and more deadlines to be met. as a matter of fact, the team has already contributed more that 100k lines on github
submitted by sexystick to Particl [link] [comments]

anyone can help me checking what's the problem on my raspberry c-lightning

I am running bitcoind 0.15.1 from Bitcoin Core (testnet3) and c-lightning. Bitcoin Core can run without problem. I can build successfully but when i run "lightningd/lightningd --network=testnet --log-level=debug"
[email protected]:~/pihdd/home/lightning $ lightningd/lightningd --network=testnet --log-level=debug 2018-02-26T16:12:05.000Z lightningd(10507): Trying to guess public addresses... 2018-02-26T16:12:05.000Z lightningd(10507): Address 10.0.1.201:9735 is not routable 2018-02-26T16:12:05.001Z lightningd(10507): Failed to connect 10 socket: Network is unreachable 2018-02-26T16:12:05.002Z lightningd(10507): testing /home/pi/pihdd/home/lightning/lightningd/lightning_channeld 2018-02-26T16:12:05.007Z lightningd(10507): testing /home/pi/pihdd/home/lightning/lightningd/lightning_closingd 2018-02-26T16:12:05.011Z lightningd(10507): testing /home/pi/pihdd/home/lightning/lightningd/lightning_gossipd 2018-02-26T16:12:05.016Z lightningd(10507): testing /home/pi/pihdd/home/lightning/lightningd/lightning_hsmd 2018-02-26T16:12:05.021Z lightningd(10507): testing /home/pi/pihdd/home/lightning/lightningd/lightning_onchaind 2018-02-26T16:12:05.025Z lightningd(10507): testing /home/pi/pihdd/home/lightning/lightningd/lightning_openingd 2018-02-26T16:12:05.883Z lightningd(10507): Client: Received message 11 from client 2018-02-26T16:12:06.049Z lightningd(10507): Loaded 0 invoices from DB 2018-02-26T16:12:06.050Z lightningd(10507): Client: Received message 9 from client 2018-02-26T16:12:06.051Z lightning_gossipd(10515): pid 10515, msgfd 13 2018-02-26T16:12:06.053Z lightningd(10507): Loaded 0 channels from DB 2018-02-26T16:12:06.191Z lightningd(10507): Adding block 1286352: 00000000000003103573ddc55daba410455b20afe5a1e9be62f5e07f7176ec30 lightningd: Binding rpc socket to 'lightning-rpc': Input/output error
seems my socket can never bind to lightning-rpc (Error is 5). I tried many way and no luck.
this is my fstab UUID="XXXX-XXXX" /home/pi/pihdd exfat uid=pi,gid=pi,umask=0022,sync,auto,nosuid,rw,nouser 0 0
anything else may come to your mind that I can check? let me know! thanks!
submitted by cocacokareddit to bitcoinLN [link] [comments]

Testnet helpers, make your debug logs available again for us and add bandwidth metering with this

Make sure your node is logging data properly.
The following instructions are for Debian 8.2 (jessie). You may have to make some adjustments for other OSes. Post a comment if you have trouble.
Run these lines:
sudo apt-get install lighttpd tcpstat sudo touch /vawww/html/debug-filtered.log.gz sudo touch /vawww/html/bw.log sudo chown `whoami`.`whoami` /vawww/html/debug-filtered.log.gz sudo chown `whoami`.`whoami` /vawww/html/bw.log 
You may want to do the first line by itself to get through the password prompt before pasting in the other lines. Also, you might end up using /vawww/ instead of /vawww/html/, depending on your server and configuration.
Next, run crontab -e and add this line at the bottom:
31 */2 * * * grep -v "eject " ~/.bitcoin/testnet3/debug.log | grep -v " tx " | grep -v "received: inv" | grep -v "sending: inv" | grep -v "received: getdata" | grep -v "received getdata" | grep -v "AcceptToMemoryPool" | gzip > /vawww/html/debug-filtered.log.gz 
That should compress the log files down to around 1 to 5% of their original size, rewriting it every hour. This compression will take about 1 minute (every 2 hours at 31 minutes past the hour) on most machines. If it takes too much CPU on your machine, you can reduce the frequency by changing the */2 to something like */4 (once every 4 hours).
Check to make sure you have the right version of tcpstat. There are two different programs with the same name:
sudo tcpstat -h | grep tcpstat # should say "tcpstat version 1.5", not "tcpstat 0.1 (c) J. Taimisto 2005-2013" 
If you have the wrong version, you should go to http://www.frenchfries.net/paul/tcpstat/ and rebuild from source.
Next, run this every time your machine is restarted either in a screen or in the background:
giface=eth0 # unless it's not sudo tcpstat -f "port 18333" -o "%s,\t%B\n" -i $giface 0.1 -F > /vawww/html/bw.log 
Open port 80 on your firewall if necessary. Then tell me your IP address (and optionally add it to the spreadsheet), and I'll grab the log files and include them in my analyses.
Edit: added AcceptToMemoryPool filter.
Edit2: Changed paths to /vawww/html/ for the lighttpd default.
submitted by jtoomim to bitcoinxt [link] [comments]

A BIP proposal for conveniently referring to confirmed transactions | Clark Moody | Jul 14 2017

Clark Moody on Jul 14 2017:
(copying from GitHub per jonasschnelli's request)
I can understand the desire to keep all reference strings to the nice
14-character version by keeping the data payload to 40 bits, but it
seems to place artificial limitations on the format (year 2048 & 8191
transactions). I also understand that this might be addressed with
Version 1 encoding. But current blocks are not that far from having
8191 transactions.
You could go with a variable-length encoding similar to Bitcoin's
variable ints and gain the benefit of having a format that will work
for very large blocks and the very far future.
Also, the Bech32 reference libraries allow encoding from byte arrays
into the base-5 arrays native to Bech32. It seems like bit-packing to
these 40 bits might be overkill. As an alternative you could have one
bit-packed byte to start:

First two bits are the protocol version, supporting values 0-3

V = ((protocol version) & 0x03) << 6

Next two bits are magic for the blockchain

0x00 = Bitcoin

0x01 = Testnet3

0x02 = Byte1 is another coin's magic code (gives 256 options)

0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)

M = (magic & 0x03) << 4

Next two bits are the byte length of the block reference

B = ((byte length of block reference) & 0x03) << 2

Final two bits are the byte length of the transaction index

T = ((byte length of transaction index) & 0x03)

Assemble into the first byte

Byte0 = V | M | B | T
This gives you up to 3 bytes for each block and transaction reference,
which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.
Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx
reference bytes]
So the shortest data part would have 3 bytes in it, with the reference
version 0 genesis coinbase transaction having data part 0x050000.
I know this is a departure from your vision, but it would be much more
flexible for the long term.
Clark
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014799.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Alternative chain support for payment protocol | Ross Nicoll | Aug 09 2015

Ross Nicoll on Aug 09 2015:
BIP 70 currently lists two networks, main and test (inferred as
testnet3) for payment protocol requests. This means that different
testnets cannot be supported trivially, and the protocol cannot be used
for alternative coins (or, lacks context to indicate which coin the
request applies to, which is particularly dangerous in cases where coins
share address prefixes).
I propose adding a new optional "genesis" field as a 16 byte sequence
containing the SHA-256 hash of the genesis block of the network the
request belongs to, uniquely identifying chains without any requirement
for a central registry. For backwards compatibility, the "network" field
would contain "main" for Bitcoin main net, "test" for Bitcoin testnet3,
and "other" for other networks apart from those two.
I'd appreciate initial feedback on the idea, and if there's no major
objections I'll raise this as a BIP.
Ross
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010051.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

[Bounties] Bug Hunters and Testers.

Testnet.BitcoinReserve.ch is looking for a few good bug hunters.
Offering $75 in BTC for fatal bugs and a sliding scale all the way down to $2 for minor typos.
Bitcoin Reserve allows deposit and withdrawal of Bitcoin, conversion to/from dollars and payments to other members in USD or BTC. The system is currently running on Testnet3.
I am the final and only arbiter of bounty payouts. The first person to find and report a particular bug will be paid a bounty. Subsequent reports on the same issue are helpful but will be paid a partial bounty only if they add worthwhile information. Be sure to include the URL and any supporting information with your bug reports: Bugs must be reproducible or otherwise independently observable (i.e. reviewing server logs). Larger bounties will be paid to the address you send me through a reddit personal message, smaller bounties will be paid through changetip. If bounty payouts end up exceeding 3 BTC, the contest will be paused as we examine what the hell is going on.
/BitcoinReserve has been setup to handle bug reports and discussion.
Notes:
Happy Hunting!
Again, the website is https://testnet.bitcoinreserve.ch and post bugs to our subreddit /BitcoinReserve
submitted by ReportingThisHere to Jobs4Bitcoins [link] [comments]

Alternate HD path structure: BIP, blog, or wat? | Matt Smith | Jun 19 2015

Matt Smith on Jun 19 2015:
Hey guys,
The crew at Gem is considering a new HD wallet path structure for our
wallets, which are coin-agnostic, that separates the coin_type field
into two fields as such:
m / purpose' / network' / asset_type' / account' / change / index
where network refers to the blockchain (0 - bitcoin, 1 - testnet3, 2 -
litecoin, etc) and the new asset_type refers to the kind of asset to be
held in accounts below that path (Open Assets, Omni, Counterparty).
The intent is to allow us to validate the address format, select the
appropriate daemon to scan for tokenized assets, and choose multiple
blockchain data sources (that may not know anything about token systems
running on the blockchain they expose) relevant to an HDNode in the
wallet using only information in the HDNode's path -- without having to
maintain an explicit mapping of coin_type -> network.
For example, we already have the issue of mapping network identifiers
because of the lack of standardization across cryptocurrency libraries
which ends up being ugly and obnoxious to maintain, i.e.
netcode_map = {
testnet: testnet3,
bitcoin_testnet: testnet3,
testnet3: testnet3,
XTN: testnet3, ...
}
netcode_i_want = netcode_map[netcode_returned_by_libwhatever]
We want to avoid maintaining a similar asset_type_to_blockchain mapping.
Additionally, it would be helpful for utxo selection to exclude utxos
tied to assets based on path.
BIP43 seems to suggest that we request a BIP number and publish an
informational BIP specifying the new purpose. If that's not appropriate,
then maybe we just need to publish the information in a blog post to
allow any wallet developers who want to to implement
import_from_gem_structure.
I was also wondering if anyone had previously suggested something
similar that I missed when cruising the mailing list archives on the
subject.
Thanks,

Matt Smith | Gem
https://gem.co | GH: @thedoctor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x63331857.asc
Type: application/pgp-keys
Size: 2164 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/33922f4c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/33922f4c/attachment.sig>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008908.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Streamium peerjs configuration - Sorry ... Mind trying again later? Error ... net::ERR_CONNECTION_REFUSED

I cloned Streamium from Github and published the files on a AWS machine. When I try to to start a broadcast I get:
Sorry, we're unable to start the stream right now. Mind trying again later?
In the Chrome Web Developers tool, I get:
WebSocket connection to 'wss://localhost:9000/peerjs?key=peerjs&id=llll&token=i5kksalh7m841jor' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
It seems that PeerJs has not been configured properly. I tried to change parameters in app/config.json, but I am not sure what to change. Could someone help me?
Thanks, Alejandro
Here is my app/config.json 'use strict';
var config = { network: 'livenet', appPrefix: '', // For testnet, set to '/t' otherNetwork: 'testnet', linkToOther: '/t', CHAIN: 'https://api.chain.com/v2/bitcoin/', // CHAIN: 'https://api.chain.com/v2/testnet3/', CHAIN_API_KEY: '45c19e4cfc41937124964a7a7931b427', BLOCKCYPHER: 'https://api.blockcypher.com/v1/btc/', BLOCKCYPHERTX: 'https://api.blockcypher.com/v1/btc/' + 'main' // For testnet, use: 'test3' + '/txs/', peerServers: [ { key: 'peerjs', host: 'localhost', port: 9000, }, { key: 'peerjs', host: 'localhost', port: 9000, } ], peerJS: { debug: 0, secure: true, config: { 'iceServers': [ {url:'stun:stun.l.google.com:19302'}, {url:'stun:stun1.l.google.com:19302'}, {url:'stun:stun2.l.google.com:19302'}, {url:'stun:stun3.l.google.com:19302'}, {url:'stun:stun4.l.google.com:19302'}, {url:'stun:stun01.sipphone.com'}, {url:'stun:stun.ekiga.net'}, {url:'stun:stun.fwdnet.net'}, {url:'stun:stun.ideasip.com'}, {url:'stun:stun.iptel.org'}, {url:'stun:stun.rixtelecom.se'}, {url:'stun:stun.schlund.de'}, {url:'stun:stunserver.org'}, {url:'stun:stun.softjoys.com'}, {url:'stun:stun.voiparound.com'}, {url:'stun:stun.voipbuster.com'}, {url:'stun:stun.voipstunt.com'}, {url:'stun:stun.voxgratia.org'}, {url:'stun:stun.xten.com'}, ] } }, userMedia: { audio: true, video: true }, confidenceDelay: 5000, confidenceTarget: 0.85, confidenceRetry: 15, analytics: true, DEBUG: false, PROVIDER_COLOR: 'green', defaults: { providerStream: 'sexybabe69', providerPrivkey: '75d79298ce12ea86863794f0080a14b424d9169f7e325fad52f60753eb072afc', providerAddress: 'n2Py6DKziqwmSWMxN8vdz7tAV6aabK9LCR', providerRate: 0.001, clinetPrivkey: 'a831f26d457a5e7edc0cef0eac6fc02dd6a2c032c9e3da8a622f3a26b9aa5fe4', clientChange: 'n3pNMEeVec5sMMhMoUseojUTSHw3LDAY3a', rateUSD: 10 } };
submitted by aavella77 to Streamium [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]

Blockchain tutorial 25: Testnet and faucets Bitcoin Testnet HowTo Send a Bitcoin Transaction with JavaScript & Bitcore ... EXSCUDO WEEKLY #26- EON Testnet Stage 3 Successfully Launched! GRIN Receiving Transactions [testnet3]

Bitcoin addresses can be generated on this site https://www.bitaddress.org, but the test network needs m or n at the beginning of the address, where can those be generated? Stack Exchange Network Stack Exchange network consists of 176 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. A Bitcoin address, or simply address, is an identifier of 26-35 alphanumeric characters, beginning with the number 1, 3 or bc1 that represents a possible destination for a bitcoin payment. Addresses can be generated at no cost by any user of Bitcoin. For example, using Bitcoin Core, one can click "New Address" and be assigned an address.It is also possible to get a Bitcoin address using an ... this address is a standard P2PKH testnet address, and can be derived from a typical priv/public keypair, by adding the testnet prefix.There is a page you can play with - in Step 4 you would change the default prefix "00" to "6F", and get a corresponding address. The composition of such an address and further details are again in the wiki. Yes, in bitcoin an address begins with "1" or "3", in testnet bitcoin an address begins with "m" or "2". In the case of Ethereum both addresses can be used, but you can't transfer ether from Rinkeby to the real network. The same for Eos, you can have a testnet account only in testnet and not in mainnet and viceversa. Can the testnet bitcoin/ether/litecoin network be reset? Yes, it could be and ... Run bitcoin-qt or bitcoind with the -testnet flag to use the testnet (or put testnet=1 in the bitcoin.conf file). There have been three generations of testnet. Testnet2 was just the first testnet reset with a different genesis block, because people were starting to trade testnet coins for real money. Testnet3 is the current test network. It was ...

[index] [21332] [2760] [11593] [36793] [48382] [28250] [11917] [29936] [47537] [5524]

Blockchain tutorial 25: Testnet and faucets

How to test wallet and receive grin from outside world. http://bit.ly/bitcoincourse (full course) This will demo creating a Bitcoin address and transaction using JavaScript and the Bitcore.io library. Full source ... A continuing look at updates and developments in the EXSCUDO space. There is a lot of buzz happening now that the ICO is over but let’s take focus on the next step. In this video we cover: 1 ... This video is unavailable. Watch Queue Queue. Watch Queue Queue Live Bitcoin Trading With DeriBot on Deribit (BTCUSD Perpetual Futures) DeriBot Backup 376 watching Live now Professor Eric Laithwaite: Magnetic River 1975 - Duration: 18:39.

#