Block Explorer: how to use Get Started ...

Devcoin: ethically inspired cryptocurrency

A community based around the Devcoin cryptocurrency, an ethically inspired project created to help fund FOSS developers, artists, musicians, writers and more.

Constructing an Opt-In alternative reward for securing the blockchain

Since a keyboard with a monero logo got upvoted to the top I realized I should post various thoughts I have and generate some discussion. I hope others do the same.
Monero is currently secured by a dwindling block reward. There is a chance that the tail emission reward + transaction fees to secure the blockchain could become insufficient and allow for a scenario where it is profitable for someone to execute a 51% attack.
To understand this issue better, read this:
In Game Theory, Tragedy of the Commons is a market failure scenario where a common good is produced in lower quantities than the public desires, or consumed in greater quantities than desired. One example is pollution - it is in the public's best interest not to pollute, but every individual has incentive to pollute (e.g. because burning fossil fuel is cheap, and individually each consumer doesn't affect the environment much). The relevance to Bitcoin is a hypothetical market failure that might happen in the far future when the block reward from mining drops near zero. In the current Bitcoin design, the only fees miners earn at this time are Transaction fees. Miners will accept transactions with any fees (because the marginal cost of including them is minimal) and users will pay lower and lower fees (in the order of satoshis). It is possible that the honest miners will be under-incentivized, and that too few miners will mine, resulting in lower difficulty than what the public desires. This might mean various 51% attacks will happen frequently, and the Bitcoin will not function correctly. The Bitcoin protocol can be altered to combat this problem - one proposed solution is Dominant Assurance Contracts. Another more radical proposal (in the sense that the required change won't be accepted by most bitcoiners) is to have a perpetual reward that is constant in proportion to the monetary base. That can be achieved in two ways. An ever increasing reward (inflatacoin/expocoin) or a constant reward plus a demurrage fee in all funds that caps the monetary base (freicoin). This scenario was discussed on several threads: - Tragedy of the Commons - Disturbingly low future difficulty equilibrium - Stack Exchange Currently there is no consensus whether this problem is real, and if so, what is the best solution. 

I suspect that least contentious solution to it is not to change code, emission or artificially increase fees (which would actually undermine the tail emission and lead to other problems, I believe: but rather use a Dominant Assurance Contract that makes it rational for those who benefit from Monero to contribute to the block reward.

Dominant assurance contracts
Dominant assurance contracts, created by Alex Tabarrok, involve an extra component, an entrepreneur who profits when the quorum is reached and pays the signors extra if it is not. If the quorum is not formed, the signors do not pay their share and indeed actively profit from having participated since they keep the money the entrepreneur paid them. Conversely, if the quorum succeeds, the entrepreneur is compensated for taking the risk of the quorum failing. Thus, a player will benefit whether or not the quorum succeeds; if it fails he reaps a monetary return, and if it succeeds, he pays only a small amount more than under an assurance contract, and the public good will be provided.
Tabarrok asserts that this creates a dominant strategy) of participation for all players. Because all players will calculate that it is in their best interests to participate, the contract will succeed, and the entrepreneur will be rewarded. In a meta-game, this reward is an incentive for other entrepreneurs to enter the DAC market, driving down the cost disadvantage of dominant assurance contract versus regular assurance contracts.
Monero doesn't have a lot of scripting options to work with currently so it is very hard for me to understand how one might go about creating a Dominant Assurance Contract using Monero, especially in regards to paying out to a miner address.
This is how it could work in Bitcoin:
This scheme is an attempt at Mike Hearn's exercise for the reader: an implementation of dominant assurance contracts. The scheme requires the use of multisignature transactions, nLockTime and transaction replacement which means it won't work until these features are available on the Bitcoin network.
A vendor agrees to produce a good if X BTC are raised by date D and to pay Y BTC to each of n contributors if X BTC are not raised by date D, or to pay nY BTC if X BTC are raised and the vendor fails to produce the good to the satisfaction of 2 of 3 independent arbitrators picked through a fair process
The arbitrators specify a 2-of-3 multisignature script to use as an output for the fundraiser with a public key from each arbitrator, which will allow them to judge the performance on actually producing the good
For each contributor:
The vendor and the contributor exchange public keys
They create a 2-of-2 multisignature output from those public keys
With no change, they create but do not sign a transaction with an input of X/n BTC from the contributor and an input of Y BTC from the vendor, with X/n+Y going to the output created in 3.2
The contributor creates a transaction where the output is X+nY to the address created in step 2 and the input is the output of the transaction in 3.3, signs it using SIGHASH_ALL | SIGHASH_ANYONECANPAY, with version = UINT_MAX and gives it to the vendor
The vendor creates a transaction of the entire balance of the transaction in 3.3 to the contributor with nLockTime of D and version < UINT_MAX, signs it and gives it to the contributor
The vendor and contributor then both sign the transaction in 3.3 and broadcast it to the network, making the transaction in 3.4 valid when enough contributors participate and the transaction in 3.5 valid when nLockTime expires
As date D nears, nLockTime comes close to expiration.
If enough (n) people contribute, all of the inputs from 3.4 can combine to make the output valid when signed by the vendor, creating a valid transaction sending that money to the arbitrators, which only agree to release the funds when the vendor produces a satisfactory output
If not enough people ( Note that there is a limit at which it can be more profitable for the vendor to make the remaining contributions when D approaches
Now the arbitrators have control of X (the payment from the contributors) + nY (the performance bond from the vendor) BTC and pay the vendor only when the vendor performs satisfactorily
Such contracts can be used for crowdfunding. Notable examples from Mike Hearn include:
Funding Internet radio stations which don't want to play ads: donations are the only viable revenue source as pay-for-streaming models allow undercutting by subscribers who relay the stream to their own subscribers
Automatically contributing to the human translation of web pages

Monero has these features:
  1. Multisig
  2. LockTime (but it is much different then BTCs)
  3. A possibility to do MoJoin (CoinJoin) like transactions, even if less then optimally private. There is hope that the MoJoin Schemes will allow for better privacy in the future:
I have a draft writeup for a merged-input system called MoJoin that allows multiple parties to generate a single transaction. The goal is to complete the transaction merging with no trust in any party, but this introduces significant complexity and may not be possible with the known Bulletproofs multiparty computation scheme. My current version of MoJoin assumes partial trust in a dealer, who learns the mappings between input rings and outputs (but not true spends or Pedersen commitment data).

Additionally, Non-Interactive Refund Transactions could also be possible in Monero's future.
I can't fully workout how all of these could work together to make a DAC that allows miners to put up and payout a reward if it doesn't succeed, or how we could make it so *any* miner who participated (by putting up a reward) could claim the reward if it succeeded. I think this should really be explored as it could make for a much more secure blockchain, potentially saving us if a "crypto winter" hits where the value of monero and number of transactions are low, making for a blockchain that is hard to trust because it would be so cheap to perform a 51% attack.

I am still skeptical of Dominant Assurance Contracts, despite success in an initial test
it still remains questionable or at least confusing:
submitted by Vespco to Monero [link] [comments]

What is a Bitcoin Block Explorer WHAT IS A BLOCKCHAIN EXPLORER? (CRYPTO TWINZ) How to Program a Block Chain Explorer with Python and Bitcoin Pdf How to use abe block explorer Bitcoin Blockchain Explorer: Everything Beginners Need to Know

One of the very first things you may encounter when you begin using Bitcoin Cash (BCH) or Bitcoin (BTC) is a block explorer. This article will help you understand what it is, how to use the block explorer, and provide you with other helpful tips and information to get you going down the path of discovering and understanding Bitcoin Cash, Bitcoin, and the blockchain. A block explorer is an online browser for viewing or “exploring” all of the information on the bitcoin blockchain. With a block explorer, you can view address balances, transactions, transactions fees, the congestion of the MemPool, the number of daily transactions, current and past block rewards, the current mining difficulty, the flow of bitcoin and even view the value of bitcoin when it ... The most popular and trusted block explorer and crypto transaction search engine. launched a Bitcoin Cash (BCH) block explorer with which people can search for transaction hashes, blocks and addresses on the BCH blockchain. The Explorer provides block, transaction, and address data for the Bitcoin Cash (BCH) and Bitcoin (BTC) chains. The data is displayed within an awesome interface and is available in several different languages.

[index] [17370] [17912] [12747] [12769] [20946] [22511] [30800] [16768] [20055] [27005]

What is a Bitcoin Block Explorer

What is a Bitcoin Block Explorer - Duration: 1:41. Ofir Beigel 2,869 views. 1:41. How to build your swimming pool - Step by step - Duration: 1:22:03. Nicole Michael Recommended for you. Bitcoin Explained Lab 1: Block Chain Explorer - Duration: 3:42. Emeka aka On1 Productions 2,102 views. 3:42. Avoid These 4 Crypto Scams & How To Invest The Right Way - Duration: 18:24. Blockchain/Bitcoin for beginners 6: blocks and mining, content and creation of bitcoin blocks - Duration: 46:48. Matt Thomas 11,082 views Bitcoin 101 - Merkle Roots and Merkle Trees - Bitcoin Coding and Software - The Block Header - Duration: 24:18. CRI 42,372 views And in this video of Bitcoin Blockchain explorer, you will learn:--What is Bitcoin Blockchain Explorer-How to use a Bitcoin Blockchain Explorer-How to view a transaction/public address in the ...