How To Find Any Bitcoin Transaction On The Blockchain

[FULL ANALYSIS] Bitcoin exchanges and payment processors in Canada are now regulated as Money Service Businesses

Hello Bitcoiners!
Many of you saw my tweet yesterday about the Bitcoin regulations in Canada. As usual, some journalists decided to write articles about my tweets without asking me for the full context :P Which means there has been a lot of misunderstanding. Particuarly, these regulations mean that we can lower the KYC requirements and no longer require ID documents or bank account connections! We can also increase the daily transaction limit from $3,000 per day to $10,000 per day for unverified accounts. The main difference is that we now have a $1,000 per-transaction limit (instead of per day) and we must report suspicious transactions. It's important to read about our reporting requirements, as it is the main difference since pretty much every exchange was doing KYC anyway.
Hopefully you appreciate the transparency, and I'm available for questions!
Cheers,
Francis
*********************************************
Text below is copied from: https://medium.com/bull-bitcoin/bitcoin-exchanges-and-payment-processors-in-canada-are-now-regulated-as-money-service-businesses-1ca820575511

Bitcoin is money, regulated like money

Notice to Canadian Bitcoin users

If you are the user of a Canadian Bitcoin company, be assured that:
You may notice that the exchange service you are using has change its transactions limits or is now requiring more information from you.
You can stop reading this email now without any consequence! Otherwise, keep regarding if you are interested in my unique insights into this important topic!

Background on regulation

Today marks an important chapter for Bitcoin’s history in Canada: Bitcoin is officially regulated as money (virtual currency) under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act of Canada (PCMLTFA), under the jurisdiction of the Financial Transaction and Reports Analysis Centre of Canada (FINTRAC).
This is the culmination of 5 years of effort by numerous Bitcoin Canadian advocates collaborating with the Ministry of Finance, Fintrac and other Canadian government agencies.
It is important to note that there is no new Bitcoin law in Canada. In June of 2014, the Governor General of Canada (representing Her Majesty Queen Elizabeth II) gave royal asset to Bill C-31, voted by parliament under Stephen Harper’s Conservative government, which included amendments to the PCMLTFA to included Bitcoin companies (named “dealers in virtual currency”) as a category of Money Service Businesses.
Thereafter, FINTRAC engaged in the process of defining what exactly is meant by “dealing in virtual currency” and what particular rules would apply to the businesses in this category. Much of our work was centred around excluding things like non-custodial wallets, nodes, mining and other activities that were not related exchange or payments processing.
To give an idea, the other categories that apply to traditional fiat currency businesses are:
When we say that Bitcoin is now regulated, what we mean is that these questions have been settled, officially published, and that they are now legally binding.
Businesses that are deemed to be “dealing in virtual currency” must register with FINTRAC as a money service business, just like they would if they were doing traditional currency exchange or payment processing.
There is no “license” required, which means that you do not need the government’s approval before you can operate a Bitcoin exchange business. However, when you operate a Money Service Business, you must register and comply with the laws… otherwise you risk jail time and large fines.

What activities are regulated as Money Service Business activity?

A virtual currency exchange transaction is defined as: “an exchange, at the request of another person or entity, of virtual currency for funds, funds for virtual currency or one virtual currency for another.” This includes, but is not limited to:

Notice to foreign Bitcoin companies with clients in Canada

Regardless of whether or not your business is based in Canada, you must register with FINTRAC as a Foreign Money Service Business, if:

How this affects BullBitcoin.com and Bylls.com

The regulation of Bitcoin exchange and payment services has always been inevitable. If we want Bitcoin to be considered as money, we must accept that it will be regulated like other monies. Our stance on the regulation issue has always been that Bitcoin exchanges and payment processors should be regulated like fiat currency exchanges and payment processors, no more, no less. This is the outcome we obtained.
To comply with these regulations, we are implementing a few changes to our Know-Your-Customer requirement and transaction limits which may paradoxically make your experience using Bull Bitcoin and Bylls even more private and convenient!

The bad news

The good news

To understand these regulations, we highly recommend reading this summary by our good friends and partners at Outlier Compliance.

Summary of our obligations

Our responsibilities:
The information required to perform a compliant know-your-customer validation:
Record keeping obligations:

Suspicious transaction reporting

Satoshi Portal is required to make suspicious transactions report to FINTRAC after we have detected a fact that amounts to reasonable grounds to suspect that one of your transactions is related to the commission or attempted commission of a money laundering offence or a terrorist activity financing offence.
Failure by Satoshi Portal Inc. to report a suspicious transaction could lead to up to five years imprisonment, a fine of up to $2,000,000, or both, for its executives.
We are not allowed to share with anyone other than FINTRAC, including our clients, the contents of a suspicious transaction report as well as the fact that a suspicious transaction report has been filed.

What is suspicious activity?

Note for bitcoinca: this section applies ONLY to Bull Bitcoin. Most exchanges have much stricter interpretation of what is suspicious. You should operate under the assumption that using Coinjoin or TOR will get you flagged at some other exchanges even though it's okay for Bull Bitcoin. That is simply because we have a more sophisticated understanding of privacy best practices.
Identifying suspicious behavior is heavily dependent on the context of each transaction. We understand and take into account that for many of our customers, privacy and libertarian beliefs are of the utmost importance, and that some users may not know that the behavior they are engaging in is suspicious. When we are concerned or confused about the behaviors of our users, we endeavour to discuss it with them before jumping to conclusions.
In general, here are a few tips:
Here are some examples of behavior that we do not consider suspicious:
Here are some example indicators of behavior that would lead us to investigate whether or not a transaction is suspicious:

What does this mean for Bitcoin?

It was always standard practice for Bitcoin companies to operate under the assumption they would eventually be regulated and adopt policies and procedures as if they were already regulated. The same practices used for legal KYC were already commonplace to mitigate fraud (chargebacks).
In addition, law enforcement and other government agencies in Canada were already issuing subpoenas and information requests to Bitcoin companies to obtain the information of users that were under investigation.
We suspect that cash-based Bitcoin exchanges, whether Bitcoin ATMs, physical Bitcoin exchanges or Peer-to-Peer trading, will be the most affected since they will no longer be able to operate without KYC and the absence of KYC was the primary feature that allowed them to justify charging such high fees and exchange rate premiums.
One thing is certain, as of today, there is no ambiguity whatsoever that Bitcoin is 100% legal and regulated in Canada!
submitted by FrancisPouliot to BitcoinCA [link] [comments]

I've been working on a prototype Jonathan Silverblood's proposed CashIntents. CashIntents will allow for verifiable, trustless, and decentralized payment information. For example: "pokkst#12435 sent you $10 USD on September 4th, 2019"

An example transaction can be found here: https://explorer.bitcoin.com/tbch/tx/dd5e19e8a63279cb87e000abf31211b723c2c2b5a0a8ea475a3beeb6a0a7d646
This system utilizes the OP_RETURN of a transaction, with various portions of the OP_RETURN containing data that will allow the recipient to verify that the sender is who they say they are, and that they did in fact send you that money.
When sending, the sender will include the transaction id of the recipient's Cash Account (the txid that registered the Cash Account), and the transaction id for their own Cash Account (the txid that registered their own Cash Account). The sender will also include the amount sent, and the currency in which they used, as well as a timestamp.
Then the program will take the recipient txid, sender txid, amount, currency, and timestamp and combine the strings together like so:
recipienttxidsendertxidamountcurrencytimestamp
then that string is hashed:
3adb37317e844d995aa6225905bfb0a062b98b10f8579b6f80945088b410bab3
then this hash is signed with the sender Cash Account's address, which will produce a signature like so:
HxBnqQdGRsin9+1FkFAD/8oWb87YAOhexiK4AJaNpEdydk0BZzWfrxR+WuclKNk3owynWUZXTFGFj4+gqpcAHKw=
this is then attached to the OP_RETURN at the very end, and the sender sends the transaction.
On the receiver's end, they will receive the transaction and detect that there is an OP_RETURN. It will parse the OP_RETURN to see if it's a CashIntent OP_RETURN. If it is, it will grab the data from the OP_RETURN like so:
recipient txid, sender txid, amount, currency, timestamp, signature
using the sender txid, we can grab the address that the sender signed with (as it is supposed to be signed with the Cash Account address of the sender) using Cash Account lookup servers and block explorers to grab the necessary data to parse the address:
bitcoincash:q(...)
we can then take each variable like the sender did, and combine them into one string
recipienttxidsendertxidamountcurrencytimestamp
then hash that string to get the same hash that the sender used in his message (we do this locally that way the sender doesn't have to store it on the chain, and so we can verify ourselves):
3adb37317e844d995aa6225905bfb0a062b98b10f8579b6f80945088b410bab3
then we take the signature, hash, and address and verify that the signature is in fact valid. If it verifies, then we can be certain that the sender is in fact who they say they are and that they did send us this money.
This can then be displayed in-app when viewing the transaction as:
pokkst#12435 sent you $10 USD on September 4th, 2019
This is still a prototype, and will need to be finished before rolling it out in Crescent Cash as the first wallet to support CashIntents, but it is working and will hopefully be ready soon. :)
submitted by _pokkst to btc [link] [comments]

A technical dive into CTOR

Over the last several days I've been looking into detail at numerous aspects of the now infamous CTOR change to that is scheduled for the November hard fork. I'd like to offer a concrete overview of what exactly CTOR is, what the code looks like, how well it works, what the algorithms are, and outlook. If anyone finds the change to be mysterious or unclear, then hopefully this will help them out.
This document is placed into public domain.

What is TTOR? CTOR? AOR?

Currently in Bitcoin Cash, there are many possible ways to order the transactions in a block. There is only a partial ordering requirement in that transactions must be ordered causally -- if a transaction spends an output from another transaction in the same block, then the spending transaction must come after. This is known as the Topological Transaction Ordering Rule (TTOR) since it can be mathematically described as a topological ordering of the graph of transactions held inside the block.
The November 2018 hard fork will change to a Canonical Transaction Ordering Rule (CTOR). This CTOR will enforce that for a given set of transactions in a block, there is only one valid order (hence "canonical"). Any future blocks that deviate from this ordering rule will be deemed invalid. The specific canonical ordering that has been chosen for November is a dictionary ordering (lexicographic) based on the transaction ID. You can see an example of it in this testnet block (explorer here, provided this testnet is still alive). Note that the txids are all in dictionary order, except for the coinbase transaction which always comes first. The precise canonical ordering rule can be described as "coinbase first, then ascending lexicographic order based on txid".
(If you want to have your bitcoin node join this testnet, see the instructions here. Hopefully we can get a public faucet and ElectrumX server running soon, so light wallet users can play with the testnet too.)
Another ordering rule that has been suggested is removing restrictions on ordering (except that the coinbase must come first) -- this is known as the Any Ordering Rule (AOR). There are no serious proposals to switch to AOR but it will be important in the discussions below.

Two changes: removing the old order (TTOR->AOR), and installing a new order (AOR->CTOR)

The proposed November upgrade combines two changes in one step:
  1. Removing the old causal rule: now, a spending transaction can come before the output that it spends from the same block.
  2. Adding a new rule that fixes the ordering of all transactions in the block.
In this document I am going to distinguish these two steps (TTOR->AOR, AOR->CTOR) as I believe it helps to clarify the way different components are affected by the change.

Code changes in Bitcoin ABC

In Bitcoin ABC, several thousand lines of code have been changed from version 0.17.1 to version 0.18.1 (the current version at time of writing). The differences can be viewed here, on github. The vast majority of these changes appear to be various refactorings, code style changes, and so on. The relevant bits of code that deal with the November hard fork activation can be found by searching for "MagneticAnomaly"; the variable magneticanomalyactivationtime sets the time at which the new rules will activate.
The main changes relating to transaction ordering are found in the file src/validation.cpp:
There are other changes as well:

Algorithms

Serial block processing (one thread)

One of the most important steps in validating blocks is updating the unspent transaction outputs (UTXO) set. It is during this process that double spends are detected and invalidated.
The standard way to process a block in bitcoin is to loop through transactions one-by-one, removing spent outputs and then adding new outputs. This straightforward approach requires exact topological order and fails otherwise (therefore it automatically verifies TTOR). In pseudocode:
for tx in transactions: remove_utxos(tx.inputs) add_utxos(tx.outputs) 
Note that modern implementations do not apply these changes immediately, rather, the adds/removes are saved into a commit. After validation is completed, the commit is applied to the UTXO database in batch.
By breaking this into two loops, it becomes possible to update the UTXO set in a way that doesn't care about ordering. This is known as the outputs-then-inputs (OTI) algorithm.
for tx in transactions: add_utxos(tx.outputs) for tx in transactions: remove_utxos(tx.inputs) 
Benchmarks by Jonathan Toomim with Bitcoin ABC, and by myself with ElectrumX, show that the performance penalty of OTI's two loops (as opposed to the one loop version) is negligible.

Concurrent block processing

The UTXO updates actually form a significant fraction of the time needed for block processing. It would be helpful if they could be parallelized.
There are some concurrent algorithms for block validation that require quasi-topological order to function correctly. For example, multiple workers could process the standard loop shown above, starting at the beginning. A worker temporarily pauses if the utxo does not exist yet, since it's possible that another worker will soon create that utxo.
There are issues with such order-sensitive concurrent block processing algorithms:
In contrast, the OTI algorithm's loops are fully parallelizable: the worker threads can operate in an independent manner and touch transactions in any order. Until recently, OTI was thought to be unable to verify TTOR, so one reason to remove TTOR was that it would allow changing to parallel OTI. It turns out however that this is not true: Jonathan Toomim has shown that TTOR enforcement is easily added by recording new UTXOs' indices within-block, and then comparing indices during the remove phase.
In any case, it appears to me that any concurrent validation algorithm would need such additional code to verify that TTOR is being exactly respected; thus for concurrent validation TTOR is a hindrance at best.

Advanced parallel techniques

With Bitcoin Cash blocks scaling to large sizes, it may one day be necessary to scale onto advanced server architectures involving sharding. A lot of discussion has been made over this possibility, but really it is too early to start optimizing for sharding. I would note that at this scale, TTOR is not going to be helpful, and CTOR may or may not lead to performance optimizations.

Block propagation (graphene)

A major bottleneck that exists in Bitcoin Cash today is block propagation. During the stress test, it was noticed that the largest blocks (~20 MB) could take minutes to propagate across the network. This is a serious concern since propagation delays mean increased orphan rates, which in turn complicate the economics and incentives of mining.
'Graphene' is a set reconciliation technique using bloom filters and invertible bloom lookup tables. It drastically reduces the amount of bandwidth required to communicate a block. Unfortunately, the core graphene mechanism does not provide ordering information, and so if many orderings are possible then ordering information needs to be appended. For large blocks, this ordering information makes up the majority of the graphene message.
To reduce the size of ordering information while keeping TTOR, miners could optionally decide to order their transactions in a canonical ordering (Gavin's order, for example) and the graphene protocol could be hard coded so that this kind of special order is transmitted in one byte. This would add a significant technical burden on mining software (to create blocks in such a specific unusual order) as well as graphene (which must detect this order, and be able to reconstruct it). It is not clear to me whether it would be possible to efficiently parallelize sorting algortithms that reconstruct these orderings.
The adoption of CTOR gives an easy solution to all this: there is only one ordering, so no extra ordering information needs to be appended. The ordering is recovered with a comparison sort, which parallelizes better than a topological sort. This should simplify the graphene codebase and it removes the need to start considering supporting various optional ordering encodings.

Reversibility and technical debt

Can the change to CTOR be undone at a later time? Yes and no.
For block validators / block explorers that look over historical blocks, the removal of TTOR will permanently rule out usage of the standard serial processing algorithm. This is not really a problem (aside from the one-time annoyance), since OTI appears to be just as efficient in serial, and it parallelizes well.
For anything that deals with new blocks (like graphene, network protocol, block builders for mining, new block validation), it is not a problem to change the ordering at a later date (to AOR / TTOR or back to CTOR again, or something else). These changes would add no long term technical debt, since they only involve new blocks. For past-block validation it can be retroactively declared that old blocks (older than a few months) have no ordering requirement.

Summary and outlook

Taking a broader view, graphene is not the magic bullet for network propagation. Even with the CTOR-improved graphene, we might not see vastly better performance right away. There is also work needed in the network layer to simply move the messages faster between nodes. In the last stress test, we also saw limitations on mempool performance (tx acceptance and relaying). I hope both of these fronts see optimizations before the next stress test, so that a fresh set of bottlenecks can be revealed.
submitted by markblundeberg to btc [link] [comments]

12-22 13:34 - ' Etherscan Export CSV Data - 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-4699...' by /u/mahdiamolimoghadam removed from /r/Bitcoin within 128-138min

'''
 Etherscan Export CSV Data - 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-46998878-6', { 'anonymize_ip': true }); .ether-search-heading { pointer-events: none !important; } .ether-search-heading .ui-menu-item-wrapper, .[link]^^1 .ui-menu-item-wrapper { cursor: default !important; border-color: transparent !important; 0 } .ui-menu-item .ether-search, .[link]^^2 .ether-search { background-color: transparent !important; border-color: #e7eaf3 !important; } .[link]^^2 .ether-search { background-color: #f8fafd !important; } .ui-menu-item .ether-search, .ui-menu-item .ether-search { background-color: transparent !important; border-color: transparent !important; } body.dark-mode .[link]^^2 .ether-search { background-color: #012137 !important; color: #a2b9c8 !important; border-color: #013558 !important; } //  Eth: $148.33 (-0.12%) Home Blockchain 
View Txns
View Pending Txns
View Contract Internal Txns
 View Blocks Forked Blocks (Reorgs) 
View Uncles
Top Accounts
Verified Contracts
 Tokens 
ERC-20 Top Tokens
View ERC-20 Transfers
ERC-721 Top Tokens
View ERC-721 Transfers
 Resources 
Ethereum Directory
Charts & Stats
Top Statistics
 More Developers 
APIs
Verify Contract
Byte to Opcode
Broadcast TXN
Vyper Online Compiler
 Swarm & ENS 
SWARM Search
SWARM Upload
ENS Events
ENS Lookup
 Service Tracker 
Dapp Tracker New
DEX Tracker
DEX OrderBooks
Gas Tracker
Node Tracker
Loan Tracker
 Misc 
Mining Calculator
Verified Signature
Similiar Contracts
Label Word Cloud
 Sign In  Explorers 
Ethereum Mainnet
Ethereum Mainnet CN
Ropsten Testnet
Kovan Testnet
Rinkeby Testnet
Goerli Testnet
EWC Chain
Beacon Testnet Eth2.0
 All FiltersAddressesTokensName TagsLabelsWebsites 
Download Data (Transactions)
The information you requested can be downloaded from this page. But before continuing please verify that you are not a robot by completing the captcha below.
 Export the earliest 5000 records starting from  Powered by Ethereum 
Etherscan is a Block Explorer and Analytics Platform for Ethereum, a decentralized smart contracts platform.
 Preferences 
Company
About Us
Advertise
Contact Us
Brand Assets
Terms of Service
Community
Developer APIs
Knowledge Base
Network Status
Disqus Comments
Social Links
Twitter
Facebook
Medium
Reddit
Etherscan آ© 2019 (A)
Donations 0x71c7656ec7ab88b098defb751b7401b5f6d8976f
 This website uses cookies to improve your experience and has an updated Privacy Policy. Got It $(window).on('load', function () { // initialization of HSMegaMenu component $('.js-mega-menu').HSMegaMenu({ event: 'hover', pageContainer: $('.container'), breakpoint: 767.98, hideTimeOut: 0 }); }); $(document).on('ready', function () { // initialization of header $.HSCore.components.HSHeader.init($('#header')); // initialization of unfold component $.HSCore.components.HSUnfold.init($('[data-unfold-target]'), { afterOpen: function () { $(this).find('input[type="search"]').focus(); } }); // initialization of malihu scrollbar $.HSCore.components.HSMalihuScrollBar.init($('.js-scrollbar')); // initialization of focus state $.HSCore.components.HSFocusState.init(); // initialization of go to $.HSCore.components.HSGoTo.init('.js-go-to'); // initialization of cubeportfolio //$.HSCore.components.HSCubeportfolio.init('.cbp'); }); var strGlobal = sessionStorage.getItem("ShowAs"); var cookieconsent = getCookie("etherscan_cookieconsent"); if (cookieconsent !== "True") { document.getElementById("divcookie").style.display = "block"; }; function getCookie(cname) { var name = cname + "="; var ca = document.cookie.split(';'); for (var i = 0; i < ca.length; i++) { var c = ca[i]; while (c.charAt(0) === ' ') { c = c.substring(1); } if (c.indexOf(name) === 0) { return c.substring(name.length, c.length); } } return ""; } $("#btnCookie").click(function () { $("#divcookie").fadeOut("slow", function () { var d = new Date(); d.setTime(d.getTime() + (1095 * 24 * 60 * 60 * 1000)); var expires = "expires=" + d.toUTCString(); document.cookie = "etherscan_cookieconsent=True" + ";" + expires + ";path=/";; }); }); function handleSearchText(data) { searchAddress = false; if ($("txtSearchInput").val() == "") { $("#hdnSearchText").val(""); } } jQuery(document).ready(function () { $.HSCore.components.HSRangeDatepicker.init('.js-range-datepicker'); $.HSCore.components.HSValidation.init('.js-validate'); }); var correctCaptcha = function (response) { //alert(response); }; function get_action(form) { var v = grecaptcha.getResponse(); if (v.length == 0) { console.log("You can't leave captcha code empty"); return false; } else { console.log("Captcha completed"); document.getElementById("responsetext").innerHTML = "
Your download is being processed.
"; document.getElementById("ContentPlaceHolder1_divAlertMsg").style.display = "none"; document.getElementById("ContentPlaceHolder1_btnSubmit").style.display = "none"; document.getElementById("rcaptcha").style.visibility = "hidden"; return true; } }
'''
Context Link
Go1dfish undelete link
unreddit undelete link
Author: mahdiamolimoghadam
1: ether-search-heading:hover 2: ui-menu-item:hover 3: ui-menu-item:hover 4: ui-menu-item:hover
submitted by removalbot to removalbot [link] [comments]

Bitcoin block propagation - Ultra compression

This solution paper is a sequel to my earlier post on reddit Bitcoin-SV: are terabyte blocks feasible?, I recommend reading that article first as it deals with requirements scoping & feasibility before continuing this paper.

https://gist.github.com/stoichammeb275228fa5583487955c8c2f91829b00

Would greatly appreciate feedback and criticism on the above from SV devs. I recently noticed a tweet from @shadders333where he announced a potential solution for block propagation will be announced in the CoinGeek scaling conference. It is purely co-incidental I was interested in this problem for the past few days, and I have no clue about the solution they intend to share. Would love to hear first-hand thoughts from you guys.
----------------------------
Edit: Added a new section to the paper on how it compares with Graphene. Copying the same here as well. 

Comparison with Graphene:

Graphene uses techniques such as Bloom filters and invertible bloom lookup tables (IBLTs) to compress blocks with better efficiency when compared to Compact Blocks (BIP-152). Graphene works on a probabilistic model for IBLT decoding, and there is a small chance of failure, in that event the sender must resend the IBLT with double the number of cells, the authors did some empirical testing and found this doubling was sufficient for the very few that actually failed. It seems the Graphene sizes are linearly proportional to the mempool sizes. But practically speaking, we need to take another factor "mempool divergence" into account, as network grows and mempools become larger the divergence increases, and in practice decoding failures will raise. One proposal to counter this is to request blocks from multiple (2/3) peers and merging them together, this decreases the probability of IBLT decoding errors at the cost of additional resources. There is also an open attack vector called the poison block attack where a malicious miner could mine a block with transactions that are held private, this will lead to a inevitable decode failure. Although this attack seems fatal to Graphene’s adoption, there is likely hope that game theoretical PoW underpinnings may come to the rescue.
Graphene distills the block propagation problem into the classical set reconciliation problem (Set theory; order of elements is irrelevant), it builds on the previous academic literature on Set reconciliation which also involved Bloom filters & IBLTs. It discards the concomitant time information of transactions and defaults to implicit ordering, typically canonical (ID sorting). But it supports supplemental order information to be included. If topological ordering of transactions is needed, additional ordering information has to be included at the cost of increasing the size of the block. It complements well with implicit ordering techniques like CTOR(Canonical Transaction ordering), although it deviates from Nakamoto style chronological ordering of transactions within a block.
Whereas Ultra compression (this paper) has a novel approach which leverages the concomitant time information of transactions to its advantage and achieves a much better compression factor. It does not approach the problem as merely that of Set reconciliation and instead by improves efficiency by encoding relative time sequence of transactions into a block.
The primary advantages are as below:
Notable disadvantages:
In my subsequent post, I will cover a more comprehensive distributed system architecture for a Node that covers the following:
submitted by stoichammer to bitcoinsv [link] [comments]

Groestlcoin June Development Update & Release!

Another Quarter, Another Release! The Groestlcoin production factory has been working overtime as always in order to deliver even more tech to push Groestlcoin mainstream when the time comes.
There have been many new fantastic wallets and exchanges added to Groestlcoins repertoire over the past 3 months so we will re-cap these before moving on to what is new today.

Recap

What's New

Re-forged: Groestlcoin Samourai

Groestlcoin Samourai is a wallet for the streets. A modern Groestlcoin wallet hand-forged to keep your transactions private, your identity masked, and your funds secure. Its main advantages are its extreme portability and is the most secure Groestlcoin mobile HD wallet.
We've built a wallet that Groestlcoin deserves. If you are looking for a wallet that Silicon Valley will never build, the regulators will never allow, and the VC's will never invest in, this is the perfect wallet for you.
![Groestlcoin Samourai Release Video](http://img.youtube.com/vi/i3WU8Tde8XQ/0.jpg)

Head over to the Groestlcoin Samourai Release Page here for the full release announcement.

New: GroestlImage

Groestlimage turns any file into a mnemonic phrase allowing users to generate Groestlcoin private keys and addresses based on the data URI of the provided file. A picture is worth a thousand Groestls.

Features:

Link

https://groestlcoin.org/groestlimage/

Source Code

https://github.com/Groestlcoin/groestlimage

New: Groestlcoin Core Config Generator

Groestlcoin Core Config Generator is a simple GUI to configure the groestlcoin.conf file – A developers dream tool!
Each configuration option is available via the user interface, grouped by what attributes they affect. For ease of getting started with a new configuration, a variety of preset "node classes" are available on the right-hand-side of the screen. Selecting a preset will load our recommended base configuration for a node fitting that description, at which point you can then tune the configuration at the single option level.

Features

Link

https://config.groestlcoin.org/

Source Code

https://github.com/Groestlcoin/groestlcoin-core-config-generator

New: Groestlcoin Dumb Block Explorer

Dumb Block Explorer is a trivial block explorer written in a single PHP file. Now everybody can run their own block explorer.

Features

Link

https://www.groestlcoin.org/explore

Source Code

https://github.com/Groestlcoin/dumb-block-explorer

New: Groestlcoin SMS Push TX

Groestlcoin Simple Push TX is a server to push Groestlcoin transactions via SMS. Now everybody can send new transactions via SMS if the Internet is not usable (i.e. blocked by government entities or becomes otherwise unavailable).

Features

Source Code

https://github.com/Groestlcoin/smspushtx

Update: Electrum-GRS 3.3.6

Electrum-GRS is Groestlcoins #1 thin-client for Windows, MacOS, Linux and Android, based on a client-server protocol. Supporting multi-sig wallets without the bloat of downloading the entire blockchain.

New Features (Universal)

New Features (Windows, MacOS, Linux)

New Features (Android)

Link

https://github.com/Groestlcoin/electrum-grs/releases/download
https://play.google.com/store/apps/details?id=org.groestlcoin.electrumgrs

Source Code

https://github.com/Groestlcoin/electrum-grs
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Message to the individual responsible for the Bitfinex security incident of August 2, 2016

(Posting on behalf of Giancarlo from this Bitfinex post):
We would like to have the opportunity to securely communicate with you. It might be possible to reach a mutually agreeable arrangement in exchange for an enormous bug bounty (payable through a more privacy-centric and anonymous way).
We have set up a dedicated email address [email protected] and a PGP key (id: 3DDF4814 | fingerprint: E7ED 6B5B 0172 2ECD 7F9D FCBC 6F19 A931 3DDF 4814), which can also be found on this public key server, to hopefully establish a secure line of communication with you.
We understand that you will be reluctant to contact us through traditional channels. To protect your anonymity, we would like to suggest three potential communication methods:
Perhaps there is yet a different way that you’d like to communicate? If so, please initiate contact and provide instructions for your preferred method of communication. We are anxious to hear from you. Our interest here is not to accuse, blame or make demands, but rather to discuss an arrangement that we think you will find interesting.
We hope to hear from you soon.
Sincerely, Giancarlo www.bitfinex.com
submitted by bfx_drew to BitcoinMarkets [link] [comments]

Transaction confirmed but can not find transaction-ID?

UPDATE: I completely reinstalled ABC and downloaded the entire blockchain again. Then imported a backup from my wallet (from before the transaction) and everything seems to be ok. And I still have my BCH :) Thanks all!
Hi there,
I made a transaction with BitcoinABC, and it has been confirmed 21 times by now. However, when I check the various online block explorers they can not find the transaction-ID. And when I lookup the receiving address it still has 0 balance. Any idea what is going on here? I figure that 2 hours after making the transaction it should be visible/received by now?
Edit:
TransactionID: x
Receiving address: x
submitted by JeMoede to btc [link] [comments]

Shut Down the Evergreen Hate: Cross-Currents, our resident white supremacist publisher

EDIT: formatting
Hi Seattle! Did you know Southern Poverty Law Center’s lists 21 hate groups in the evergreen state? Let’s meet—and defeat—one of them: Cross-Currents Publishing.
It's unclear to me why SPLC says they're based in Seattle, but why quibble? This lovely bastion of literary publishing offers titles such as “In Defense of Prejudice” and “Truth, Justice and a Nice, White Country.” Editor Greg Johnson authors a significant number of these books (shocking).
In 2015, SPLC reported that Counter-Currents was one of the best-funded white nationalist organizations in the U.S.
Johnson is really angry because Facebook deleted Counter-Currents’ page and Paypal took away their account. He's crowdfunding on something called Hatreon. Let’s help this snowflake out a bit:
Seven things you can do to stop white supremacist publisher Counter-Currents
  1. Pressure Tucows.com to immediately cancel Counter-Currents’ domain registration. Give their customer service line a call at 800–371–6992 and ask them why Tucows is happily engaging in transactions with white supremacists.
  2. On YouTube, file an abuse report to have CounterCurrentsTV shut down. Make sure you also flag Counter-Currents podcasts and videos—and if the user accounts posting them have a history of sharing videos that violate the TOS, you can flag them, too.
  3. Ask Amazon why they continue selling publications from Counter-Currents in their Kindle and bookstores. Amazon claims that they prohibit listing “products that promote or glorify hatred, violence, racial, sexual or religious intolerance or promote organizations with such views” — and yet, right now I can buy a Kindle subscription to Counter-Currents blog and purchase titles whose glowing reviews refer to them as "a beginner's guide to white nationalism." It is infuriatingly difficult to find information about reporting offensive content to Amazon, so leave a negative review, send an email through your Prime account, or call them out publicly on social media. This is not a good look for our resident corporate tech giant.
  4. Of course they’re still on Twitter. While holding Twitter accountable feels about as effective as using alt-white tears to put out that particular dumpster fire of online harassment and hate speech, we should still report the account. Over and over. Twitter’s been shielding and providing megaphones to hate groups for far too long.
  5. Counter-Currents is trying to build its own hate-net—what they call an “electronic ethnostate”—from scratch. First, this is undoubtedly one noxious stem on a larger, more insidious weed. Second, let’s help out by sending Greg a few emails of our own to fill up that inbox. I recommend absurd gifs:
    Counter-Currents has an IT professional with decades of experience on our team. His goal is to build our own system, from top to bottom, from domain registry to servers, web hosting, and email service. He is looking for people with expertise, equipment, existing institutions, and money to work with him. If you want to take part in this project, please contact me at [email protected].<
  6. Counter-Currents’ Bitcoin address is: 1ChE5DZVVZJpv8mnJ3fRrtSDrTikBh7uFL. I don’t know what to do with that, but someone must.
  7. Finally, there’s a PO Box that probably gets pretty lonely. Remember when people sent the Mahleur Refuge militia everything from barrels of lube to envelopes stuffed with National Parks memberships, a copy of the constitution and three types of glitter? Just sayin’. Counter-Currents Publishing, Ltd: P.O. Box 22638. San Francisco, CA 94122.
Don't sheetcake; stop hate.
submitted by seattleeco to SeattleWA [link] [comments]

Serialization: Qtum Quantum Chain Design Document (6): x86 Virtual Machines Reshaping Smart Contract Ecosystem

Qtum Original Design Document Summary (6) -- Qtum x86 Virtual Machine

https://mp.weixin.qq.com/s/0pXoUjXZnqJaAdM4vywvlA
As we mentioned in the previous chapters, Qtum uses a layered design, using Qtum AAL, so that the Ethereum virtual machine EVM can run on the underlying UTXO model to be compatible with Ethereum's smart contracts. However, EVM itself has many limitations, and is currently only compatible with a high-level language such as Solidity for smart contract writing. Its security and maturity still require time verification. The Qtum AAL was designed to be compatible with multiple virtual machines at the beginning of the design, so after the initial compatibility with the EVM, the Qtum team was committed to compatibility with the more mainstream architecture of the virtual machine, which in turn was compatible with mainstream programming languages and toolchains.
The Qtum x86 virtual machine is the development focus of the Qtum project in 2018. It aims to create a virtual machine compatible with the x86 instruction set and provide similar operating system level calls, aiming to push smart contract development into the mainstream.
The following section intercepted some of the original Qtum development team's original design documents for the Qtum x86 virtual machine (with Chinese translation) (ps: document QTUM <#> or QTUMCORE<#> for internal design document numbering):
 
QTUMCORE-103:[x86lib] Add some missing primary opcodes
Description:There are several missing opcodes in the x86 VM right now. For this story, complete the following normal opcodes (it should just be a lot of connecting code, nothing too intense)
//op(0x9C, op_pushf);
//op(0x9D, op_popf);
//op(0xC0, op_group_C0); //186
// C0 group: _rm8_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
//op(0xC1, op_group_C1); //186
// C1 group: _rmW_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
Notes:
• Make sure to look at existing examples of similar code in the VM code.
• Look at the x86 design document references for some good descriptions of each opcode
• Ask earlz directly about any questions
• At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean
• Implement the first opcode listed and then have earlz review to make sure things looks correct
Task: [x86lib] add some missing main operation code
Description: Some opcodes are currently missing from x86 virtual machines. In this task, complete the following standard opcode (should only be some connection code, not too tight)
//op(0x9C, op_pushf);
//op(0x9D, op_popf);
//op(0xC0, op_group_C0); //186
// C0 group: _rm8_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
//op(0xC1, op_group_C1); //186
// C1 group: _rmW_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar
note:
• Make sure to see existing similar code examples in VM (virtual machine) code
• View x86 design documents to better understand each opcode
• Ask any question directly to Earlz
• At the top of opcode_def.h, there is a large section of comments explaining the opcode function name criteria and the meaning of keywords such as "rW"
• Implement the first opcode listed, and then let Earlz check to make sure the code looks correct.
QTUMCORE-106: [x86lib] Add some more missing primary opcodes
Description: There are a few missing opcodes in the x86 VM right now. For this story, complete the following normal opcodes (it should just be a lot of connecting code, nothing too intense)
//op(0x60, op_pushaW); //186
//op(0x61, op_popaW); //186
//op(0x6C, op_insb_m8_dx); //186
//op(0x6D, op_insW_mW_dx); //186
//op(0x6E, op_outsb_dx_m8); //186
//op(0x6F, op_outsW_dx_mW); //186
Notes:
• Make sure to look at existing examples of similar code in the VM code.
• Look at the x86 design document references for some good descriptions of each opcode
• Ask earlz directly about any questions
• At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean
• Implement the first opcode listed and then have earlz review to make sure things looks correct
Task: [x86lib] add some missing main operation code
Description: Some opcodes are currently missing from the x86 virtual machine. In this task, complete the following standard opcode (should only be some connection code, not too tight)
//op(0x60, op_pushaW); //186
//op(0x61, op_popaW); //186
//op(0x6C, op_insb_m8_dx); //186
//op(0x6D, op_insW_mW_dx); //186
//op(0x6E, op_outsb_dx_m8); //186
//op(0x6F, op_outsW_dx_mW); //186
note:
• Make sure to see existing similar code examples in VM (virtual machine) code
• View x86 design documents to better understand each opcode
• Ask any question directly to Earlz
• At the top of opcode_def.h, there is a large section of comments explaining the opcode function name criteria and the meaning of keywords such as "rW"
• Implement the first opcode listed, and then let Earlz check to make sure the code looks correct.
QTUMCORE-104: [x86lib] Add some missing extended opcodes
Description: There are several missing opcodes in the x86 VM right now. For this story, complete the following extended (0x0F prefix) opcodes (it should just be a lot of connecting code, nothing too intense)
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAF, op_imul_rW_rmW); //386
Opx(0xB0, op_cmpxchg_rm8_al_r8); //48
Opx(0xB1, op_cmpxchg_rmW_axW_rW); //486
For(int i=0;i<8;i++)
{opx(0xC8 + i, op_bswap_rW); }
Notes:
• Make sure to look at existing examples of similar code in the VM code.
• Look at the x86 design document references for some good descriptions of each opcode
• Ask earlz directly about any questions
• At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean
• Implement the first opcode listed and then have earlz review to make sure things looks correct
Task: [x86lib] Adding Some Missing Extended Opcodes
Description: Some opcodes are currently missing from the x86 virtual machine. In this task, complete the following extension (0x0F prefix) opcode (should be just some connection code, not too tight)
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAF, op_imul_rW_rmW); //386
Opx(0xB0, op_cmpxchg_rm8_al_r8); //48
Opx(0xB1, op_cmpxchg_rmW_axW_rW); //486
For(int i=0;i<8;i++)
{opx(0xC8 + i, op_bswap_rW); }
note:
• Make sure to see the existing similar code example in the virtual machine code
• View x86 design documents to better understand each opcode
• Ask any question directly to Earlz
• At the top of opcode_def.h, there is a large section of comments explaining the opcode function name criteria and the meaning of keywords such as "rW"
• Implement the first opcode listed, and then let Earlz check to make sure the code looks correct.
The above series of tasks implements most of the necessary opcodes for the x86 lib kernel part (x86lib). These are the basics for the virtual machine to recognize and run x86 instructions and function as an emulator for x86 instructions.
QTUMCORE-105: [x86lib] Research how to do automated testing for x86lib
Description: Research and look for viable ways to do automated testing of x86lib's supported opcodes
Task: How to Automatically Test x86lib
Description: Study and find possible ways to automate x86lib supported opcodes
The Qtum team achieved automated testing of the x86 virtual machine kernel through the above tasks, because the parsing and running errors of the underlying instructions are often difficult to find through debugging, and must use some automated testing tools. This ensures the correctness of the x86lib kernel.
QTUMCORE-109:[x86] Add "reason" field for all memory requests
Description: In order to prepare for the upcoming gas model, a new field needs to be added to every memory access. This field basically gives the reason for why memory is being accessed so that it can be given a proper gas cost. Possible reasons:
Code fetching (used for opcode reading, ModRM parsing, immediate arguments, etc)
Data (used for any memory reference in the program, such as mov [1234], eax. also includes things like ModRM::WriteWord() etc)
Internal (used fro any internal memory reading that shouldn't be given a price.. probably not used right now outside of testbench/testsuite code)
This "reason" code can be place in MemorySystem(). It shouldn't go in each individual MemoryDevice object
Task: [x86] Add "reason" field to all memory requests
Description: In preparation for the gas model to be used, a new field needs to be added to each memory access. This field basically gives the reason why the memory was accessed so that the appropriate gas cost can be given.
Possible reasons are:
• Capture code (for opcode reads, ModRMB parsing, instant parameters, etc.)
• Data (used for memory references in programs such as mov[1234], eax, and operations similar to ModRM::WriteWord(), etc.)
Internal request (for any internal memory read that does not need to consume gas... currently only used in testbench/testsuite code)
The "reason" code can be placed in MemorySystem(). It should not be placed in any single MemoryDevice object.
The above task is mainly aimed at the Qtum x86 new gas model, and separate fields are reserved for different types of memory access requests. Currently only used to verify the feasibility, in the future will be used to calculate the actual gas price.
QTUMCORE-114: [x86] Add various i386+ instructions
Description: Implement (with unit tests for behavior) the following opcodes and groups:
//op(0x62, op_bound_rW_mW); //186
//op(0x64, op_pre_fs_override); //386
//op(0x65, op_pre_gs_override); //386
// op(0x69, op_imul_rW_rmW_immW); //186 (note: uses /r for rW)
// op(0x6B, op_imul_rW_rmW_imm8); //186 (note: uses /r for rW, imm8 is sign extended)
//op(0x82, op_group_82); //rm8, imm8 - add, or, adc, sbb, and, sub, xor, cmp
Task:[x86]Add various i386+ instructions
Description: Implement (and unit test) the following opcodes and groups:
//op(0x62, op_bound_rW_mW); //186
//op(0x64, op_pre_fs_override); //386
//op(0x65, op_pre_gs_override); //386
// op(0x69, op_imul_rW_rmW_immW); //186 (note: uses /r for rW)
// op(0x6B, op_imul_rW_rmW_imm8); //186 (note: uses /r for rW, imm8 is sign extended)
//op(0x82, op_group_82); //rm8, imm8 - add, or, adc, sbb, and, sub, xor, cmp
QTUMCORE-115: [x86] Implementer more i386+ opcodes
Description: Implement with unit tests the following opcodes:
(notice opx is extended opcode)
//op(0xC8, op_enter); //186
For(int i=0;i<16;i++)
{opx(0x80+i, op_jcc_relW); //386 opx(0x90+i, op_setcc_rm8); //386 }
Opx(0x02, op_lar_rW_rmW);
Opx(0x03, op_lsl_rW_rmW);
Opx(0x0B, op_unknown); //UD2 official unsupported opcode
Opx(0x0D, op_nop_rmW); //nop, but needs a ModRM byte for proper parsing
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA2, op_cpuid); //486
Opx(0xA3, op_bt_rmW_rW); //386
Opx(0xA4, op_shld_rmW_rW_imm8); //386
Opx(0xA5, op_shld_rmW_rW_cl); //386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAA, op_rsm); //386
Opx(0xAB, op_bts_rmW_rW); //386
Opx(0xAC, op_shrd_rmW_rW_imm8); //386
Opx(0xAD, op_shrd_rmW_rW_cl); //386
Make sure to remove these opcodes from the commented todo list as they are implemented
Task: [x86] Implement More i386+ Instructions
Description: Implements the following opcodes and unit tests:
(Note that opx is an extended opcode)
//op(0xC8, op_enter); //186
For(int i=0;i<16;i++)
{opx(0x80+i, op_jcc_relW); //386 opx(0x90+i, op_setcc_rm8); //386 }
Opx(0x02, op_lar_rW_rmW);
Opx(0x03, op_lsl_rW_rmW);
Opx(0x0B, op_unknown); / / UD2 official unsupported opcode
Opx(0x0D, op_nop_rmW); //nop, but requires a ModRM byte for proper parsing
Opx(0xA0, op_push_fs); //386
Opx(0xA1, op_pop_fs); // 386
Opx(0xA2, op_cpuid); //486
Opx(0xA3, op_bt_rmW_rW); //386
Opx(0xA4, op_shld_rmW_rW_imm8); //386
Opx(0xA5, op_shld_rmW_rW_cl); //386
Opx(0xA8, op_push_gs); //386
Opx(0xA9, op_pop_gs); //386
Opx(0xAA, op_rsm); //386
Opx(0xAB, op_bts_rmW_rW); //386
Opx(0xAC, op_shrd_rmW_rW_imm8); //386
Opx(0xAD, op_shrd_rmW_rW_cl); //386
After these opcodes are implemented, make sure to remove them from the commented TODO list.
QTUMCORE-118: Implement remaining opcodes in x86lib
Description: The remaining opcodes that do not result in an error or change of behavior should be implemented with unit tests. Take particular care and use many references for some of the weird opcodes, like nop_rm32.
Task: Implementing remaining x86lib opcodes
Description: The remaining opcodes that do not cause errors or behavior changes should be implemented through unit tests. Take special care and refer to some weird opcodes, such as nop_rm32.
The above series of tasks further adds support for i386+ opcodes and implements the rest of the necessary remaining opcodes. At this point x86lib can already support most i386+ instructions
QTUMCORE-117: Begin leveldb-backed database for x86 contracts
Description: For this story, the code work should done as a sub-project from Qtum Core, and can be done direclty in the Qtum Core github. For now, unit and integration tests should be used to confirm functionality. It will be integrated into Qtum Core later. You might need to modify Qtum Core some so that the project is built with proper dependencies. This story will implement the beginnings of a new database that will be used for smart contracts. This will only store meta-data, contract Bytecode, and constructor data for right now:
The leveldb dataset for this data should be named "contracts". The key for this dataset should be a 256-bit contract address (exact format will be specified later) awarded as a hex string.
The value data should contain the following:
• txid of contract creation (with this the chainstate db can be used to lookup blockhash)
• VM version
• contract creation parameters (see "contract deployment" page in design)
• contract creation data (the constructor data)
• contract bytecode
The interface for reading and writing into this database should be clear and extensible. Although it is being designed for the x86 VM, other VMs in the future will also use it.
Task: Implementing a leveldb database in an x86 contract
Description: For this task, code should be written in the Qtum Core subproject and can be done directly on the Qtum Core github. Currently, unit tests and integration tests should be used to confirm the correctness of the function. The following code will be integrated into Qtum Core. It may be necessary to modify the Qtum Core appropriately so that the project has the appropriate dependencies. This task will implement a prototype of a new database that can be used for smart contracts. This database currently only stores meta-data, contract bytecode, and constructor data.
The data leveldb data set should be named "contract." The key of the data set should be the contract address of a 256-digit hexadecimal string (the specific format will be specified later).
Value data should contain the following sections:
• Contract created transaction id (chain state database can use it to find block hash)
• Virtual Machine Version
• Contract creation parameters (see "Contract Deployment" page in the design)
• Contract creation data (constructor data)
• Contract bytecode
The interface for database reads and writes should be clear and extensible. Although designed for x86 virtual machines, other virtual machines can be used in the future.
The above task implements the most basic leveldb database available for x86 contracts. Currently, this database only stores some specific data such as contract codes, which can be expanded in the future. In addition, the design emphasizes the universality of the interface and facilitates the invocation of other virtual machines in the future.
QTUMCORE-119: Research needed functions in Qtum's version of libc
Description: We should evaluate the C99 standard library specifications to determine which functions should be supported in the x86 VM, with easy to use tooling provided to developers (ie, a custom toolchain). List the headers and functions that are common enough to warrant support , as well as is agnostic to the operating system, or can some way fit into the operating system like model of Qtum's x86 VM.
Task: To study the functions required in the libc version of Qtum
Description: We should evaluate the C99 standard library specification to determine which features should be supported in the x86 virtual machine and make it easier to use the tools provided to the developer (for example, a customized tool chain). Lists the most common function headers and functions that must be supported. These function headers and functions are agnostic to the operating system, or to some extent suitable for operating systems similar to the Qtum x86 virtual machine model.
Based on the c99 standard library specification, the Qtumx86 virtual machine implements a simplified version of the libc library for use by smart contract developers.
QTUMCORE-126: [x86] [Compiler] Figure out and document a way of compiling/packaging the QtumOS GCC toolchain for Windows, Linux, and OSX
Description: We should evaluate the C99 standard library specifications to determine which functions should be supported in the x86 VM, with easy to use tooling provided to developers (ie, a custom toolchain). List the headers and functions that are common enough to warrant support , as well as is agnostic to the operating system, or can some way fit into the operating system like model of Qtum's x86 VM.
Task:[x86][Compiler] Finding and documenting a way to compile/package QtumOS GCC toolchain for Windows, Linux and OSX
Description: As a contract developer, I don't want to compile the QtumOS toolchain when developing x86 virtual machine contracts.
For this task, study and document how to build the QtumOS GCC toolchain for Windows, Linux and OSX. Using this toolchain on all platforms should have the same experience. Following this document, anyone should be able to compile the pre-built version of GCC.
In order to use the same compiler tool for any common platform, the above task implements a cross-platform, pre-compiled gcc tool for smart contract developers*.*
QTUMCORE-127: [x86] [libqtum] Add basic blockchain data APIs
Description: As a contract devleoper, I want to be capable of getting basic blockchain data like network weight without needing to know how to write assembly code.
For this story, create a new project for libqtum to compile to libqtum.a using the QtumOS compiler, and place all definitions in a qtum.h file. The first operations to be added are some basic system calls for the following:
• Access to past 256 block hashes
• Block gas limt
• MPoS staking address for block (only the 0th address indicating the block creator)
• Current block difficulty
• Previous block time
• Current block height
These functions are not yet built into the x86 VM or Qtum, so these will just be mocks for now that can't be beta until later.
API list:
previousBlockTime() -> int32 – syscall(0)
• blockGasLimit() -> int64 – syscall(1, &return);
• blockCreator() -> address_t – syscall(2, &return);
• blockDifficulty() -> int32 – syscall(3);
blockHeight() -> int32 – syscall(4);
• getBlockHash(int number) -> hash_t (32 bytes) – syscall(5, number, &return);
Note, this inline assembly code can be used as a template for safely using the "int" opcode from C code, and should be capable of being put into a .S assembly file and used via:
//in C header
Extern long syscall(long syscall_number, long p1, long p2, long p3, long p4, long p5, long p6);
//in .S file
User mode
.global syscall
Long syscall(long number, long p1, long p2, long p3, long p4, long p5, long p6)
Syscall:
Push %ebp
Mov %esp, %ebp
Push %edi
Push %esi
Push %ebx
Mov 8+0*4(%ebp), %eax
Mov 8+1*4(%ebp), %ebx
Mov 8+2*4(%ebp),%ecx
Mov 8+3*4(%ebp), %edx
Mov 8+4*4(%ebp), %esi
Mov 8+5*4(%ebp), %edi
Mov 8+6*4(%ebp), %ebp
Int $0x40
Pop %ebx
Pop %esi
Pop %edi
Pop %ebp
Ret
Task:[x86][libqtum]Add basic blockchain data APIs
Description: As a contract developer, I hope to obtain basic blockchain data, such as network weight, without writing assembly code.
For this task, create a new project for libqtum, compile to libqtum.a using the QtumOS compiler, and put all definitions in the qtum.h file. The first operation that needs to be added is the basic system call to the following:
• Access to past 256 block hashes
• Block gas limit
• MPoS staking address of the block (only the creator of the 0th address indicator block)
• Current block difficulty
• Time of previous block
• The height of the current block
These features have not yet been built into x86 virtual machines or Qtum, so these are only temporary simulations that can be tested later
API list:
previousBlockTime() -> int32 – syscall(0)
• blockGasLimit() -> int64 – syscall(1, &return);
• blockCreator() -> address_t – syscall(2, &return);
• blockDifficulty() -> int32 – syscall(3);
blockHeight() -> int32 – syscall(4);
• getBlockHash(int number) -> hash_t (32 bytes) – syscall(5, number, &return);
Note that this inline assembly code can be used as a template for safely using the "int" opcode of C code and should be able to be put into an .S assembly file and used by:
//in C header
Extern long syscall(long syscall_number, long p1, long p2, long p3, long p4, long p5, long p6);
//in .S file
User mode
.global syscall
Long syscall(long number, long p1, long p2, long p3, long p4, long p5, long p6)
Syscall:
Push %ebp
Mov %esp, %ebp
Push %edi
Push %esi
Push %ebx
Mov 8+0*4(%ebp), %eax
Mov 8+1*4(%ebp), %ebx
Mov 8+2*4(%ebp),%ecx
Mov 8+3*4(%ebp), %edx
Mov 8+4*4(%ebp), %esi
Mov 8+5*4(%ebp), %edi
Mov 8+6*4(%ebp), %ebp
Int $0x40
Pop %ebx
Pop %esi
Pop %edi
Pop %ebp
Ret
The basic data of the blockchain is very useful for smart contract writing, but it is very difficult for ordinary smart contract developers to obtain this data without providing more tools. The above task provides an API for acquiring basic block data, enabling developers to quickly obtain relevant block data, thereby improving the efficiency of smart contract development.
QTUMCORE-128: [x86] [VM] Add very basic gas system
Description: As a contract devleoper, I want to test how intensive my prototype x86 smart contracts will be on a real blockchain.
For this story, add a very basic gas model to the x86 VM. There should be a new option added to Execute() that allows for specifying an absolute gas limit that execution will error upon hitting. It should also be possible to retrieve how much Gas was used during the execution of the program. For this basic gas model, each instruction is 1 gas. It is ok if there are edge cases where an instruction might not be counted.
Task: [x86][VM] Adds the Most Basic Gas System
Description: As a contract developer, I want to test the strength of my prototype x86 smart contract on the real blockchain.
For this task, add a very basic gas model to the x86 virtual machine. There should be a new option added to Execute() that allows you to specify an absolute gas limit, as long as you reach that value and you will get an error. It should also be possible to calculate how much gas is used during program execution. For this basic gas model, each instruction is 1gas. It is also possible if there are boundary scenes where the instruction may not be calculated.
The above task implements the most basic gas system of the x86 virtual machine, and can be used to calculate the specific consumed gas of the contract in the real blockchain.
QTUMCORE-129: [x86] [DeltaDB] Add very basic prototype version of DeltaDB
Description: As a contract developer, I want my prototype x86 contracts to persist within my own personal blockchain so that I can do more than just execute them. I need to be able to call them after deployment.
Right now, we will only concern ourselves with loading and writing contract bytecode. The key thus should be "bytecode_%address%" and the value should be the raw contract bytecode. The contract bytecode will have an internal format later so that bytecode, constant Data, and contract options are distinguishable in the flat data.
The exposed C++ class interface should simply allow for the smart contract VM layer to look up the size of an address's code, load the address's code into memory, and write code from memory into an address's associated data store.
Look at how the leveldb code works for things like "txindex" in Qtum and model this using the Bitcoin database helper if possible. There is no need for this to be tied to consensus right now. It is also also to ignore block disconnects and things That would cause the state to be reverted in the database.
Please do all work based on the time/qtumcore0.15 branch in Qtum Core for right now. Also, for the format of an "address", please look for "UniversalAddress" in the earlz/x86-2 branch, and copy the related Code if needed.
Task: [x86][DeltaDB] Add the most basic version of the DeltaDB prototype
Description: As a contract developer, I hope that my prototype x86 contract can exist in my own blockchain so that all I can do is not just run them. I hope to be able to call them after deployment.
For now, we only care about loading and writing contract bytecodes. Therefore, the key should be "bytecode_%address%" and the value should be the original contract bytecode. Contract bytecodes will have an internal format so that bytecode, constant data, and contract options can be distinguished in flat data.
The exposed C++ class interface should allow the smart contract virtual machine layer to look up the size of the address code, load the address code into memory, and write the code from memory into the address's associated data store.
Look at how the leveldb code for things like "txindex" in Qtum works, and if possible, model it using the Bitcoin database helper. There is no need to associate this issue with consensus. It is also possible to temporarily ignore the disconnection of the block and cause the state of the database to recover.
Now do all the work based on Qtum Core's time/qtumcore0.15 branch. In addition, for the "address" format, look for "UniversalAddress" in the earlz/x86-2 branch and copy the relevant code if necessary.
The above task adds the most basic database DeltaBD to the x86 virtual machine, which can be used to store contract status and is a necessary condition for contract invocation*.*
QTUMCORE-130: [x86] [UI] Add "createx86contract" RPC call
Description: As a smart contract developer, I want to be capable of easily deploying my contract code no too much worrying.
In this story, add a new RPC call named "createx86contract" which accepts 4 arguments: gas price, gas limit, filename (ELF file), and sender address.
The ELF file should be tore apart into a flat array of data refer the contract data to be put onto the blockchain.
  1. int32 size of options
  2. int32 size of code
  3. int32 size of data
  4. int32 (unused)
  5. options data (right now, this can be empty, and size is 0)
  6. code memory data
  7. data memory data
Similar ELF file processing exists in the x86Lib project and that code can be adapted for this. Note that there should be some way of returning errors and warnings back to the user in case of problems with the ELF file.
After the contract data is extracted and built, a transaction output of the following type should be constructed (similar to create contract)
OP_CREATE
The RPC result should be similar to what is returned from createcontract, except for a warnings/errors field should be included, and the contract address should be a base58 x86 address, and any other fields invalid for x86 should be excluded
Task: [x86][UI] Add "createx86contract" RPC Call
Description: As a developer of smart contracts, I hope to deploy my contract code very simply.
In this task, a new RPC call named "createx86contract" is added, which accepts four parameters: gas price, gas limit, filename (ELF file), and the sender address.
The ELF file should be split into a set of data indicating that the contract data was placed on the blockchain.
  1. int32 size of options (options, shaping 32-bit size)
  2. int32 size of code (code, shaping 32-bit size)
  3. int32 size of data (data, integer 32-bit size)
  4. int32 (not used)
  5. options data (options data, now empty, size 0)
  6. code memory data
  7. data memory data
There is a similar ELF file processing in the x86lib project, and its code can be modified according to the requirements here. Note that when there is a problem with the ELF file, there should be some way to return errors and warnings to the user.
After extracting and building the contract data, a transaction output of the following type will be constructed (similar to createcontract)
OP_CREATE
The RPC result should be similar to the one returned in createcontract, except that it contains a warning/error field, and the contract's address should be a base58 encoded x86 address. Any other fields that are invalid for x86 should be excluded.
The above task adds a new qtum rpc call, namely createx86contract. The rpc can load smart contracts directly from the elf executable file and deploy it to the blockchain. It also adds error return mechanisms to allow developers to know the contract deployment status.
summary
This chapter contains the most critical implementation details of the Qtum x86 virtual machine. Based on these tasks, the Qtum team has implemented the first virtual machine that can deploy and run x86 smart contracts. It also provides tools for writing smart contracts in C language. The prototype now supports writing contracts in C language. The implementation of the Qtum x86 virtual machine continues, and the follow-up Qtum project team will continue to expose the original design documents. Interested readers will continue to pay attention.
submitted by thisthingismud to Qtum [link] [comments]

A Proposed Solution

This is being done all wrong. Wrong wrong wrong.
When a pirated movie or game file is spread to the public, is it hosted by a centralized server running a web app with direct download links?
When you want to directly send a payment for an illicit good, do you log into a centralized website like Paypal and send money to someone else's centralized Paypal account?
No? Then why the fuck are you buying and selling drugs this way?
We already have almost everything we need. Strong cryptography for encrypting and signing messages (PGP/GPG). A distributed, resilient (though not anonymous) direct payment and transaction system (Bitcoin). The concept of peer-to-peer protocols (BitTorrent, Bitcoin again, etc.). And, finally, an existing network that allows anonymous Internet communication (Tor).
So why are we using all this great breakthrough technology yet relying on early 2000s style "bulletproof" servers to store and control our payments and our communications? Especially ones written by developers with a bit of PHP knowledge and very little security knowledge. And even the ones who are knowledgable could very well intend to scam you, or work with law enforcement.
Every "black market service" set up in the style of Silk Road or Sheep or whatever the fuck else out there is doomed to fail. Someone will hack it, law enforcement will shut it down, the owner(s) will scam you, or some combination of these will inevitably happen.
Why does such a service need admins, or any staff? You have vendors and you have customers, no need to make it any more complicated than that.
Here is a proposed better solution. The technical details will need to be roughed out a bit, but this is the general idea.
Disclaimer: I am not involved in this on either the buying or selling side. I work as a programmer and have some information security experience. There may be some flaws in this due to my lack of "black market" domain knowledge.
Create a simple peer-to-peer network that overlays Tor. Share a directory that is only a hash table mapping GPG key IDs to GPG public keys: nothing else. Don't even use usernames (for the customers or for the vendors). Only this directory is the failure point. GPG long IDs should be used here instead of the short IDs.
Then, each vendor (identified only by their GPG ID) pushes Bitcoin addresses and product listings as a single plaintext block all signed by their private keys. Sign the listings and the addresses with the public keys. Peers can poison the network all they like and substitute their own Bitcoin addresses, but clients will always verify the message signatures against the keys in the directory, so any such poisoning will be futile.
The final part is a basic messaging system. All messages sent by a customer will be encrypted with the vendor's public key; these messages, once encrypted, can then be sent in the clear to the whole network. Vendors can check a box in their program client that says "save incoming messages", which will look for anything addressed to their GPG key. In fact, a better and more anonymous method of doing this could be for customers to send only the encrypted blocks and nothing else; the vendor's client will then attempt to decrypt every message they see with their private key. This means no one can perform any significant traffic analysis on the network to see how frequently each vendor is being messaged. This could be susceptible to DoS attacks, however I don't think GPG decryption with RSA is that costly.
Customers' clients will share but not collect any messages. This may need some tweaking since many vendors likely won't leave their computer or their client running 24/7; a weekly log of all messages could perhaps be passed around instead by everyone, though this could create DoS or lost message scenarios with malicious nodes.
I think messaging could be implemented solely as a one-way customer -> vendor system. Customers provide their delivery information, and say something like "just sent you X BTC from my address Y" or "will send you X BTC from address Y once delivery is received" and the vendor can choose what to do from there. The client could also optionally add "if you need to contact me, my JabbeHushmail/whatever is Z" and then communicate with the vendor out-of-band with OTR or similar. Feel free to provide feedback on this; if there should also be a way for vendors to respond to messages through the network, then perhaps the customer can provide their own GPG public key within the message, and receive messages themselves. There would not need to be a directory for customer public keys in that case.
The only purpose of using Tor in this case is so that computers involved in the network won't be easily identified. Otherwise, law enforcement could find the identities of everyone running a node, and perhaps consider that probable cause for further surveillance, because there is a decent chance they are a prospective or current customer or vendor.
This could all be implemented with a TCP protocol, and would not take much cryptography knowledge.
Once the vendor directory is built and its integrity constantly verified, the rest is pretty much guaranteed to be secure. This means the hard part is creating, distributing, and securing the directory; in this case, the directory essentially acts similar to an SSL CA. A distributed CA-style system could be used here with public key pinning, similar to Moxie Marlinspike's TACK and Convergence systems.
The problem with all this, of course, is that there is no managed escrow system. Instead, I propose that out-of-band forums are used to provide feedback and comments on vendors (again, who are only identified by their GPG key IDs). Perhaps the customer's client can be configured to automatically perform a lookup on one or more forums to see if any scam reports have been filed for any key ID, and if so, they can be linked to the report and its discussion, and make a reasonable judgment. This way, a scamming vendor hopefully won't be able to scam more than once.
None of this is using any new methodologies or techniques. The technology and software is all already here. Connect customers to vendors directly, with no middle man.
What do you guys think? Have any such attempts at this been proposed or even built in the past?
Feel free to provide feedback, questions, comments, and concerns.
submitted by jsdfifojsidjf89778 to SilkRoad [link] [comments]

Bitcoinj 0.11 released

Mike Hearn posted this on the Bitcoin Developer Mailing List:
I'm pleased to announce the release of bitcoinj 0.11, a library for writing Bitcoin applications that run on the JVM. BitcoinJ is widely used across the Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit, Hive, blockchain.info, the biteasy.com block explorer (written in Lisp!), Circle, Neo/Bee (Cypriot payment network), bitpos.me, Bitcoin Touch, BlueMatt's relay network and DNS crawler, academic advanced contracts research and more.
The release-0.11 git tag is signed by Andreas Schildbach's GPG key. The commit hash is 410d4547a7dd. This paragraph is signed by the same Bitcoin key as with previous releases (check their release announcements to establish continuity). Additionally, this email is signed using DKIM and for the first time, a key that was ID verified by the Swiss government.
Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature for last paragraph: H3DvWBqFHPxKW/cdYUdZ6OHjbq6ZtC5PHK4ebpeiE+FqTHyRLJ58BItbC0R2vo77h+DthpQigdEZ0V8ivSM7VIg=
Notable changes and new features
Smaller improvements
Notable bug fixes
API changes
New documentation
Announcement: https://groups.google.com/forum/?fromgroups#!topic/bitcoinj-announce/3LW0uXhlRZY
Message on Bitcoin Developer Mailing List: http://www.mail-archive.com/bitcoin-develo[email protected]/msg03873.html
Google Code: https://code.google.com/p/bitcoinj/
GitHub: https://github.com/bitcoinj/bitcoinj
Edit: Added links to articles about BIP39 and BIP70 which were included in the original announcement.
submitted by alsomahler to Bitcoin [link] [comments]

If "normal" Bloom lookup filters suffer only from false *positives* and "inverse" Bloom lookup filters suffer only from false *negatives*, then wouldn't it be possible to use either one or the other in order to support "thin blocks" (which could reduce node relaying traffic by up to 85%)?

UPDATE: Error in OP title!
SAYS: "inverse Bloom lookup filters"
SHOULD sAY: "the opposite of a Bloom lookup filter"
Sorry about the confusion, I'm still studying this stuff!
I'm not a specialist in Bloom lookup filters yet, and I'm still researching them, but I think the following facts can be established at this point.
Facts
https://np.reddit.com/btc/comments/43iup7/mike_hearn_implemented_a_test_version_of_thin/
Hypothesis
There most likely ais some form of Bloom filter (either a "normal" one, or its "opposite" form) which would have worked fine for the particular use case "thin blocks" - Bitcoin nodes relaying blocks and transactions, and the need to reduce the traffic between nodes when testing whether a transaction is included in a particular block.
Conclusion
If the above hypothesis turns out to be true, then it appears that Gregory Maxwell has been quietly trying to suppress a proposed enhancement to Bitcoin which could have provided an 85% reduction in the amount of traffic required for nodes to relay blocks and transactions.
Literature
https://www.google.de/search?q=inverted+bloom+lookup+%22false+negative%22
PDF - http://www.eecs.harvard.edu/~michaelm/postscripts/tempim3.pdf
A Bloom filter is a simple space-efficient randomized data structure for representing a set in order to support membership queries. Bloom filters allow false positives but the space savings often outweigh this drawback when the probability of an error is controlled. The aim of this paper is to survey the ways Bloom filters have been used and modified in a variety of network problems, with the aim of providing a unified mathematical and practical framework for understanding them and stimulating their use in future applications.
https://stackoverflow.com/questions/635728/opposite-of-bloom-filter
I'm trying to optimize a piece of software which is basically running millions of tests. These tests are generated in such a way that there can be some repetitions. Of course, I don't want to spend time running tests which I already ran if I can avoid it efficiently.
So, I'm thinking about using a Bloom filter to store the tests which have been already ran. However, the Bloom filter errs on the unsafe side for me. It gives false positives. That is, it may report that I've ran a test which I haven't. Although this could be acceptable in the scenario I'm working on, I was wondering if there's an equivalent to a Bloom filter, but erring on the opposite side, that is, only giving false negatives.
https://news.ycombinator.com/item?id=4251313
The Opposite of a Bloom Filter
https://www.somethingsimilar.com/2012/05/21/the-opposite-of-a-bloom-filte
DanielRibeiro on HackerNews
Took me a few reads, but it's actually quite simple.
You want a structure that can tell you something has been seen, but sometimes forgets, but will never incorrectly tell you something has been seen.
Solution: an array. Hash the item to find its index, swap out what's there, and see if it is your item. If so, you know for sure it was previously placed. If not, then it might not have (it may have been forgotten).
let arr = Array of key let contains_key key = let index = hash key % arr.length let prev_key = arr.swap[index, key] return prev_key = key 
The hash algorithm is crucial. Reducing forgetfulness is as simple as making the array longer. And he points out that if you can compress the keys, you can reduce storage size.
MichaelGG on HackerNews
https://www.somethingsimilar.com/2012/05/21/the-opposite-of-a-bloom-filte
https://github.com/jmhodges/opposite_of_a_bloom_filter
A Bloom filter is a data structure that may report it contains an item that it does not (a false positive), but is guaranteed to report correctly if it contains the item (“no false negatives”). The opposite of a Bloom filter is a data structure that may report a false negative, but can never report a false positive. That is, it may claim that it has not seen an item when it has, but will never claim to have seen an item it has not.
PDF! - http://www.gta.ufrj.bftp/gta/TechReports/LVD05d.pdf
Generalized Bloom Filters
Abstract — In this paper, we propose the Generalized Bloom Filter (GBF), a space-efficient data structure to securely represent a set. Different from the standard Bloom Filter, the GBF imposes an upper bound on the false-positive probability. The key idea of the GBF is to reset bits of the filter. For that purpose, the GBF uses both hash functions that set and hash functions that reset bits. This procedure limits the false positives at the expense of introducing false negatives in membership queries. We derive expressions for the false-positive and false-negative probabilities and show that they are both upper-bounded in the GBF. We also show that these upper bounds depend only on the number ofhash functions used, k0 and k1, and on the relative size of the filter, m/n. As a result, a saturated filter cannot yield high false-positive ratios anymore. Simulations are conducted to validate the expressions. We show that the GBF is robust and fits well for security purposes, such as securing distributed applications that transmit the filter over the network.
submitted by ydtm to btc [link] [comments]

New version released: 0.4.9.9

https://github.com/bitsquare/bitsquare/releases/tag/v0.4.9.9
With this update we increase the transaction (mining) fee and the security deposit. This will avoid problems that transactions needs longer to get confirmed in periods when the backlog of unconfirmed transactions on the blockchain is very high. Offers from this version and offers from older versions are not compatible. You cannot take an offer which was created with version 0.4.9.8 or earlier, as well a user with an old version cannot take an offer which was created with version 0.4.9.9. It is highly recommended to remove your offers before you update to that version. When you update you get forced to remove your old offers (or shut down the app). You can update even if you have a trade open (if the offer was created with an older version we use the old tx fee and security deposit for that trade).
Beside that important change we improved the Tor handling for BitcoinJ (supports now DNS lookup over Tor and connection to Bitcoin full nodes running as hidden service).
Release notes 0.4.9.9: - Changed trade transaction fee from 0.0002 BTC to 0.0005 BTC - Change protocol version for offers to support higher transaction fee - Change Create-Offer-Fee from 0.0005 BTC to 0.0008 BTC (includes the 0.0005 tx fee, so the net fee to the arbitrator is same as before -> 0.0003 BTC) - Increase security deposit from 0.01 BTC to 0.03 BTC - Add LTBcoin, Fermat (IOP), Swarm City Token (SWT), AquariusCoin, Byte, Nevacoin, PIVX, Xaurum, Safe FileSystem Coin (SFSC) - Support for Bitcoin nodes running as hidden services - DNS lookup over Tor - Connect to local Bitcoin Core node if it is running (ignore use Tor flag) - Add program argument: socks5DiscoverMode - Export Wallet data (keys) feature - Show percentage in spreads table - Add input validation for Norwegian bank account - Fix bank account from for Chile and Norwegian - Add Georgia, Botswana - Add new blockexplores: SoChain, Bitaps - Added check for ZEC addresses (only t addresses are permitted) and info popup for ZEC and ZXC - Added input validation for altocin addresses: IOP, PIVX, GBYTE - Added input validation for IBAN, BIC, email - Rename Cash/ATM deposit to Cash deposit - Increase max. allowed deviation from market price to 30% - Don't show error popup for exception on Linux after screen resolution change or return from monitor standby - Use more randomized prefix for short offer ID, add version as postfix - Show arbitrators support tab if arbitrator has revoked but has open disputes - Increase offer availability and trade timeouts - Update to JDK 8u121 - Enable again the Apple developer certificate for code signing on OSX
submitted by Manfred_Karrer to bitsquare [link] [comments]

Real World Model for a Bitcoin Blockchain Election

Real World Model for a Bitcoin Blockchain Election
tl;dr The Bitcoin Blockchain can be used to ensure every vote in a government election is counted and no mass vote manipulation has occurred. This can replace papeelectronic vote counting as used today.
Bitcoin enables you to publicly track transactions on it’s blockchain. These transactions can also have arbitrary meaning. For example, a vote one way or another.
You could vote for Option A or Option B by sending a tiny dust amount to Address A or to Address B. These options could each represent candidates seeking government election.
Imagine that the address with the greatest number of incoming transactions during the specified time wins the vote, regardless of ending balance.
Voters can periodically check their vote transaction to make sure it still exists and is confirmed. Each voter can see the total vote counts and perform blockchain analysis of the election as desired. This means we can reasonably assume every vote is counted, and no votes can be redirected to another candidate.
Problem 1: How do you ensure voters don’t vote twice? Bitcoin addresses can be generated at will.
Bitcoin addresses can be generated in mass and pre-qualified ahead of the election. Only pre-qualified addresses can have their vote transaction counted.
A Bitcoin address is pre-qualified by having a government published “master election address” confirm a transaction to it before the election starts. The address is now provably linked to the election and now has a balance that can be re-allocated during the election.
All voters can see the “master election address” and every Bitcoin address it’s pre-qualified. Votes from addresses that not pre-qualified are not counted. Only the last vote from a pre-qualified address is counted.
Now we can ensure that only a limited number of votes can occur.
Problem 2: Distributing control of the pre-qualified addresses to voters.
We already have a system of distributing ballots to voters - polling stations – let’s use them.
The pre-qualified address keypairs are printed to paper wallet ballots. The paper wallet ballots are distributed to the polling stations and have no personally identifiable information on them. They may have some basic security features to them – such as folded and then connected perforated edges that need to be broken (like a paystub).
The paper wallet ballots replace traditional ballots for all voters.
Each polling station receives an extra % of ballots - for sampling, new voter registrations etc. This surplus amount must be enough to cover logistics issues of voters, but not enough to allow “ghost votes”.
An online spreadsheet is released by the government ahead of the vote, documenting each address that has been pre-qualified and it’s associated polling station. This allows everyone to see how the addresses have been allocated, and to ensure that the right numbers are delivered to each polling station. This can also be cross-referenced with the Bitcoin blockchain. On election day, polling station staff can randomly draw ballots and ensure they have been allocated properly on the spreadsheet.
This spreadsheet can also list published destination (candidate) addresses for each polling station and other pertinent information. Each candidate has a pre-authorized address made public for the sole purpose of the election. Those addresses will be monitored during the election time to determine the outcome. Any transactions sent before or after is disregarded.
It is assumed that pre-qualified addresses will be loaded with enough coin to pay dust and a reasonable transaction fee. The voting transaction does not need to confirm in the next block. Today, 1 cent would be enough. Destination addresses could be controlled by the government or provided ahead of time by a candidate.
We now have three groups of addresses, all created specifically for one election:
1) The one "Master Election Address"
2) Millions of pre-qualified Bitcoin addresses as ballots
3) Destination addresses for each candidate running for election
Election Day
Voters appear at their polling stations, identify with ID and are given a ballot. The ballot contains a public and private key, and associated QR codes. It's really just a paper wallet with a preloaded cent, from the "Master Election Address".
They can use a “voting machine” to scan the QR code of their private key and easily choose from a list of options to vote for. Once they confirm their vote, a transaction is broadcast from their pre-qualified address to the candidate's address. A receipt is printed with TX info, that they can lookup at home.
This means that any issues with voting machines will be immediately identifiable, as it’s reasonable to assume some percentage of people will actually verify their transaction. Electronic voting machines have a reputation for re-directing votes or not counting them at all.
Alternatively, voters could use a government created mobile App to scan their paper wallet ballot, cast their vote easily with the public pre-programmed destination addresses for that election, and store a copy of their TX details. This can be done outside of the polling location, reducing the load on the location’s resources.
Finally, voters can use their own trusted Bitcoin wallet and some expertise to import the private key (not sweep!) and place their vote using the publicly available data.
Only votes cast within the election time are counted. Votes from non-pre-qualified addresses are not counted. Only the last transaction from a pre-qualified address is counted.
Polling station staff watch the un-used ballots until the election time is over, at which point they are only worth the dust on them and sent back to main office. Transactions sent after the election time are not counted.
Anyone can now see the results and check to see if their vote was manipulated. They can also track voter turnout and suspicious polling station activity (all ballots used etc). As long as a blockchain with enough power like Bitcoin is used, votes can be considered secure.
Outstanding:
The election time may need to be longer than 12 hours if 300 million Americans attempted to vote in 12 hours (not enough space in blocks for all votes).
Voters can see how other voters are voting in real time. Some voters may then hold out until later in the election time when partial results are available, compounding the effect.
Deal breaker? Still seems better than what we do now. Any thoughts on pre-qualified addresses, ballot distribution, vote tracking etc?
EDIT: Typos etc.
submitted by jamierobinsondotco to Bitcoin [link] [comments]

[uncensored-r/Bitcoin] Help! Bitcoin Tx Stuck

The following post by Viddy78 is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ Bitcoin/comments/7p9vlp
The original post's content was as follows:
Hello, just over a month ago I tried sending some BTC from my ledger wallet to an exchange. Didn't notice 'til after but the fee was set waaaaaay too low and now it's stuck in limbo. It was still showing as an unconfirmed transaction in my ledger wallet, but now it's not there anymore, the funds weren't transferred back and the receiving wallet still says unconfirmed. When I lookup the tx id it just says unconfirmed...is there any way to cancel this or I would just like to know if it cancels itself after a while?
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

One-click way to estimate your transaction confirmation time (Blockonomics.co)

The Blockonomics.co transaction explorer has now integrated estimates from BitcoinFees.21.co! We currently return a time estimate that is one half of the max time given for the related fee level at BitcoinFees.
How do I use this?
  1. Visit Blockonomics.co
  2. Enter your transaction ID (example: 4ff24694b1b8f85d6b1e8c64360b283336334ba042f4d602741a1d5ec1614d1a) or lookup your unconfirmed transaction using any of the addresses associated with your transaction (such as recipient address). In the case of an address lookup, Blockonomics will automatically show pending transactions in a separate tab.
  3. Blockonomics will then show you the current elapsed time since the transaction was detected and estimated time required for confirmation based on current BitcoinFees data.
Mycelium, Multibit, and BitSquare users can also select Blockonomics as the default block explorer for true one-click transaction lookups.
We hope this gives users an easier way to gain a rough estimate of when their transactions may confirm (i.e., matter of minutes, hours, or days).
submitted by bits-of-change to Bitcoin [link] [comments]

One-click way to estimate your transaction confirmation time (Blockonomics.co)

The Blockonomics.co transaction explorer has now integrated estimates from BitcoinFees.21.co! We currently return a time estimate that is one half of the max time given for the related fee level at BitcoinFees.
How do I use this?
  1. Visit Blockonomics.co
  2. Enter your transaction ID (example: 4ff24694b1b8f85d6b1e8c64360b283336334ba042f4d602741a1d5ec1614d1a) or lookup your unconfirmed transaction using any of the addresses associated with your transaction (such as recipient address). In the case of an address lookup, Blockonomics will automatically show pending transactions in a separate tab.
  3. Blockonomics will then show you the current elapsed time since the transaction was detected and estimated time required for confirmation based on current BitcoinFees data.
Mycelium, Multibit, and BitSquare users can also select Blockonomics as the default block explorer for true one-click transaction lookups.
We hope this gives users an easier way to gain a rough estimate of when their transactions may confirm (i.e., matter of minutes, hours, or days).
submitted by bits-of-change to btc [link] [comments]

Flexible Transactions. | Russell O'Connor | Nov 21 2016

Russell O'Connor on Nov 21 2016:
Hi Tom,
On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev linuxfoundation.org> wrote:
The OP_CHECKSIG is the most well known and, as its name implies, it
validates a signature.
In the new version of 'script' (version 2) the data that is signed is
changed to be equivalent to the transaction-id. This is a massive
simplification and also the only change between version 1 and version 2 of
script.
I'm a fan of simplicity too; Unfortunately, your proposal above to change
the semantics of OP_CHECKSIG is too naive.
The SIGHASH data used in both the original Bitcoin script and in Segwit
script contains data indicating which input is being signed. In Bitcoin
script, the input is being signed is indicated by the input that has a
non-empty scriptSig field. In the Segwit script, the outpoint
corresponding to the input being signed is explicitly included in the
signature data. By signing only the transaction id, your proposed signature
does not include the data that tells which input of the transaction is
being signed. Thus if different inputs share the same public key due to
key reuse, then the signatures on those different inputs will be
identical. Your Flexible Transactions proposal opens up a new line of
attack against Bitcoin that doesn't currently exist.
Consider the following simple example, suppose you and I are jointly
preparing a transaction to mix our coins, or perhaps we are jointly funding
some purchase. We jointly prepare a transaction with one input from you
and another input from me. We each sign the transaction and hand the
signature data over to each other so we can produce a completed
transaction. But oh no! I lied to you. I didn't use my own input to the
transaction. "My input" was actually the outpoint from one of your
transactions; one that has the same public key as the input you have
chosen. Now I copy your signature you have provided in your input to cover
"my input", which is really your coins. Surprise, it turns out you are
funding both inputs to our "jointly" funded purchase. Other protocols are
likely similarly broken by your Flexible Transactions proposal.
I personally rate this flaw as about the same caliber as the transaction
malleability you are trying to fix. Sure, with enough vigilance, perhaps
you can detect and avoid this trap. However, it requires a bunch of
unexpected work. You must always examine every other input to a
transaction you are about to sign to make sure that it isn't one of your
inputs, which means you probably need a copy of the UXTO set to lookup
outpoints, which is a huge burden, especially if you are a hardware
wallet. If you are not vigilante, your funds may end up stolen. Surely it
is better not to open this line of attack.
For the most part, the SIGHASH works the way it does in Bitcoin for a
reason. You cannot simply throw away the parts you don't understand or
appreciate. You should take the time to learn why things are the way they
are, and then, only once you are certain that some aspects are not, or no
longer, needed then can you propose removing them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161121/4af91442/attachment.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Novembe013318.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Digital Receipts with Bitcoins

Is it possible to store data with a transaction? For example if a seller accepts bitcoin, an I buy several items, I can see in my transaction history the total amount I paid. However it would be great if instead of the seller giving me a paper receipt breaking down the total cost, the POS could automatically attach the breakdown to the transaction.
The digital receipt would just be a list of item ID's and the price they cost and possibly the name of each item. Also included in the digital receipt would be a URL of a page on the seller's website which takes an item ID so more detail about each item can easily be accessed. (like "http://example.com/lookup?item=#itemid#", where #itemid# can be replaced by the item IDs in the list, and any program that can access the receipt would know to replace the "#itemid#" with the actual ID, allowing each seller to have a different style of URL, e.g. another seller might be "http://example.com/#itemid#")
This would be useful so I can say track how much of a particular item I'm buying, link into budgeting apps, health apps (e.g. what food you eat), eventually like home automation.
submitted by Jon889 to Bitcoin [link] [comments]

The next big thing - THE NEW INTERNET

FreeSpeechMe-SPECIFIC IMPROVEMENTS WE PLAN TO DO:
Hide nmcontrol/namecoind windows on Windows
GNU/Linux users don't see the terminal windows for backend software; Windows users shouldn't be bothered by them either.
Don't try to visit .bit websites when blockchain isn't downloaded
Right now, visiting a .bit website with an incomplete blockchain will use an older version of that name's data. Usually this results in a failure to load the page with no good explanation of what's wrong, but in certain rare cases it could also hypothetically result in security issues such as hijacking. A better version of FreeSpeechMe should refuse to use incomplete blockchains.
Facilitate non-Firefox usage
FreeSpeechMe uses a networking method, HTTP, which is specific to website traffic. Replacing it with a different method, SOCKS, would make it much more flexible, so you could use Dot-Bit for non-website Internet applications such as SSH. It should also be possible to route other web browsers such as Chromium through FreeSpeechMe. FreeSpeechMe should support being installed as a standalone application for users who don't use Firefox (although obviously Firefox will remain the main method of installation).
Improvements for anonymous browsing
Right now FreeSpeechMe supports routing its traffic through anonymization proxies such as Tor and I2P (if they are installed), but it is not compatible with TorBrowser, so while attackers generally can't see your location or IP address, they can deduce that different activities you do online may have come from the same person. FreeSpeechMe should be improved to function in TorBrowser, which would prevent linkage of different online activities.
Improvements for anonymous hosting
FreeSpeechMe supports Tor and I2P hidden services (if the user has Tor or I2P installed), but does not support Freenet, OnionCat, GarliCat, or other anonymous hosting networks. This should be improved.
Support for next-gen TLS specification
FreeSpeechMe is using a method of specifying certificates to prevent hijacking which is deprecated in the Dot-Bit specification. While this method remains very secure, the newer specification has more features, and FreeSpeechMe should implement it.
HTTPS enforcement
Websites which claim to support HTTPS in their domain record should automatically be loaded in HTTPS, even if the user accidentally forgets the "s", to prevent hijacking in such cases. (Note for geeks: this is like the HSTS specification, but works even for sites you haven't visited before.)
Intelligent Redirecting
Websites that want to support Dot-Bit should be able to do so without changing their server configuration, and instead have FreeSpeechMe make the server think the preexisting domain is being requested. The user would still see the Dot-Bit URL in Firefox, and unlike iframe-based methods, the URL displayed in Firefox would change accordingly as the user clicks links..
Fix HTTP protocol bugs
Unencrypted HTTP Dot-Bit websites occasionally have odd behavior in FreeSpeechMe (sometimes manifesting as links not working properly); this is most frequently seen in WordPress websites. While we strongly encourage the use of HTTPS (which isn't subject to these bugs), we still want to fix the bugs with HTTP websites.
Round-Robin Load Balancing
Some large websites use multiple server IP addresses for a single domain. FreeSpeechMe should be able to randomly choose one.
OTHER NAMECOIN SOFTWARE IMPROVEMENTS
Some of this is possibly out of the scope of this one Indiegogo campaign, depending on funds raised. But these are things we're very interested in helping implement:
Rebase on the latest Bitcoin code
Namecoin is based on an outdated version of Bitcoin (0.3.x). We should rebase on a current release. We inquired with a well-qualified and well-respected contractor (who developed Namecoin-Qt) about how much this rebase would cost; the estimate was around $17,000-$35,000 US. Spending that much on one project would be out of the realm of this first campaign. However, it may be possible to reduce this cost significantly by rebasing on a codebase other than Bitcoin, such as libcoin.
Improve scalability
Namecoin currently requires having the entire blockchain for good security. While the 1.6GB blockchain isn't a large concern right now, future scalability requires that clients be able to securely resolve names without possessing the blockchain. There is a proposal for this called SPV+UTXO.
Automatic renewal of names
Losing your names because you forgot to renew them is a problem.
Names should be able to be renewed automatically. Preferably without decrypting the wallet each time the name is renewed, and maybe without even needing your client to be open when it renews. Any solution must be trust-free.
Cold storage of Namecoin name keys
To update a Namecoin name, the keys must be decrypted on a computer with Internet access; this could be a security risk if malware is installed on that computer. To fix this, cold storage should be used, as is possible with Bitcoin.
This is in two parts: (1) port the Armory client to Namecoin (this allows transactions to be signed offline), and (2) allow a cold-storage name to be used as a revocation key for a hot-wallet name (this is called the "import" field).
Optimize Speed
Dot-Bit is already much faster than other top-level domains for both name lookup and name propagation. However, it can be made even faster.
We estimate that pre-cached name lookup time can be decreased by 2- to 5-fold in some cases, uncached name lookup time can be decreased significantly, name update propagation can be reduced from 40 minutes to under 1 minute, and blockchain sync time can be reduced significantly.
Android support
Namecoin software currently does not support Android; this situation should be improved.
Better blockchain anonymity
Like Bitcoin, Namecoin can keep the location and IP address of name owners anonymous (if used with Tor), but the various activities of name owners can be linked by an attacker. This should be improved, e.g. by implementing Zerocoin.
Better blockchain privacy
Some name owners may wish their records to not be publicly accessible; encryption would improve this situation.
Decentralized website single sign-on
Namecoin can be used to log into websites in a secure way without needing a password (protecting people from database leaks or cracked passwords without trusting a third party such as "all your data are belong to us" systems like Facebook); this is implemented as the NameID library by domob. Unfortunately, this library is not easy for non-programmers to integrate with existing websites. Plugins should be created for major website backends such as Drupal, phpBB, WordPress, and SMF, to allow trust-free NameID sign-on to be as easy as checking a box.
Automated builds
Namecoin software should support automated builds and testing so that our developers and testers can work more efficiently. The builds should also be deterministic (as Bitcoin and Tor are doing) to improve security.
Offline signing of static websites
Verifying signatures of static websites against the blockchain would prevent hijacking even if a web server is completely compromised.
SSH client integration
Log into your servers remotely without trusting your network or manually verifying fingerprints, using the same anti-hijacking features that FreeSpeechMe first implemented.
submitted by kitthecar to Bitcoin [link] [comments]

Closed Seal Sets and Truth Lists for Better Privacy and Censorship Resistance | Peter Todd | Jun 22 2016

Peter Todd on Jun 22 2016:
At the recent coredev.tech meetup in Zurich I spent much of my time discussing
anti-censorship improvements with Adam Back, building on his idea of blind
symmetric commitments[bsc], and my own ideas of client-side verification. Our
goal here is to combat censorship by ensuring that miners do not have the
information needed to selectively censor (blacklist) transactions, forcing them
to adopt a whitelist approach of allowed transactions if they choose to censor.
Back's work achieves that by changing the protocol such that users commit to
their transaction in advance, in such a way that the commitment doesn't contain
the information necessary to censor the transaction, although after commitment
all transactional information becomes available. Here we propose a similar
scheme with using "smart contract" state machine tooling, with the potential
for an even better Zerocash-like guarantee that only a subset of data ever
becomes public, without requiring "moon math" of uncertain security.

The Closed Seal Maps

To implement Single-Use Seals we propose that miners attest to the contents of
a series of key:value maps of true expressions, with the keys being the
expressions, and the values being commitments, which along with (discardable)
witnesses make up the argument to the expression. Once an expression is added
to the closed seal map, the value associated with it can't be changed.
Periodically - perhaps once a year - the most recent map is archived, and the
map is started fresh again. Once archived a closed seal map is never changed.
Miners are expected to keep the contents of the current map, as well as the
most recent closed seal map - the contents of older maps are proven on demand
using techniques similar to TXO commitments.
A single-use seal[sma] implemented with the closed seal maps is then
identified by the expression and a block height. The seal is open if the
expression does not exist in any closed seal maps between the creation block
height and the most recent block height. A witness to the fact that the seal
has been closed is then a proof that the seal was recorded as closed in one of
the closed seal maps, and (if needed) proof that the seal was still open in any
prior maps between its creation and closing.
Similar to the logic in Bitcoin's segregated witnesses proposal, separating the
commitment and witness arguments to the seal expression ensures that the
witness attesting to the fact that a given seal was closed does not depend on
the exact signature used to actually close it.
Here's a very simple example of such a seal expression, in the author's
Dex[dex] expression language, for an application that can avoid reusing
pubkeys:
 (checksig (hash )) 
This desugars to the following after all named arguments were replaced by
explicit destructuring of the expression argument, denoted by the arg symbol:
(and (checksig (cdr arg) (digest (car arg)))) 
The arguments to the expression are the closed seal map's commitment and
witness, which are our committed value and signature respectively:
( . ) 

The Truth List

We implement an expression validity oracle by having miners attest to the
validity of a perpetually growing list of true predicate expressions, whose
evaluation can in turn depend on depend on previously attested expressions in
the truth list. SPV clients who trust miners can use the truth list to skip
validation of old history.
Similar to TXO commitments, we expect miners to have a copy of recent entries
in the truth list, perhaps the previous year. Older history can be proven on an
as-needed basis. Unlike TXO commitments, since this is a pure list of valid
expressions, once an item is added to the list it is never modified.
As the truth list can include expressions that reference previously
evaluated expressions, expressions of arbitrary depth can be evaluated. For
example, suppose we have an extremely long linked list of numbers, represented
as the following sexpr:
(i_n i_n-1 i_n-2 ... i_1 i_0) 
We want to check that every number in the list is even:
(defun all-even? (l) (match l (nil true) ((n . rest) (if (mod n 2) false (all-even? rest))))) 
In any real system this will fail for a sufficiently long list, either due to
stack overflow, or (if tail recursion is supported) due to exceeding the
anti-DoS limits on cycles executed in one expression; expressing the above may
even be impossible in expression systems that don't allow unbounded recursion.
A more subtle issue is that in a merkelized expression language, an expression
that calls itself is impossible to directly represent: doing so creates a cycle
in the call graph, which isn't possible without breaking the hash function. So
instead we'll define the special symbol self, which triggers a lookup in the
truth map instead of actually evaluating directly. Now our expression is:
(defun all-even? (l) (match l (nil true) ((n . rest) (if (mod n 2) false (self rest))))) 
We evaluate it in parts, starting with the end of the list. The truth list only
attests to valid expressions - not arguments - so we curry the argument to form
the following expression:
(all-even? nil) 
The second thing that is appended to the truth list is:
(all-even? (0 . #)) 
Note how we haven't actually provided the cdr of the cons cell - it's been
pruned and replaced by the digest of nil. With an additional bit of metadata -
the index of that expression within the trust list, and possibly a merkle path
to the tip if the expression has been archived - we can show that the
expression has been previously evaluated and is true.
Subsequent expressions follow the same pattern:
(all-even? (1 . #)) 
Until finally we reach the last item:
(all-even? (n_i . #)) 
Now we can show anyone who trusts that the truth list is valid - like a SPV
client - that evaluating all-even? on that list returns true by extracting a
merkle path from that item to the tip of the list's MMR commitment.

Transactions

When we spend an output our goal is to direct the funds spent to a set of
outputs by irrovocably committing single-use seals to that distribution of
outputs. Equally, to validate an output we must show that sufficient funds have
been directed assigned to it. However, our anti-censorship goals make this
difficult, as we'll often want to reveal some information about where funds
being spend are going immediately - say to pay fees - while delaying when other
information is revealed as long as possible.
To achieve this we generalize the idea of a transaction slightly. Rather than
simply having a set of inputs spent and outputs created, we have a set of
input splits spent, and outputs created. An input split is then a merkle-sum
map of nonces:values that the particular input has been split into; the
transaction commits to a specific nonce within that split, and is only valid if
the seal for that input is closed over a split actually committing to the
transaction.
Secondly, in a transaction with multiple outputs, we don't want it to be
immediately possible to link outputs together as seals associated with them are
closed, even if the transaction ID is known publicly. So we associate each
output with a unique nonce.
Thus we can uniquely identify a specific transaction output - an outpoint - by
the following data (remember that the tx would usually be pruned, leaving just
the digest):
(struct outpoint (tx :transaction) (nonce :digest)) 
An transaction output is defined as:
(struct txout (value :int) ; value of output (nonce :digest) (authexpr :func)) ; authorization expression 
An input:
(struct txin (prevout :outpoint) ; authorization expression (split :digest) ; split nonce (value :int)) ; claimed value of output spent 
And a transaction:
(struct transaction ; fixme: need to define functions to extract sums and keys (inputs :(merkle-sum-map (:digest :txin)) (outputs :(merkle-sum-map (:digest :txout)) ; and probably more metadata here) 

Spending Outputs

Our single-use seal associated with a specific output is the expression:
( . arg) 
When the seal is closed it commits to the merkle-sum split map, which is
indexed by split nonces, one per (tx, value) pair committed to. This means
that in the general case of an spend authorization expression that just checks
a signature, the actual outpoint can be pruned and what actually gets published
in the closed seal set is just:
( #> . arg) 
Along with the commitment:
# 
With the relevant data hidden behind opaque digests, protected from
brute-forcing by nonces, external observers have no information about what
transaction output was spent, or anything about the transaction spending that
output. The nonce in the seal commitment prevents that multiple spends for the
same transaction from being linked together. Yet at the same time, we're still
able to write a special-purpose spend auth expressions that do inspect the
contents of the transaction if needed.

Validating Transactions

When validating a transaction, we want to validate the least amount of data
possible, allowing the maximum amount of data to be omitted for a given
recipient. Thus when we validate a transa...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-June/012796.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Blockchain - How To Verify A Bitcoin Transaction And Get ... How to Trace a Bitcoin Transaction using a Bitcoin ... How to find the transaction ID in your Blockchain.info ... How to retrieve or get your transaction ID or Hash from BlockChain How To Find Your Bitcoin Transaction On The BlockChain - Hash ID.

2. Find the unique transaction ID. Every Bitcoin transaction comes with its own transaction ID (TXID), a string of letters and numbers that makes it unique. The Bitcoin.com wallet conveniently provides the TXID for you, as do some other wallets and exchanges. 3. View on Block Explorer The most popular and trusted block explorer and crypto transaction search engine. The easiest and most trusted transaction search engine and block explorer. Products. Wallet Buy & Sell Crypto. Exchange ... Buying crypto like Bitcoin and Ether is as easy as verifying your identity, adding a payment and clicking "Buy". Sign up for our Wallet ... Once you've sent a crytpocurrency payment from Wirex to an external cryptoc address, transfer details (such as amount of crypto sent, sending/receiving crypto address, the date of transfer) can be found on the blockchain. This information is then publicly available and given its own transaction ID - or TXID. Block Explorers provide a visually appealing and intuitive way to navigate a cryptocurrency's blockchain. Our Block Explorer launched in August 2011. It began as a way for anyone to study bitcoin transactions, along with a variety of helpful charts and statistics about activity on the network. Included in block is the ID of the block in which this transaction was confirmed. Remember – mining is a competitive sport. Several extremely powerful computers are competing in who will guess a nonce (a random number) first, because the winner gets both the transaction fees from all transactions in a block and the newly minted Bitcoins. We ...

[index] [25011] [13389] [4286] [5371] [14653] [30406] [13106] [8852] [30291] [9522]

Blockchain - How To Verify A Bitcoin Transaction And Get ...

A short screencast showing how to find a transaction ID. Do you send Bitcoins from your Blockchain.Info wallet? Do you often get asked to send the "Receiver/Recipient" the proof of payment, especially the Hash/Tran... How To Find Your Bitcoin Transaction On The BlockChain - Hash ID. Get a Free Bitcoin wallet at Coinbase: http://coinbase.loubiz.com. The Crypto Dad shows you how to trace a Bitcoin transaction. Important software used is: Electrum bitcoin wallet: https://electrum.org/#home The Blockchain e... For more tips like these visit http://bodymindsuccess.com/bitcoin or subscribe to our channel

#