Freicoin explorer - Development & Technical Discussion ...

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.
[link]

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 https://bitcointalk.org/index.php?topic=6284.0 - Stack Exchange http://bitcoin.stackexchange.com/questions/3111/will-bitcoin-suffer-from-a-mining-tragedy-of-the-commons-when-mining-fees-drop-t Currently there is no consensus whether this problem is real, and if so, what is the best solution. 
Source: https://en.bitcoin.it/wiki/Tragedy_of_the_Commons

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: https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/) 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:
https://en.bitcoin.it/wiki/Dominant_Assurance_Contracts
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.
https://eprint.iacr.org/2019/595
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 https://marginalrevolution.com/marginalrevolution/2013/08/a-test-of-dominant-assurance-contracts.html
it still remains questionable or at least confusing: https://forum.ethereum.org/discussion/747/im-not-understanding-why-dominant-assurance-contracts-are-so-special
submitted by Vespco to Monero [link] [comments]

Bitcoin Explained Lab 1: Block Chain Explorer How to Program a Block Chain Explorer with Python and Bitcoin Pdf Basic Tutorial On Bitcoin Block explorer OneCoin ก็อปข้อมูลจาก Bitcoin Block Explorer - YouTube How To Mine 1 Bitcoin in 10 Minutes - Blockchain BTC Miner ...

Search the block chain. Find info that other block explorers don't have. BTC. Bitcoin; Ethereum ; Bitcoin Testnet; Litecoin; DogeCoin; Dash; Blockcypher Testnet; Enter an address, transaction hash, block hash, block number, or wallet name. Search Browse the Blockchain. Bitcoin. Ethereum. Grin. Litecoin. Dogecoin. Dash. BlockCypher Testnet. Read more about what makes this block explorer ... The easiest and most trusted transaction search engine and block explorer. producten. Portemonnee Verzenden, ontvangen en ruilen ... Bitcoin Explorer Zoek BTC Blockchain Ethereum Explorer Zoek ETH Blockchain Bitcoin Cash Explorer Zoek BCH Blockchain. All Blockchains. All Blockchains. Mainnet. Bitcoin. Ethereum. Bitcoin Cash. Testnet. Bitcoin. Bitcoin Cash. Zoeken. Log in Aanmelden ... 21 ist freie Software, die jeden Computer in einen Bitcoin-Computer verwandelt. Einmal installiert, ist es möglich, Bitcoin auf jedem Gerät in fast jedem Land ohne Bankkonto oder Kreditkarte zu erhalten. Es ermöglicht auch die Möglichkeit, Micropayments zu jeder App hinzuzufügen und Bitcoin bei jeder HTTP-Anfrage zu verdienen. Sie bieten aktualisierte Bitcoin-Gebühren und öffnen API ... Reddcoin Explorer New Official Block Explorer (self.FedoraCoin) submitted 1 year ago by tipsytipper [ M ] Thanks so much to psycodad, we now have a brand new Fedora Tips Block Explorer, Fedora Tips Rich List and a few other neat tools at: https://tipsbe.netcraft.ch

[index] [26394] [5800] [22915] [34296] [38258] [5526] [47896] [50693] [16562] [49601]

Bitcoin Explained Lab 1: Block Chain Explorer

A short video explaining what a block explorer is. For the complete text guide visit: http://bit.ly/2DD1vQT Join our 7-day Bitcoin crash course absolutely fr... I have realised that there is a lot of interest in Bitcoin, Blockchain and Crypto in general. I have decided to do a series of basic tutorials on some vital information for the beginners. This is ... *LIVE BITCOIN TRANSACTION* How To Use A Block Explorer How To Check "Unconfirmed" Transactions In this video, I do a demo of a live bitcoin cash transactio... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. Bitcoin 101 - Merkle Roots and Merkle Trees - Bitcoin Coding and Software - The Block Header - Duration: 24:18. CRI 42,372 views

#