Bitcoin Website Templates from ThemeForest

Re-Launching The Borderless, Unkillable Crypto-Fiat Gateway, DAIHard. Enter or Exit Crypto via Any Fiat and Any Payment Method, Anywhere in the World, Without KYC. All you need is a little Dai.

Some of you might recall recall our initial facepalm failed launch about 3 months ago (post-mortem here). Well, we're back--this time with an audit and some new features. This version of DAIHard should should die a little harder this time ;)

The Audit

After shopping around a bit in the auditor space, we decided to go with Adam Dossa--the very same Adam Dossa that actually found our launch vulnerability and responsibly disclosed it to us! You can see his report here. By the way, Adam has been a gem: friendly, professional, timely, and flexible. Definitely keep him in mind if you need an audit!

(Re)Introducing DAIHard

Following is an updated version of our original launch post. If you've already read that, you might want to skip to the heading What's New in v0.9.2. Or you can go straight to the app or go to our info site for more info!
Here is a legitimate concern most of us are familiar with:
To enter or exit the crypto economy, we rely on centralized exchanges such as Coinbase, which track their users, impose limits, and are tightly coupled to their jurisdiction and its banking system. And for all we know, any day now regulations could start tightening these controls further (*we've actually seen some of this play out in the two months since our first launch post). In light of this, can we say in any meaningful sense that crypto is anonymous, limtiless, borderless, immune to regulation, and (most importantly) unstoppable?
To really address this concern, we need a completely decentralized gateway between fiat and crypto: something that extends the benefits of crypto to the very act of moving between the old and new economies. But the design of such a platform is far from obvious.
(Localethereum comes close, but as discussed under Unkillable, it doesn't quite cut it. And Bisq is decentralized, but has significant UX hurdles.)
We believe we've found a solution. We are proud to present:

DAIHard v0.9.2 - Almost Definitely Not Broken This Time

If you want to jump right in, we recommend first watching our latest usage demo (7 min), then diving in and giving it a shot with a small amount of Dai. (Try it on Kovan first if mainnet is too scary!)
DAIHard extends many of the promises of crypto (borderless, anonymous, limitless, unstoppable) into the exchange mechanism itself, allowing anyone, anywhere to bypass centralized exchanges and the control they impose.
More concretely, DAIHard is a platform, run on smart contracts, for forming one-off crypto/fiat exchanges with other users, in which:
Again, our latest usage demo (7 min) shows this process in action.

Two drawbacks

You Need either xDai, or both Dai and Ether, to Use The Tool (At Least For Now)

If you want to buy Dai on DAIHard, you must already have Dai--1/3 of the amount you want to purchase--to put up as a burnable deposit. For example, if you only have 10 Dai now, you can only commit to buying 30 Dai, and must complete that trade before using the newly bought Dai to open up a bigger offer (for up to 120 Dai that time).
Most tragically of course, this means that if you don't already have some crypto, you can't use this tool to get crypto--this is why we avoid calling DAIHard an onramp specifically. This comes from the fact that both parties must have "skin in the game" for the game theory to work, and a smart contract can only threaten to burn crypto.
We have some ideas on how to address this drawback in the not-too-distant future, which we'll write about soon. For now it's time to launch this thing and get some users!

Dangerous and Scary To Use

In rare cases, a user may have to burn Dai and face a loss on the entire trade amount. The necessity of this ever-present risk is explained in detail in DAIHard Game Theory.
However, a cautious, rational user can gather information (possibly via our [subreddit](daihard)!) about how people have used the tool, successfully and unsuccessfully. They can then create a buy or sell offer with wisely chosen settings based on what has worked for others. Other cautious, rational users can find this offer and commit to the trade if they dare. We expect the vast majority of committed trades should involve rational, cautious users, and should therefore resolve happily.
Still, inevitably there will be sloppy trades that result in burns. As the tool is used, we'll be keeping a close eye on the frequency of burns and keeping you guys updated (perhaps via a "System Status" utility similar to the one found on MakerDao's explorer). In the end, though, we expect the risk in using DAIHard to be comparable to the risk of using any exchange or DNM: ever-present but low enough for the platform to be useful as whole.
So, while DAIHard will never shut down and can't perform an exit scam, the bad news is it's not risk-free. Users will have to approach DAIhard with the same level of caution they would with any new exchange (albeit for different reasons and with a different approach).
So what's the good news?

The Good News

While these drawbacks are significant, they enable some remarkable features that no other crypto/fiat exchange mechanism can boast.

Unkillable

(Correction: Bisq seems to have a decentralized arbitration system)
We are aware of no other crypto/fiat exchange platform that is truly unkillable. Bisq and localethereum comes close, but both localethereum relies on centralized processes of arbitration. This means their fraud-and-scam-prevention system can be sued, jailed, or otherwise harrassed--and if that part stops working, it doesn't matter how decentralized the rest of the system was.
DAIHard, in contrast, gives the users the power to police and punish each other, via the aforementioned credible threat of burn. This is simple game theory, and the rules of this game are etched permanently into the DAIHard Factory and Trade contract code: impervious to litigation, regulation, and political pressure.
This Factory contract has no owner and no suicide or pause code. It cannot be stopped by us or anyone else.
Like Toastycoin, this thing was immortal the moment it was deployed (even more immortal than RadarRelay, for example, which does rely on an ownership role). Both DAIHard and Toastycoin (and probably whatever we build next) will last for as long as a single Ethereum node continues mining, and it will remain easy to use as long as someone can find the HTML/JS front-end and a web3 wallet.
(The HTML/JS front-end (built in Elm, by the way, with the lovely elm-ethereum!) is currently hosted on Github pages, which is centralized--but even if Github takes down the page and deletes the code, it's a minor step to get the page hosted on IPFS, something that is on our near-term roadmap in any case)

No KYC, No Limits

It's smart contracts all the way down, so DAIHard never asks any nosy questions--if you have Metamask or some other web3 wallet installed and set up, with some ETH and Dai (or just xDai), you can immediately open or commit to a trade. You don't even need a username!
(In fact, we're so inclusive, even machines are allowed--no CAPTCHA here!)
You're limited only by the collateral you put up, so if you have 10,000 Dai you could open up a buy offer for 30,000 Dai (or a sell offer for 10,000 Dai) right now.
We do reccommend trying the tool out first with a small amount of Dai... But we're not your mom! Do what you want!

Borderless

It simply doesn't matter where you are, because DAIHard doesn't need to interface with any particular jurisdiction or payment system to work. DIAHard works by incentivizing people (or robots?) to navigate the particular real-world hurdles of bank transfers, cash drops, or other fiat transfer methods. These incentives work whether you're in America, Zimbabwe, or the Atlantic; they work whether the fiat is USD, EUR, ZAR, seashells, or Rai Stones; and they work whether your counterparty is a human, an organization, a script, or a particularly intelligent dog with Internet access.

Any Fiat Type, and Highly Customizeable

Here are some examples of the types of trades you might create or find on DAIHard.
As the DAIHard community grows, users will doubtless find much more creative ways to use the system, and we will discover together which types of trades are reliable and which are more risky. Because users can set their own prices and phase timeout settings, we expect the risky trades to charge a premium or have longer time windows, while the reliable ones rapidly multiply at close to a 1:1 price ratio, with quick turnaround times.

Extensible (with profit) by Third Parties

Not satisfied with our interface? Do you have some nifty idea for how to display and organize user reputation? Or maybe some idea for how trades could be chained togeher? Maybe you'd like to design a notification system for DAIHard? Maybe you just want a different color scheme!
Well, you won't need our permission to do any of this. Any tool that watches the same Factory contract will share the pool of trades, regardless of which tool actually creates the trade. This means we don't even have to fight over network effects!
And if you look closely at our fee structure, you might notice that only half of the 1% DAIHard fee is "hardcoded" into the Factory contract. The other half is set and charged by our interface. What does this mean for you? If you go out and make a better interface, you can essentially replace half of our 1% fee with your own fee--it's up to you whether it's smaller or larger than the replaced 0.5%.
The reason for this is to explicitly welcome other developers to extend what we've built. For as long as our team is the only one improving the platform, a threat to us is a threat to future upgrades. But if others begin extending the DAIHard platform too, then DAIHard will not only be unstoppable as it is today, but also grow unstoppably.

(For Real This Time) This Is a Big Fucking Deal

DAIHard is a turning point in crypto and a breakthrough in decentralized markets, and is an irreversible augmentation of the Ethereum platform.
What we've built is a gateway to crypto completely devoid of centralized components--rendering entry and exit to crypto unkillable, flexible, borderless, and private. Centralized exchanges, and the control they impose, can now be bypassed by anyone with Dai and a web3 wallet.

What's New in v0.9.2

There have been many changes made since our first failed launch, but there are two rather important ones: xDai support and reputation tools.

xDai support

DAIHard is now operational on xDai, a sidechain whose native token (xDai) is pegged to the Dai (and therefore $1). Add the xDai network to your Metamask (or just install Nifty Wallet), then switch to the xDai network in your wallet, to try it out. xDai has some pretty incredible benefits, compared to vanilla Ethereum:

Reputation tools

We now have a few reputation tools. First, on any open trade, there is a widget showing the number of releases, aborts, and burns the given address has been involved in as that role (buyer or seller). Clicking on this expands the widget to show more detailed information, and also provides a link to a page that lists each trade this user has been or is involved in.

What's next?

We have tons of ideas on how to improve the product--too many, in fact, to commit to any before we get a good chunk of user feedback. Here are some of our favorite ideas:

Near-Term, Smaller Features

  1. Lots of usability improvements.
  2. A "System Status" utility similar to the one found on MakerDao's explorer).
  3. Marketplace / My Trades rework.
  4. A "QuickTrade" page, offering Trade Templates as an alternative to the current Create Offer page.

Big Exciting Features

  1. Bootstrapping people with no DAI via other mechanisms and community outreach.
  2. Partial commits to trades. eg. Place a 10,000 DAI trade and allow it to be picked up in blocks larger than 500 DAI at a time.
  3. More chains, get this thing working on Bitcoin via Rootstock, on Ethereum Classic and Binance Chain.

Stay Informed!

A lot of the above features will be prioritized more clearly as we get user feedback, and we will be posting fairly frequent updates and articles on our info site. If you don't want to miss anything, note the subscribe widget and sign up!
submitted by coinop-logan to ethereum [link] [comments]

Finnettech.com Review: 1.6% daily for 20 days and principal back

Finnettech.com is a HYIP project which provides medium and long term deposit plans. The shortest investment cycle only needs 20 calendar days. The program started on 07th Apr and admin bought standard listing on my website two days ago. My first withdrawal request was processed successfully into my PerfectMoney wallet. Now let me introduce it to you all.
Started: 2020–04–07
My deposit: $200
The amount of 200 USD has been withdrawn from your account. Accounts: U3869878->U20413753. Memo: Shopping Cart Payment. . Date: 05:12 07.04.20. Batch: 310030382
Investment Plans
  1. Deposit 50–499 dollars, earn 1.6% daily for 20 days and principal back
  2. Deposit 500–4999 dollars, earn 1.9% daily for 25 days and principal back
  3. Deposit 5000–24999 dollars, earn 2.2% daily for 30 days and principal back
  4. Deposit 25000–50000 dollars, earn 2.5% daily for 40 days and principal back
  5. Deposit 1000–7999 dollars, earn 2.8% daily for 100 days and principal included
  6. Deposit 8000–19999 dollars, earn 3.5% daily for 100 days and principal included
  7. Deposit 20000–49999 dollars, earn 4.0% daily for 100 days and principal included
  8. Deposit 50000–100000 dollars, earn 4.5% daily for 100 days and principal included
What I should remind is that you can see a button called “Accrued Interest” when you deposit.The accrued interest is the interest accrued from one payment due day to the next as well as the total amount of interest payable to a deposit over time. If you choose “Accrued Interest”, the amount of interest and deposit will receive at the end of the cycle, so you should not choose it if you want to withdraw profit daily.
Referral Commissions
For promoters, they can earn up to 23 level commissions. But you can also earn referral commissions without having your own deposit.
Payment Options
Currently, Finnettech.com supports PerfectMoney, Bitcoin and Ethereum; But maybe Litecoin and Payeer will be added in the near future, because we can already see the payment option when replenishing account balance.
Withdrawal Type
The minimum withdrawal amount is 5 USD, and any funds withdrawal request can be processed by the system for up to 24 hours.
More Information
Finnettech.com runs its website on a customized script and original template. You can find Telegram channel, Twitter, Instagram and Youtube on top of their website, so please follow them if you are interested in Finnettech.com. It supports 8 languages currently, including English, Chinese, Russian, Korea, Vietnamese, French, Italian and Spanish. Although Finnettech.com doesn’t publish out their company certificate on the website now, I still found it on UK company house called “Finnet Technology Limited” which is the same as the title of their website.
For now, if you have more questions and want to communicate with admin, you can leave messages through the online chat widget at the bottom of their website. But in the near future, Finnettech.com will close the online chat feature. All support requests will be processed on Telegram Group and Facebook Group. You can join their Telegram and Facebook groups from their details page on my website.
Register: https://finnettech.com/ref=hQ405BsJCxfA7UG
More: https://www.hyiper.net/blog/159.html
submitted by vipinvestor1988 to u/vipinvestor1988 [link] [comments]

A slightly overboard response to my threat model.

For what I hope are obvious reasons, I don't want, and probably will never post my threat model publicly online. However, regardless of that, what I'm sure you will extrapolate from this post is that I live my life, digitally in particular, with a fairly high level threat model. This is not because I'm some super sophisticated criminal mastermind, but rather, I am at this level because I genuinely love playing around with this stuff. And I just happen to understand the importance of privacy and just how vital it is to a truly healthy society. I would like to extend a thanks to ProgressiveArchitect for the sharing of the knowledge they have done on this subreddit, /privacytoolsio, and the like. We may have never interacted, but nevertheless, your input into this community is truly interesting and extremely informative and educating. I'm sure those of you familiar with PA's setup will be able to draw some parallels with mine and their's.
Thank you.
I hope you all enjoy reading this write up.
I run Qubes OS on a Lenovo ThinkPad X230 laptop. Specs for it are as following: - i7-3520M - 16GB RAM - 1TB Samsung 860 Evo SSD - Qualcomm Atheros AR9285 wireless card
Additionally, I used a Raspberry Pi Model 3B+ and a Pomono SPI clip to replace the stock BIOS firmware with coreboot+me_cleaner. This wasn't done out of any "real" concern for the Intel ME (though of course proprietary black-boxes like it should be avoided at all costs and not trusted), but rather for open source enthusiasm and for increased security and faster boot times than what the stock BIOS firmware allows for. On that note about the ME, I don't believe the conspiracy theories that claim that it is a state-sponsored attack method for surveillance. I believe that Intel had good intentions for improving the lives of IT professionals who need to manage hundreds, if not thousands of remote machines. However, it has proven time and time again to be insecure, and I don't need the remote management and the "features" that it provides on my machines.
In Qubes, I use a combination of AppVMs and StandaloneVMs for a variety of different purposes. All VMs use PVH over HVM, except for the Mirage Unikernel Firewall, which uses PV, and the sys-net and sys-usb StandaloneVMs which have to use HVM because of PCI device passthrough. Right now most of my VMs are AppVMs, but for maintenance and compartmentalization reasons, I am considering moving more towards StandaloneVMs, despite the increase in disk space and bandwidth usage for updates.
General route of from Qubes to the Internet for anonymous browsing, general private browsing, accessing Uni services, and Uni-related anonymous browsing respectively: 1. Qubes->sys-mirage-firewall->sys-vpn-wg->sys-corridor->sys-whonix->whonix-ws-15-dvm to the internet. 2. Qubes->sys-mirage-firewall->sys-vpn-wg to the Internet. 3. Qubes->sys-mirage-firewall->uni-vpn-wg to the Internet. 4. Qubes->sys-mirage-firewall->uni-vpn-wg->uni-corridor->uni-whonix->uni-anon-research to the Internet.

(Note: the VPN name is substituted in the "vpn" above. I had to remove it to comply with this subreddit's rules. It is easy to identify what VPN it is as it randomly generates a long numaric string and has fantastic support for WireGuard.)

Web Browsers: - Tor Browser (primary) in a disposable Whonix VM. - Firefox (secondary) with the about:config changes listed on privacytools.io and the following extensions: Cookies AutoDelete, Decentraleyes, HTTPS Everywhere, uBlock Origin (advance user, all third party content blocked and JavaScript disabled), and Vim Vixen. Used in my personal AppVM. - Ungoogled Chromium (Uni only) with standard uBlock Origin and cVim. Used only for Uni-related access in my uni-campus and uni-home AppVMs.
Search Engine: SearX, Startpage, and DuckDuckGo.
Password Manager: KeePassXC.
Office: LibreOffice.
Notes: Standard Notes.
Messaging: Signal Desktop.
Media Playback: mpv.
Emails: I access my personal email within my personal Qubes domain and my Uni email using my Uni Qubes domains. My emails are downloaded to a local repository using isync, send using msmtp, and read using neomutt with html emails converted to plain text using w3m. Emails are sent in plain text too. All of the attachments in the emails (PDFs mostly) are automatically opened in DisposableVMs.
My personal Posteo email account has incoming encryption setup. This means that I emailed my public GPG key to an address correlated to my actual Posteo email address so that all email that I receive is encrypted with my public key and can only be decrypted using my private key. So even if my emails were intercepted and/or my account broken into, the contents of them are safe since they are encrypted as soon as they hit Posteo's servers.
I have setup a number of Posteo aliases that are completely segregated from the email I used to register my account. One of those is considered my "professional" email for my current job. I have another couple aliases, one dedicated for 33mail and another dedicated for Abine Blur. I make use of 33mail alias addresses for catch-all email addresses for registering for accounts that need to be under a username associated with my name anyways. This is for purposes like putting different compartmentalized, but still related emails to put onto my Resume. I use a different alias for each Resume I put out online. That way, when that information gets sold, traded, etc., I can easily trace it back to who sold the information. For example, if I applied for a job online that required me to go through the process of registering an account through a third-party, say 'xyz Inc', the address I would register that account with would be [email protected], or something along those lines. Abine Blur is used much in the same manner but for accounts that don't need to be associated with my real name in any way, say online shopping on Amazon that I do under an many aliases, then ship to various address that I don't live at, but that I can visit with no problems. I use a different Blur address with each service like with 33mail for the same reasoning shown above.
The passwords for the accounts are encrypted and stored locally in each of the domains, however, my private key is stored in my vault domain, so even if an adversary were to compromise the domains, they wouldn't be able to steal my private key without exploiting the hypervisor. They would only be able to wait for me to authorize the usage of my private key in that domain, and even then, it could only be used to decrypt files. That is a concern that they can use my private key to decrypt messages, but they wouldn't be able to steal the key. With my personal email, the emails would also be encrypted locally anyway so they wouldn't be able to read them. My Uni email, in contrast, uses Outlook unfortunately, so there isn't any option to enable incoming encryption, and even if it was, I'm not sure how private it would be anyways.
For those looking for an in depth list of all my VMs, with explanations for the more obscure ones, I have listed them below. I have got a lot of templates, hence why I am considering moving over to StandaloneVMs, but as of right now:

Templates:

StandaloneVMs:

AppVMs:

Phone: Motorola Moto G5s running Lineage OS 16.0 Pie no G-Apps or micro-G with the following Apps: - AdAway: Open Source hosts file-based ad blocker. (Requires root.) - AFWall+: Linux iptables front end. (Requires root.) - Amaze: File manager. - andOPT: 2FA app. I like it since it can export the entries to an AES encrypted file. - AntennaPod: Podcast manager. - AnySoftKeyboard - Simple Calendar - Simple Contacts Pro - DAVx5: CalDav syncronization with my calendar on my Posteo email account. - F-Droid - Fennec F-Droid: Web Browser. Has the same Firefox addons like on Qubes minus Vim Vixen. I used the app Privacy Settings to configure the about:config. - KeePassDX: Password manager. - KISS launcher - Magisk Manager - NewPipe: YouTube app replacement. - S.Notes: Standard Notes. - OsmAnd~: Maps and navigation. - Red Moon: Blue light filter. - SELinuxModeChanger: Exactly as it sounds. (Requires root.) - Shelter: Work profile manager. - Signal: Messaging. - Vinyl Music Player: Music player. - WireGuard: VPN protocol frontend. Is configured to use my VPN account. Is setup as an always-on and connected VPN.
As mentioned, I use Shelter to manage my work profile. In it I isolate the following apps: - Clover: *chan browser. - Orbot: For routing apps through Tor. Is setup as an always-on and connected VPN. - RedReader: Reddit client. - Tor Browser
Over the last several years, I have started using my phone less and less and taking advantage of less of what it has got to offer. I don't check email on my device. I have no real need to browse the Internet on it outside of watching videos using NewPipe, browsing Reddit, and various *chan boards.
On the Smart Phone side of things, I am considering purchasing an older used iPhone SE or 6S for use with MySudo when outside of my home as well as an iPod Touch for use on WiFi only for use inside my home. The iPhone would be kept inside of a faraday bag when I am at home and not using it. It would also be kept in the faraday bag whenever at home to avoid associating that device with my home address. The iPod Touch would be used for MySudo calls instead.
Future outlook and plan for my privacy and security:
To avoid as much deanonymisation of my privacy as possible, I'm only going to specify enough so that anyone reading this can get the jist of my situation in life. I am quite young (age 16 to 25) and I started along this privacy journey when I was even younger. I was never a very heavy social media user, however I did have an online presence if you looked hard enough. My name fortunately is a very common and short name, so that does help to bury information that I was not able to remove further in the vast trenches that is the Internet.
On the digital side of things, I mentioned that I have a dedicated Crypto AppVM for handling crypto currency transactions using Bisq. I have setup a dedicated bank account that I have periodically been transferring money into so that I can trade crypto. Unfortunately, I do not live in the US, so being able to effectively start trades with others is more difficult. I also do not have access to a credit card masking account like privacy.com (that I absolutely would use given the ability). I plan on getting an anonymous VPS to host my own Tor exit node for better speeds and to mitigate the possibility of malicious exit nodes. The country I live in has been a proponent of absolute dragnet surveillance on all activities occurring online and in real life, though the former is far more visible on this subreddit. I will be using crypto with cleaned Bitcoin (as seen with ProgressiveArchitect's setup) for purchasing my VPN service, etc.
With future hardware, to replace my aging laptop, I am very hopeful for Xen, then eventually Qubes OS getting ported to Power9. When that happens I'll be getting a Raptor Computing Blackbird as a desktop. Maybe in the future I'll get a Purism Librem laptop, but for now my corebooted X230 works perfectly for my use cases. On that note, I have successfully build the Heads firmware for the X230 and I was able to get the minimal 4MB image flashed on my laptop. I did revert it back to my coreboot setup after playing around a little with it, and unfortunately I haven't had time since to do a full, complete flash of it.
On the physical/real life side of things, I plan on making use of various Trusts in order to hold assets, say to keep my name from being immediately visible on the title of my car. As of right now I am fortunate enough to have the title of my car under the name of someone who I trust. Unless I am legally required, and where there are immediate and absolute consequences, I use fake names in real life. With Uni, I am enrolled under my real name and address. This is a requirement and it is verified, so there is nothing that I can realistically do about it. As for other services, I plan on setting up a personal mailbox (PMB), etc if possible to use as a real, physical address that is associated with my real name and that is used for things like Government issued ID. In the future when I move again, I plan on renting a place in cash to try and keep my name dissociated with my real address. For those looking for reasoning on why one would want to do that, please read How to be Invisible by J.J. Luna. It's truly the Bible of physical privacy.
At this stage I am just going off on a ramble, so I should cut it short here.
I have just started and I live for this shit.
submitted by ComprehensiveAddict to privacy [link] [comments]

BitShop 1.0.6v – Bitcoin Shop Script

What is BitShop
BitShop is a powerful PHP/MYSQL shop script which allows merchants to easily sell digital items such as software or codes, in return for bitcoin and other cryptocurrencies. BitShop is the #1 shop script for selling digital goods. It also powers the official BitShop website (screenshot above).
Fast and Simple
The checkout process is designed to be as simple and fast as possible. The buyer will go through an easy checkout process and they will receive the item instantly after the payment is confirmed. Multiple payment gateways, including Coinbase and GoCoin, can be enabled simultaneously.
Flexible and Modular
BitShop is designed with developers in mind. Unlike many other scripts, BitShop is extremely modular and offers developer flexibility. For example new payment gateways can easily be installed as self-contained modules and new themes can also be installed without overwriting other themes.
Dynamic and Responsive
BitShop makes use of the latest in web technology to provide a dynamic and responsive user experience. Built upon Bootstrap 2 and HTML5 Boilerplate, the BitShop script is fast and looks good on any platform. Witness the power of HTML5 and PHP (and a bit of JS and CSS of course).
Bootstrap Template
The default template used by BitShop is built around the Bootstrap 2 framework. If you visit WrapBootstrap or Bootswatch you can get custom made Bootstrap themes. This provides a great way to change the default theme but it’s also easy to remove Bootstrap and build a theme from scratch.
Powerful Admin Area
BitShop includes an administration area where it’s possible to manage your orders, products, vouchers, accounts, etc. BitShop supports a wide range of different methods for selling digital items such as files, keys, and gift codes. It now also includes basic support for selling physical items.
Regain Independence
The built-in payment gateway is fully customizable and uses multiple public block explorer API’s to handle payments. Addresses can be automatically generated on the fly or taken from a custom list. You can also run a bitcoin/altcoin daemon to directly process payments without a 3rd party.
https://cracked-scriptz.ru/bitshop-1-0-6v-bitcoin-shop-script/
submitted by CrackedScriptz to u/CrackedScriptz [link] [comments]

Decred Journal – September 2018

Note: you can read this on GitHub (link), Medium (link) or old Reddit (link).

Development

Final version 1.3.0 of the core software was released bringing all the enhancements reported last month to the rest of the community. The groundwork for SPV (simplified payment verification) is complete, another reduction of fees is being deployed, and performance stepped up once again with a 50% reduction in startup time, 20% increased sync speed and more than 3x faster peer delivery of block headers (a key update for SPV). Decrediton's integrations of SPV and Politeia are open for testing by experienced users. Read the full release notes and get the downloads on GitHub. As always, don't forget to verify signatures.
dcrd: completed several steps towards multipeer downloads, improved introduction to the software in the main README, continued porting cleanups and refactoring from upstream btcd.
Currently in review are initial release of smart fee estimator and a change to UTXO set semantics. The latter is a large and important change that provides simpler handling, and resolves various issues with the previous approach. A lot of testing and careful review is needed so help is welcome.
Educational series for new Decred developers by @matheusd added two episodes: 02 Simnet Setup shows how to automate simnet management with tmux and 03 Miner Reward Invalidation explains block validity rules.
Finally, a pull request template with a list of checks was added to help guide the contributors to dcrd.
dcrwallet: bugfixes and RPC improvements to support desktop and mobile wallets.
Developers are welcome to comment on this idea to derive stakepool keys from the HD wallet seed. This would eliminate the need to backup and restore redeem scripts, thus greatly improving wallet UX. (missed in July issue)
Decrediton: bugfixes, refactoring to make the sync process more robust, new loading animations, design polishing.
Politeia: multiple improvements to the CLI client (security conscious users with more funds at risk might prefer CLI) and security hardening. A feature to deprecate or timeout proposals was identified as necessary for initial release and the work started. A privacy enhancement to not leak metadata of ticket holders was merged.
Android: update from @collins: "Second test release for dcrandroid is out. Major bugs have been fixed since last test. Latest code from SPV sync has been integrated. Once again, bug reports are welcome and issues can be opened on GitHub". Ask in #dev room for the APK to join testing.
A new security page was added that allows one to validate addresses and to sign/verify messages, similar to Decrediton's Security Center. Work on translations is beginning.
Overall the app is quite stable and accepting more testers. Next milestone is getting the test app on the app store.
iOS: the app started accepting testers last week. @macsleven: "the test version of Decred Wallet for iOS is available, we have a link for installing the app but the builds currently require your UDID. Contact either @macsleven or @raedah with your UDID if you would like to help test.".
Nearest goal is to make the app crash free.
Both mobile apps received new design themes.
dcrdata: v3.0 was released for mainnet! Highlights: charts, "merged debits" view, agendas page, Insight API support, side chain tracking, Go 1.11 support with module builds, numerous backend improvements. Full release notes here. This release featured 9 contributors and development lead @chappjc noted: "This collaboration with @raedahgroup on our own block explorer and web API for @decredproject has been super productive.".
Up next is supporting dynamic page widths site wide and deploying new visual blocks home page.
Trezor: proof of concept implementation for Trezor Model T firmware is in the works (previous work was for Model One).
Ticket splitting: updated to use Go modules and added simnet support, several fixes.
docs: beginner's guide overhaul, multiple fixes and cleanups.
decred.org: added 3rd party wallets, removed inactive PoW pools and removed web wallet.
@Richard-Red is building a curated list of Decred-related GitHub repositories.
Welcome to new people contributing for the first time: @klebe, @s_ben, @victorguedes, and PrimeDominus!
Dev activity stats for September: 219 active PRs, 197 commits, 28.7k added and 18.8k deleted lines spread across 6 repositories. Contributions came from 4-10 developers per repository. (chart)

Network

Hashrate: started and ended the month around 75 PH/s, hitting a low of 60.5 and a new high of 110 PH/s. BeePool is again the leader with their share varying between 23-54%, followed by F2Pool 13-30%, Coinmine 4-6% and Luxor 3-5%. As in previous months, there were multiple spikes of unidentified hashrate.
Staking: 30-day average ticket price is 98 DCR (+2.4). The price varied between 95.7 and 101.9 DCR. Locked DCR amount was 3.86-3.96 million DCR, or 45.7-46.5% of the supply.
Nodes: there are 201 public listening nodes and 325 normal nodes per dcred.eu. Version distribution: 5% are v1.4.0(pre) dev builds (+3%), 30% on v1.3.0 (+25%), 42% on v1.2.0 (-20%), 15% on v1.1.2 (-7%), 6% on v1.1.0. More than 76% of nodes run v1.2.0 and higher and therefore support client filters. Data as of Oct 1.

ASICs

Obelisk posted two updates on their mailing list. 70% of Batch 1 units are shipped, an extensive user guide is available, Obelisk Scanner application was released that allows one to automatically update firmware. First firmware update was released and bumped SC1 hashrate by 10-20%, added new pools and fixed multiple bugs. Next update will focus on DCR1. It is worth a special mention that the firmware source code is now open! Let us hope more manufacturers will follow this example.
A few details about Whatsminer surfaced this month. The manufacturer is MicroBT, also known as Bitwei and commonly misspelled as Bitewei. Pangolinminer is a reseller, and the model name is Whatsminer D1.
Bitmain has finally entered Decred ASIC space with their Antminer DR3. Hash rate is 7.8 TH/s while pulling 1410 W, at the price of $673. These specs mean it has the best GH/W and GH/USD of currently sold miners until the Whatsminer or others come out, although its GH/USD of 11.6 already competes with Whatsminer's 10.5. Discussed on Reddit and bitcointalk, unboxing video here.

Integrations

Meet our 17th voting service provider: decredvoting.com. It is operated by @david, has 2% fee and supports ticket splitting. Reddit thread is here.
For a historical note, the first VSP to support ticket splitting was decredbrasil.com:
@matheusd started tests on testnet several months ago. I contacted him so we could integrate with the pool in June this year. We set up the machine in July and bought the first split ticket on mainnet, using the decredbrasil pool, on July 19. It was voted on July 30. After this first vote on mainnet, we opened the tests to selected users (with more technical background) on the pool. In August we opened the tests to everyone, and would call people who want to join to the #ticket_splitting channel, or to our own Slack (in Portuguese, so mostly Brazilian users). We have 28 split tickets already voted, and 16 are live. So little more than 40 split tickets total were bought on decredbrasil pool. (@girino in #pos-voting)
KuCoin exchange listed DCBTC and DCETH pairs. To celebrate their anniversary they had a 99% trading fees discount on DCR pairs for 2 weeks.
Three more wallets integrated Decred in September:
ChangeNow announced Decred addition to their Android app that allows accountless swaps between 150+ assets.
Coinbase launched informational asset pages for top 50 coins by market cap, including Decred. First the pages started showing in the Coinbase app for a small group of testers, and later the web price dashboard went live.

Adoption

The birth of a Brazilian girl was registered on the Decred blockchain using OriginalMy, a blockchain proof of authenticity services provider. Read the full story in Portuguese and in English.

Marketing

Advertising report for September is ready. Next month the graphics for all the ads will be changing.
Marketing might seem quiet right now, but a ton is actually going on behind the scenes to put the right foundation in place for the future. Discovery data are being analyzed to generate a positioning strategy, as well as a messaging hierarchy that can guide how to talk about Decred. This will all be agreed upon via consensus of the community in the work channels, and materials will be distributed.
Next, work is being done to identify the right PR partner to help with media relations, media training, and coordination at events. While all of this is coming up to speed, we believe the website needs a refresher reflecting the soon to be agreed upon messaging, plus a more intuitive architecture to make it easier to navigate. (@Dustorf)

Events

Attended:
Upcoming:
We'll begin shortly reviewing conferences and events planned for the first half of 2019. Highlights are sure to include The North American Bitcoin Conference in Miami (Jan 16-18) and Consensus in NYC (May 14-16). If you have suggestions of events or conferences Decred should attend, please share them in #event_planning. In 2019, we would like to expand our presence in Europe, Asia, and South America, and we're looking for community members to help identify and staff those events. (@Dustorf)

Media

August issue of Decred Journal was translated to Russian. Many thanks to @DZ!
Rency cryptocurrency ratings published a report on Decred and incorporated a lot of feedback from the community on Reddit.
September issue of Chinese CCID ratings was published (snapshot), Decred is still at the bottom.
Videos:
Featured articles:
Articles:

Community Discussions

Community stats:
Comm systems news: Several work channels were migrated to Matrix, #writers_room is finally bridged.
Highlights:
Twitter: why decentralized governance and funding are necessary for network survival and the power of controlling the narrative; learning about governance more broadly by watching its evolution in cryptocurrency space, importance of community consensus and communications infrastructure.
Reddit: yet another strong pitch by @solar; question about buyer protections; dcrtime internals; a proposal to sponsor hoodies in the University of Cape Town; Lightning Network support for altcoins.
Chats: skills to operate a stakepool; voting details: 2 of 3 votes can approve a block, what votes really approve are regular tx, etc; scriptless script atomic swaps using Schnorr adaptor signatures; dev dashboard, choosing work, people do best when working on what interests them most; opportunities for governments and enterprise for anchoring legal data to blockchain; terminology: DAO vs DAE; human-friendly payments, sharing xpub vs payment protocols; funding btcsuite development; Politeia vote types: approval vote, sentiment vote and a defund vote, also linking proposals and financial statements; algo trading and programming languages (yes, on #trading!); alternative implementation, C/C++/Go/Rust; HFTs, algo trading, fake volume and slippage; offline wallets, usb/write-only media/optical scanners vs auditing traffic between dcrd and dcrwallet; Proof of Activity did not inspire Decred but spurred Decred to get moving, Wikipedia page hurdles; how stakeholders could veto blocks; how many votes are needed to approve a proposal; why Decrediton uses Electron; CVE-2018-17144 and over-dependence on single Bitcoin implementation, btcsuite, fuzz testing; tracking proposal progress after voting and funding; why the wallet does not store the seed at all; power connectors, electricity, wiring and fire safety; reasonable spendings from project fund; ways to measure sync progress better than block height; using Politeia without email address; concurrency in Go, locks vs channels.
#support is not often mentioned, but it must be noted that every day on this channel people get high quality support. (@bee: To my surprise, even those poor souls running Windows 10. My greatest respect to the support team!)

Markets

In September DCR was trading in the range of USD 34-45 / BTC 0.0054-0.0063. On Sep 6, DCR revisited the bottom of USD 34 / BTC 0.0054 when BTC quickly dropped from USD 7,300 to 6,400. On Sep 14, a small price rise coincided with both the start of KuCoin trading and hashrate spike to 104 PH/s. Looking at coinmarketcap charts, the trading volume is a bit lower than in July and August.
As of Oct 4, Decred is #18 by the number of daily transactions with 3,200 tx, and #9 by the USD value of daily issuance with $230k. (source: onchainfx)
Interesting observation by @ImacallyouJawdy: while we sit at 2018 price lows the amount locked in tickets is testing 2018 high.

Relevant External

ASIC for Lyra2REv2 was spotted on the web. Vertcoin team is preparing a new PoW algorithm. This would be the 3rd fork after two previous forks to change the algorithm in 2014 and 2015.
A report titled The Positive Externalities of Bitcoin Mining discusses the benefits of PoW mining that are often overlooked by the critics of its energy use.
A Brief Study of Cryptonetwork Forks by Alex Evans of Placeholder studies the behavior of users, developers and miners after the fork, and makes the cases that it is hard for child chains to attract users and developers from their parent chains.
New research on private atomic swaps: the paper "Anonymous Atomic Swaps Using Homomorphic Hashing" attempts to break the public link between two transactions. (bitcointalk, decred)
On Sep 18 Poloniex announced delisting of 8 more assets. That day they took a 12-80% dive showing their dependence on this one exchange.
Circle introduced USDC markets on Poloniex: "USDC is a fully collateralized US dollar stablecoin using the ERC-20 standard that provides detailed financial and operational transparency, operates within the regulated framework of US money transmission laws, and is reinforced by established banking partners and auditors.".
Coinbase announced new asset listing process and is accepting submissions on their listing portal. (decred)
The New York State Office of the Attorney General posted a study of 13 exchanges that contains many insights.
A critical vulnerability was discovered and fixed in Bitcoin Core. Few days later a full disclosure was posted revealing the severity of the bug. In a bitcointalk thread btcd was called 'amateur' despite not being vulnerable, and some Core developers voiced their concerns about multiple implementations. The Bitcoin Unlimited developer who found the bug shared his perspective in a blog post. Decred's vision so far is that more full node implementations is a strength, just like for any Internet protocol.

About This Issue

This is the 6th 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 also welcome: some areas are adding content, pre-release review or translations to other languages.
Credits (Slack names, alphabetical order): bee, Dustorf, jz, Haon, oregonisaac, raedah and Richard-Red.
submitted by jet_user to decred [link] [comments]

What is Finatch?

ABOUT FINATCH Finatch is a private Blockchain Technology Company which aim's at revolutrionizing the Blockchain Technology industry.
Looking at the lack of stable, fast and reliable decentralized crypto exchanges which causes inconviniences to crypto traders in the space. We have come up with the solution to the problems faced by decentralized exchanges.
There are basically two different types of exchanges: Centralized and Decentralized exchanges. We will focus on the Deentralized exchange system. We have a strong belief that Decentralized based crypto exchanges will be bigger than Centralized based crypto exchanges in the nearest future, because Blockchain is all about Decentralization.
They will play an evermore role in the world of finance, and we call this FINATCH EXCHANGE. FINATCH EXCHANGE Finatch Exchange is a Decntralized crypto exchange, which is run and powered by the Finatch Smart Contract Blockchain. Problems Poor technical architecture in Decentralized exchanges There are a good number of exchanges set up by professionals who have little or no experience in finance or in operating an exchange. They often take the easiest route to get the system up and running. While this may work well in the beginning, as traffic grows, the system will not be able to handle the increased load. Exchange systems need to be engineered from the ground up with security, efficiency, speed, and scalability in mind. This often slows down the initial development, but is critical for long-term success.
Our team has decades of combined experience building and maintaining world class financial systems that shape the economy. We understand how these systems are built from the ground up. Slow Smart Contract confirmation time Deployment of Smart contract on the blockchain takes time and causes inconveniences becauses of the poorly built blockchain, this results in a bad user experience in decentralized crypto exchanges.
Our team has designed a new and capable type of Blockchain that speeds up confirmation time for smart contratcts, making the platform user friendly and smooth. Insecured Platform There are hundreds of exchanges that went down due to being hacked.
Finatch is built to top notch quality, audited, and penetration tested. We have experience building financial systems to the highest security standards and strive to ensure security first. Poor market liquidity Professional traders and normal users are significantly affected by this. Having a shallow orderbook means high slippage when trading, which is very expensive for traders.
Finatch’s team have been in both the finance and crypto industry for many years. The team has worked on and operated a number of exchanges, and have accumulated a large network of partners in this space. These partners will be key in bootstrapping the exchange. Poor customer service Traders are a different breed when it comes to users. Understanding the trader mentality is vital for running a successful exchange. Money is literally on-the-line. Many exchange service trades as if they were running a social media site. A 3-second delay in seeing your friends’ status update would hardly be noticed, but on an exchange, the same would be unacceptable, resulting in a torrent of user complaints.
In additional to the technology stack, Finatch is built with service in mind. Finatch shares and supports responsibilities across the entire staff and company. When a trader has a problem, they get an answer directly from someone who knows the system and not someone reading from a script. Limited access to decentralized services There are few existing decentralized exchanges with close to good user interface and lacks quick and reasonable smart contract transaction fees, causing slow platorm functioning.
Our team has designed a new and capable type of Blockchain that speeds up confirmation time for smart contratcts, making the platform user friendly and smooth. Poor internationalization and language support Blockchains have no borders. Most exchanges focus only on one language or one country.
Our international multi-lingual team has extensive working experience in North America, Europe, Asia and Africa and we are able to smoothly support the global market. Lack of transparency All trading activities should be decentralized and open to the general public to insure trust and transparency in trades. Centralized crypto exchanges lack this quality.
Finatch runs on a Decentralized crypto platform where all trading activities are transparent.
Finatch is a Crypto Decentralized crypto exchange that has the feel and look of Centralized Crypto exchange but with more convinience And extra Blockchain Security Layer. An Exchange where you own your private keys.
Finatch exchange is a huge decentralized trading exchange platform equipped with various sub-platform, trading tools and secure decentralized wallet.
Finatch exchange consists of various sub platforms to choose from, this changes the trading experience namely: 1. Binary Platform: Fin vault platform, FinBox platform 2. Finatch trading tools: Finatch exchange have the best trading tools ready for traders on all our trading platform, taking trading experience to the next level. You can choose from our multiple trading tools the one that suits your trading skills. 3.Andriod and iOs Mobile Trading Application. MATCHING ENGINE With our Unique Smart Contract Blockchain Our matching engine is capable of sustaining 1,500,000 orders / second, making Finatch one of the fastest exchanges in the market today. You can be certain, on our exchange, that your orders will never be stuck due to the matching engine being overwhelmed.
FEATURE ROLLOUT We will roll out the platform in roughly the following order: Decentralized (on-chain) exchange Spot trading Margin trading Futures Anonymous instant exchange and more... COINS Finatch will support trading pairs in the following coins: BTC ETH LTC BCH FIN (Finatch Coin) More coins will be added over time. We generally will only add coins that have strong credibility, user base, and liquidity. If you have a coin that you wish to be listed on Finatch later. DEVICE COVRAGE We will provide cross-platform trading clients for: Web-based decentralized trading client Android native client iOS native client (pending App Store review) Mobile HTML5 client (including WeChat H5 client) PC (Windows) native client REST API MULTILINGUAL SUPPORT We will support English, Chinese, Japanese and Korean on all of our user interfaces. (The very initial release will be in English only.) More languages will be added over time.
FINATCH COIN We will build our own Blockchain based Crypto coin, called the Finatch Coin. The Finatch Coin Total Supply is capped at 952.5M, but a strict pre mine of 200M FIN will be mined during the genesis Block. FIN Coin will run on the Finatch Blockchain. Percentage (%) Amount (FIN) Participant 25% 50,000,000 Airdrop&Bounty Programs 25% 50,000,000 Project Development 40% 80,000,000 Founding Team 10% 20,000,000 Angel Investors No ICO or Pre-ICO will take place. 50% of pre-mined Coins will be distributed to the general Public Via Airdrop stages and Bounty Programs. FIN VALUE AND REPURCHASING PLAN You can use FIN to pay for any fees on our platform, inculding but not limited to: Exchange fees Withdraw fees Listing fees Any other fee
When you use FIN to pay for fees, you will receive a significant discount: 1st year 2nd year 3rd year 4th year 5th year Discount Rate 60% 30% 12.5% 6.75%5 no discount
REPURCHASING PLAN Every quater, we will use 15% of our profits to buy back the pre-mined FIN coin and Burn them, until we buy up 50% of the pre-mined FIN coin during genesis block (100M) back. All buy back transactions will be annouced on the blockchain. FUNDS USAGE
35% of the funds will be used to build the Finatch platform and perform upgrades to the system, which inculdes team recruiting, training, and the development budget. 50% will be used for Finatch branding and marketing, including continuous promotion and education of Finatch and Blockchain innovations in industry mediums. A sufficient budget for various advertisment activities, to help Finatch become popular among investors, and to attract active users to the platform. 15% will be kept in reserve to cope with any emergency or unexpected situation that might come up. FINATCH BLOCKCHAIN Finatch Blockchain is a powerful unique blockchain built to solve the problems of long confirmation times and high transaction fees on smart contract Blockchains.
We also solve the scalablity problem with block size, by increasing the block size limit to 1GB. Finatch Blockchain can handle more than 100,000,000 tranactions per second, with as little to as low as $0.001 tranaction fee, making our blockchain the most convinent and reliable blockchain in exixtence.
Our Blockchain runs on Scrypt PoW/PoS and Fault Tolorence Algorithms, making it one the most secure blockchains. You can deploy smart contracts, decentralized applications and create your own (FRC Tokens) on our blockchain.
BUILD DECENTRALIZED APPLICATIONS Combining a modified Bitcoin Core infrastructure with an intercompatible version of the Ethereum Virtual Machine (EVM), Finatch Blockchain merges the reliability of Bitcoin’s unfailing blockchain with the endless possibilities provided by smart contracts.
Designed with stability, modularity and interoperability in mind, Finatch Blockchain is the foremost toolkit for building trusted decentralized applications, suited for real-world, business oriented use cases. Its hybrid nature, in combination with a PoS/PoW consensus protocol, allows Finatch Blockchain applications to be compatible with major blockchain ecosystems, while providing native support for mobile devices and IoT appliances.
DEPLOY DECENTRALIZED SMART CONTRACTS Finatch makes it easier than ever for established sectors and legacy institutions to interface with blockchain technology. Create your own tokens, automate supply chain management and engage in self-executing agreements in a standardized environment, verified and tested for stability.
SMART CONTRACT LIFE CYCLE MANAGMENT Finatch, in cooperation with its academic partners, develops tools and methods to standardize the workflow for business smart contract development. This includes the formally verifiable translation of human-readable agreements to machine smart contracts, and the error-resilient specification of their elements, terms and conditions.
SETTING INDUSTRY STANDARDS Cooperating with a series of partners and third parties, Finatch aims to establish a smart contract hub, offering secure and thoroughly tested contract templates, tailor fitted for a multitude of industries and use cases, such as supply chain management, telecommunications, IoT, social networking, Crypto exchanges and many more. ABOUT FIN COIN FIN Coin is a decentralised Cryptocurrency based on Finatch. It is the local based Cryptocurrency of Finatch Blockchain. FIN Coins are cryptographic software tokens used to engage with distributed applications (DApps) and smart contracts on the Finatch Platform. FIN Coins will serve as the staking currency of the Finatch blockchain and fuel computational operations performed by the Finatch network.
SPECIFICATION Total Pre-Mined Supply: 200,000,000 Block Target: 3-15 seconds Stake Return: ~5 FIN Coin Algorithm: Scrypt PoW/PoS and FT The FINATCH Foundation: Governance Structure The development and maintenance of the FINATCH Blockchain, as well as all services provided by FINATCH, are directed and supervised by the FINATCH Foundation - a non-profit organization, representing FINATCH’s stake and token holders as elaborated below.
In order to avoid the inefficient conduct, open source and blockchain projects often suffer from, and to ensure a coherent and standardized implementation of the FINATCH blockchain, the FINATCH Foundation was established under the guidance and support of FINATCH Inc. The Foundation will oversee the development of the FINATCH Blockchain, advocate governance transparency, and promote the safety and harmony of the open source ecosystem.
The design of the Foundation’s governance structure mainly considers sustainability, management effectiveness, and fund-raising security in the open source community. The Foundation consists of various committees, such as Executive Judgment, Code Review, Finance & HR, as well as Marketing & PR. The different committees work in cooperation to manage FINATCH’s daily operations and special occasions with detailed operational procedures and rules.
Learn more here: https://finatch.org/governance-structure
Decentralized Governance Protocol The Decentralized Governance Protocol (DGP) is designed so that individual blockchain parameters can be modified through a specially designed smart contract on the blockchain. Most importantly, this technology allows these blockchain parameters to be changed without any disruption to the ecosystem. After a setting change, no new software must be downloaded by users, and no intervention is needed from stakers, miners and node operators.
The way the DGP works is relatively straightforward. First, a governing party for the DGP makes a proposal to change a parameter. Afterward, all the governing parties for the DGP can vote on the proposal, and if it receives enough approval votes, then the parameter change proposal becomes active. The proposal data is then placed in a standardized format and a particular storage space so that the blockchain software can easily access it without needing to execute the DGP contract directly.
Learn more here: https://finatch.org/decentralized-governance-protocol
The FINATCH Foundation will list the total assets that it holds including Bitcoin, Ethereum, Legal Tender, and FIN COINS. The Foundation will also seek complementary services to aid our efforts in transparency and professionalism with a professional auditing firm, legal team and a professional digital asset management solution. We hope this will help promote the healthy development of the FINATCH Project and serve as a model for other projects. The content will be made public to the community on the FINATCH.org Website
EXCHANGE LIST
Binance
Huobi
Kucoin
Bibox
Qryptos
Satoexchange
BIGone
Bitrue
Bilaxy
Bit-Z
Linkcoin
SECURE WALLET
Ledgerwallet
Trezor
submitted by icoinformation2021 to Finatch [link] [comments]

Bitcoin-development Digest, Vol 48, Issue 62 | Damian Gomez | May 11 2015

Damian Gomez on May 11 2015:
Hllo
I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a set
of transactions and the originiator themselves.
It is my belief that the process to begin a new encryption tool using a
variant of the WinterNitz OTS for its existential unforgeability to be the
added signatures with every Wallet transaction in order to provide a
consesnus systemt that takes into accont a personal level of intergrity for
the intention fo a transaction to occur. This signature would then be
hashes for there to be an intermediate proxy state that then verifies and
evaluates the trust fucntion for the receiving trnsactions. This
evaluation loop would itself be a state in which the mining power and the
rewards derived from them would be an increased level of integrity as
provided for the "brainers" of a systems who are then the "signatuers" of
the transaction authenticity, and additiaonally program extranonces of x
bits {72} in order to have a double valid signature that the rest of the
nodes would accept in order to have a valid address from which to be able
to continuously receive transactions.
There is a level of diffculty in obtaining brainers, fees would only apply
uin so much as they are able to create authentic transactions based off the
voting power of the rest of the received nodes. The greater number of
faults within the system from a brainer then the more, so would his
computational power be restricted in order to provide a reward feedback
system. This singularity in a Byzantine consensus is only achieved if the
route of an appropriate transformation occurs, one that is invariant to the
participants of the system, thus being able to provide initial vector
transformations from a person's online identity is the responsibilty that
we have to ensure and calulate a lagrangian method that utilisizes a set of
convolutional neural network funcitons [backpropagation, fuzzy logic] and
and tranformation function taking the vectors of tranformations in a
kahunen-loeve algorithm and using the convergence of a baryon wave function
in order to proceed with a baseline reading of the current level of
integrity in the state today that is an instance of actionable acceleration
within a system.
This is something that I am trying to continue to parse out. Therefore
there are still heavy questions to be answered(the most important being the
consent of the people to measure their own levels of integrity through
mined information)> There must always be the option to disconnect from a
transactional system where payments occur in order to allow a level of
solace and peace within individuals -- withour repercussions and a seperate
system that supports the offline realm as well. (THis is a design problem)
Ultimately, quite literally such a transaction system could exist to
provide detailed analysis that promotes integrity being the basis for
sharing information. The fee structure would be eliminated, due to the
level of integrity and procesing power to have messages and transactions
and reviews of unfiduciary responsible orgnizations be merited as highly
true (.9 in fizzy logic) in order to promote a well-being in the state.
That is its own reward, the strenght of having more processing speed.
FYI(thank you to peter whom nudged my thinking and interest (again) in this
area. )
This is something I am attempting to design in order to program it. Though
I am not an expert and my technology stack is limited to java and c (and my
issues from it). I provided a class the other day the was pseudo code for
the beginning of the consensus. Now I might to now if I am missing any of
teh technical paradigms that might make this illogical? I now with the
advent of 7petabyte computers one could easily store 2.5 petabytes of human
information for just an instance of integrity not to mention otehr
emotions.
*Also, might someone be able to provide a bit of information on Bitcoin
core project?*
thank you again. Damain.
On Mon, May 11, 2015 at 10:29 AM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Fwd: Bitcoin core 0.11 planning (Wladimir)
  2. Re: Bitcoin core 0.11 planning (Wladimir)
  3. Long-term mining incentives (Thomas Voegtlin)
  4. Re: Long-term mining incentives
    (insecurity at national.shitposting.agency)
  5. Re: Reducing the block rate instead of increasing the maximum
    block size (Luke Dashjr)
  6. Re: Long-term mining incentives (Gavin Andresen)
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 14:49:53 +0000
Subject: [Bitcoin-development] Fwd: Bitcoin core 0.11 planning
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
As softforks almost certainly require backports to older releases and
other
software anyway, I don't think they should necessarily be bound to
Bitcoin
Core major releases. If they don't require large code changes, we can
easily
do them in minor releases too.
Agree here - there is no need to time consensus changes with a major
release, as they need to be ported back to older releases anyhow.
(I don't really classify them as software features, but properties of
the underlying system that we need to adopt to)
Wladimir
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 15:00:03 +0000
Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning
A reminder - feature freeze and string freeze is coming up this Friday the
15th.
Let me know if your pull request is ready to be merged before then,
Wladimir
On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
Hello all,
The release window for 0.11 is nearing, I'd propose the following
schedule:
2015-05-01 Soft translation string freeze
 Open Transifex translations for 0.11 Finalize and close translation for 0.9 
2015-05-15 Feature freeze, string freeze
2015-06-01 Split off 0.11 branch
 Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 
2015-07-01 Release 0.11.0 final (aim)
In contrast to former releases, which were protracted for months, let's
try to be more strict about the dates. Of course it is always possible for
last-minute critical issues to interfere with the planning. The release
will not be held up for features, though, and anything that will not make
it to 0.11 will be postponed to next release scheduled for end of the year.
Wladimir
---------- Forwarded message ----------
From: Thomas Voegtlin <thomasv at electrum.org>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 18:28:46 +0200
Subject: [Bitcoin-development] Long-term mining incentives
The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep mining to protect the network. Such a steady
state regime does not exist today, because miners get most of their
reward from the block subsidy, which will progressively be removed.
Thus, today's 3 billion USD question is the following: Will a steady
state regime be reached in the future? Can such a regime exist? What are
the necessary conditions for its existence?
Satoshi's paper suggests that this may be achieved through miner fees.
Quite a few people seem to take this for granted, and are working to
make it happen (developing cpfp and replace-by-fee). This explains part
of the opposition to raising the block size limit; some people would
like to see some fee pressure building up first, in order to get closer
to a regime where miners are incentivised by transaction fees instead of
block subsidy. Indeed, the emergence of a working fee market would be
extremely reassuring for the long-term viability of bitcoin. So, the
thinking goes, by raising the block size limit, we would be postponing a
crucial reality check. We would be buying time, at the expenses of
Bitcoin's decentralization.
OTOH, proponents of a block size increase have a very good point: if the
block size is not raised soon, Bitcoin is going to enter a new, unknown
and potentially harmful regime. In the current regime, almost all
transaction get confirmed quickly, and fee pressure does not exist. Mike
Hearn suggested that, when blocks reach full capacity and users start to
experience confirmation delays and confirmation uncertainty, users will
simply go away and stop using Bitcoin. To me, that outcome sounds very
plausible indeed. Thus, proponents of the block size increase are
conservative; they are trying to preserve the current regime, which is
known to work, instead of letting the network enter uncharted territory.
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
OTOH, I also fail to see evidence that a limited block capacity will
lead to a functional fee market, able to sustain a steady state. A
functional market requires well-informed participants who make rational
choices and accept the outcomes of their choices. That is not the case
today, and to believe that it will magically happen because blocks start
to reach full capacity sounds a lot like like wishful thinking.
So here is my question, to both proponents and opponents of a block size
increase: What steady-state regime do you envision for Bitcoin, and what
is is your plan to get there? More specifically, how will the
steady-state regime look like? Will users experience fee pressure and
delays, or will it look more like a scaled up version of what we enjoy
today? Should fee pressure be increased jointly with subsidy decrease,
or as soon as possible, or never? What incentives will exist for miners
once the subsidy is gone? Will miners have an incentive to permanently
fork off the last block and capture its fees? Do you expect Bitcoin to
work because miners are altruistic/selfish/honest/caring?
A clear vision would be welcome.
---------- Forwarded message ----------
From: insecurity at national.shitposting.agency
To: thomasv at electrum.org
Cc: bitcoin-development at lists.sourceforge.net
Date: Mon, 11 May 2015 16:52:10 +0000
Subject: Re: [Bitcoin-development] Long-term mining incentives
On 2015-05-11 16:28, Thomas Voegtlin wrote:
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
If your end goal is "compete with VISA" you might as well just give up
and go home right now. There's lots of terrible proposals where people
try to demonstrate that so many hundred thousand transactions a second
are possible if we just make the block size 500GB. In the real world
with physical limits, you literally can not verify more than a few
thousand ECDSA signatures a second on a CPU core. The tradeoff taken
in Bitcoin is that the signatures are pretty small, but they are also
slow to verify on any sort of scale. There's no way competing with a
centralised entity using on-chain transactions is even a sane goal.
---------- Forwarded message ----------
From: Luke Dashjr <luke at dashjr.org>
To: bitcoin-development at lists.sourceforge.net
Cc:
Date: Mon, 11 May 2015 16:47:47 +0000
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
increasing the maximum block size
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
  1. It will encourage centralization, because participants of mining
pools will loose more money because of excessive initial block template
latency, which leads to higher stale shares
When a new block is solved, that information needs to propagate
throughout the Bitcoin network up to the mining pool operator nodes,
then a new block header candidate is created, and this header must be
propagated to all the mining pool users, ether by a push or a pull
model. Generally the mining server pushes new work units to the
individual miners. If done other way around, the server would need to
handle a high load of continuous work requests that would be difficult
to distinguish from a DDoS attack. So if the server pushes new block
header candidates to clients, then the problem boils down to increasing
bandwidth of the servers to achieve a tenfold increase in work
distribution. Or distributing the servers geographically to achieve a
lower latency. Propagating blocks does not require additional CPU
resources, so mining pools administrators would need to increase
moderately their investment in the server infrastructure to achieve
lower latency and higher bandwidth, but I guess the investment would be
low.
  1. Latency is what matters here, not bandwidth so much. And latency
reduction
is either expensive or impossible.
  1. Mining pools are mostly run at a loss (with exception to only the most
centralised pools), and have nothing to invest in increasing
infrastructure.
3, It will reduce the security of the network
The security of the network is based on two facts:
A- The miners are incentivized to extend the best chain
B- The probability of a reversal based on a long block competition
decreases as more confirmation blocks are appended.
C- Renting or buying hardware to perform a 51% attack is costly.
A still holds. B holds for the same amount of confirmation blocks, so 6
confirmation blocks in a 10-minute block-chain is approximately
equivalent to 6 confirmation blocks in a 1-minute block-chain.
Only C changes, as renting the hashing power for 6 minutes is ten times
less expensive as renting it for 1 hour. However, there is no shop where
one can find 51% of the hashing power to rent right now, nor probably
will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
confirmation (60 1-minute blocks) if you wish for high-valued payments,
so the security decreases only if participant wish to decrease it.
You're overlooking at least:
  1. The real network has to suffer wasted work as a result of the stale
blocks,
while an attacker does not. If 20% of blocks are stale, the attacker only
needs 40% of the legitimate hashrate to achieve 50%-in-practice.
  1. Since blocks are individually weaker, it becomes cheaper to DoS nodes
with
invalid blocks. (not sure if this is a real concern, but it ought to be
considered and addressed)
  1. Reducing the block propagation time on the average case is good, but
what happen in the worse case?
Most methods proposed to reduce the block propagation delay do it only
on the average case. Any kind of block compression relies on both
parties sharing some previous information. In the worse case it's true
that a miner can create and try to broadcast a block that takes too much
time to verify or bandwidth to transmit. This is currently true on the
Bitcoin network. Nevertheless there is no such incentive for miners,
since they will be shooting on their own foots. Peter Todd has argued
that the best strategy for miners is actually to reach 51% of the
network, but not more. In other words, to exclude the slowest 49%
percent. But this strategy of creating bloated blocks is too risky in
practice, and surely doomed to fail, as network conditions dynamically
change. Also it would be perceived as an attack to the network, and the
miner (if it is a public mining pool) would be probably blacklisted.
One can probably overcome changing network conditions merely by trying to
reach 75% and exclude the slowest 25%. Also, there is no way to identify or
blacklist miners.
  1. Thousands of SPV wallets running in mobile devices would need to be
upgraded (thanks Mike).
That depends on the current upgrade rate for SPV wallets like Bitcoin
Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we
develop the source code for the change now and apply the change in Q2
2016, then most of the nodes will already be upgraded by when the
hardfork takes place. Also a public notice telling people to upgrade in
web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
advance will give plenty of time to SPV wallet users to upgrade.
I agree this shouldn't be a real concern. SPV wallets are also more likely
and
less risky (globally) to be auto-updated.
  1. If there are 10x more blocks, then there are 10x more block headers,
and that increases the amount of bandwidth SPV wallets need to catch up
with the chain
A standard smartphone with average cellular downstream speed downloads
2.6 headers per second (1600 kbits/sec) [3], so if synchronization were
to be done only at night when the phone is connected to the power line,
then it would take 9 minutes to synchronize with 1440 headers/day. If a
person should accept a payment, and the smart-phone is 1 day
out-of-synch, then it takes less time to download all the missing
headers than to wait for a 10-minute one block confirmation. Obviously
all smartphones with 3G have a downstream bandwidth much higher,
averaging 1 Mbps. So the whole synchronization will be done less than a
1-minute block confirmation.
Uh, I think you need to be using at least median speeds. As an example, I
can
only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G
has
worse range/coverage than 2G. No doubt the average is skewed so high
because
of densely populated areas like San Francisco having 400+ Mbps cellular
data.
It's not reasonable to assume sync only at night: most payments will be
during
the day, on battery - so increased power use must also be considered.
According to CISCO mobile bandwidth connection speed increases 20% every
year.
Only in small densely populated areas of first-world countries.
Luke
---------- Forwarded message ----------
From: Gavin Andresen <gavinandresen at gmail.com>
To: insecurity at national.shitposting.agency
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Date: Mon, 11 May 2015 13:29:02 -0400
Subject: Re: [Bitcoin-development] Long-term mining incentives
I think long-term the chain will not be secured purely by proof-of-work. I
think when the Bitcoin network was tiny running solely on people's home
computers proof-of-work was the right way to secure the chain, and the only
fair way to both secure the chain and distribute the coins.
See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
half-baked thoughts along those lines. I don't think proof-of-work is the
last word in distributed consensus (I also don't think any alternatives are
anywhere near ready to deploy, but they might be in ten years).
I also think it is premature to worry about what will happen in twenty or
thirty years when the block subsidy is insignificant. A lot will happen in
the next twenty years. I could spin a vision of what will secure the chain
in twenty years, but I'd put a low probability on that vision actually
turning out to be correct.
That is why I keep saying Bitcoin is an experiment. But I also believe
that the incentives are correct, and there are a lot of very motivated,
smart, hard-working people who will make it work. When you're talking about
trying to predict what will happen decades from now, I think that is the
best you can (honestly) do.

Gavin Andresen
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150511/46bc687a/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008095.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin-development Digest, Vol 48, Issue 63 | Damian Gomez | May 11 2015

Damian Gomez on May 11 2015:
Btw How awful that I didn't cite my sources, please exucse me, this is
definitely not my intention sometimes I get too caught up in my own
excitemtnt
1) Martin, J., Alvisi, L., Fast Byzantine Consensus. *IEEE Transactions on
Dependable and Secure Computing. 2006. *3(3) doi: Please see
John-Phillipe Martin and Lorenzo ALvisi
2) https://eprint.iacr.org/2011/191.pdf One_Time Winternitz Signatures.
On Mon, May 11, 2015 at 1:20 PM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Re: Bitcoin-development Digest, Vol 48, Issue 62 (Damian Gomez)
---------- Forwarded message ----------
From: Damian Gomez <dgomez1092 at gmail.com>
To: bitcoin-development at lists.sourceforge.net
Cc:
Date: Mon, 11 May 2015 13:20:46 -0700
Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48,
Issue 62
Hllo
I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a set
of transactions and the originiator themselves.
It is my belief that the process to begin a new encryption tool using a
variant of the WinterNitz OTS for its existential unforgeability to be the
added signatures with every Wallet transaction in order to provide a
consesnus systemt that takes into accont a personal level of intergrity for
the intention fo a transaction to occur. This signature would then be
hashes for there to be an intermediate proxy state that then verifies and
evaluates the trust fucntion for the receiving trnsactions. This
evaluation loop would itself be a state in which the mining power and the
rewards derived from them would be an increased level of integrity as
provided for the "brainers" of a systems who are then the "signatuers" of
the transaction authenticity, and additiaonally program extranonces of x
bits {72} in order to have a double valid signature that the rest of the
nodes would accept in order to have a valid address from which to be able
to continuously receive transactions.
There is a level of diffculty in obtaining brainers, fees would only apply
uin so much as they are able to create authentic transactions based off the
voting power of the rest of the received nodes. The greater number of
faults within the system from a brainer then the more, so would his
computational power be restricted in order to provide a reward feedback
system. This singularity in a Byzantine consensus is only achieved if the
route of an appropriate transformation occurs, one that is invariant to the
participants of the system, thus being able to provide initial vector
transformations from a person's online identity is the responsibilty that
we have to ensure and calulate a lagrangian method that utilisizes a set of
convolutional neural network funcitons [backpropagation, fuzzy logic] and
and tranformation function taking the vectors of tranformations in a
kahunen-loeve algorithm and using the convergence of a baryon wave function
in order to proceed with a baseline reading of the current level of
integrity in the state today that is an instance of actionable acceleration
within a system.
This is something that I am trying to continue to parse out. Therefore
there are still heavy questions to be answered(the most important being the
consent of the people to measure their own levels of integrity through
mined information)> There must always be the option to disconnect from a
transactional system where payments occur in order to allow a level of
solace and peace within individuals -- withour repercussions and a seperate
system that supports the offline realm as well. (THis is a design problem)
Ultimately, quite literally such a transaction system could exist to
provide detailed analysis that promotes integrity being the basis for
sharing information. The fee structure would be eliminated, due to the
level of integrity and procesing power to have messages and transactions
and reviews of unfiduciary responsible orgnizations be merited as highly
true (.9 in fizzy logic) in order to promote a well-being in the state.
That is its own reward, the strenght of having more processing speed.
FYI(thank you to peter whom nudged my thinking and interest (again) in
this area. )
This is something I am attempting to design in order to program it. Though
I am not an expert and my technology stack is limited to java and c (and my
issues from it). I provided a class the other day the was pseudo code for
the beginning of the consensus. Now I might to now if I am missing any of
teh technical paradigms that might make this illogical? I now with the
advent of 7petabyte computers one could easily store 2.5 petabytes of human
information for just an instance of integrity not to mention otehr
emotions.
*Also, might someone be able to provide a bit of information on Bitcoin
core project?*
thank you again. Damain.
On Mon, May 11, 2015 at 10:29 AM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Fwd: Bitcoin core 0.11 planning (Wladimir)
  2. Re: Bitcoin core 0.11 planning (Wladimir)
  3. Long-term mining incentives (Thomas Voegtlin)
  4. Re: Long-term mining incentives
    (insecurity at national.shitposting.agency)
  5. Re: Reducing the block rate instead of increasing the maximum
    block size (Luke Dashjr)
  6. Re: Long-term mining incentives (Gavin Andresen)
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 14:49:53 +0000
Subject: [Bitcoin-development] Fwd: Bitcoin core 0.11 planning
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
As softforks almost certainly require backports to older releases and
other
software anyway, I don't think they should necessarily be bound to
Bitcoin
Core major releases. If they don't require large code changes, we can
easily
do them in minor releases too.
Agree here - there is no need to time consensus changes with a major
release, as they need to be ported back to older releases anyhow.
(I don't really classify them as software features, but properties of
the underlying system that we need to adopt to)
Wladimir
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 15:00:03 +0000
Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning
A reminder - feature freeze and string freeze is coming up this Friday
the 15th.
Let me know if your pull request is ready to be merged before then,
Wladimir
On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
Hello all,
The release window for 0.11 is nearing, I'd propose the following
schedule:
2015-05-01 Soft translation string freeze
 Open Transifex translations for 0.11 Finalize and close translation for 0.9 
2015-05-15 Feature freeze, string freeze
2015-06-01 Split off 0.11 branch
 Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 
2015-07-01 Release 0.11.0 final (aim)
In contrast to former releases, which were protracted for months, let's
try to be more strict about the dates. Of course it is always possible for
last-minute critical issues to interfere with the planning. The release
will not be held up for features, though, and anything that will not make
it to 0.11 will be postponed to next release scheduled for end of the year.
Wladimir
---------- Forwarded message ----------
From: Thomas Voegtlin <thomasv at electrum.org>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 18:28:46 +0200
Subject: [Bitcoin-development] Long-term mining incentives
The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep mining to protect the network. Such a steady
state regime does not exist today, because miners get most of their
reward from the block subsidy, which will progressively be removed.
Thus, today's 3 billion USD question is the following: Will a steady
state regime be reached in the future? Can such a regime exist? What are
the necessary conditions for its existence?
Satoshi's paper suggests that this may be achieved through miner fees.
Quite a few people seem to take this for granted, and are working to
make it happen (developing cpfp and replace-by-fee). This explains part
of the opposition to raising the block size limit; some people would
like to see some fee pressure building up first, in order to get closer
to a regime where miners are incentivised by transaction fees instead of
block subsidy. Indeed, the emergence of a working fee market would be
extremely reassuring for the long-term viability of bitcoin. So, the
thinking goes, by raising the block size limit, we would be postponing a
crucial reality check. We would be buying time, at the expenses of
Bitcoin's decentralization.
OTOH, proponents of a block size increase have a very good point: if the
block size is not raised soon, Bitcoin is going to enter a new, unknown
and potentially harmful regime. In the current regime, almost all
transaction get confirmed quickly, and fee pressure does not exist. Mike
Hearn suggested that, when blocks reach full capacity and users start to
experience confirmation delays and confirmation uncertainty, users will
simply go away and stop using Bitcoin. To me, that outcome sounds very
plausible indeed. Thus, proponents of the block size increase are
conservative; they are trying to preserve the current regime, which is
known to work, instead of letting the network enter uncharted territory.
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
OTOH, I also fail to see evidence that a limited block capacity will
lead to a functional fee market, able to sustain a steady state. A
functional market requires well-informed participants who make rational
choices and accept the outcomes of their choices. That is not the case
today, and to believe that it will magically happen because blocks start
to reach full capacity sounds a lot like like wishful thinking.
So here is my question, to both proponents and opponents of a block size
increase: What steady-state regime do you envision for Bitcoin, and what
is is your plan to get there? More specifically, how will the
steady-state regime look like? Will users experience fee pressure and
delays, or will it look more like a scaled up version of what we enjoy
today? Should fee pressure be increased jointly with subsidy decrease,
or as soon as possible, or never? What incentives will exist for miners
once the subsidy is gone? Will miners have an incentive to permanently
fork off the last block and capture its fees? Do you expect Bitcoin to
work because miners are altruistic/selfish/honest/caring?
A clear vision would be welcome.
---------- Forwarded message ----------
From: insecurity at national.shitposting.agency
To: thomasv at electrum.org
Cc: bitcoin-development at lists.sourceforge.net
Date: Mon, 11 May 2015 16:52:10 +0000
Subject: Re: [Bitcoin-development] Long-term mining incentives
On 2015-05-11 16:28, Thomas Voegtlin wrote:
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
If your end goal is "compete with VISA" you might as well just give up
and go home right now. There's lots of terrible proposals where people
try to demonstrate that so many hundred thousand transactions a second
are possible if we just make the block size 500GB. In the real world
with physical limits, you literally can not verify more than a few
thousand ECDSA signatures a second on a CPU core. The tradeoff taken
in Bitcoin is that the signatures are pretty small, but they are also
slow to verify on any sort of scale. There's no way competing with a
centralised entity using on-chain transactions is even a sane goal.
---------- Forwarded message ----------
From: Luke Dashjr <luke at dashjr.org>
To: bitcoin-development at lists.sourceforge.net
Cc:
Date: Mon, 11 May 2015 16:47:47 +0000
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
increasing the maximum block size
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
  1. It will encourage centralization, because participants of mining
pools will loose more money because of excessive initial block template
latency, which leads to higher stale shares
When a new block is solved, that information needs to propagate
throughout the Bitcoin network up to the mining pool operator nodes,
then a new block header candidate is created, and this header must be
propagated to all the mining pool users, ether by a push or a pull
model. Generally the mining server pushes new work units to the
individual miners. If done other way around, the server would need to
handle a high load of continuous work requests that would be difficult
to distinguish from a DDoS attack. So if the server pushes new block
header candidates to clients, then the problem boils down to increasing
bandwidth of the servers to achieve a tenfold increase in work
distribution. Or distributing the servers geographically to achieve a
lower latency. Propagating blocks does not require additional CPU
resources, so mining pools administrators would need to increase
moderately their investment in the server infrastructure to achieve
lower latency and higher bandwidth, but I guess the investment would be
low.
  1. Latency is what matters here, not bandwidth so much. And latency
reduction
is either expensive or impossible.
  1. Mining pools are mostly run at a loss (with exception to only the most
centralised pools), and have nothing to invest in increasing
infrastructure.
3, It will reduce the security of the network
The security of the network is based on two facts:
A- The miners are incentivized to extend the best chain
B- The probability of a reversal based on a long block competition
decreases as more confirmation blocks are appended.
C- Renting or buying hardware to perform a 51% attack is costly.
A still holds. B holds for the same amount of confirmation blocks, so 6
confirmation blocks in a 10-minute block-chain is approximately
equivalent to 6 confirmation blocks in a 1-minute block-chain.
Only C changes, as renting the hashing power for 6 minutes is ten times
less expensive as renting it for 1 hour. However, there is no shop where
one can find 51% of the hashing power to rent right now, nor probably
will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
confirmation (60 1-minute blocks) if you wish for high-valued payments,
so the security decreases only if participant wish to decrease it.
You're overlooking at least:
  1. The real network has to suffer wasted work as a result of the stale
blocks,
while an attacker does not. If 20% of blocks are stale, the attacker only
needs 40% of the legitimate hashrate to achieve 50%-in-practice.
  1. Since blocks are individually weaker, it becomes cheaper to DoS nodes
with
invalid blocks. (not sure if this is a real concern, but it ought to be
considered and addressed)
  1. Reducing the block propagation time on the average case is good, but
what happen in the worse case?
Most methods proposed to reduce the block propagation delay do it only
on the average case. Any kind of block compression relies on both
parties sharing some previous information. In the worse case it's true
that a miner can create and try to broadcast a block that takes too much
time to verify or bandwidth to transmit. This is currently true on the
Bitcoin network. Nevertheless there is no such incentive for miners,
since they will be shooting on their own foots. Peter Todd has argued
that the best strategy for miners is actually to reach 51% of the
network, but not more. In other words, to exclude the slowest 49%
percent. But this strategy of creating bloated blocks is too risky in
practice, and surely doomed to fail, as network conditions dynamically
change. Also it would be perceived as an attack to the network, and the
miner (if it is a public mining pool) would be probably blacklisted.
One can probably overcome changing network conditions merely by trying to
reach 75% and exclude the slowest 25%. Also, there is no way to identify
or
blacklist miners.
  1. Thousands of SPV wallets running in mobile devices would need to be
upgraded (thanks Mike).
That depends on the current upgrade rate for SPV wallets like Bitcoin
Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we
develop the source code for the change now and apply the change in Q2
2016, then most of the nodes will already be upgraded by when the
hardfork takes place. Also a public notice telling people to upgrade in
web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
advance will give plenty of time to SPV wallet users to upgrade.
I agree this shouldn't be a real concern. SPV wallets are also more
likely and
less risky (globally) to be auto-updated.
  1. If there are 10x more blocks, then there are 10x more block headers,
and that increases the amount of bandwidth SPV wallets need to catch up
with the chain
A standard smartphone with average cellular downstream speed downloads
2.6 headers per second (1600 kbits/sec) [3], so if synchronization were
to be done only at night when the phone is connected to the power line,
then it would take 9 minutes to synchronize with 1440 headers/day. If a
person should accept a payment, and the smart-phone is 1 day
out-of-synch, then it takes less time to download all the missing
headers than to wait for a 10-minute one block confirmation. Obviously
all smartphones with 3G have a downstream bandwidth much higher,
averaging 1 Mbps. So the whole synchronization will be done less than a
1-minute block confirmation.
Uh, I think you need to be using at least median speeds. As an example, I
can
only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G
has
worse range/coverage than 2G. No doubt the average is skewed so high
because
of densely populated areas like San Francisco having 400+ Mbps cellular
data.
It's not reasonable to assume sync only at night: most payments will be
during
the day, on battery - so increased power use must also be considered.
According to CISCO mobile bandwidth connection speed increases 20% every
year.
Only in small densely populated areas of first-world countries.
Luke
---------- Forwarded message ----------
From: Gavin Andresen <gavinandresen at gmail.com>
To: insecurity at national.shitposting.agency
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Date: Mon, 11 May 2015 13:29:02 -0400
Subject: Re: [Bitcoin-development] Long-term mining incentives
I think long-term the chain will not be secured purely by proof-of-work.
I think when the Bitcoin network was tiny running solely on people's home
computers proof-of-work was the right way to secure the chain, and the only
fair way to both secure the chain and distribute the coins.
See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
half-baked thoughts along those lines. I don't think proof-of-work is the
last word in distributed consensus (I also don't think any alternatives are
anywhere near ready to deploy, but they might be in ten years).
I also think it is premature to worry about what will happen in twenty or
thirty years when the block subsidy is insignificant. A lot will happen in
the next twenty years. I could spin a vision of what will secure the chain
in twenty years, but I'd put a low probability on that vision actually
turning out to be correct.
That is why I keep saying Bitcoin is an experiment. But I also believe
that the incentives are correct, and there are a lot of very motivated,
smart, hard-working people who will make it work. When you're talking about
trying to predict what will happen decades from now, I think that is the
best you can (honestly) do.

Gavin Andresen
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150511/8f777233/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008096.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

COMPLETE Shopify Tutorial For Beginners 2020 - How To ... Earn bitcoin Script auto bonus via termux with payment proof Bitcoin Trading for Beginners (A Guide in Plain English ... Blockchain Hack Script 2020 GENERATES Unlimited Bitcoin 100% WORKING bitcoin hacked How Does Bitcoin Work? - YouTube

If you looking for bitcoin doubler script 2020 version? than this script will be helps you to build your own Bitcoin Altcoin Investment or Doubler Script Website. Bitcoin Altcoin Investment Doubler Script is one of the best Bitcoin Doubler script we have ever build. This is latest build script. You can accept bitcoin payment and other altcoin like eth, doge, ltc etc as well. Script comes with ... Get 416 bitcoin website templates on ThemeForest. Buy bitcoin website templates from $3. All created by our Global Community of independent Web Designers and Developers. Home Shop Bitcoin Doubler Script. Bitcoin Doubler Script. In Stock. $499.00 $399.00. Add to Cart. Demo . Templates . Description; Support; ECHYIP Bitcoin Doubler Script. Buy best Bitcoin Doubler with handy price, stunning templates and high security. No technical knowledge required to manage the Doubler script. 45 Days Dedicated Support ; Completely encrypted Doubler Script with no more ... Earn money by starting your own digital store, Allow clients to buy digital items, and make a profit. DigaSell includes a complete client area with Listed items, Categories, Announcements, Testimonials, Pages, PayPal, Bitcoin(CoinPayments) , reCAPTCHA integration and much more... Optima Bitcoin Website Templates. Optima is a multipurpose website template that can be used to create different kinds of sites including Bitcoin, marketing, finance, loan, SEO & consultation business and you can also use this template for any other business as well. It is based on bootstrap four framework and comes with a responsive design means your site will look great on all types of ...

[index] [30043] [41415] [27367] [37008] [12531] [40664] [12715] [42155] [33678] [15938]

COMPLETE Shopify Tutorial For Beginners 2020 - How To ...

24/7 Live Bitcoin Algo Trading on Deribit Exchange (DeriBot) Bitcoin Trading Robots 327 watching Live now James Baldwin Debates William F. Buckley (1965) - Duration: 58:58. Thanks for watching! For donations: Bitcoin - 1CpGMM8Ag8gNYL3FffusVqEBUvHyYenTP8 #2020 #bitcoin #hacked #hack #blockchain #wallet #btc #how #to #free #crypto #generator #coinbase #script #bitsler #new #coin #binance #eth #hacking #withdraw #proof #giveaway #official #litecoin ... Como Criar Um WEBSITE GRÁTIS Com TEMPLATES PRONTOS https://bit.ly/QueroSiteGratis ⬅⬅ CLIQUE NO LINK ACIMA PARA MAIORES DETALHES ... A step by step guide, A to Z, on how to create a profitable Shopify dropshipping store from scratch in 2019 and 2020. In this video, you will learn everythin...

#