Bitcoin Transaction accelerator

Calculate txid from coinbase tx, remove segwit? Python assignment /r/Bitcoin

Calculate txid from coinbase tx, remove segwit? Python assignment /Bitcoin submitted by SimilarAdvantage to BitcoinAll [link] [comments]

More fun with OP_HODL (CheckLockTimeVerify)

Last week I wrote a post with a script to create a HODL address. A HODL address is a UTXO that cannot be spent until a certain epoch time or blocktime. It can be used to secure funds in a will or trust that has a designated maturity date. Or you may have some other reason to lock the funds, the point is that the UTXO can be physically verified to be funded, and under an unbreakable timelock.
I've liked the feature but have been frustrated that there is limited HW and SW wallet support for it presently. My previous post walked through how to make a segwit HODL UTXO, this post will detail how to make a BIP16 legacy P2SH HODL UTXO.
Similar to last week, I wrote a bitcoinlib script to do it, but this week I also went through the steps to do it on the CoinBin wallet. CoinBin is a JavaScript wallet that can (and should) be run locally. CoinBin, or raw python (bitcoinlib) are the only ways I currently know of to spend a HODL address.
Here's the basic rundown to create and fund your UTXO with CoinBin
  1. Use either Electrum or Bitcoin Core to collect a Bitcoin public and private key.
  2. Run the CoinBin app either locally (best option) or through the live site
  3. Choose New -> Time Locked Address
  4. Enter the public key (from #1) and either a block height or timestamp for your lock
  5. Hit Submit and record the address and redeem script
  6. Ensure you have accurately recorded everything in step #1 and step #5
  7. Send funds to the address recorded in step 5 as you normally would.
Here's the basic rundown on how to spend your UTXO with CoinBin
  1. Use either Electrum or Bitcoin Core to collect an address to spend your UTXO to
  2. Run the CoinBin app either locally (best option) or through the live site
  3. Choose New -> Transaction
  4. Enter the Redeem Script you copied in the creation process (step #5), then Load
  5. After a few minutes it should automatically load your UTXO into the form
  6. Enter the address you want to spend your UTXO to and adjust the output amount for fees
  7. Hit the question mark next to Transaction Fee for the calculator
  8. Hit Submit when satisfied and record the unsigned transaction data
  9. Select Sign on the top nav bar to begin the signing operation
  10. Enter your private key from the creation process (step #1) and the unsigned TXN
  11. Select Submit to produce the signed TXN
  12. Broadcast the signed TXN with either Electrum or Bitcoin Core
Note, if you try to broadcast before the UTXO's timelock expires, you will get a terse not final error in either Electrum or Core.
For Extra Credit, CoinBin can also be run against Testnet, but to do so you have to unhide the settings element, manually code the TXN input script and manually code the TXN nLockTime to sync with your HODL address.
Here are a Testnet and Mainnet HODL spend TXN I created in CoinBin * Mainnet: txid ea6a1...79d53 * Testnet: txid a8110...adc93
submitted by brianddk to Bitcoin [link] [comments]

Gridcoin "Fern" Release
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.



Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.


Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.


The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog



Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.







As a reminder:









Detailed Changelog

[] 2020-09-03, mandatory, "Fern"





submitted by jamescowens to gridcoin [link] [comments]

Calculate txn_id from raw txn_hex

I'm trying to calculate a txn_id from raw txn_hex. The procedure works fine for legacy TXNs but gets non-expected results on Segwit TXNs. I compared this snippet of code to what txn_id was produced by Electrum and the TXN decoder:
  1. Take in TXN in hex
  2. Convert the hex to binarray
  3. Double hash binarray
  4. Reverse the resultant digest because of endianness
  5. Display in hex.
t0 is my legacy testnet TXN and t1 is my segwit testnet TXN.


Found the relevant source in Electrum
Basically you strip the flags and tx_witnesses listed in the wiki spec

!/usbin/env python3

[repo] ... python/


from hashlib import sha256
def txid(tx): bin = bytes.fromhex(tx) txid = sha256(sha256(bin).digest()).digest()[::-1].hex() return txid

Raw Legacy

t0 = ('0200000001cd3b93f5b24ae190ce5141235091cd93fbb2908e24e5b9ff6776ae' 'c11b0e04e5000000006b4830450221009f156db3585c19fe8e294578edbf5b5e' '4159a7afc3a7a00ebaab080dc25ecb9702202581f8ae41d7ade2f06c9bb9869e' '42e9091bafe39290820438b97931dab61e140121030e669acac1f280d1ddf441' 'cd2ba5e97417bf2689e4bbec86df4f831bf9f7ffd0fdffffff010005d9010000' '00001976a91485eb47fe98f349065d6f044e27a4ac541af79ee288ac00000000')

Raw Segwit

t1 = ('0200000000010100ff121dd31ead0f06e3014d9192be8485afd6459e36b09179' 'd8c372c1c494e20000000000fdffffff013ba3bf070000000017a914051877a0' 'cc43165e48975c1e62bdef3b6c942a38870247304402205644234fa352d1ddbe' 'c754c863638d2c26abb9381966358ace8ad7c52dda4250022074d8501460f4e4' 'f5ca9788e60afafa1e1bcbf93e51529defa48317ad83e069dd012103adc58245' 'cf28406af0ef5cc24b8afba7f1be6c72f279b642d85c48798685f86200000000')

UPDATE Raw Segwit with flags and tx_witnesses stripped

t2 = ('02000000' '0100ff121dd31ead0f06e3014d9192be8485afd6459e36b09179' 'd8c372c1c494e20000000000fdffffff013ba3bf070000000017a914051877a0' 'cc43165e48975c1e62bdef3b6c942a3887' '00000000')
print(f"t0: {txid(t0)}\nt1: {txid(t1)}\nt2: {txid(t2)}")

TXN_IDs from the above python

t0: cb33472bcaed59c66fae30d7802b6ea2ca97dc33c6aad76ce2e553b1b4a4e017

t1: b11fdde7e3e635c7f15863a9399cca42d46b5a42d87f4e779dfd4806af2401ce

t2: d360581ee248be29da9636b3d2e9470d8852de1afcf3c3644770c1005d415b30

TXN_IDs from Electrum

t0: cb33472bcaed59c66fae30d7802b6ea2ca97dc33c6aad76ce2e553b1b4a4e017

t1: d360581ee248be29da9636b3d2e9470d8852de1afcf3c3644770c1005d415b30

submitted by brianddk to Bitcoin [link] [comments]

Full malleability fix with BIP-134 hardfork

Is there any strong opposition to trying to activate BIP-134 on Bitcoin Cash, in a controlled manner (requiring overwhelming consensus, akin to BIP-9)?
BIP-134 (Flexible Transactions) is a new choice for transaction format, fixing all known kinds of transaction malleability and allowing for Lightning Network on Bitcoin Cash. It differs from Segwit because it is simply creates an alternative transaction format, requiring a hardfork and update of every software client, instead of using a convoluted trickery to fool old clients into accepting segwit transactions as valid.
The way I see it, many may believe it is not strictly needed (soft opposition), because we've already have a path for on-chain scalability, but I can't see why would someone think it is not desirable (hard opposition), because we already (hopefully) did overcome the psychological barrier against hardforks.
Such Pareto optimal improvement should be accepted by node runners without much resistance.
submitted by lcvella to btc [link] [comments]

Bitcoin-SV: are terabyte blocks feasible?

Block propagation time and block processing time (to prepare & validate) are very crucial factors. Every node(miner) has an economic incentive in propagating its block as quickly as possible so that nodes would be more likely to build on this fork. But simultaneously having a very large number of transactions contained in the block increases the block propagation time, so a node has to optimally balance the number of transactions to include (block size) with transaction fees plus block reward so for the best outcome.
But BSVs scaling approach expects to have logical blocks at gigabytes/terabytes sizes in future, the problem outlined above can be a huge obstacle in getting there. This problem will be exacerbated when block sizes get too big and ultimately the rational economically motivated nodes begin to ration the number of transactions in a block.
I believe currently the time complexity of block propagation is at O(~n), where n is the number of transactions, as there is currently no block compression (like Graphene). Also, block processing time complexity is at O(~n) too as most of the processing is serial.
Compact blocks (BIP 152) as implemented currently in BitcoinSV already does a basic level of block compression by,
typically a Compact block is about 10 - 15 % of the full uncompressed legacy block & this reduces the effective propagation time; while this is probably good enough for Bitcoin-Core as they are not seeking to increase block size, its certainly not enough for Bitcoin-SV.
Graphene which uses Bloom filters and Invertible Bloom Lookup Tables (IBLTs) seems to provide an efficient solution to the transaction set reconciliation problem, and it offers additional (from Compact blocks) compression where a Graphene block is ~10% of the size of a typical Compact block (from the author's empirical tests)
With the above information and certain assumptions we can quickly calculate the demands of a terabyte node and its feasibility with current hardware & bandwidth limitations.
1 TB block ==> 100-150 GB Compact block ==> 10 - 15 GB Graphene block
Lets conservatively go with the low of 10 GB Graphene compressed block, 10GB/ 10 Gb/s = 8 secs
we still need 8 full seconds to propagate this block one hop to the next immediate peer. Also, note that we conveniently ignored the massive parallelization that would be needed for transaction and block processing which would likely involve techniques like mempool and UTXO set sharding in the node architecture.
But the point to take home is 8 seconds is exorbitant and we need a better workable compression algorithm irrespective of other architectural improvements under the outlined assumptions.
The above led me to begin work on an "ultra compression" algorithm which is a stateful protocol and highly parallelizable (places high memory & CPU demands) and fits with the goal of a horizontally scalable architecture built on affordable consumer grade h/w. The outline of the algorithm looks promising and seems to compress the block by factor of thousands if not more especially for the block publisher and although the block size grows as we head farther from the publishing node, its still reasonable IMO.
Now, before I go further down this rabbit hole I wanted you guys to poke holes into my assumptions, requirements & calculation outlines. Subsequently I will publish (semi-formal) a paper detailing the ultra compression algorithm and how it fits with the overall node architecture per ideas expressed above.
Would appreciate if someone could point/educate me to alternative practical solutions that have already been vetted and are in the dev pipeline.
submitted by stoichammer to bitcoincashSV [link] [comments]

Weekly Dev Update #19

THORChain Weekly Dev Update for Week 19–02 Nov 2019


1 Rune Fee

Reasoning about gas costs on networks with non-deterministic fee schedules (such as Bitcoin) becomes unnecessarily complex. The issue is that the final gas cost cannot be known ahead of time so the system must cover any variability in the gas cost so that the user can be charged a flat rate. If the user is not charged anything, then the system can be depleted of funds, passing the cost back to stakers. Additionally, swaps below 1 Rune bring negligible economic value to the network and saturate the mempool with low value transactions. As such the solution is to charge a flat 1 Rune fee (or 1 Rune equivalent) on all outgoing transactions (swap and withdrawals). This 1 Rune fee is moved into the Protocol Reserve and increases the network’s future income. When the nodes report on the final transaction, they include the observed transaction fee. This transaction fee is then reimbursed back to the pool that paid for it ( BNB.BNB, BTC.BTC, ETH.ETH etc). There are cases that the outgoing transaction fee may exceed 1 Rune (Bitcoin in high use), but more than likely 1 Rune will be more than sufficient to cover the costs and ensure the network grows its reserves. Additionally, it sets a floor on the minimum transaction that the network will process. A swap of less than 1 Rune will end up becoming a donation to the network.

THORChain Development

The team are working on 4 parallel streams of effort. Cross-chain infrastructure has now been merged into a single repo called “THORNode”. * THORChain * Midgard Public API * Threshold Signature Scheme implementation * Front-end Integration for BEPSwap


Much work has been done to refactor and clean up the codebase which will make public audits easier. This includes splitting up the keeper, separating out the events module and more. Smoke tests have been fully-integrated into the test schedule. Safer subtraction and division methods were added to prevent the likelihood of panic events. * [refactor] split keeper funcs/interface into separate files * [tests] use gow * [refactor] Redo how get key works in keeper * [security] require no signers on tx ins * Resolve “ADD: 1 Rune Fee on all Swaps” * [bug] fix smoke tests * [ADD] semantic versioning * [Refactor] Keeper chains * [Refactor] Events Keeper * Resolve “Adds a SafeSub method” * [Refactor] Last Height Keeper * [Refactor] keeper liquidity fees * FIX: Issue 208 * [ISSUE] Get smoke tests to 100%

Midgard Public API

Midgard is now ready for integration into the FrontEnd. The manner in which USD price of assets in now updated to source only from internal pool pricing. This includes BNB.BUSD, BNB.TUSD, BNB.USDS. ROI endpoints are now added. * Fix : Updated our mock data to include a correct BNB address. * Add: Return the date a staker first staked. * Add: Previously missing implementations for pool data (24hr and 12m). * Fix: Several potential query issues. Updates to return the TX date as a UNIX timestamp. * Fix: Additional query updates/fixes. * Fix: Build system * Add: Filtering implementation for TxID and Asset. * Added missing import. * Fix/build issues * Fixed issue with my auto refactor * Add: Filtering updates. DB Config fix. * Add: Missing Staker methods for ROI and earnings. * Added fix to enabled timescale extension * Fix: Added build config for rpc_host * Add: Support to Calculate USD price of an asset. * Added: Health check for mainnet to test that we still have a db connection… * Add: Tests for the recent endpoints work. * jq syntax fix. * Additional jq fixes. * [ADD] Manage docker image on gitlab

Threshold Signature Scheme

The Binance Go TSS library is now fully implemented and deploys in a four-node chain. integrate with new go-tss * 212-issue export private key thus we can use it to start tss * 214-issue consolidate tss keygen and tss keysign config, with our new go-tss… * [ADD] Setup go-tss in genesis docker * [ADD] Have CI run smoke tests on a four node chain with TSS

Frontend Implementation

The frontend makes some final tweaks on the interface, before integrating the Midgard APIs. * Resolve “Update stake page share panel” * Resolve “UPDATE: Network Dropdown Titles” * Resolve “ADD: Sorting of columns in pool list” * Resolve “ADD: Sorting of columns in pool list” * Resolve “FIX: Close token selection drop down when clicking outside” * Resolve “Add redux saga for midgard apis” * Resolve “Update protect price UI” * Resolve “Update wallet drawer”


The next milestone is: ChaosNet: 03 January 2020 on-time


To keep up to date, please monitor community channels, particularly Telegram and Twitter: Twitter: Telegram Community: Telegram Announcements: Reddit: Github: Medium:
submitted by thorchain_org to THORChain [link] [comments]

What's the f*****ng benefit of the reactivated OP_Codes?

Nobody explained what we can do with the soon to be reactivated OP_Codes for Bitcoin Cash, and nobody explained why we need them. It's a fact that there are risks associated with them, and there is no sufficient testing of these risks by independent developers, nor is there a sufficient explanation why they carry no risk. BitcoinABC developers, explain yourselves, please.
Edit: Instead of calling me a troll, please answer the question. If not, ask someone else.
Edit Edit: tomtomtom7 provided a resfreshing answer on the question:
The OP_Codes were disabled because bugs were found, and worry existed that more bugs could exist.
They are now being re-enabled with these bugs fixed, with sufficient test cases and they will be put through thorough review.
These are missing pieces in the language for which various use cases have been proposed over the years.
The reason to include these, is because all developers from various implementations have agreed that this is a good idea. No objections are raised.
Note that this does not mean that all these OP_Codes will make it in the next hardfork. This is obviously uncertain when testing and reviewing is still being done.
This is not yet the case for OP_GROUP. Some objection and questions have been raised which takes time to discuss and time to come to agreement. IMO this is a very healthy process.
Another good comment is here
One precise thing: Allowing more bitwise logical operators can (will) yield smaller scripts, this saves data on the blockchain, the hex code gets smaller.
Here is a detailled answer. I did not goe through it if it is satisfying, but at least it is a very good start, Thank you silverjustice.
But further, if you want specific advantages for some of these, then I recommend you check out the below from the scaling Bitcoin conference:
opcodes are very useful, such as in for example with CAT you can do tree signatures even if you have a very complicated multisig design using CAT you could reduce that size to log(n) size. It would be much more compact. Or with XOR we could do some kind of deterministic random number generator by combining secret values from different parties so that nobody could cheat. They could combine and generate a new random number. If people think-- ... we could use LEFT to make weaker hash. These opcodes were re-enabled in sidechain elements project. It's a sidechain from Bitcoin Core. We can reintroduce these functions to bitcoin.
The other problem are the ... numeric operations which were disabled by Satoshi. There's another problem. Which is that the range of values accepted by script is limited and confused because the CScript.. is processed at ..... bit integers internally. But to these opcodes it's only 32 bits at most. So it's quite confusing. The other problem is that we have this.. it requires 251 encode or calculate or manipulate this number. So we need at least 52 bits. But right now it is only 32 bits. So the proposal is to expand the valid input range to 7 bytes which would allow 56 bits. And it limits the maximum size to 7 bytes so we could have the same size for inputs and outputs. For these operations, we could re-enable them within these safe limits. It would be safe for us to have these functions again.
The other problem is that we currently cannot commit to additional scripts. In the original design of bitcoin, we could have script operations inside of the signature. But the problem is that the signature is not covered by the signature itself. So any script in the scriptSig is modifiable by any third party in the network. For example, if we tried to do a CHECKSIG operation in the signature, people could simply replace it with an OP_0 and invalidate the transaction. This is a bypass of the.. signature check in the scriptSig. But actually this function is really useful, for example, we can do... delegation, people could add additional scripts to a new UTXO without first spending it. So people could do something like let's say to let their son spend their coin within a year if it is not first spent otherwise.. and also, people, talk about replay protection. So we have some ohter new opcode like pushing the blockhash to the stack, with this function we could have replay protection to make sure the transaction is valid only in a specified blockchain.
So the proposal is that in the future the CHECKSIG should have the ability to sign additional script and to execute these scripts. And finally the other problem is that the script has limited access to different parts of the transaction. There is only one type of operation that allowed to investigate different parts of the transaction, which is CHECKSIG and CHECKMULTISIG. But it is very limited. There are sighash limitations here... there are only 6 types of sighash. The advantage of doing this is that it's very compact and could use only one byte to indicate which component to sign. But the problem is that it's inflexible. The meaning of this sighash is set at the beginning and you can't change it. You need a new witness version to have another checksig. And the other problem is that the sighash can be complex and people might make mistakes so Satoshi made this mistake in the sighash design such as the well-known bug in validation time and also the SIGHASH_SINGLE bug. It's not easy to prevent.
The proposal is that we might have the next generation of sighash (sighashv2) to expand to two bytes, allow it to cover different parts of the transaction and allow people to choose which components they would like to sign. This would allow more flexibility and hopefully not overly complicated. But still this is probably not enough for more flexible design.
Another proposal is OP_PUSHTXDATA which pushes the value of different components of a transaction to the stack. It's easy to implement, for example, we could just push the scriptpubkey of the second output to the stack, okay. So it is actually easier to implement. We could do something more than just... because we have sighash, we could check where something is equal to the specified value. But if we could push the value, like the value of an output to the stack, then we could use other operations like more than or less than and then we could do something like checking whether the value of output x must be at least y bitcoin, which is a fixed value.
There are some other useful functions like MAST which would allow for more compact scripts by hiding the other unexecuted branches. There's also aggregation that would allow n-of-n multisig to be reduced to a single signature and so on. In the elements project, they implemented CHECKSIGFROMSTACK where they don't check the transaction structure but instead they verify a message on the stack. So it could be some message like not bitcoin maybe, perhaps cross-chain swap, or another bitcoin UTXO. And also we might have some elliptic curve point addition and operations which are also useful in lightning network design.
Here are some related works in progress. If you are interested in this topic, I would like to encourage you to join our discussions because it's a very active topic. jl2012 bip114 MAST, maaku's MBV, luke-jr or version-1 witness program, Simplicity, etc.
so you have your script template the amount value and there is a block impactor beause we have the sha chain whih allows you to hae the hashes.. we can hae that errortate constant beause you need the HTLC chashes, to properly reoke the prior states and if you an't do that then you can't onstruct the redeem script. Right now it ineeds a signature for eery state, you need all the HTLCs, it needs the netowrk erification state, and there's another cool thing you can do with which is like trap door erification and you can include it in the transaction itself and there can be a alsue where there is some margin for it.. Which make sit powerful, and then you can make it more private with these constructs. We only have a few minutes left, we can cover this.
One furthe rthing is that in the transformation, we have privacy issue because we need to keep going forward, we need to have hte private state, so there's a history of this in the ages in the past, the current one used replications, which was one of the cool things about lightning. We used to have deckman signatures we had a sequence value of like 30 days, we did an update, we had to switch sides then we make it 29 then 27 etc. You can only broadcast the most recent state because otherwise the other party can transact the other transaction. If you start with 30 days then you can only do about 30 bidirectiona lswitches. Then there was cdecker's payment channels where you have a root tree and every time you need to- you had two payment channels, you had to rebalance htem and then it's on your part of the channel you can reset the channel state. You can do 30 this way, you have another tree, you can do it that way, and then there's a new version of it in the indefinite lifetime... by keeping the transaction in CSV, the drawback on that paproahc because you have al arge validation tree, in the worst cas eyou have 8 or 10 on the tree, and then you nee dfor the prior state and then you do the 12 per day, and every time you have to make a state, you have to revoke the preimage from the prior state, this is cool because if they ever broadcast the entire state, eahc one has the caluse so that you can draw the entire money in the event o f a violation. There are some limitations for doing more complex verifications and you have this log(n) state that you have to deal with ehen you deal with that.
We're going to do the key power on the stack to limit key verifications on this main contract. this is all composable. You can do discreet log contracts. You can now check signtures on arbitrary messages. You can sign a message nad then we can enforce structure on the messages themselves. Right now you need to have sequene numbers. So each state we are going to increment the sequence numbers. So you give me a siequence number on that state. On the touputs we have a commitment ot the sequence number and the value r. So people on chain will know that how many places we did in that itself. The ool part about this is that because we have a seq number then I have the one if it's highest neough. Then I am opening that commitment to say this is state 5 and I present to you a new signed ommitment and open that as well, that's in a validation state. The cool things is that you only need one of those m. So we have to some auxiliary state, and each time I have a new state I an drop the old state. I have a signed commitment to revoke the prior state. This is a ibg deal beause the state is much smaller. Currently we require you to fwe use a state mahcine on state 2, and it also has implications for verifications and watch tower
So on lightning, there's this technique itself- it's timelocks CSV value and if you can't react within that value then you can't go to court and enforce judgement on this attacker. So the watchtower is a requirement, you delegate the state watching to the watchtower. They know which channels you're watching. You send some initial points, like a script template. For every one you send the signautre and the verification state. They can use the verification stat ethat collapses into a log(n) tree, you can basically use state where you send half the txids, you can decrypt this in... some time.
submitted by Der_Bergmann to btc [link] [comments]

WitLess Mining - Removing Signatures from Bitcoin Cash

WitLess Mining

A Selfish Miner Variant to Remove Signatures from Bitcoin Cash
WitLess Mining is a hypothetical adversarial hybrid fork leveraging a variant of the selfish miner strategy to remove signatures from Bitcoin Cash. By orphaning blocks produced by miners unwilling to blindly accept WitLess blocks without validation, a miner or cartel of collaborating miners with a substantial, yet less than majority, share of the total Bitcoin Cash network hash power can alter the Nash equilibrium of Bitcoin Cash’s economic incentives, enticing otherwise honest miners to engage in non-validated mining. Once a majority of network hash power has switched to non-validated mining it will be possible to steal arbitrary UTXOs using invalid signatures - even non-existent signatures. As miners would risk losing all of their prior rewards and fees were signatures to be released that prove their malfeasance, it could even be possible to steal coins using non-existent transactions, leaving victims no evidence to prove the theft occurred.
WitLess Mining introduces two new data structures, the WitLess Transaction (wltx) and the WitLess Transaction Input (wltxin). These data structures are modifications of their standard counterpart data structures, Transaction (tx) and Transaction Input (txin), and can be used as drop-in replacements to create a WitLess Block (wlblock). These new structures provide WitLess Miners signature-withheld (WitLess) transaction data sufficient to reliably update their local UTXO sets based on the transactions contained within a WitLess block while preventing validation of the transaction signature scripts.
The specific mechanism by which WitLess Mining transaction and block data will be communicated among WitLess miners is left as an exercise for the reader. The author suggests it may be possible to extend the existing Bitcoin Cash gossip network protocol to handle the new WitLess data structures. Until WitLess Mining becomes well-adopted, it may be preferable to implement an out-of-band mechanism for releasing WitLess transactions and blocks as service. In order to offset potential revenue reduction due to the selfish mining strategy, the WitLess Mining cartel might provide a distribution service under a subscription model, offering earlier updates for higher tiers. An advanced distribution system could even implement a per-block bidding option, creating a WitLess information market.
Regardless of the distribution mechanism chosen, the risk having their blocks orphaned will provide strong economic incentive for rational short-term profit-maximizing agents to seek out WitLess transaction and block data. To encourage other segments of the Bitcoin Cash ecosystem to adopt WitLess Mining, the WitLess data structures are designed specifically to facilitating malicous fee-based transaction replacement:
It is expected that fee-based transaction replacement will be particularly popular among malicious users wishing to defraud 0-conf accepting merchants as well as the vulnerable merchants themselves. The feature is likely to encourage higher fees from the users resulting in their WitLess transaction data fetching a premium price under subscription- or market-based distribution. Malicious users may also be interested in subscribing directly to a WitLess Mining distribution service in order to receive notification when the cartel is in a position to reliably orphan non-compliant blocks, during which time their efforts will be most effective.

WitLess Block - wlblock

The wlblock is an alternate serialization of a standard block, containing the set of wltx as a direct replacement of the tx records. The hashMerkleRoot of a wlblock should be identical to the corresponding value in the standard block and can verified to apply to a set of txid by constructing a Merkelized root of txid_commitments from the wltx set. The same proof of work validation that applies to the standard block header also ensures legitimacy of the wltx set thanks to a WitLess Commitment included as an input to the coinbase tx.

WitLess Transaction - wltx

Field Size Description Data type Comments
4 version int32_t Transaction data format version as it appears in the corresponding tx
2 flag uint8_t[2] Always 0x5052 and indicates that the transaction is WitLess
1+ wltx_in count var_int Number of WitLess transaction inputs (never zero)
41+ wltx_in wtx_in[] A list of 1 or more WitLess transaction inputs or sources for coins
1+ tx_out count var_int Number of transaction outputs as it appears in the corresponding tx
9+ tx_out tx_out[] A list of 1 or more transaction outputs or destinations for coins as it appears in the corresponding tx
4 lock_time uint32_t The block number or timestamp at which this transaction is unlocked. This can vary from the corresponding tx, with the higher of the two taking precedence.
Each wltx can be referenced by a wltxid generated in way similar to the standard txid.

WitLess Transaction Input - wltxin

Field Size Description Data type Comments
36 previous_output outpoint The previous output transaction reference as it appears in the corresponding txin
1+ script length var_int The length of the signature script as it appears in the corresponding txin
32 or 0 txid_commitment char[32] Only for the first the wltxin of a transaction, the txid of the tx containing the corresponding txin; omitted for all subsequent wltxin entries
4 sequence uint32_t Transaction version as defined by the sender. Intended for replacement of transactions when sender wants to defraud 0-conf merchants. This can vary from the corresponding txin, with the lower of the two taking precedence.

WitLess Commitment Structure

A new block rule is added which requires a commitment to the wltxid. The wltxid of coinbase WitLess transaction is assumed to be 0x828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe.
A witless root hash is calculated with all those wltxid as leaves, in a way similar to the hashMerkleRoot in the block header.
The commitment is recorded in a scriptPubKey of the coinbase tx. It must be at least 42 bytes, with the first 10-byte of 0x6a284353573e3d534e43, that is:
 1-byte - OP_RETURN (0x6a) 1-byte - Push the following 40 bytes (0x28) 8-byte - WitLess Commitment header (0x4353573e3d534e43) 32-byte - WitLess Commitment hash: Double-SHA256(witless root hash) 43rd byte onwards: Optional data with no consensus meaning 
If there are more than one scriptPubKey matching the pattern, the one with highest output index is assumed to be the WitLess commitment.
submitted by tripledogdareya to btc [link] [comments]

The right way to fix transaction malleability

Recently I was asked about what a hard fork alternative to segwit would look like, and although I know this has been discussed in various venues, I couldn't find a single writeup anywhere.
There are two general use cases that require a transaction to have a name of some kind:
Bitcoin currently uses the transaction hash as the transaction identifier. The problem with this is that it's possible for the transaction to hash to chance before being mined, and it's not possible to prevent this malleability. This means you can't make a transaction that spends an output until it's been included in the block because you can't be certain about the transaction identifier.
How the problem could have been avoided
Everyone's life would have been easier if Satoshi would have made the transaction identifier and the transaction has explicitly different. A transaction identifier should be calculated by hashing the transaction after transforming all inputs to their signing form (input scripts blanked out).
In order to retain the ability to prove the inclusion of a transaction in a block either using the transaction hash or the transaction identifier, the Merkle tree ideally would have contained two leaf nodes for each transaction: one for the hash, and another for the ID.
How to deploy a solution
Pick a transaction version, n, to represent non-malleable transaction types.
All transactions with a version < n will have their txid calculated as it is currently, and transactions with a version >= n will use the non-malleable txid.
The leaf nodes for transactions with a version >=n will be calculated as the hash of (tx hash, tx id).
submitted by ABlockInTheChain to btc [link] [comments]

Dao Ethereum va dau tu Ethereum nhu the nao cho hieu qua tin tuc ve Ethereum tai Viet Nam

Dao Ethereum va dau tu Ethereum nhu the nao cho hieu qua tin tuc ve Ethereum tai Viet Nam
Xem tại đây.

Ethereum được mệnh danh là Bitcoin 2.0 vì cuộc cách mạng về kỹ thuật mà ETH mang lại khi ra đời. Những câu hỏi xung quanh Ethereum mà người mới tìm hiểu thị trường cryptocurrency thường đặt ra như cách đào Ethereum, đầu tư Ethereum, “cách chơi” Ethereum, cách kiếm Ethereum miễn phí và những dự đoán giá Ethereum năm 2018, 2019,… sẽ được giải đáp trong bài viết này.

  1. Cách đào Ethereum và nơi mua máy đào
1.1. Đào Ethereum với Minergate

Hiện nay, có khá nhiều cách đào Ethereum nhưng với người mới thì một số cách đào ETH rất phức tạp. Trong bài viết này, sẽ hướng dẫn đào Ethereum theo một cách đơn giản và dễ thực hiện là đào Ethereum với Minergate. Ngoài ra, có thể sử dụng một số tool đào ETH như Claymore Ethereum,…

Minergate là một trong những pool đào ETH tốt nhất và phổ biến nhất trên thế giới, nên khi mới bắt đầu, thợ đào có thể chọn pool đào ETH này để tiến hành đào Ethereum.

Bước 1: Đăng ký tài khoản Minergate

Truy cập vào website để tiến hành đăng ký tài khoản.

Sau khi điền thông tin Email và Password, chọn “Sign up & start mining” để đăng ký, sau đó hệ thống của Minergate sẽ gửi một Email để kích hoạt tài khoản. Bạn vào Email rồi bấm vào đường link nhận được.

Bước 2: Tải phần mềm đào Ethereum

Bước 2: Tải phần mềm đào Ethereum.

Click vào nút Download tương ứng với hệ điều hành của máy tính.

Sau khi tải về, bạn tiến hành cài đặt theo các bước. Cài đặt tool đào Ethereum của Minergate khá đơn giản, cũng tương tự như cài các phần mềm bình thường.

Tiến hành cài đặt tool đào Ethereum.

Sau khi cài đặt xong, khởi động chương trình rồi đăng nhập vào để bắt đầu đào Ethereum.

Đăng nhập tài khoản sau khi cài đặt xong tool đào ETH.

Bước 3: Bắt đầu đào Ethereum

– Click chọn Tab Miner.

– Chọn Coin muốn đào là Ethereum.

– Chọn số nhân muốn đào.

– Sau đó click chọn CPU Mining và GPU Mining. Nghĩa là bạn chọn đào Ethereum bằng CPU và GPU.

Lúc này chương trình sẽ mất khoảng 2 – 5 phút để khởi động.

Bước 3: Bắt đầu đào Ethereum.

1.2. Cấu hình máy đào Ethereum chuyên dụng

Tham khảo cấu hình phần cứng đào Ethereum như sau:

  • Main: Nên chọn main có 5 khe PCI-E, như: Biostar H81 Hifi, Asrock H81 Pro BTC motherboard,…
  • CPU: Celeron G3250 hay G1840 có thể giúp bạn tiết kiệm chi phí.
  • RAM: 4GB DDR3 cài hệ điều hành Win10 Untimate 64Bit để chạy phần mềm đào Ethereum.
  • Nguồn: Nên chọn nguồn có công suất thực như HDD/SSD.
  • HDH: Nên cài Win10 64Bit và tắt hết các hiệu ứng Win, tắt update, để Classic, tắt security, đặt Power Option là High performance.
  • VGA: Đây là yêu cầu quan trọng nhất khi cấu hình máy đào ETH chuyên dụng. Bạn cần tìm hiểu kỹ thông tin tốc độ đào Ethereum của các dòng Card màn hình khác nhau trước khi lựa chọn.
Sau khi đã nắm được hết sức mạnh của GPU là bao nhiêu Mh/s, thì bạn có thể thử tính với sức mạnh như vậy, một ngày mình có thể khai thác Ethereum bao nhiêu ở link:

Kiểm tra với máy đào ETH được cấu hình, một ngày có thể đào bao nhiêu ETH.

Là một miner (thợ đào), Ethereum difficulty hay độ khó đào Ethereum là yếu tố quan trọng cần lưu ý. Độ khó đào ETH tăng cao khi càng có nhiều miner tham gia cạnh tranh đào, dẫn đến tỷ lệ đào trúng ETH thấp đi.

Khi chuẩn bị bắt đầu đào ETH, bạn nên cân nhắc và tìm hiểu kỹ những vấn đề này.

1.3. Mua bán máy đào Ethereum

Sau khi đã tìm hiểu kỹ những thông tin liên quan đến vấn đề đào Ethereum, bạn sẽ muốn tìm cách mua bán máy đào Ethereum, hoặc là để tự mình đào ETH, hoặc là làm trung gian mua đi bán lại.

Hiện trên facebook, telegram có nhiều hội nhóm mua bán trâu cày ETH (bán máy đào Ethereum), bạn có thể tham gia và tìm hiểu ở những diễn đàn của dân “chuyên chăn trâu” này để có thêm nhiều kiến thức, được giải đáp thắc mắc, vấn đề phát sinh.

1.4. Cách kiếm Ethereum miễn phí

Nếu không có nhiều vốn đầu tư những dàn máy đào Ethereum chuyên dụng, chắc hẳn các bạn muốn tìm những cách đào Ethereum miễn phí (đào ETH free) hay kiếm ETH free. Thật ra, chỉ cần search Google là bạn có thể có hàng ngàn kết quả, nhưng phải đặc biệt lưu ý là không có chuyện gì dễ dàng, có rất nhiều trang web lừa đảo (scam) trong cryptocurrency.

Một số cách kiếm Ethereum free như sau:

  • Đào Ethereum free trên một trang web. Dĩ nhiên điều tiên quyết là bạn phải tìm được website uy tín. Cách này có thể trả về rất ít ETH.
  • Tham gia các chương trình airdrop, bounty của các dự án ICO. Sau đó, dự án có thể trả cho bạn bằng ETH hoặc token dự án, bạn bán ra trên các sàn giao dịch Ethereum để thu về ETH.
Cách kiếm Ethereum miễn phí.

Những cách kể trên chỉ là lý tưởng, độc giả cần nghiên cứu, xem xét kỹ các hình thức kiếm ETH miễn phí, vì có thể dễ dàng rơi vào một vụ scam làm mất cả thời gian, sức lực lẫn tiền bạc của chính mình.

  1. Cách đầu tư Ethereum
2.1. Có nên đầu tư Ethereum không?

Cuối năm 2017 và giai đoạn đầu năm 2018, cái tên Ethereum nổi lên trong cộng đồng như là một trong những đồng coin giá trị đáng đầu tư nhất. Đã có rất nhiều đánh giá tốt về đồng coin của Vitalik Buterin, và đồng thời giá ETH thực sự mang lại lợi nhuận cho nhà đầu tư qua những lần tăng mạnh.

Tuy nhiên, càng dần về cuối năm 2018, tin tức Ethereum tiêu cực xuất hiện liên tiếp. Casper Ethereum và những nâng cấp khác đều lần lượt bị trì hoãn, làm cộng đồng dần mất niềm tin với ETH. Quá trình chuyển thuật toán ETH từ Proof-of-Work sang Proof-of-Stake thu hút sự quan tâm rất lớn, nhưng cần tốn nhiều thời gian để thực hiện, nên không thể trở thành “cú hit” đẩy giá nhất thời.

Có nên đầu tư Ethereum không?

Vậy có nên đầu tư ETH nữa không? “Cách chơi” Ethereum như thế nào để sinh lời nhất? Điều này tùy thuộc vào sự tin tưởng của bạn vào tương lai Ethereum. Ngoài vấn đề về giá cả, chúng ta cần hiểu biết cả những công nghệ và phát triển đằng sau đồng altcoin này, từ đó có được đánh giá đúng đắn nhất về ETH và dự đoán giá Ethereum năm 2018 cũng như những năm tiếp theo. Cách chơi ETH có nhiều kiểu, trade lướt sóng hay đầu tư dài hạn là tùy thuộc vào phương pháp và nhận định của từng người.

Theo những ETH news mới nhất, đợt hard fork Ethereum tiếp theo là Constantinople sau bao lần trì hoãn đã được ấn định vào tháng 1/2019. Cộng đồng đang “nín thở” chờ đón Ethereum hard fork này, vì nó là một yếu tố quan trọng trong quá trình phát triển công nghệ của đồng altcoin. Nếu Constantinople thành công theo đúng dự kiến, nhà đầu tư và người hâm mộ có lẽ sẽ có thêm lòng tin khi đầu tư Ethereum.

2.2. Check ETH transaction – Kiểm tra giao dịch ETH

Để kiểm tra lịch sử giao dịch Ethereum, hay lịch sự chuyển ETH từ ví này sang ví khác, chúng ta thực hiện theo các bước sau:

  • vào
  • nhập vào ô Search by Address… địa chỉ ví A hoặc ví B
  • chọn GO
Etherscan (không phải là Ethereum scan nhé!) sẽ show ra lịch sử giao dịch của ví, hay tất cả TxHash của chiếc ví. Muốn check TxID ETH nào, bạn click vào giao dịch đó để xem chi tiết.

Check ETH transaction.
Ở mục TxReceipt Status:

  • nếu Success tức là giao dịch này đã thực hiện thành công và ví người nhận đã nhận được ETH
  • nếu Pending nghĩa là giao dịch này vẫn đang trong quá trình xác nhận và ví của người nhận vẫn chưa nhận được ETH

Kiểm tra giao dịch ETH.

Bên cạnh check ETH transaction, một nỗi băn khoăn khác của người dùng là Gas limit Ethereum là gì? Gas limit Ethereum được gọi là giới hạn năng lượng vì đó là số Ether tối thiểu mà bạn sẵn sàng chi trả cho phí giao dịch. Điều này tránh được tình huống có một lỗi ở nơi nào đó trong hợp đồng, và bạn gửi 1 ETH mà không có nơi nhận. Nếu bạn không đủ gas limit Ethereum thì khi gửi giao dịch sẽ gặp lỗi “Out of Gas” và giao dịch không được thực hiện.

Bạn có thể kiểm tra các mức gas ETH hiện nay với ETH Gas Station tại địa chỉ web: để tính toán được phí giao dịch ETH phù hợp nhất.

ETH Gas Station.v

  1. Cách tìm kiếm thông tin và đọc thông tin về Ethereum
Thị trường cryptocurrency biến động rất mạnh và news Ethereum xuất hiện liên tục. Để cập nhật những thông tin, tin tức Ethereum mới nhất và thường xuyên, các bạn có thể theo dõi trên các trang web ETH news phổ biến như: Cointelegraph, Bitcoinist, CCN, News.bitcoin,… và các mạng xã hội như Twitter, Telegram, Facebook cũng như những diễn đàn cryptocurrency như Bitcointalk.

Dù có một số dự báo giá Ethereum 2018 rất tốt, sẽ tăng mạnh nhưng thực tế thì giá ETH liên tục biến động lên xuống thất thường. Vào ngày 13/1/2018, giá Ethereum đạt đỉnh điểm hơn 1.440 USD, đánh dấu “thời khắc huy hoàng” của đồng altcoin là “vua của mọi altcoin” khi đó. Nhưng sau đó, giá ETH bắt đầu sụt giảm, đến tháng 12/2018 chỉ dao động quanh cột mốc 100 USD. Những biến động đó được thể hiện một phần qua biểu đồ giá ETH trên Coinmarketcap như sau:

Biểu đồ giá ETH.

  1. Tóm tắt
Hiện nay, có khá nhiều cách đào Ethereum nhưng với người mới thì một số cách đào ETH rất phức tạp. Trong bài viết này, sẽ hướng dẫn đào Ethereum theo một cách đơn giản và dễ thực hiện là đào Ethereum với Minergate. Ngoài ra, có thể sử dụng một số tool đào ETH như Claymore Ethereum,… Minergate là một trong những pool đào ETH tốt nhất và phổ biến nhất trên thế giới, nên khi mới bắt đầu, thợ đào có thể chọn pool đào ETH này để tiến hành đào Ethereum.

Là một miner (thợ đào), Ethereum difficulty hay độ khó đào Ethereum là yếu tố quan trọng cần lưu ý. Độ khó đào ETH tăng cao khi càng có nhiều miner tham gia cạnh tranh đào, dẫn đến tỷ lệ đào trúng ETH thấp đi.

Đào Ethereum và đầu tư Ethereum như thế nào cho hiệu quả, tin tức về Ethereum tại Việt Nam.

Vậy có nên đầu tư ETH nữa không? “Cách chơi” Ethereum như thế nào để sinh lời nhất? Điều này tùy thuộc vào sự tin tưởng của bạn vào tương lai Ethereum. Ngoài vấn đề về giá cả, chúng ta cần hiểu biết cả những công nghệ và phát triển đằng sau đồng altcoin này, từ đó có được đánh giá đúng đắn nhất về ETH và dự đoán giá Ethereum năm 2018 cũng như những năm tiếp theo.

Check ETH transaction trên Etherscan (không phải Ethereum scan) để kiểm tra lịch sử các giao dịch Ethereum.

Cập nhật tin tức mới nhất về blockchain và cryptocurrency tại
submitted by tiendientuorg to u/tiendientuorg [link] [comments]

BCH on-chain raffle:

There is a new place to play bch called playBCH ( This is a new kind of raffle, played exclusively in BCH and controlled by Bitcoin Cash blockchain. It receives bets of 10k (5 cents) or 100k (50 cents) satoshis. It is in beta for now running since August 20th. The last 5 bytes of tx id is the bet number. After the end of the round that is defined as 18 blocks, on the 3rd block after (like 3 confirmations), the last 5 bytes of the hash of the block created is the drawn number and the system automatically send all bets to the winner (discounting 1% for the site). A person can send many tx as he or she wants and each tx will have a new bet number. All the bch received by the wallet is sent to a winner on each round, the site only gets 1% of the jackpot. Everything can be audited by the blockchain.
There is a bot in memo (playBCH) that answers for each bet received (at least for now) and also posts the winner at the end of the round.
I need to put the system in stress test and would love to have people send bets there! Beyond help us to test and fix eventual bugs, this is a real game based exclusively in luck, you would also contributing to the stresstest.
We are in beta phase, checking the system and solving any problems that may appear.
How to play (in a nutshell):
1- You send one or more bets to the playBCH wallet (bitcoincash:qqszqehzculwhsa62wrcqndraer4cxkj8vlgddplhg) during the period of the round (18 blocks).
2- The bet amount must be exactly 0.001 or 0.0001 BCH.
3- For the sending transaction, an id (transaction id) is generated randomly, this is the number that you will compete with in the draw, your lucky number.
4- After the end of the round, in the generation of the third block, a block hash code will also be generated randomly. This will be considered the number drawn in the round.
5- The bet (transaction id) that is closest to that block hash will be the champion and will automatically receive all the bets made in the round, discounting 1% that is website fee.
More details on how it works and the rules:
Bet Number: TXID is the bet number, it is random and because it is very large, it has 32 bytes, we use the last 5 bytes. We get the last 5 bytes of TXID, convert it to decimal and, to be more readable, divide by 1,000,000. This results in a number between 0 and 100,000 with 6 decimal places. This is considered as your bet number.
Sending many bets: there is no limit of amount of bets. You can send any quantity of bets, of same value or different values (10K or 100K), during a round. Each bet will have a different TXID and will compete with the other ones of equal value.
Number drawn: the number drawn follows the same logic as TXID. In the third block after the end of the round, we get the hash code of the block, which is a number of 32 bytes, we use the last 5 bytes, convert to decimal and divide by 1,000,000. The result is considered the number drawn in the round.
Winning bet: the winning bet will be the closest to the number drawn. When we calculate the result, we verify the difference between each bet and the number drawn, the smallest difference is the winner.
Prize Value: The prize amount is the total of all bets (of the same value) of the round, discounted from the bot commission, which is 1%.
Prize Payment: At the end of the round result calculation, the bot automatically sends the prize to the winner and records the TXID of the payment, as well as discloses in the Memo system.
Disclosure: All transactions are recorded with TXID in a round file available on our website. In our history section on our website, each round can be consulted. We are also launching in the memo system, playBCH topic, all the events of the round, beginning of the round, bets received, TXIDs, as well as the result of the round and payment.
Value of the bet: at this moment, the value of the bet can only be 10K or 100K satoshis (0.0001 or 0.001 bch). Each bet participates in the round with other bets of the same value. That is, for each round, there are two disputes, one for the 10K bets and another for the 100K bets.
Betting period: the betting period is 18 blocks, in the future we will have rounds with different periods. At each close of a round, another round begins immediately.
Parallel draws: there are many draws running in parallel during a round, each one considers all bets of same value. During a round, there may be several draws in parallel for each different bet value, for instance 0.001 or 0.0001.
Only one bet in the round: If during the round only one bet is received (0.001 or 0.0001 value), the value will be returned without discounting the commission of the website. This ensures that if there is no dispute, the value of the bet will be returned without discount.
Wrong bet value: in case of transfer of incorrect value, the value will be considered as a bet on that value. If there is no other transfer of the same value, it will be returned intact in the closing of the round. If there is another transfer of the same value during the period, this new transfer will be considered a bet also and there will be a dispute and the winner will receive the total value of the bets of that value minus the website fee.
Transfers below 1,000 satoshis: are currently not returned, they are considered donations to the bot.
Audit: The entire process can be easily audited by checking the bot's wallet and verifying all incoming and outgoing transactions. All entries (except for values below 1,000) are considered bets. Exits are of three types: 1) jackpot payment (including the return of bets that have not been disputed), 2) memo messages, 3) withdrawal of the website fee.
Provably fair: all things are based on blockchain, so the result (drawn number) and the way you bet (bet number is extracted from TXID) are completely provably fair. It's all luck.
Smart contract: the closing of the round and the transfer of the Jackpot will be done by smart contract that are being created and will soon be in charge. With this, the entire process will be provably fair and playBCH will be one of the first website to have a play site totatly provably fair.
About stresstest: this project can help during the stress test to bring transactions to bch:, plus have fun. All things are based on blockchain, so the results and the way you bet are completely provably fair. It is all luck.
BCH on-chain raffle
You can bet as little as 10K satoshis (0.05 USD) and at this moment help is needed to test the site and see how much volume and how many bets it can support.
How to play / Rules:
Donations: 19aG46zNwRG3qoap2DA8zaRs3Wmu5PQefn
submitted by esthonm to btc [link] [comments]

Great interview questions for bitcoin engineers

From here...
Questions. Chapter 1: Introduction 1. What are the main Bitcoin terms? 2. What is a Bitcoin address? 3. What is a Bitcoin transaction? 4. What is a Bitcoin block? 5. What is a Bitcoin blockchain? 6. What is a Bitcoin transaction ledger? 7. What is a Bitcoin system? What is a bitcoin (cryptocurrency)? How are they different? 8. What is a full Bitcoin stack? 9. What are two types of issues that digital money have to address? 10. What is a “double-spend” problem? 11. What is a distributed computing problem? What is the other name of this problem? 12. What is an election? 13. What is a consensus? 14. What is the name of the main algorithm that brings the bitcoin network to the consensus? 15. What are the different types of bitcoin clients? What is the difference between these clients? Which client offers the most flexibility? Which client offers the least flexibility? Which client is the most and least secure? 16. What is a bitcoin wallet? 17. What is a confirmed transaction and what is an unconfirmed transaction? Chapter 2: How Bitcoin works. 1. What is the best way to understand transactions in the Bitcoin network? 2. What is a transaction? What does it contain? What is the similarity of a transaction to a double entry ledger? What does input correspond to? What does output correspond to? 3. What are the typical transactions in the bitcoin network? Could you please name three of such transactions and give examples of each type of the transaction? 4. What is a QR and how it is used in the Bitcoin network? Are there different types of QRs? If so, what are the different types? Which type is more informational? What kind of information does it provide? 5. What is SPV? What does this procedure check and what type of clients of the Bitcoin network usually use this procedure? Chapter 3: The Bitcoin client. 1. How to download and install the Core Bitcoin client? 2. What is the best way to test the API available for the Core Bitcoin client without actually programming? What is the interface called? 3. What are the major areas of operations in the Bitcoin client? What can we do with the client? 4. What are the available operations for the Bitcoin addresses? 5. What are the available read operations for the Bitcoin transactions? How is a transaction encoded in the Bitcoin network? What is a raw transaction and what is a decoded transaction? 6. If I want to get information about a transaction that is not related to any address in my own wallet, do I need to change anything in the Bitcoin client configuration? If yes, which option do I need to modify? 7. What are the available read operation for the Bitcoin blocks? 8. What are the available operations for the creation of the transactions in the Bitcoin network? 9. How do you normally need to address the unspent output from the previous transaction in order to use it as an input for a new transaction? 10. What is the mandatory operation after creating a new transaction and before sending this new transaction to the network? What state does the wallet have to be in order to perform this operation? 11. Is the transaction ID immutable (TXID)? If not why, if yes, why and when? 12. What does signing a transaction mean? 13. What are the other options for Bitcoin clients? Are there any libraries that are written for some specific languages? What types of clients do these libraries implement? Chapter 4: Keys, Addresses and Wallets. 1. What is a PKC? When it was developed? What are the main mathematical foundations or functions that PKC is using? 2. What is ECC? Could you please provide the formula of the EC? What is the p and what is the Fp? What are the defined operations in ECC? What is a “point to infinity”? 3. What is a Bitcoin wallet? Does this wallet contain coins? If not, what does it contain then? 4. What is a BIP? What it is used for? 5. What is an encrypted private key? Why would we want to encrypt private keys? 6. What is a paper wallet? What kind of storage it is an example of? 7. What is a nondeterministic wallet? Is it a good wallet or a bad wallet? Could you justify? 8. What is a deterministic wallet? 9. What is an HD wallet? 10. How many keys are needed for one in and out transaction? What is a key pair? Which keys are in the key pair? 11. How many keys are stored in a wallet? 12. How does a public key gets created in Bitcoin? What is a “generator point”? 13. Could you please show on a picture how ECC multiplication is done? 14. How does a private key gets created in Bitcoin? What we should be aware of when creating a new private key? What is CSPRNG? What kind of input should this function be getting? 15. What is a WIF? What is WIF-Compressed? 16. What is Base58 encoding and what is Base58Check encoding? How it is different from Base64 encoding? Which characters are used in Base58? Why Base58Check was invented? What kind of problems does it solve? How is Base58Check encoding is created from Base58 encoding? 17. How can Bitcoin addresses be encoded? Which different encodings are used? Which key is used for the address creation? How is the address created? How this key is used and what is the used formula? 18. Can we visually distinguish between different keys in Base58Check format? If yes, how are they different from each other? What kind of prefixes are used? Could you please provide information about used prefixes for each type of the key? 19. What is an index in HD wallets? How many siblings can exist for a parent in an HD wallet? 20. What is the depth limitation for an HD wallet key hierarchy? 21. What are the main two advantages of an HD wallet comparing to the nondeterministic wallets? 22. What are the risks of non-hardened keys creation in an HD wallet? Could you please describe each of them? 23. What is a chain code in HD wallets? How many different chain code types there are? 24. What is the mnemonic code words? What are they used for? 25. What is a seed in an HD wallet? Is there any other name for it? 26. What is an extended key? How long is it and which parts does it consist of? 27. What is P2SH address? What function are P2SH addresses normally used for? Is that correct to call P2SH address a multi-sig address? Which BIP suggested using P2SH addresses? 28. What is a WIF-compressed private key? Is there such a thing as a compressed private key? Is there such a thing as a compressed public key? 29. What is a vanity address? 30. What is a vanity pool? 31. What is a P2PKH address? What is the prefix for the P2PKH address? 32. How does the owner prove that he is the real owner of some address? What does he have to represent to the network to prove the ownership? Why a perpetrator cannot copy this information and reuse it in the next transactions? 33. What is the rule for using funds that are secured by a cold storage wallet? How many times you can send to the address that is protected by the private key stored in a cold storage? How many times can you send funds from the address that is protected by the private key stored in a cold storage? Chapter 5: Transactions. 1. What is a transaction in Bitcoin? Why is it the most important operation in the Bitcoin ecosystem? 2. What is UTXO? What is one of the important rules of the UTXO? 3. Which language is used to write scripts in Bitcoin ecosystem? What are the features of this language? Which language does it look like? What are the limitations of this language? 4. What is the structure of a transaction? What does transaction consists of? 5. What are the standard transactions in Bitcoin? How many standard transactions there are (as of 2014)? 6. What is a “locking script” and what is an “unlocking script”? What is inside these scripts for a usual operation of P2PKH? What is a signature? Could you please describe in details how locking and unlocking scripts work and draw the necessary diagrams? 7. What is a transaction fee? What does the transaction fee depend on? 8. If you are manually creating transactions, what should you be very careful about? 9. Could you please provide a real life scenario when you might need a P2SH payment and operation? 10. What is the Script operation that is used to store in the blockchain some important data? Is it a good practice? Explain your answer. Chapter 6: The Bitcoin Network. 1. What is the network used in Bitcoin? What is it called? What is the abbreviation? What is the difference between this network architecture and the other network architectures? Could you please describe another network architecture and compare the Bitcoin network and the other network architectures? 2. What is a Bitcoin network? What is an extended Bitcoin network? What is the difference between those two networks? What are the other protocols used in the extended Bitcoin network? Why are these new protocols used? Can you give an example of one such protocol? What is it called? 3. What are the main functions of a bitcoin node? How many of them there are? Could you please name and describe each of them? Which functions are mandatory? 4. What is a full node in the Bitcoin network? What does it do and how does it differ from the other nodes? 5. What is a lightweight node in the Bitcoin network? What is another name of the lightweight node? How lightweight node checks transactions? 6. What are the main problems in the SPV process? What does SPV stand for? How does SPV work and what does it rely on? 7. What is a Sybil attack? 8. What is a transaction pool? Where are transaction pools stored in a Bitcoin network client? What are the two different transaction pools usually available in implementations? 9. What is the main Bitcoin client used in the network? What is the official name of the client and what is an unofficial name of this client? 10. What is UTXO pool? Do all clients keep this pool? Where is it stored? How does it differ from the transaction pools? 11. What is a Bloom filter? Why are Bloom filters used in the Bitcoin network? Were they originally used in the initial SW or were they introduced with a specific BIP? Chapter 7: The Blockchain. 1. What is a blockchain? 2. What is a block hash? Is it really a block hash or is it a hash of something else? 3. What is included in the block? What kind of information? 4. How many parents can one block have? 5. How many children can one block have? Is it a temporary or permanent state of the blockchain? What is the name of this state of the blockchain? 6. What is a Merkle tree? Why does Bitcoin network use Merkle trees? What is the advantage of using Merkle trees? What is the other name of the Merkle tree? What kind of form must this tree have? 7. How are blocks identified in the blockchain? What are the two commonly used identities? Are these identities stored in the blockchain? 8. What is the average size of one transaction? How many transactions are normally in one block? What is the size of a block header? 9. What kind of information do SPV nodes download? How much space do they save by that comparing to what they would need if they had to download the whole blockchain? 10. What is a usual representation of a blockchain? 11. What is a genesis block? Do clients download this block and if yes – where from? What is the number of the genesis block? 12. What is a Merkle root? What is a Merkle path? Chapter 8: Mining and Consensus. 1. What is the main purpose of mining? Is it to get the new coins for the miners? Alternatively, it is something else? Is mining the right or good term to describe the process? 2. What is PoW algorithm? 3. What are the two main incentives for miners to participate in the Bitcoin network? What is the current main incentive and will it be changed in the future? 4. Is the money supply in the Bitcoin network diminishing? If so, what is the diminishing rate? What was the original Bitcoin supply rate and how is it changed over time? Is the diminishing rate time related or rather block related? 5. What is the maximum number of Bitcoins available in the network after all the Bitcoins have been mined? When will all the Bitcoins be mined? 6. What is a decentralized consensus? What is a usual setup to clear transactions? What does a clearinghouse do? 7. What is deflationary money? Are they good or bad usually? What is the bad example of deflationary spiral? 8. What is an emergent consensus? What is the feature of emergent consensus? How does it differ from a usual consensus? What are the main processes out of which this emergent decentralized consensus becomes true? 9. Could you please describe the process of Independent Transaction Verification? What is the list of criteria that are checked against a newly received transaction? Where can these rules be checked? Can they be changed over time? If yes, why would they be changed? 10. Does mining node have to be a full node? If not, what are the other options for a node that is not full to be a mining node? 11. What is a candidate block? What types of nodes in the Bitcoin network create candidate blocks? What is a memory pool? Is there any other name of the memory pool? What are the transactions kept in this memory pool? 12. How are transactions added to the candidate block? How does a candidate block become a valid block? 13. What is the minimum value in the Bitcoin network? What is it called and what is the value? Are there any alternative names? 14. What is the age of the UTXO? 15. How is the priority of a transaction is calculated? What is the exact formula? What are the units of each contributing member? When is a transaction considered to be old? Can low priority transactions carry a zero fee? Will they be processed in this case? 16. How much size in each block is reserved for high priority transactions? How are transactions prioritized for the remaining space? 17. Do transactions expire in Bitcoin? Can transactions disappear in the Bitcoin network? If yes, could you please describe such scenario? 18. What is a generation transaction? Does it have another name? If it does, what is the other name of the transaction? What is the position of the generation transaction in the block? Does it have an input? Is the input usual UTXO? If not – what is the input called? How many outputs there are for the generation transaction? 19. What is the Coinbase data? What is it currently used for? 20. What is little-endian and big-endian formats? Could you please give an example of both? 21. How is the block header constructed? Which fields are calculated and added to the block header? Could you please describe the steps for calculation of the block header fields? 22. What is a mantissa-exponent encoding? How is this encoding used in the Bitcoin network? What is the difficulty target? What is the actual process of mining? What kind of mathematical calculation is executed to conduct mining? 23. Which hash function is used in the Bitcoin mining process? 24. Could you describe the PoW algorithm? What features of the hash function does it depend on? What is the other name of the hash function? What is a nonce? How can we increase the difficulty of the PoW calculation? What do we need to change and how do we need to change this parameter? 25. What is difficulty bits notation? Could you please describe in details how it works? What is the formula for the difficulty notation? 26. Why is difficulty adjustable? Who adjusts it and how exactly? Where is the adjustment made? On which node? How many blocks are taken into consideration to predict the next block issuance rate? What is the change limitation? Does the target difficulty depend on the number of transactions? 27. How is a new block propagated in the network? What kind of verification does each node do? What is the list of criteria for the new block? What kind of process ensures that the miners do not cheat? 28. How does a process of block assembly work? What are the sets of blocks each full node have? Could you please describe these sets of blocks? 29. What is a secondary chain? What does each node do to check this chain and perhaps to promote it to the primary chain? Could you please describe an example when a fork occurs and what happens? 30. How quickly forks are resolved most of the time? Within how many new block periods? 31. Why the next block is generated within 10 minutes from the previous? What is this compromise about? What do designers of the Bitcoin network thought about when implementing this rule? 32. What is a hashing race? How did Bitcoin hashing capacity has changed within years from inception? What kind of hardware devices were initially used and how did the HW utilization evolved? What kind of hardware is used now to do mining? How has the network difficulty improved? 33. What is the size of the field that stores nonce in the block header? What is the limitation and problem of the nonce? Why was an extra nonce created? Was there any intermediate solution? If yes, what was the solution? What are the limitations of the solution? 34. What is the exact solution for the extra nonce? Where does the new space come from? How much space is currently used and what is the range of the extra nonce now? 35. What is a mining pool? Why was it created? How are normally such pools operated? Do they pay regularly to the pool participants? Where are newly created Bitcoins distributed? To which address? How do mining pools make money? How do the mining pools calculate the participation? How are shares earned calculated? 36. What is a managed pool? How is the owner of the pool called? Do pool members need to run full nodes? Explain why or why not? 37. What are the most famous protocols used to coordinate pool activities? What is a block template? How is it used? 38. What is the limitation of a centralized pool? Is there any alternative? If yes, what is it? How is it called? How does it work? 39. What is a consensus attack? What is the main assumption of the Bitcoin network? What can be the targets of the consensus attacks? What can these attacks do and what they cannot do? How much overall capacity of the network do you have to control to exercise a consensus attack? Chapter 9: Alternative Chains, Currencies and Applications. 1. What is the name of alternative coins? Are they built on top of the Bitcoin network? What are examples of them? Is there any alternative approach? Could you please describe some alternatives? 2. Are there any alternatives to the PoW algorithm? If yes – what are the alternatives? Could you please name two or three? 3. What is the operation of the Script language that is used to store a metadata in Bitcoin blockchain? 4. What is a coloured coin? Could you please explain how it is created and how it works? Do you need any special SW to manage coloured coins? 5. What is the difference between alt coins and alt chains? What is a Litecoin? What are the major differences between the Bitcoin and Litecoin? Why so many alt coins have been created? What are they usually based on? 6. What is Scrypt? Where is it used and how is it different from the original algorithm from which it has been created? 7. What is a demurrage currency? Could you please give an example of one blockchain and crypto currency that is demurrage? 8. What is a good example of an alternative algorithm to PoW? What is it called and how is it different from the PoW? Why the alternatives to Bitcoin PoW have been created? What is the main reason for this? What is dual-purpose PoW algorithms? Why have they been created? 9. Is Bitcoin “anonymous” currency? Is it difficult to trace transactions and understand someone’s spending habits? 10. What is Ethereum? What kind of currency does it use? What is the difference from Bitcoin? Chapter 10: Bitcoin security. 1. What is the main approach of Bitcoin security? 2. What are two common mistakes made by newcomers to the world of Bitcoin? 3. What is a root of trust in traditional security settings? What is a root of trust in Bitcoin network? How should you assess security of your system? 4. What is a cold storage and paper wallet? 5. What is a hardware wallet? How is it better than storing private keys on your computer or your smart phone?
submitted by 5tu to BitcoinTechnology [link] [comments]

How much of an idiot am I?

First up - I have very little idea what I'm doing. Mined a bunch of BTC back in the day, sold most of them years ago, I'm just now having a play with the remainder.
I tried to send some BTC into an exchange just now, and I'm rather confused by what I'm seeing. I've no doubt that I'm an idiot and did something wrong, I'd just like to understand what I did! Here's the output from bitcoin-cli:
$ bitcoin-cli getinfo { "version": 140200, "protocolversion": 70015, "walletversion": 10500, "balance": 1.34880220, "blocks": 502207, "timeoffset": 0, "connections": 8, "proxy": "", "difficulty": 1931136454487.716, "testnet": false, "keypoololdest": 1293896718, "keypoolsize": 100, "paytxfee": 0.00005000, "relayfee": 0.00001000, "errors": "" } $ bitcoin-cli sendtoaddress 1FtRC6jnSPRxDXZ9dQFknkEvHvTNKmFDV6 0.02 b4b2dcd0e76518dee186a24c61ce9d76d9441cf48728e850d9049da5e0b0badf $ bitcoin-cli getinfo { "version": 140200, "protocolversion": 70015, "walletversion": 10500, "balance": 1.19619004, "blocks": 502207, "timeoffset": 0, "connections": 8, "proxy": "", "difficulty": 1931136454487.716, "testnet": false, "keypoololdest": 1293896718, "keypoolsize": 100, "paytxfee": 0.00005000, "relayfee": 0.00001000, "errors": "" } 
"Holy crap", thought I, "the transaction fees must have been ridiculous". But the transaction info is:
{ "account": "", "address": "1FtRC6jnSPRxDXZ9dQFknkEvHvTNKmFDV6", "category": "send", "amount": -0.02000000, "vout": 1, "fee": -0.00001290, "confirmations": 0, "trusted": false, "txid": "b4b2dcd0e76518dee186a24c61ce9d76d9441cf48728e850d9049da5e0b0badf", "walletconflicts": [ ], "time": 1514898128, "timereceived": 1514898128, "bip125-replaceable": "unknown", "abandoned": false } 
My calculations say 1.34880220 - 0.02 - 0.00001290 = 1.3287893. I have no other transactions listed, so why is my balance now showing 1.19619004BTC?! I look forward to face-palming very hard...
submitted by techWARlrus to Bitcoin [link] [comments]

Blockchain to fix horribly broken e-mail system like it is today?

E-mail as it is, is horribly broken. Horrendously broken.
It wasn't that many years ago that you could be assured your e-mail reaches whoever you were mailing to. Today it is a mere suggestion, that perhaps this should be delivered to this person, at least for any automated e-mail. This seems to be creeping to manual, organic email as well. Hell, we are seeing even internal e-mails being flagged by spamassassin as spam, organic, human written conversations! In that instance, the spamassassin is also maintained by one of the largest hosting providers in the world...
Hotmail/MS services has been for years (atleast about 4 years now!) been silently dropping email, not all, but some. There's a bit of relief lately, as they have started to favor a bit more marking as spam, rather than silently dropping.
I know, most email users don't see this problem, but those who use email a lot to do their work, and those who need to send automated emails (say, welcome e-mails for a service) this is a big problem. (Disclaimer, for us, our niche of hosting probably causes flagging as well. Our site is blocked by many corporate firewalls for example)
Blockchain to the rescue?
This is an idea i've been toying around with a few years. What if any single e-mail would cost a faction of a cent, and who receives the e-mail, gets paid for it? Now that would solve a lot of problems. I realize there has been some half assed attempts on blockchain based e-mail, but they are about replacing email (never going to happen). Using blockchain to enhance the current experience, with least minimal friction should be the goal, not re-inventing the wheel.
Imagine a say 0.01 cent (0.0001 USD) cost per e-mail. This price would not be cost prohibitive even for free e-mail service providers (Ad revenue etc. should exceed this value), never mind any legit e-mail users. Especially considering you get paid for receiving. So all legit e-mail services would work rather well regardless of the cost. (never mind free email service could profit from this)
Spam however? To send 1 million emails you would need to pay 100$. How many spammers would continue doing so? At least it makes things much harder, not so easy to use a botnet to send your email when you need to include your private key(s) to the botnet, or make some kind of private key management system, makes more complicated.
Small business newsletters? Say you need to send 100k e-mails to legit customers, 10$ is nothing. To human time crafting that newsletter is order (possibly orders) of magnitude greater than that.
Price would also fluctuate as per the market. The most difficult thing would probably be setting the self balancing mechanisms to keep per mail cost sensible. As such, the biggest hurdle in this might not be technical at all.
Technically, how could this work?
Sender sends a TX for e-mail they are sending for recipient. This TX contains message with mail ID, and a segment which can be used with the email contents to unlock the private key for the payment. This way it is verified that recipient mail servers receives and reads the email. Once the recipient server has calculated the private key, they can either TX the received sum to their wallet, or this needs to be formatted so that once the sender has sent it, they cannot recover the private key and double spend (technical hurdle A. For someone who knows their stuff unlikely to be an major hurdle)
Step by step repeat: * Sender checks if recipient has "MailCoin" capability * Sender sends TX to recipient * Sender sends the email to recipient * Recipient notices on mail header (say x-mailcoin-tx: TXID_HERE) that this is a "mailcoin" mail * Recipient checks TX if it has been received * Recipient puts the mail on delivery queue, antispam is instructed of heavy negative score (MTA admin configurable) * Recipient claims the value of the TX (this is the hurdle A). Recipient can only claim the TX value in case they have received the full e-mail. (Question, can this step be pushed even further down the delivery chain, but still remain MTA only level without mail client support?). Most likely solution is that the header contains the encrypted private key, and chain TX contains the key to decrypt that private key to claim the coins, or vice-versa?
Once recipient has the email & payment, they simply mark on their Antispam a automatic lower score and deliver it normally.
E-mail server side we have several components:
Most typical scenario would be the Recipient server works as outgoing as well, with single wallet. So depending on your mail volume, do you send or receive more on that wallet you might never need to worry about the coins (except for value going skyhigh and having like 10k $ worth of "MailCoins").
So perhaps additional components on per use case are needed, or more likely rudimentary scripting capability (ie. "MailCoin" daemon api) to keep the balances in check.
Technical hurdle B: This needs to be super super simple to setup. Or sufficient financial incentive. One would need to develop standard components & configs for exim, postfix, and other MTAs. Infact, make it autogenerate wallet ID etc. and easy to replace or import private keys etc. to put in coins for sending if you need to.
Privacy: On the blockchain you would not see the e-mail contents, only that e-mail likely took place (TX with mail UUID) to recipient. If sender can be deciphered it depends on them if it can be traced who they were. Automatic mixers? :) Recipient can also keep cycling the receive addresses to keep things private if they want to.
The biggest problem i see here, is that if an attacker can deduce the sender and/or recipient, it might to lead to some issues out of the scope of technical solutions. If attacker could read the emails, they would already have accomplished MitM and could just grab all e-mails.
Default implementation should be so, that from recipient address outsider cannot deduce the recipient server nor hostname.
Also, if attacker gains access to your mail with full headers, they could see the TXs in blockchain. MTA might need to scrub mailcoin related headers (yuck, scrubbing headers ....) for paranoid users, but most likely solution is that recipient retransmits those mailcoins as soon as they got the private key for the balance.
Blockchain: Blocks needs to be done every 10seconds or so, it needs to be fast. Preferrably even every 5 seconds, as not to cause any undue delay. Then again, if your application is reliant on receiving email within seconds, one should consider another means for communicating. Imho, email should be considered a little bit like snail mail, but on internet pace: Couple minutes delay is just OK.
Block size given the e-mail volume needs to be fairly large as well, considering the time between blocks. This is technical hurdle C: Hosting the full blockchain. I can easily foresee that this would grow to be terabytes in size. However, any large email operator would have vested interest in ensuring smooth operation of the blockchain, and for them, running a full node would have neglible cost.
(Technical hurdle C) Single email sent using the system could easily have TX contents of 100 bytes + TX headers + block headers etc. Say 100 bytes, and 100 million emails per day: 9.31GiB per day, 3 399GiB per year, 5 years later: 16.60 TiB just for the mail TXs.
Some estimate there is 200+ billion emails per day, but we all know large portion of this is spam. But even at 50 billion emails a day, 100 bytes per mail TX would add to 4.55TiB per day! So optimizing the blockchain size is obviously going to be important. The volume will be obviously much smaller as semi-spam (those daily half opt-in spamvertising from companies you know) will be lower as well. So probs 100+ billion emails per day at 100% adoption.
Blockchain should then be compressed, the whole block. Algorithm probably should favor speed over compression rate, and should be task specifically optimized (needs a simple reference release, where you can just stream the block contents into it and get output as compressed or uncompressed). The more compression there is, the more full nodes will be hosted by smaller operators :)
For large e-mail server clusters there should be central store for the blockchain, but this can be accessed on the system administratoconfig level already. The MTA components will just remotely talk to single full node daemon (so not really different from many implementations in existence right now), instead of each one running locally a full node.
At today's cheapest hosting rates 16.60TiB is roughly around 85-100€ a month. Purchase cost per 8TB drive is around 230€ mark right now, externals are cheaper. Not an issue for any even semi serious mail provider. Not even issue for datahoarder individuals.
However at 100 billion mails per day: 9.09TiB per day added, which is prohibitively large! We should be targeting something like 20bytes per mail final storage spent, or even less.
If it looks like it is going to grow really large, full node needs to have configurable multiple storages, so they can store parts of the blockchain on multiple different devices (ie. individual might choose to have it on 4 different external drives).
Filesystem side optimizations are needed as well, but these are fairly simple, just split into multiple subdirectories by the 10 thousand blocks or so, ie. 1 for blocks 1-10k, 2 for blocks 10 001 to 20k etc. Filesystems get exponentially slower the more files there is per directory. 10k might start to show slowing down, but is not significant yet.
Nodes could also implement secondary compression (compress multiple blocks together), if the blockchain starts to become stupid large. If it starts to become impossible to maintain, we could possibly implement a scrubbing methodology, where very old blocks get the TX contents wiped as they are not necessary anymore. Should not be an issue
Blocks with 10second target generated per annum: 3 153 600 Mails per 10second: 115 740 e-mails per 10second block. Final compressed size (say 20 bytes per mail): 2.20MiB + headers etc. per block Let's start small and allow linear growth to this, say 0.1% per day (36.5% annual) and start from 20k / 512KiB. After 3 years: 41.9k / 1072.64KiB per block, After 10 years: 93k / 2380.8KiB. (2027 we should have HDDs in the size of 30TB and daily max size for chain growth is 19.61TiB)
On the positive side every problem is an opportunity in disguise. If the blockchain is large, once again botnets will have a hard hard time to spamming, they can't host the full blockchain on infected machines. They will need to develop centralized mechanisms on this regard as well. One method i can see is by having TOR client built in, and via .onion domain to anonymize, but this is two way street, security researchers could exploit this (see above about the private keys) as well. Even without botnets, spammers will need to dedicate significant resources to host the full blockchain.
On the flip side, if spammer has also mining operation on the same local area network, they have both the income for mailcoins + full blockchain, and could leverage economies of scale, but this too would increase cost. And after all: This is all about increasing cost for spamming, while having the price in vicinity where real e-mail users, real businesses it is not a significant impact, or may even be an income source
Client side
Zero, Nada changes. No changes to outlook, thunderbird etc. Everything works under the hood at the MTA level. Very easy adoption for the end user. Everything is in the backend, server side.
Economics for users
Cost of operation has above been shown to increase wildly for spammers. But how about normal use cases?
Joe Average: They receive e-mail a lot more than they send, all kinds of order confirmations, invoices, newsletters and other automated e-mail. They will actually earn (however tiny amounts) from using this system. So for the masses, this is a good thing, they will see the earning potentials! which brings us to ....
New business opportunities! I could foresee a business setting up spam traps, the more e-mail you receive the more you earn! So it pays to get your receiver into spam lists. You don't ever need to read these, just confirm receive of them. All of sudden we could see even greater numbers of invalid e-mail addresses in spam lists, making spamming ever more expensive!
Free email services might proof to be extremely profitable, to the point of potential revenue sharing with Joe Averages (and above spamtraps). Because free email is mostly joe averages, they will have greater influx than outgoing. On the caveat, free email needs to have limits, but due to the low cost and potential of earnings, they could implement "mail credits" system, base is like 20 emails a day, but each received email could increase this credit limit. As such, it makes actually sense for free email services to implement this at the very least on the receiving side.
Business mass emailings. A business which has 100k valid e-mails on their database will not have a problem with paying few dozen bucks to have their mass mailing delivered. BUT they will make extra sure the content is good and targeted, something the recipient wants to receive. These will be the biggest spenders on email, apart from spammers.
ISPs, hell they get paid to provide e-mail. And they are on the same spot as free email service providers, they stand to earn more than spend!
Blockchain economics
This is where things might get interesting, there is so much potential.
However, there are several things definitively should not be done:
1 & 2 are easy, just do not mine outside of testnet prior to launch. (If devs get paid by companies, there is conflict of interest as well, but let's not get into that right now)
3: Miners and/or full node maintainers decide what goes on. Probably miners like bitcoin is supposed to.
4: Infinite & preferential supply: No after the launch "contracts" etc. to give coins to preferential parties, it should remain as on the launch unless majority consensus says there will be a change. Proof of stake is gray area imho, but then again also proof of work is the rich gets richer.
Mining: Storage requirement is a blessing in disguise, the massive storages required for this to function means that there will be no central hardware developer who sells all the shovels, without significant other markets. Ie. WD, Seagate, Toshiba the main players.
This means algo needs to be based on the full blockchain being hosted. The hashing needs to be so that GPUs are the king most likely, since almost anything good for CPUs is also doable in GPUs. Eventually someone will likely come with ASIC alternative, but due to masses of data it WILL require high bandwidth, high memory. Nothing like bitcoin currently, where low bandwidth, no memory requirement for the ASIC. There needs to be some expensive commodity components in there (RAM, Storage), and as such GPUs are the most likely candidate, and the bottleneck will not likely be computation, but I/O bandwidth.
Quickly thinking, previous block could include number of blocks to be included on the next for verification, in a highly compressible format. Let's say difficulty is number of blocks to be hashed, or from difficulty you can calculate number of blocks to be included. Previous blocks miner just chooses on random blocks to be included on the next one. Listing 10 series of blocks to be included, which can include series instructions. It could request block #5729375+100, or #357492+500 stepping 5 (every 5th block). Hell the random generator could use last block as seed for the next one to make it deterministic YET random as the emails and TXs change. (WTF, Did i just solve how the algo needs to work?!?) Only blocks which would differentiate is the first few, and obviously Genesis, for which an "empty" block would be what is to be hashed.
Hashing algo could be SHA256 because of the high requirement of streaming data, and most ASIC miners lacking in bandwidth (infact, it could be made compatible with bitcoin, but only those ASICS with higher I/O bandwidth than storage/ram I/O bandwidth is could actually boost the perf)
Different hashable list operations could be (on the block list what to be hashed on the next one): * Single block * Block # + number of blocks * Block # + (number of blocks with stepping) * Block # + number of blocks chosen by random using each hashed block as the seed for choosing next one (makes prefetch, preread, caching not work efficiently) * Number of previous blocks mined (ie. 50 last blocks) * Above but with stepping operator * Above but with choose random next X blocks, with variations based on the last hashed, sum of the hashed * All random pickers would have operation modes for the seed to be used: From hashed sum, the whole block, block contents, block header
These modes would ensure the blocks are there and makes it a lot dependable on variable factors, RAM speed, I/O seek time, I/O bandwidth.
This way we have proof that the miner has access to those blocks in efficient manner and the full blockchain is stored there, even if it is not practically retrievable from him / her over the internet for others to obtain a copy. HOWEVER, due to the data volumes, i think it is given they have fast access, but a miner would probably prefer not to share their blockchain contents to have bandwidth free for their mining, as the deadlines are tight. It could be built into the full node spec that they do not accept new blocks from sources which are not ready to supply any given block, and perhaps even periodic test of this. However, this would be unenforceable if people start running custom coded nodes which disables this, as it is not part of the blockchain calculation. It is not miner's benefit to "waste" precious bandwidth to serve others the vast blockchain, meanwhile it is end users benefit those running full nodes without mining to get them fast. So an equilibrium might be reached, if miners start loosing out because other miners will not share their blocks, they will start offering them, even if prioritized.
At 2MiB blocks, 10 second deadline, a miner would preferentially want the new block within 500ms, which would be barely sufficient time for a round trip across the globe. 500ms for 2MiB is 4MiB/s transfer rate inbound, and when block found you want it out even faster, say 250ms you'll need 8MiB/s burst which very very few have at a home. At more usual 1MiB/s it would take 2secs to submit your new block. On the other hand, if you found the block, you'd have immediate access to begin calcing the next one.
Block verification needs to be fast, and as such the above difficulty setting alone is not sufficient, there needs to be nonce. Just picking the right block is not guarantee there will be match, so traditional !???? nonce needs to be set as well most likely. As such, a lot of maths needs to be done to ensure this algorithm does not have dead ends, yet ensures certain blocks needs to be read as full and stored fully by the miners, just plain hashes of the blocks is not sufficient.
Perhaps it should be block data + nonce, then all the blocks hashes (with nonce, or pre-chosen salt) and to be generated block combined hash with nonce needs to have certain number of zeroes. Needs testing and maths :)
So there are many ways to accomplish proof of storage, we'd need just to figure out the which is the best.
Sidenote, this same algo could potentially be used with different settings for immutable, forever storage of data. Since there is no continuing cost to store data, TX Fee for every message (data) byte should be very high in such a coin.
Supply. Needs to be predictable and easy to understand. It would be preferential the standard mailing out is always 1x MailCoin, albeit coin itself should be practically infinitively divisable, and as such supply needs to be in the trillions eventually. But these things get complicated really fast, so we need to set a schedule.
Current email use is very large, so we should have something in the same magnitude. 8640 blocks per day - so maybe 10 000 coins per block == 86 400 000 new coins per day == 31 536 000 000 new coins per year, halving every 2 years. First halving: 63 072 000 000, Second halving: 94 608 000 000, Third (6 years): 110 376 000 000, but only halving 4 or 5 times to keep some new supply for ever increasing adoption and lost coins.
Got all the way here? :D
Thanks for reading up. Let me know what you think, and let's start a discussion on the feasibility of such a system!
I cannot develop this myself, but i would definitively back an effort up in the ways i can if anyone attempts to do something like this :) And i know i got probably many of the details incorrect
The main point of the methods described above is ease of adoption. Without adoption any system is worthless, and with email, you just cannot replace it like that (see the attempts trying to replace IPv4 with IPv6 ...), but you can enhance it. adoption is very critical in communications systems. (No one would have a phone if no one else had a phone)
Addendum 1: Forgot to add about pricing and markets, read comment here
Addendun 2: Bad actors and voting
submitted by PulsedMedia to Bitcoin [link] [comments]

/u/jl_2012 comments on new extension block BIP - "a block reorg will almost guarantee changing txid of the resolution tx, that will permanently invalidate all the child txs based on the resolution tx"

Comments from jl_2012
I feel particularly disappointed that while this BIP is 80% similar to my proposal made 2 months ago ( ), Matt Corallo was only the person replied me. Also, this BIP seems ignored the txid malleability of the resolution tx, as my major technical critique of xblock design.
But anyway, here I’m only making comments on the design. As I said in my earlier post, I consider this more as an academic topic than something really ready for production use.
This specification defines a method of increasing bitcoin transaction throughput without altering any existing consensus rules.
Softforks by definition tighten consensus rules
There has been great debate regarding other ways of increasing transaction throughput, with no proposed consensus-layer solutions that have proven themselves to be particularly safe.
so the authors don’t consider segwit as a consensus-layer solution to increase transaction throughput, or not think segwit is safe? But logically speaking if segwit is not safe, this BIP could only be worse. OTOH, segwit also obviously increases tx throughput, although it may not be as much as some people wish to have.
This specification refines many of Lau's ideas, and offers a much simpler method of tackling the value transfer issue, which, in Lau's proposal, was solved with consensus-layer UTXO selection.
The 2013 one is outdated. As the authors are not quoting it, not sure if they read my January proposal
extension block activation entails BIP141 activation.
I think extension block in the proposed form actually breaks BIP141. It may say it activates segregated witness as a general idea, but not a specific proposal like BIP141
The merkle root is to be calculated as a merkle tree with all extension block txids and wtxids as the leaves.
It needs to be more specific here. How are they exactly arranged? I suggest it uses a root of all txids, and a root of all wtxids, and combine them as the commitment. The reason is to allow people to prune the witness data, yet still able to serve the pruned tx to light wallets. If it makes txid and wtxid as pairs, after witness pruning it still needs to store all the wtxids or it can’t reconstruct the tree
Outputs signal to exit the extension block if the contained script is either a minimally encoded P2PKH or P2SH script.
This hits the biggest question I asked in my January post: do you want to allow direct exit payment to legacy addresses? As a block reorg will almost guarantee changing txid of the resolution tx, that will permanently invalidate all the child txs based on the resolution tx. This is a significant change to the current tx model. To fix this, you need to make exit outputs unspendable for up to 100 blocks. Doing this, however, will make legacy wallet users very confused as they do not anticipate funding being locked up for a long period of time. So you can’t let the money sent back to a legacy address directly, but sent to a new format address that only recognized by new wallet, which understands the lock up requirement. This way, however, introduces friction and some fungibility issues, and I’d expect people using cross chain atomic swap to exchange bitcoin and xbitcoin
To summarise, my questions are: 1. Is it acceptable to have massive txid malleability and transaction chain invalidation for every natural happening reorg? Yes: the current spec is ok; No: next question (I’d say no) 2. Is locking up exit outputs the best way to deal with the problem? (I tried really hard to find a better solution but failed) 3. How long the lock-up period should be? Answer could be anywhere from 1 to 100 4. With a lock-up period, should it allow direct exit to legacy address? (I think it’s ok if the lock-up is short, like 1-2 block. But is that safe enough?) 5. Due to the fungibility issues, it may need a new name for the tokens in the ext-block
Verification of transactions within the extension block shall enforce all currently deployed softforks, along with an extra BIP141-like ruleset.
I suggest to only allow push-only and OP_RETURN scriptPubKey in xblock. Especially, you don’t want to replicate the sighash bug to xblock. Also, requires scriptSig to be always empty
This leaves room for 7 future soft-fork upgrades to relax DoS limits.
Why 7? There are 16 unused witness program versions
Witness script hash v0 shall be worth the number of accurately counted sigops in the redeem script, multiplied by a factor of 8.
There is a flaw here: witness script with no sigop will be counted as 0 and have a lot free space
every 73 bytes in the serialized witness vector is worth 1 additional point.
so 72 bytes is 1 point or 0 point? Maybe it should just scale everything up by 64 or 128, and make 1 witness byte = 1 point . So it won’t provide any “free space” in the block.
Currently defined witness programs (v0) are each worth 8 points. Unknown witness program outputs are worth 1 point. Any exiting output is always worth 8 points.
I’d suggest to have at least 16 points for each witness v0 output, so it will make it always more expensive to create than spend UTXO. It may even provide extra “discount” if a tx has more input than output. The overall objective is to limit the UTXO growth. The ext block should be mainly for making transactions, not store of value (I’ll explain later)
Dust Threshold
In general I think it’s ok, but I’d suggest a higher threshold like 5000 satoshi. It may also combine the threshold with the output witness version, so unknown version may have a lower or no threshold. Alternatively, it may start with a high threshold and leave a backdoor softfork to reduce it.
It is a double-edged sword. While it is good for us to be able to discard an unused chain, it may create really bad user experience and people may even lose money. For example, people may have opened Lightning channels and they will find it not possible to close the channel. So you need to make sure people are not making time-locked tx for years, and require people to refresh their channel regularly. And have big red warning when the deactivation SF is locked in. Generally, xblock with deactivation should never be used as long-term storage of value.
———— some general comments:
  1. This BIP in current form is not compatible with BIP141. Since most nodes are already upgraded to BIP141, this BIP must not be activated unless BIP141 failed to activate. However, if the community really endorse the idea of ext block, I see no reason why we couldn’t activate BIP141 first (which could be done in 2 weeks), then work together to make ext block possible. Ext block is more complicated than segwit. If it took dozens of developers a whole year to release segwit, I don’t see how ext block could become ready for production with less time and efforts.
  2. Another reason to make this BIP compatible with BIP141 is we also need malleability fix in the main chain. As the xblock has a deactivation mechanism, it can’t be used for longterm value storage.
  3. I think the size and cost limit of the xblock should be lower at the beginning, and increases as we find it works smoothly. It could be a predefined growth curve like BIP103, or a backdoor softfork. With the current design, it leaves a massive space for miners to fill up with non-tx garbage. Also, I’d also like to see a complete SPV fraud-proof solution before the size grows bigger.
submitted by jonny1000 to Bitcoin [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
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
• 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
• 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
• 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
• 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); }
• 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); }
• 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)
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
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)
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
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)
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)
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.
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]

HOW to WITHDRAW on DATDROP (with PayPal, Bitcoin, Ethereum ... Top Up MTI Account before Friday Close of Forex (8 min) Bitcoin transfer takibi ve hızlı gönderim nasıl yapılır? Buy & Exchange Bitcoins BTC Instant  Skrill to Bitcoins Instantly 2019 Without Verifications Bitcoin generator 2019 - 2 btc in 5 munite only 10 dollar fee

Bitcoin Txid Lookup . Apr 8, 2018 DTN Staff. twitter. pinterest. google plus. facebook. Blockexplorer - Bitcoin Cash: How To Check Address Balance / Transactions? - Bitcoin Stack Exchange. Bitcoin Cash: how to check address balance / transactions? BlockExplorer ( ) provides a way to check bitcoin balances. What is the alternative to check for transations in Bitcoin Cash addresses? * Shows only ... Bitcoin Mining Profit Calculator - Free Bitcoin Cloud Mining Platform Bitcoin Mining Profit Calculator Bitcoin Mining A Scam Bitcoin Asset Protection Helping Bitcoin-based businesses integrate scaling technology. ... Outpoint (36) The txid and vout index number of the output (UTXO) being spent. scriptSig length (compactSize) The length of the scriptSig field. 1 vbyte for a scriptSig up to 252 vbytes. Maximum of 3 vbytes for a maximum-length scriptSig (10,000 vbytes). scriptSig (varies) The source of witness data for legacy UTXOs. This data ... Transactions last 24h (Number of transactions in blockchain per day) 100,160: Transactions avg. per hour: 4,173: Litecoins sent last 24h: 2,904,387 LTC ($167,078,995 USD) 4.39% market cap: Litecoins sent avg. per hour (last 24h) Buying crypto like Bitcoin and Ether is as easy as verifying your identity, adding a payment and clicking "Buy". Sign up for our Wallet today. Create Wallet. Trade Crypto at the Exchange. Integrated with the Blockchain Wallet, our Exchange is a one-stop shop where you can deposit funds and place trades seamlessly in minutes. Get Started . Dive Deeper. Buy Crypto. Bitcoin $ USD. Your Email ...

[index] [27797] [4194] [10204] [50952] [14812] [6835] [29438] [6121] [4180] [5344]

HOW to WITHDRAW on DATDROP (with PayPal, Bitcoin, Ethereum ...

This Bitcoin Mining Software can mine with your computer or laptop CPU at least 0.5 bitcoin per day. So if you need bitcoin in your wallet,or just want to earn more money from your home,then this ... In this video i will invest and test this bitcoin mining pool that claims to have a high hash rate possible. and i we will find out if it is really paying or not. i will giveaway 0.10 Bitcoins to ... For example, if you want to exchange Bitcoin to Ethereum, type in the amount of BTC you would like to exchange in the “You send” section and choose “BTC” from the drop-down menu. LINK TO COINBASE: (link gives us both $10, it helps me out a lot) USE CODE: “HAUNTED” FOR A FREE 5% DEPOSIT BONUS ON ... Exchange Skrill to bitcoins instantly Delivery to any bitcoin wallet without any verifications or passports. That’s it! In a few seconds, your Bitcoins & Ethereum will be sent to you.