Effects of Bigger Bitcoin Blocks on Mining Centralization

I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. Help greatly appreciated!

I posted this on /cryptotechnology . It attracted quite a bit of upvotes but not many potential contributors. Someone mentioned I should try this sub. I read the rules and it seems to fit within them. Hope this kind of post is alright here...
EDIT: My mother language is french (I'm from Montreal/Canada). Please excuse any blatant grammatical errors.
TLDR: I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. If you're interested, send me an email to discuss: [email protected] . Thanks in advance!
Hi guys,
For the last few years, I've been working on a decentralized legal-binding contract system. Basically, I created a PoW blockchain software that can receive a hash as an address, and another hash as a bucket, in each transaction.
The address hash is used to tell a specific entity (application/contract/company/person, etc) that uses the blockchain that this transaction might be addressed to them. The bucket hash simply tells the nodes which hashtree of files they need to download in order to execute that contract.
The buckets are shared within the network of nodes. Someone could, for example, write a contract with a series of nodes in order to host their data for them. Buckets can hold any kind of data, and can be of any size... including encrypted data.
The blockchain's blocks are chained together using a mining system similar to bitcoin (hashcash algorithm). Each block contains transactions. The requested difficulty increases when the amount of transactions in a block increases, linearly. Then, when a block is mined properly, another smaller mining effort is requested to link the block to the network's head block.
To replace a block, you need to create another block with more transactions than the amount that were transacted in and after the mined block.
I expect current payment processors to begin accepting transactions and mine them for their customers and make money with fees, in parallel. Using such a mechanism, miners will need to have a lot of bandwidth available in order to keep downloading the blocks of other miners, just like the current payment processors.
The contracts is code written in our custom programming language. Their code is pushed using a transaction, and hosted in buckets. Like you can see, the contract's data are off-chain, only its bucket hash is on-chain. The contract can be used to listen to events that occurs on the blockchain, in any buckets hosted by nodes or on any website that can be crawled and parsed in the contract.
There is also an identity system and a vouching system...which enable the creation of soft-money (promise of future payment in hard money (our cryptocurrency) if a series of events arrive).
The contracts can also be compiled to a legal-binding framework and be potentially be used in court. The contracts currently compile to english and french only.
I also built a browser that contains a 3D viewport, using OpenGL. The browser contains a domain name system (DNS) in form of contracts. Anyone can buy a new domain by creating a transaction with a bucket that contains code to reserve a specific name. When a user request a domain name, it discovers the bucket that is attached to the domain, download that bucket and executes its scripts... which renders in the 3D viewport.
When people interact with an application, the application can create contracts on behalf of the user and send them to the blockchain via a transaction. This enables normal users (non-developers) to interact with others using legal contracts, by using a GUI software.
The hard money (cryptocurrency) is all pre-mined and will be sold to entities (people/company) that want to use the network. The hard money can be re-sold using the contract proposition system, for payment in cash or a bank transfer. The fiat funds will go to my company in order to create services that use this specific network of contracts. The goal is to use the funds to make the network grow and increase its demand in hard money. For now, we plan to create:
A logistic and transportation company
A delivery company
A company that buy and sell real estate options
A company that manage real estate
A software development company
A world-wide fiat money transfer company
A payment processor company
We chose these niche because our team has a lot of experience in these areas: we currently run companies in these fields. These niche also generate a lot of revenue and expenses, making the value of exchanges high. We expect this to drive volume in contracts, soft-money and hard-money exchanges.
We also plan to use the funds to create a venture capital fund that invests in startups that wants to create contracts on our network to execute a specific service in a specific niche.
I'm about to release the software open source very soon and begin executing our commercial activities on the network. Before launching, I'd like to open a discussion with the community regarding the details of how this software works and how it is explained in the whitepaper.
If you'd like to read the whitepaper and open a discussion with me regarding how things work, please send me an email at [email protected] .
If you have any comment, please comment below and Ill try to answer every question. Please note that before peer-reviewing the software and the whitepaper, I'd like to keep the specific details of the software private, but can discuss the general details. A release date will be given once my work has been peer reviewed.
Thanks all in advance!
P.S: This project is not a competition to bitcoin. My goal with this project is to enable companies to write contracts together, easily follow events that are executed in their contracts, understand what to expect from their partnership and what they need to give in order to receive their share of deals... and sell their contracts that they no longer need to other community members.
Bitcoin already has a network of people that uses it. It has its own value. In fact, I plan to create contracts on our network to exchange value from our network for bitcoin and vice-versa. Same for any commodity and currency that currently exits in this world.
submitted by steve-rodrigue to compsci [link] [comments]

[ Bitcoin ] Technical: Taproot: Why Activate?

Topic originally posted in Bitcoin by almkglor [link]
This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given private key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

almkglor your post has been copied because one or more comments in this topic have been removed. This copy will preserve unmoderated topic. If you would like to opt-out, please send a message using [this link].
[deleted comment]
[deleted comment]
[deleted comment]
submitted by anticensor_bot to u/anticensor_bot [link] [comments]

I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. Help greatly appreciated!

I originally posted this on /cryptocurrency. I just thought you guys might be able to help as well so I posted it as well. I didn't link to the original post because the bot here keeps deleting my post, even if I use the np link. Hope that's ok...
EDIT: My mother language is french (I'm from Montreal/Canada). Please excuse any blatant grammatical errors.
TLDR: I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. If you're interested, send me an email to discuss: [[email protected]](mailto:[email protected]) . Thanks in advance!
Hi guys,
For the last few years, I've been working on a decentralized legal-binding contract system. Basically, I created a PoW blockchain software that can receive a hash as an address, and another hash as a bucket, in each transaction.
The address hash is used to tell a specific entity (application/contract/company/person, etc) that uses the blockchain that this transaction might be addressed to them. The bucket hash simply tells the nodes which hashtree of files they need to download in order to execute that contract.
The buckets are shared within the network of nodes. Someone could, for example, write a contract with a series of nodes in order to host their data for them. Buckets can hold any kind of data, and can be of any size... including encrypted data.
The blockchain's blocks are chained together using a mining system similar to bitcoin (hashcash algorithm). Each block contains transactions. The requested difficulty increases when the amount of transactions in a block increases, linearly. Then, when a block is mined properly, another smaller mining effort is requested to link the block to the network's head block.
To replace a block, you need to create another block with more transactions than the amount that were transacted in and after the mined block.
I expect current payment processors to begin accepting transactions and mine them for their customers and make money with fees, in parallel. Using such a mechanism, miners will need to have a lot of bandwidth available in order to keep downloading the blocks of other miners, just like the current payment processors.
The contracts is code written in our custom programming language. Their code is pushed using a transaction, and hosted in buckets. Like you can see, the contract's data are off-chain, only its bucket hash is on-chain. The contract can be used to listen to events that occurs on the blockchain, in any buckets hosted by nodes or on any website that can be crawled and parsed in the contract.
There is also an identity system and a vouching system...which enable the creation of soft-money (promise of future payment in hard money (our cryptocurrency) if a series of events arrive).
The contracts can also be compiled to a legal-binding framework and be potentially be used in court. The contracts currently compile to english and french only.
I also built a browser that contains a 3D viewport, using OpenGL. The browser contains a domain name system (DNS) in form of contracts. Anyone can buy a new domain by creating a transaction with a bucket that contains code to reserve a specific name. When a user request a domain name, it discovers the bucket that is attached to the domain, download that bucket and executes its scripts... which renders in the 3D viewport.
When people interact with an application, the application can create contracts on behalf of the user and send them to the blockchain via a transaction. This enables normal users (non-developers) to interact with others using legal contracts, by using a GUI software.
The hard money (cryptocurrency) is all pre-mined and will be sold to entities (people/company) that want to use the network. The hard money can be re-sold using the contract proposition system, for payment in cash or a bank transfer. The fiat funds will go to my company in order to create services that use this specific network of contracts. The goal is to use the funds to make the network grow and increase its demand in hard money. For now, we plan to create:
  1. A logistic and transportation company
  2. A delivery company
  3. A company that buy and sell real estate options
  4. A company that manage real estate
  5. A software development company
  6. A world-wide fiat money transfer company
  7. A payment processor company
We chose these niche because our team has a lot of experience in these areas: we currently run companies in these fields. These niche also generate a lot of revenue and expenses, making the value of exchanges high. We expect this to drive volume in contracts, soft-money and hard-money.
We also plan to use the funds to create a venture capital fund that invests in startups that wants to create contracts on our network to execute a specific service in a specific niche.
I'm about to release the software open source very soon and begin executing our commercial activities on the network. Before launching, I'd like to open a discussion with the community regarding the details of how this software works and how it is explained in the whitepaper.
If you'd like to read the whitepaper and open a discussion with me regarding how things work, please send me an email at [[email protected]](mailto:[email protected]) .
If you have any comment, please comment below and Ill try to answer every question. Please note that before peer-reviewing the software and the whitepaper, I'd like to keep the specific details of the software private, but can discuss the general details. A release date will be given once my work has been peer reviewed.
Thanks all in advance!
P.S: This project is not a competition to bitcoin. My goal with this project is to enable companies to write contracts together, easily follow events that are executed in their contracts, understand what to expect from their partnership and what they need to give in order to receive their share of deals... and sell their contracts that they no longer need to other community members.
Bitcoin already has a network of people that uses it. It has its own value. In fact, I plan to create contracts on our network to exchange value from our network for bitcoin and vice-versa. Same for any commodity and currency that currently exits in this world.
submitted by steve-rodrigue to CryptoTechnology [link] [comments]

I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. Help greatly appreciated!

EDIT: My mother language is french (I'm from Montreal/Canada). Please excuse any blatant grammatical errors.
TLDR: I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. If you're interested, send me an email to discuss: [[email protected]](mailto:[email protected]) . Thanks in advance!
Hi guys,
For the last few years, I've been working on a decentralized legal-binding contract system. Basically, I created a PoW blockchain software that can receive a hash as an address, and another hash as a bucket, in each transaction.
The address hash is used to tell a specific entity (application/contract/company/person, etc) that uses the blockchain that this transaction might be addressed to them. The bucket hash simply tells the nodes which hashtree of files they need to download in order to execute that contract.
The buckets are shared within the network of nodes. Someone could, for example, write a contract with a series of nodes in order to host their data for them. Buckets can hold any kind of data, and can be of any size... including encrypted data.
The blockchain's blocks are chained together using a mining system similar to bitcoin (hashcash algorithm). Each block contains transactions. The requested difficulty increases when the amount of transactions in a block increases, linearly. Then, when a block is mined properly, another smaller mining effort is requested to link the block to the network's head block.
To replace a block, you need to create another block with more transactions than the amount that were transacted in and after the mined block.
I expect current payment processors to begin accepting transactions and mine them for their customers and make money with fees, in parallel. Using such a mechanism, miners will need to have a lot of bandwidth available in order to keep downloading the blocks of other miners, just like the current payment processors.
The contracts is code written in our custom programming language. Their code is pushed using a transaction, and hosted in buckets. Like you can see, the contract's data are off-chain, only its bucket hash is on-chain. The contract can be used to listen to events that occurs on the blockchain, in any buckets hosted by nodes or on any website that can be crawled and parsed in the contract.
There is also an identity system and a vouching system...which enable the creation of soft-money (promise of future payment in hard money (our cryptocurrency) if a series of events arrive).
The contracts can also be compiled to a legal-binding framework and be potentially be used in court. The contracts currently compile to english and french only.
I also built a browser that contains a 3D viewport, using OpenGL. The browser contains a domain name system (DNS) in form of contracts. Anyone can buy a new domain by creating a transaction with a bucket that contains code to reserve a specific name. When a user request a domain name, it discovers the bucket that is attached to the domain, download that bucket and executes its scripts... which renders in the 3D viewport.
When people interact with an application, the application can create contracts on behalf of the user and send them to the blockchain via a transaction. This enables normal users (non-developers) to interact with others using legal contracts, by using a GUI software.
The hard money (cryptocurrency) is all pre-mined and will be sold to entities (people/company) that want to use the network. The hard money can be re-sold using the contract proposition system, for payment in cash or a bank transfer. The fiat funds will go to my company in order to create services that use this specific network of contracts. The goal is to use the funds to make the network grow and increase its demand in hard money. For now, we plan to create:
  1. A logistic and transportation company
  2. A delivery company
  3. A company that buy and sell real estate options
  4. A company that manage real estate
  5. A software development company
  6. A world-wide fiat money transfer company
  7. A payment processor company
We chose these niche because our team has a lot of experience in these areas: we currently run companies in these fields. These niche also generate a lot of revenue and expenses, making the value of exchanges high. We expect this to drive volume in contracts, soft-money and hard-money.
We also plan to use the funds to create a venture capital fund that invests in startups that wants to create contracts on our network to execute a specific service in a specific niche.
I'm about to release the software open source very soon and begin executing our commercial activities on the network. Before launching, I'd like to open a discussion with the community regarding the details of how this software works and how it is explained in the whitepaper.
If you'd like to read the whitepaper and open a discussion with me regarding how things work, please send me an email at [[email protected]](mailto:[email protected]) .
If you have any comment, please comment below and Ill try to answer every question. Please note that before peer-reviewing the software and the whitepaper, I'd like to keep the specific details of the software private, but can discuss the general details. A release date will be given once my work has been peer reviewed.
Thanks all in advance!
P.S: This project is not a competition to bitcoin. My goal with this project is to enable companies to write contracts together, easily follow events that are executed in their contracts, understand what to expect from their partnership and what they need to give in order to receive their share of deals... and sell their contracts that they no longer need to other community members.
Bitcoin already has a network of people that uses it. It has its own value. In fact, I plan to create contracts on our network to exchange value from our network for bitcoin and vice-versa. Same for any commodity and currency that currently exits in this world.
submitted by steve-rodrigue to CryptoCurrency [link] [comments]

I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. Help greatly appreciated!

I originally posted this on cryptocurrency. I just thought you guys might be able to help as well so I posted it as well. I didn't link to the original post because the bot here keeps deleting my post, even if I use the np link. Hope that's ok...
EDIT: My mother language is french (I'm from Montreal/Canada). Please excuse any blatant grammatical errors.
TLDR: I built a decentralized legal-binding smart contract system. I need peer reviewers and whitepaper proof readers. If you're interested, send me an email to discuss: [[email protected]](mailto:[email protected]) . Thanks in advance!
Hi guys,
For the last few years, I've been working on a decentralized legal-binding contract system. Basically, I created a PoW blockchain software that can receive a hash as an address, and another hash as a bucket, in each transaction.
The address hash is used to tell a specific entity (application/contract/company/person, etc) that uses the blockchain that this transaction might be addressed to them. The bucket hash simply tells the nodes which hashtree of files they need to download in order to execute that contract.
The buckets are shared within the network of nodes. Someone could, for example, write a contract with a series of nodes in order to host their data for them. Buckets can hold any kind of data, and can be of any size... including encrypted data.
The blockchain's blocks are chained together using a mining system similar to bitcoin (hashcash algorithm). Each block contains transactions. The requested difficulty increases when the amount of transactions in a block increases, linearly. Then, when a block is mined properly, another smaller mining effort is requested to link the block to the network's head block.
To replace a block, you need to create another block with more transactions than the amount that were transacted in and after the mined block.
I expect current payment processors to begin accepting transactions and mine them for their customers and make money with fees, in parallel. Using such a mechanism, miners will need to have a lot of bandwidth available in order to keep downloading the blocks of other miners, just like the current payment processors.
The contracts is code written in our custom programming language. Their code is pushed using a transaction, and hosted in buckets. Like you can see, the contract's data are off-chain, only its bucket hash is on-chain. The contract can be used to listen to events that occurs on the blockchain, in any buckets hosted by nodes or on any website that can be crawled and parsed in the contract.
There is also an identity system and a vouching system...which enable the creation of soft-money (promise of future payment in hard money (our cryptocurrency) if a series of events arrive).
The contracts can also be compiled to a legal-binding framework and be potentially be used in court. The contracts currently compile to english and french only.
I also built a browser that contains a 3D viewport, using OpenGL. The browser contains a domain name system (DNS) in form of contracts. Anyone can buy a new domain by creating a transaction with a bucket that contains code to reserve a specific name. When a user request a domain name, it discovers the bucket that is attached to the domain, download that bucket and executes its scripts... which renders in the 3D viewport.
When people interact with an application, the application can create contracts on behalf of the user and send them to the blockchain via a transaction. This enables normal users (non-developers) to interact with others using legal contracts, by using a GUI software.
The hard money (cryptocurrency) is all pre-mined and will be sold to entities (people/company) that want to use the network. The hard money can be re-sold using the contract proposition system, for payment in cash or a bank transfer. The fiat funds will go to my company in order to create services that use this specific network of contracts. The goal is to use the funds to make the network grow and increase its demand in hard money. For now, we plan to create:
  1. A logistic and transportation company
  2. A delivery company
  3. A company that buy and sell real estate options
  4. A company that manage real estate
  5. A software development company
  6. A world-wide fiat money transfer company
  7. A payment processor company
We chose these niche because our team has a lot of experience in these areas: we currently run companies in these fields. These niche also generate a lot of revenue and expenses, making the value of exchanges high. We expect this to drive volume in contracts, soft-money and hard-money.
We also plan to use the funds to create a venture capital fund that invests in startups that wants to create contracts on our network to execute a specific service in a specific niche.
I'm about to release the software open source very soon and begin executing our commercial activities on the network. Before launching, I'd like to open a discussion with the community regarding the details of how this software works and how it is explained in the whitepaper.
If you'd like to read the whitepaper and open a discussion with me regarding how things work, please send me an email at [[email protected]](mailto:[email protected]) .
If you have any comment, please comment below and Ill try to answer every question. Please note that before peer-reviewing the software and the whitepaper, I'd like to keep the specific details of the software private, but can discuss the general details. A release date will be given once my work has been peer reviewed.
Thanks all in advance!
P.S: This project is not a competition to bitcoin. My goal with this project is to enable companies to write contracts together, easily follow events that are executed in their contracts, understand what to expect from their partnership and what they need to give in order to receive their share of deals... and sell their contracts that they no longer need to other community members.
Bitcoin already has a network of people that uses it. It has its own value. In fact, I plan to create contracts on our network to exchange value from our network for bitcoin and vice-versa. Same for any commodity and currency that currently exits in this world.
submitted by steve-rodrigue to cryptodevs [link] [comments]

Polkadot Launch AMA Recap

Polkadot Launch AMA Recap

The Polkadot Telegram AMA below took place on June 10, 2020

https://preview.redd.it/4ti681okap951.png?width=4920&format=png&auto=webp&s=e21f6a9a276d35bb9cdec59f46744f23c37966ef
AMA featured:
Dieter Fishbein, Ecosystem Development Lead, Web3 Foundation
Logan Saether, Technical Education, Web3 Foundation
Will Pankiewicz, Master of Validators, Parity Technologies
Moderated by Dan Reecer, Community and Growth, Polkadot & Kusama at Web3 Foundation

Transcription compiled by Theresa Boettger, Polkadot Ambassador:

Dieter Fishbein, Ecosystem Development Lead, Web3 Foundation

Dan: Hey everyone, thanks for joining us for the Polkadot Launch AMA. We have Dieter Fishbein (Head of Ecosystem Development, our business development team), Logan Saether (Technical Education), and Will Pankiewicz (Master of Validators) joining us today.
We had some great questions submitted in advance, and we’ll start by answering those and learning a bit about each of our guests. After we go through the pre-submitted questions, then we’ll open up the chat to live Q&A and the hosts will answer as many questions as they can.
We’ll start off with Dieter and ask him a set of some business-related questions.

Dieter could you introduce yourself, your background, and your role within the Polkadot ecosystem?

Dieter: I got my start in the space as a cryptography researcher at the University of Waterloo. This is where I first learned about Bitcoin and started following the space. I spent the next four years or so on the investment team for a large asset manager where I primarily focused on emerging markets. In 2017 I decided to take the plunge and join the space full-time. I worked at a small blockchain-focused VC fund and then joined the Polkadot team just over a year ago. My role at Polkadot is mainly focused on ensuring there is a vibrant community of projects building on our technology.

Q: Adoption of Polkadot of the important factors that all projects need to focus on to become more attractive to the industry. So, what is Polkadot's plan to gain more Adoption? [sic]

A (Dieter): Polkadot is fundamentally a developer-focused product so much of our adoption strategy is focused around making Polkadot an attractive product for developers. This has many elements. Right now the path for most developers to build on Polkadot is by creating a blockchain using the Substrate framework which they will later connect to Polkadot when parachains are enabled. This means that much of our adoption strategy comes down to making Substrate an attractive tool and framework. However, it’s not just enough to make building on Substrate attractive, we must also provide an incentive to these developers to actually connect their Substrate-based chain to Polkadot. Part of this incentive is the security that the Polkadot relay chain provides but another key incentive is becoming interoperable with a rich ecosystem of other projects that connect to Polkadot. This means that a key part of our adoption strategy is outreach focused. We go out there and try to convince the best projects in the space that building on our technology will provide them with significant value-add. This is not a purely technical argument. We provide significant support to projects building in our ecosystem through grants, technical support, incubatoaccelerator programs and other structured support programs such as the Substrate Builders Program (https://www.substrate.io/builders-program). I do think we really stand out in the significant, continued support that we provide to builders in our ecosystem. You can also take a look at the over 100 Grants that we’ve given from the Web3 Foundation: https://medium.com/web3foundation/web3-foundation-grants-program-reaches-100-projects-milestone-8fd2a775fd6b

Q: On moving forward through your roadmap, what are your most important next priorities? Does the Polkadot team have enough fundamentals (Funds, Community, etc.) to achieve those milestones?

A (Dieter): I would say the top priority by far is to ensure a smooth roll-out of key Polkadot features such as parachains, XCMP and other key parts of the protocol. Our recent Proof of Authority network launch was only just the beginning, it’s crucial that we carefully and successfully deploy features that allow builders to build meaningful technology. Second to that, we want to promote adoption by making more teams aware of Polkadot and how they can leverage it to build their product. Part of this comes down to the outreach that I discussed before but a major part of it is much more community-driven and many members of the team focus on this.
We are also blessed to have an awesome community to make this process easier 🙂

Q: Where can a list of Polkadot's application-specific chains can be found?

A (Dieter): The best list right now is http://www.polkaproject.com/. This is a community-led effort and the team behind it has done a terrific job. We’re also working on providing our own resource for this and we’ll share that with the community when it’s ready.

Q: Could you explain the differences and similarities between Kusama and Polkadot?

A (Dieter): Kusama is fundamentally a less robust, faster-moving version of Polkadot with less economic backing by validators. It is less robust since we will be deploying new technology to Kusama before Polkadot so it may break more frequently. It has less economic backing than Polkadot, so a network takeover is easier on Kusama than on Polkadot, lending itself more to use cases without the need for bank-like security.
In exchange for lower security and robustness, we expect the cost of a parachain lease to be lower on Kusama than Polkadot. Polkadot will always be 100% focused on security and robustness and I expect that applications that deal with high-value transactions such as those in the DeFi space will always want a Polkadot deployment, I think there will be a market for applications that are willing to trade cheap, high throughput for lower security and robustness such as those in the gaming, content distribution or social networking sectors. Check out - https://polkadot.network/kusama-polkadot-comparing-the-cousins/ for more detailed info!

Q: and for what reasons would a developer choose one over the other?

A (Dieter): Firstly, I see some earlier stage teams who are still iterating on their technology choosing to deploy to Kusama exclusively because of its lower-stakes, faster moving environment where it will be easier for them to iterate on their technology and build their user base. These will likely encompass the above sectors I identified earlier. To these teams, Polkadot becomes an eventual upgrade path for them if, and when, they are able to perfect their product, build a larger community of users and start to need the increased stability and security that Polkadot will provide.
Secondly, I suspect many teams who have their main deployment on Polkadot will also have an additional deployment on Kusama to allow them to test new features, either their tech or changes to the network, before these are deployed to Polkadot mainnet.

Logan Saether, Technical Education, Web3 Foundation

Q: Sweet, let's move over to Logan. Logan - could you introduce yourself, your background, and your role within the Polkadot ecosystem?

A (Logan): My initial involvement in the industry was as a smart contract engineer. During this time I worked on a few projects, including a reboot of the Ethereum Alarm Clock project originally by Piper Merriam. However, I had some frustrations at the time with the limitations of the EVM environment and began to look at other tools which could help me build the projects that I envisioned. This led to me looking at Substrate and completing a bounty for Web3 Foundation, after which I applied and joined the Technical Education team. My responsibilities at the Technical Education team include maintaining the Polkadot Wiki as a source of truth on the Polkadot ecosystem, creating example applications, writing technical documentation, giving talks and workshops, as well as helping initiatives such as the Thousand Validator Programme.

Q: The first technical question submitted for you was: "When will an official Polkadot mobile wallet appear?"

A (Logan): There is already an “official” wallet from Parity Technologies called the Parity Signer. Parity Signer allows you to keep your private keys on an air-gapped mobile device and to interactively sign messages using web interfaces such as Polkadot JS Apps. If you’re looking for something that is more of an interface to the blockchain as well as a wallet, you might be interested in PolkaWallet which is a community team that is building a full mobile interface for Polkadot.
For more information on Parity Signer check out the website: https://www.parity.io/signe

Q: Great thanks...our next question is: If someone already developed an application to run on Ethereum, but wants the interoperability that Polkadot will offer, are there any advantages to rebuilding with Substrate to run as a parachain on the Polkadot network instead of just keeping it on Ethereum and using the Ethereum bridge for use with Polkadot?

A (Logan): Yes, the advantage you would get from building on Substrate is more control over how your application will interact with the greater Polkadot ecosystem, as well as a larger design canvas for future iterations of your application.
Using an Ethereum bridge will probably have more cross chain latency than using a Polkadot parachain directly. The reason for this is due to the nature of Ethereum’s separate consensus protocol from Polkadot. For parachains, messages can be sent to be included in the next block with guarantees that they will be delivered. On bridged chains, your application will need to go through more routes in order to execute on the desired destination. It must first route from your application on Ethereum to the Ethereum bridge parachain, and afterward dispatch the XCMP message from the Polkadot side of the parachain. In other words, an application on Ethereum would first need to cross the bridge then send a message, while an application as a parachain would only need to send the message without needing to route across an external bridge.

Q: DOT transfers won't go live until Web3 removes the Sudo module and token holders approve the proposal to unlock them. But when will staking rewards start to be distributed? Will it have to after token transfers unlock? Or will accounts be able to accumulate rewards (still locked) once the network transitions to NPoS?

A (Logan): Staking rewards will be distributed starting with the transition to NPoS. Transfers will still be locked during the beginning of this phase, but reward payments are technically different from the normal transfer mechanism. You can read more about the launch process and steps at http://polkadot.network/launch-roadmap

Q: Next question is: I'm interested in how Cumulus/parachain development is going. ETA for when we will see the first parachain registered working on Kusama or some other public testnet like Westend maybe?

A (Logan): Parachains and Cumulus is a current high priority development objective of the Parity team. There have already been PoC parachains running with Cumulus on local testnets for months. The current work now is making the availability and validity subprotocols production ready in the Polkadot client. The best way to stay up to date would be to follow the project boards on GitHub that have delineated all of the tasks that should be done. Ideally, we can start seeing parachains on Westend soon with the first real parachains being deployed on Kusama thereafter.
The projects board can be viewed here: https://github.com/paritytech/polkadot/projects
Dan: Also...check out Basti's tweet from yesterday on the Cumulus topic: https://twitter.com/bkchstatus/1270479898696695808?s=20

Q: In what ways does Polkadot support smart contracts?

A (Logan): The philosophy behind the Polkadot Relay Chain is to be as minimal as possible, but allow arbitrary logic at the edges in the parachains. For this reason, Polkadot does not support smart contracts natively on the Relay Chain. However, it will support smart contracts on parachains. There are already a couple major initiatives out there. One initiative is to allow EVM contracts to be deployed on parachains, this includes the Substrate EVM module, Parity’s Frontier, and projects such as Moonbeam. Another initiative is to create a completely new smart contract stack that is native to Substrate. This includes the Substrate Contracts pallet, and the ink! DSL for writing smart contracts.
Learn more about Substrate's compatibility layer with Ethereum smart contracts here: https://github.com/paritytech/frontier

Will Pankiewicz, Master of Validators, Parity Technologies


Q: (Dan) Thanks for all the answers. Now we’ll start going through some staking questions with Will related to validating and nominating on Polkadot. Will - could you introduce yourself, your background, and your role within the Polkadot ecosystem?

A (Will): Sure thing. Like many others, Bitcoin drew me in back in 2013, but it wasn't until Ethereum came that I took the deep dive into working in the space full time. It was the financial infrastructure aspects of cryptocurrencies I was initially interested in, and first worked on dexes, algorithmic trading, and crypto funds. I really liked the idea of "Generalized Mining" that CoinFund came up with, and started to explore the whacky ways the crypto funds and others can both support ecosystems and be self-sustaining at the same time. This drew me to a lot of interesting experiments in what later became DeFi, as well as running validators on Proof of Stake networks. My role in the Polkadot ecosystem as “Master of Validators” is ensuring the needs of our validator community get met.

Q: Cool thanks. Our first community question was "Is it still more profitable to nominate the validators with lesser stake?"

A (Will): It depends on their commission, but generally yes it is more profitable to nominate validators with lesser stake. When validators have lesser stake, when you nominate them this makes your nomination stake a higher percentage of total stake. This means when rewards get distributed, it will be split more favorably toward you, as rewards are split by total stake percentage. Our entire rewards scheme is that every era (6 hours in Kusama, 24 hours in Polkadot), a certain amount of rewards get distributed, where that amount of rewards is dependent on the total amount of tokens staked for the entire network (50% of all tokens staked is currently optimal). These rewards from the end of an era get distributed roughly equally to all validators active in the validator set. The reward given to each validator is then split between the validators and all their nominators, determined by the total stake that each entity contributes. So if you contribute to a higher percentage of the total stake, you will earn more rewards.

Q: What does priority ranking under nominator addresses mean? For example, what does it mean that nominator A has priority 1 and nominator B has priority 6?

A (Will): Priority ranking is just the index of the nomination that gets stored on chain. It has no effect on how stake gets distributed in Phragmen or how rewards get calculated. This is only the order that the nominator chose their validators. The way that stake from a nominator gets distributed from a nominator to validators is via Phragmen, which is an algorithm that will optimally put stake behind validators so that distribution is roughly equal to those that will get in the validator set. It will try to maximize the total amount at stake in the network and maximize the stake behind minimally staked validators.

Q: On Polkadot.js, what does it mean when there are nodes waiting on Polkadot?

**A (Will):**In Polkadot there is a fixed validator set size that is determined by governance. The way validators get in the active set is by having the highest amount of total stake relative to other validators. So if the validator set size is 100, the top 100 validators by total stake will be in the validator set. Those not active in the validator set will be considered “waiting”.

Q: Another question...Is it necessary to become a waiting validator node right now?

A (Will): It's not necessary, but highly encouraged if you actively want to validate on Polkadot. The longer you are in the waiting tab, the longer you get exposure to nominators that may nominate you.

Q: Will current validators for Kusama also validate for Polkadot? How strongly should I consider their history (with Kusama) when looking to nominate a good validator for DOTs?

A (Will): A lot of Kusama validators will also be validators for Polkadot, as KSM was initially distributed to DOT holders. The early Kusama Validators will also likely be the first Polkadot validators. Being a Kusama validator should be a strong indicator for who to nominate on Polkadot, as the chaos that has ensued with Kusama has allowed validators to battle test their infrastructure. Kusama validators by now are very familiar with tooling, block explorers, terminology, common errors, log formats, upgrades, backups, and other aspects of node operation. This gives them an edge against Polkadot validators that may be new to the ecosystem. You should strongly consider well known Kusama validators when making your choices as a nominator on Polkadot.

Q: Can you go into more details about the process for becoming a DOT validator? Is it similar as the KSM 1000 validators program?

A (Will): The Process for becoming a DOT validators is first to have DOTs. You cannot be a validator without DOTs, as DOTs are used to pay transaction fees, and the minimum amount of DOTs you need is enough to create a validate transaction. After obtaining enough DOTs, you will need to set up your validator infrastructure. Ideally you should have a validator node with specs that match what we call standard hardware, as well as one or more sentry nodes to help isolate the validator node from attacks. After the infrastructure is up and running, you should have your Polkadot accounts set up right with a stash bonded to a controller account, and then submit a validate transaction, which will tell the network your nodes are ready to be a part of the network. You should then try and build a community around your validator to let others know you are trustworthy so that they will nominate you. The 1000 validators programme for Kusama is a programme that gives a certain amount of nominations from the Web3 Foundation and Parity to help bootstrap a community and reputation for validators. There may eventually be a similar type of programme for Polkadot as well.
Dan: Thanks a lot for all the answers, Will. That’s the end of the pre-submitted questions and now we’ll open the chat up to live Q&A, and our three team members will get through as many of your questions as possible.
We will take questions related to business development, technology, validating, and staking. For those wondering about DOT:
DOT tokens do not exist yet. Allocations of Polkadot's native DOT token are technically and legally non-transferable. Hence any publicized sale of DOTs is unsanctioned by Web3 Foundation and possibly fraudulent. Any official public sale of DOTs will be announced on the Web3 Foundation website. Polkadot’s launch process started in May and full network decentralization later this year, holders of DOT allocations will determine issuance and transferability. For those who participated in previous DOT sales, you can learn how to claim your DOTs here (https://wiki.polkadot.network/docs/en/claims).


Telegram Community Follow-up Questions Addressed Below


Q: Polkadot looks good but it confuses me that there are so many other Blockchain projects. What should I pay attention in Polkadot to give it the importance it deserves? What are your planning to achieve with your project?

A (Will): Personally, what I think differentiates it is the governance process. Coordinating forkless upgrades and social coordination helps stand it apart.
A (Dieter): The wiki is awesome - https://wiki.polkadot.network/

Q: Over 10,000 ETH paid as a transaction fee , what if this happens on Polkadot? Is it possible we can go through governance to return it to the owner?

A: Anything is possible with governance including transaction reversals, if a network quorum is reached on a topic.
A (Logan): Polkadot transaction fees work differently than the fees on Ethereum so it's a bit more difficult to shoot yourself in the foot as the whale who sent this unfortunate transaction. See here for details on fees: https://w3f-research.readthedocs.io/en/latest/polkadot/Token%20Economics.html?highlight=transaction%20fees#relay-chain-transaction-fees-and-per-block-transaction-limits
However, there is a tip that the user can input themselves which they could accidentally set to a large amount. In this cases, yes, they could proposition governance to reduce the amount that was paid in the tip.

Q: What is the minimum ideal amount of DOT and KSM to have if you want to become a validator and how much technical knowledge do you need aside from following the docs?

A (Will): It depends on what the other validators in the ecosystem are staking as well as the validator set size. You just need to be in the top staking amount of the validator set size. So if its 100 validators, you need to be in the top 100 validators by stake.

Q: Will Web3 nominate validators? If yes, which criteria to be elected?

A (Will): Web 3 Foundation is running programs like the 1000 validators programme for Kusama. There's a possibility this will continue on for Polkadot as well after transfers are enabled. https://thousand-validators.kusama.network/#/
You will need to be an active validator to earn rewards. Only those active in the validator set earn rewards. I would recommend checking out parts of the wiki: https://wiki.polkadot.network/docs/en/maintain-guides-validator-payout

Q: Is it possible to implement hastables or dag with substrate?

A (Logan): Yes.

Q: Polkadot project looks very futuristic! But, could you tell us the main role of DOT Tokens in the Polkadot Ecosystem?

A (Dan): That's a good question. The short answer is Staking, Governance, Bonding. More here: http://polkadot.network/dot-token

Q: How did you manage to prove that the consensus protocol is safe and unbreakable mathematically?

A (Dieter): We have a research teams of over a dozen scientists with PhDs and post-docs in cryptography and distributed computing who do thorough theoretical analyses on all the protocols used in Polkadot

Q: What are the prospects for NFT?

A: Already being built 🙂

Q: What will be Polkadot next roadmap for 2020 ?

A (Dieter): Building. But seriously - we will continue to add many more features and upgrades to Polkadot as well as continue to strongly focus on adoption from other builders in the ecosystem 🙂
A (Will): https://polkadot.network/launch-roadmap/
This is the launch roadmap. Ideally adding parachains and xcmp towards the end of the year

Q: How Do you stay active in terms of marketing developments during this PANDEMIC? Because I'm sure you're very excited to promote more after this settles down.

A (Dan): The main impact of covid was the impact on in-person events. We have been very active on Crowdcast for webinars since 2019, so it was quite the smooth transition to all-online events. You can see our 40+ past event recordings and follow us on Crowdcast here: https://www.crowdcast.io/polkadot. If you're interested in following our emails for updates (including online events), subscribe here: https://info.polkadot.network/subscribe

Q: Hi, who do you think is your biggest competitor in the space?

A (Dan): Polkadot is a metaprotocol that hasn't been seen in the industry up until this point. We hope to elevate the industry by providing interoperability between all major public networks as well as private blockchains.

Q: Is Polkadot a friend or competitor of Ethereum?

A: Polkadot aims to elevate the whole blockchain space with serious advancements in interoperability, governance and beyond :)

Q: When will there be hardware wallet support?

A (Will): Parity Signer works well for now. Other hardware wallets will be added pretty soon

Q: What are the attractive feature of DOT project that can attract any new users ?

A: https://polkadot.network/what-is-polkadot-a-brief-introduction/
A (Will): Buidling parachains with cross chain messaging + bridges to other chains I think will be a very appealing feature for developers

Q: According to you how much time will it take for Polkadot to get into mainstream adoption and execute all the plans set for this project?

A: We are solving many problems that have held back the blockchain industry up until now. Here is a summary in basic terms:
https://preview.redd.it/ls7i0bpm8p951.png?width=752&format=png&auto=webp&s=a8eb7bf26eac964f6b9056aa91924685ff359536

Q: When will bitpie or imtoken support DOT?

A: We are working on integrations on all the biggest and best wallet providers. ;)

Q: What event/call can we track to catch a switch to nPOS? Is it only force_new_era call? Thanks.

A (Will): If you're on riot, useful channels to follow for updates like this are #polkabot:matrix.org and #polkadot-announcements:matrix.parity.io
A (Logan): Yes this is the trigger for initiating the switch to NPoS. You can also poll the ForceEra storage for when it changes to ForceNew.

Q: What strategy will the Polkadot Team use to make new users trust its platform and be part of it?

A (Will): Pushing bleeding edge cryptography from web 3 foundation research
A (Dan): https://t.me/PolkadotOfficial/43378

Q: What technology stands behind and What are its advantages?

A (Dieter): Check out https://polkadot.network/technology/ for more info on our tech stack!

Q: What problems do you see occurring in the blockchain industry nowadays and how does your project aims to solve these problems?

A (Will): Governance I see as a huge problem. For example upgrading Bitcoin and making decisions for changing things is a very challenging process. We have robust systems of on-chain governance to help solve these coordination problems

Q: How involved are the Polkadot partners? Are they helping with the development?

A (Dieter): There are a variety of groups building in the Polkadot ecosystem. Check out http://www.polkaproject.com/ for a great list.

Q: Can you explain the role of the treasury in Polkadot?

A (Will): The treasury is for projects or people that want to build things, but don't want to go through the formal legal process of raising funds from VCs or grants or what have you. You can get paid by the community to build projects for the community.
A: There’s a whole section on the wiki about the treasury and how it functions here https://wiki.polkadot.network/docs/en/mirror-learn-treasury#docsNav

Q: Any plan to introduce Polkadot on Asia, or rising market on Asia?

**A (Will):**We're globally focused

Q: What kind of impact do you expect from the Council? Although it would be elected by token holders, what kind of people you wish to see there?

A (Will): Community focused individuals like u/jam10o that want to see cool things get built and cool communities form

If you have further questions, please ask in the official Polkadot Telegram channel.
submitted by dzr9127 to dot [link] [comments]

CYPHERIUM ENHACES BLOCKCHAIN TECHNOLOGY

OVERVIEW
Rarely has any technology such as blockchain attracted the public and media organisations. Institutions designed to catalyze the fourth industrial revolution are experimenting with technology, and investors have invested hundreds of millions of dollars in blockchain companies. This is a low-risk, experimental environment with error protection. Innovation is a combination of creativity and implementation. Ideas often must go through an evolutionary or cyclical phase before they are ready for commercialization. In fact, the cycle is so long that it is too expensive, inefficient in terms of time and money to generate and generate ideas, and in most cases almost never reaches commercial value. Thus, almost 99% of venture capital firms fail.
A fast growing technology that has come to enhance the blockchain technology is CYPHERIUM.

CHALLENGES FACING THE BLOCKCHAIN TECHNOLOGY
The Bitcoin framework is one of the most notable usage of blockchain innovations in circulated exchange based frameworks. In Bitcoin, each system hub seeks the benefit of putting away a lot of at least one exchanges in another square of the blockchain by comprehending a complex computational math issue, here and there alluded to as a mining verification of-work (POW). Under current conditions, a lot of exchanges is ordinarily put away in another square of the Bitcoin blockchain at a pace of around one new square like clockwork, and each square has an inexact size of one megabyte (MB). As needs be, the Bitcoin framework is dependent upon a looming versatility issue: as it were 3 to 7 exchanges can be handled every second, which is far underneath the quantity of exchanges handled in other exchange based frameworks, for example, the roughly 30,000 exchanges for each second in the Visa™ exchange framework. The most huge disadvantage of the Nakamoto accord is its absence of irrevocability. Conclusion implies once an exchange or an activity is performed on the blockchain, it is for all time recorded on the blockchain and difficult to turn around. This is fundamental to the wellbeing of money related repayment frameworks as exchanges must not be saved once they are made. For Bitcoin's situation, noxious on-screen characters can alter the exchange history given enough hash power, causing a twofold spending assault, given that there is sufficient motivator and money related practicality to complete such assaults. Given that mining gear leasing and botnets are at present predominant around the world, such an assault has become achievable.
Because of this absence of conclusiveness, Nakamoto accord must depend on additional measures, for example, confirmation of-work to forestall pernicious exercises. This hinders the capacity ofNakamoto accord to scale in light of the fact that a exchange must hang tight for various affirmations before coming to "probabilistic absolution".
In this way, wellbeing isn't ensured by Nakamoto agreement, and so as to secure the system, each exchange must experience extra an ideal opportunity to process. For Bitcoin's situation, an exchange isn't considered last until in any event six affirmations. Since Bitcoin can just process a couple of exchanges every second, the exchange cost is preposterously high, making it unreasonable for little installments like shopping for food or eatery feasting. This extraordinarily frustrates Bitcoin's utilization as an installment strategy in this present reality.

CYPHERIUM SOLUTIONS
Cypherium's exclusive algorithm, CypherBFT conquers burdens of the earlier craftsmanship by giving a circulated exchange framework including a gathering of validator hubs that are known to each other in a system however are undefined to the next system hubs in the system. As utilized thus, the gathering of validator hubs might be alluded to as a "Board of trustees" of validator hubs. In a few explanations, the framework reconfigures at least one validator hubs in the Committee dependent on the consequences of confirmation of-work (POW) challenges. As per some uncovered epitomes, a system hub that isn't as of now a validator hub in the Committee might be added to the Committee on the off chance that it effectively finishes a POW challenge. In such an occasion, the system hub may turn into another validator hub in the Committee, supplanting a current validator hub. In elective epitomes, a system hub may become another validator hub in the Committee dependent on a proof-of-stake (POS) accord. In yet another epitome, a system hub may turn into another validator hub in the Committee dependent on a verification of-authority (POA) agreement. In other elective exemplifications, a system hub may turn into a new validator hub in the Committee dependent on a mix of any of POW, POA, and POS accord.

In some revealed exemplifications, the new validator hub replaces a validator hub in the Committee. The substitution might be founded on a foreordained guideline known by all the hubs in the system. For model, the new validator hub may supplant the most established validator hub in the Committee. As indicated by another model, the new validator hub may supplant a validator hub that has been resolved to have gone disconnected, become bargained (e.g., hacked), fizzled (e.g., because of equipment breakdown), or in any case is inaccessible or not, at this point trusted. In the praiseworthy exemplifications, the circulated framework expect that for an adaptation to non-critical failure of f hubs, the Committee incorporates at any rate 3f +1 validator hubs.
Since the validator hubs in the Committee might be every now and again supplanted, for instance, contingent upon the measure of time required to finish the POW challenges, it is hard for vindictive outsiders to identify the total arrangement of validator hubs in the Committee at some random time.

BENEFITS OF CYPHERIUM BLOCKCHAIN TECHNOLOGY
Cypherium runs its exclusive CypherBFT accord, tied down by the HotStuff calculation, and can genuinely offer moment irrevocability for its system clients. With its HotStuff-based structure, the CypherBFT's runtime keeps going just 20-30 milliseconds (ms). A few affirmations are all that is required to for all time acknowledge a proposed obstruct into the blockchain, and it just takes 90ms for these affirmations to come to pass, making the procedure essentially quicker than the two-minutes required by EOS.
Cypherium's CypherBFT, which additionally uses HotStuff, doesn't have to pick between responsiveness and linearity. Cypherium's double blockchain structure incorporates the velocities of a dag, however its review for clients can occur a lot more straightforward and quicker, which adds to the accessibility of data and makes the data more decentralized.
As per some revealed epitomes, the validator hubs in the Committee may get exchange demands from other system hubs, for instance, in a P2P organize. The Committee may incorporate at any rate one validator hub that fills in as a "Pioneer" validator hub; the other validator hubs might be alluded to as "Partner" validator hubs. The Leader hub might be changed occasionally, on request, or inconsistently by the individuals from the Committee. At the point when any validator hub gets another exchange demand from a non-validator hub in the system, the exchange solicitation might be sent to the entirety of the validator hubs in the Committee. Further to the unveiled epitomes, the Pioneer hub facilitates with the other Associate validator hubs to arrive at an accord of an attitude (e.g., acknowledge or dismiss) for an exchange square containing the exchange solicitation and communicates the accord to the whole P2P arrange. In the event that the accord is to acknowledge or in any case approve the exchange demand, the mentioned exchange might be included another square of a blockchain that is known to in any event a portion of the system hubs in the system.
In conclusion, CYPHERIUM'S distributed smart-contracts block-chain is ideal for a good number of use cases which include (but not limited to):
Finance
Messaging
Voting
Notarization
Digital Agreements (Contracts)
Secure data storage
A.I (Artificial Intelligence)
IoT (Internet of Things
To know more about CYPHERIUM kindly visit the following links:
WEBSITE: https://cypherium.io/
GITHUB: https://github.com/cypherium
WHITEPAPER: https://github.com/cypherium/patent/blob/maste15224.0003%20-%20FINAL%20Draft%20Application%20(originally%200003%20invention%201)%20single%20chain%20in%20pipeline.pdf
TELEGRAM: https://t.me/cypherium_supergroup
TWITTER: http://twitter.com/cypheriumchain
FACEBOOK: https://www.facebook.com/CypheriumChain/
AUTHOR: Nwali Jennifer
submitted by iphygurl to BlockchainStartups [link] [comments]

What Is The Dark Web? How Can You Access It? What Will You Find?

What Is The Dark Web? How Can You Access It? What Will You Find?

Dark Net Hacker
DarkNetHacker.net
What is the dark web? How to access it and what you'll find
The dark web is part of the internet that isn't visible to search engines and requires the use of an anonymizing browser called Tor to be accessed.
Dark web definition
The dark web is a part of the internet that isn't indexed by search engines. You've no doubt heard talk of the “dark web” as a hotbed of criminal activity — and it is. Researchers Daniel Moore and Thomas Rid of King's College in London classified the contents of 2,723 live dark web sites over a five-week period in 2015 and found that 57% host illicit material.

A 2019 study, Into the Web of Profit, conducted by Dr. Michael McGuires at the University of Surrey, shows that things have become worse. The number of dark web listings that could harm an enterprise has risen by 20% since 2016. Of all listings (excluding those selling drugs), 60% could potentially harm enterprises.

You can buy credit card numbers, all manner of drugs, guns, counterfeit money, stolen subscription credentials, hacked Netflix accounts and software that helps you break into other people’s computers. Buy login credentials to a $50,000 Bank of America account for $500. Get $3,000 in counterfeit $20 bills for $600. Buy seven prepaid debit cards, each with a $2,500 balance, for $500 (express shipping included). A “lifetime” Netflix premium account goes for $6. You can hire hackers to attack computers for you. You can buy usernames and passwords.

But not everything is illegal, the dark web also has a legitimate side. For example, you can join a chess club or BlackBook, a social network described as the “the Facebook of Tor.”


Note: This post contains links to dark web sites that can only be accessed with the Tor browser, which can be downloaded for free at https://www.torproject.org.

Deep web vs. dark web: What’s the difference?
The terms “deep web” and “dark web” are sometimes used interchangeably, but they are not the same. Deep web refers to anything on the internet that is not indexed by and, therefore, accessible via a search engine like Google. Deep web content includes anything behind a paywall or requires sign-in credentials. It also includes any content that its owners have blocked web crawlers from indexing.

Medical records, fee-based content, membership websites, and confidential corporate web pages are just a few examples of what makes up the deep web. Estimates place the size of the deep web at between 96% and 99% of the internet. Only a tiny portion of the internet is accessible through a standard web browser—generally known as the “clear web”.

RECOMMENDED WHITEPAPERS
2020 Modern Backup Buyers’ Guide

Business continuity for remote workers

10 Reasons Why 15,000+ Businesses Point DNS to Cisco Umbrella

The dark web is a subset of the deep web that is intentionally hidden, requiring a specific browser—Tor—to access, as explained below. No one really knows the size of the dark web, but most estimates put it at around 5% of the total internet. Again, not all the dark web is used for illicit purposes despite its ominous-sounding name.


Dark web tools and services that present enterprise risk
The Into the Web of Profit report identified 12 categories of tools or services that could present a risk in the form of a network breach or data compromise:

Infection or attacks, including malware, distributed denial of service (DDoS) and botnets
Access, including remote access Trojans (RATs), keyloggers and exploits
Espionage, including services, customization and targeting
Support services such as tutorials
Credentials
Phishing
Refunds
Customer data
Operational data
Financial data
Intellectual property/trade secrets
Other emerging threats
The report also outlined three risk variables for each category:

Devaluing the enterprise, which could include undermining brand trust, reputational damage or losing ground to a competitor
Disrupting the enterprise, which could include DDoS attacks or other malware that affects business operations
Defrauding the enterprise, which could include IP theft or espionage that impairs a company's ability to compete or causes a direct financial loss
Dark web browser
All this activity, this vision of a bustling marketplace, might make you think that navigating the dark web is easy. It isn’t. The place is as messy and chaotic as you would expect when everyone is anonymous, and a substantial minority are out to scam others.

Accessing the dark web requires the use of an anonymizing browser called Tor. The Tor browser routes your web page requests through a series of proxy servers operated by thousands of volunteers around the globe, rendering your IP address unidentifiable and untraceable. Tor works like magic, but the result is an experience that’s like the dark web itself: unpredictable, unreliable and maddeningly slow.

[ Is your data being sold? What you need to know about monitoring the dark web. | Get the latest from CSO by signing up for our newsletters. ]

Still, for those willing to put up with the inconvenience, the dark web provides a memorable glimpse at the seamy underbelly of the human experience – without the risk of skulking around in a dark alley.

Dark web search engine
Dark web search engines exist, but even the best are challenged to keep up with the constantly shifting landscape. The experience is reminiscent of searching the web in the late 1990s. Even one of the best search engines, called Grams, returns results that are repetitive and often irrelevant to the query. Link lists like The Hidden Wiki are another option, but even indices also return a frustrating number of timed-out connections and 404 errors.

Dark web sites
Dark web sites look pretty much like any other site, but there are important differences. One is the naming structure. Instead of ending in .com or .co, dark web sites end in .onion. That’s “a special-use top level domain suffix designating an anonymous hidden service reachable via the Tor network,” according to Wikipedia. Browsers with the appropriate proxy can reach these sites, but others can’t.

Dark web sites also use a scrambled naming structure that creates URLs that are often impossible to remember. For example, a popular commerce site called Dream Market goes by the unintelligible address of “eajwlvm3z2lcca76.onion.”

Many dark websites are set up by scammers, who constantly move around to avoid the wrath of their victims. Even commerce sites that may have existed for a year or more can suddenly disappear if the owners decide to cash in and flee with the escrow money they’re holding on behalf of customers.

Law enforcement officials are getting better at finding and prosecuting owners of sites that sell illicit goods and services. In the summer of 2017, a team of cyber cops from three countries successfully shut down AlphaBay, the dark web’s largest source of contraband, sending shudders throughout the network. But many merchants simply migrated elsewhere.

The anonymous nature of the Tor network also makes it especially vulnerable to DDoS, said Patrick Tiquet, Director of Security & Architecture at Keeper Security, and the company’s resident expert on the topic. “Sites are constantly changing addresses to avoid DDoS, which makes for a very dynamic environment,” he said. As a result, “The quality of search varies widely, and a lot of material is outdated.”

SALTED HASH
Get a hands-on, inside look at the dark web | Salted Hash Ep 25
Commerce on the dark web
The dark web has flourished thanks to bitcoin, the crypto-currency that enables two parties to conduct a trusted transaction without knowing each other’s identity. “Bitcoin has been a major factor in the growth of the dark web, and the dark web has been a big factor in the growth of bitcoin,” says Tiquet.

Nearly all dark web commerce sites conduct transactions in bitcoin or some variant, but that doesn’t mean it’s safe to do business there. The inherent anonymity of the place attracts scammers and thieves, but what do you expect when buying guns or drugs is your objective?

Dark web commerce sites have the same features as any e-retail operation, including ratings/reviews, shopping carts and forums, but there are important differences. One is quality control. When both buyers and sellers are anonymous, the credibility of any ratings system is dubious. Ratings are easily manipulated, and even sellers with long track records have been known to suddenly disappear with their customers’ crypto-coins, only to set up shop later under a different alias.

Most e-commerce providers offer some kind of escrow service that keeps customer funds on hold until the product has been delivered. However, in the event of a dispute don’t expect service with a smile. It’s pretty much up to the buyer and the seller to duke it out. Every communication is encrypted, so even the simplest transaction requires a PGP key.

Even completing a transaction is no guarantee that the goods will arrive. Many need to cross international borders, and customs officials are cracking down on suspicious packages. The dark web news site Deep.Dot.Web teems with stories of buyers who have been arrested or jailed for attempted purchases.

SECURITY
How the dark web has gone corporate
Is the dark web illegal?
We don’t want to leave you with the impression that everything on the dark web is nefarious or illegal. The Tor network began as an anonymous communications channel, and it still serves a valuable purpose in helping people communicate in environments that are hostile to free speech. “A lot of people use it in countries where there’s eavesdropping or where internet access is criminalized,” Tiquet said.

If you want to learn all about privacy protection or cryptocurrency, the dark web has plenty to offer. There are a variety of private and encrypted email services, instructions for installing an anonymous operating system and advanced tips for the privacy-conscious.

There’s also material that you wouldn’t be surprised to find on the public web, such as links to full-text editions of hard-to-find books, collections of political news from mainstream websites and a guide to the steam tunnels under the Virginia Tech campus. You can conduct discussions about current events anonymously on Intel Exchange. There are several whistleblower sites, including a dark web version of Wikileaks. Pirate Bay, a BitTorrent site that law enforcement officials have repeatedly shut down, is alive and well there. Even Facebook has a dark web presence.

“More and more legitimate web companies are starting to have presences there,” Tiquet said. “It shows that they’re aware, they’re cutting edge and in the know.”

There’s also plenty of practical value for some organizations. Law enforcement agencies keep an ear to the ground on the dark web looking for stolen data from recent security breaches that might lead to a trail to the perpetrators. Many mainstream media organizations monitor whistleblower sites looking for news.

Staying on top of the hacker underground
Keeper’s Patrick Tiquet checks in regularly because it’s important for him to be on top of what’s happening in the hacker underground. “I use the dark web for situational awareness, threat analysis and keeping an eye on what’s going on,” he said will. “I want to know what information is available and have an external lens into the digital assets that are being monetized – this gives us insight on what hackers are targeting.”

If you find your own information on the dark web, there’s precious little you can do about it, but at least you’ll know you’ve been compromised. Bottom line: If you can tolerate the lousy performance, unpredictable availability, and occasional shock factor of the dark web, it’s worth a visit. Just don’t buy anything there.
submitted by hireahackerpro to u/hireahackerpro [link] [comments]

Reddcoin (RDD) 02/20 Progress Report - Core Wallet v3.1 Evolution & PoSV v2 - Commits & More Commits to v3.1! (Bitcoin Core 0.10, MacOS Catalina, QT Enhanced Speed and Security and more!)

Reddcoin (RDD) Core Dev Team Informal Progress Report, Feb 2020 - As any blockchain or software expert will confirm, the hardest part of making successful progress in blockchain and crypto is invisible to most users. As developers, the Reddcoin Core team relies on internal experts like John Nash, contributors offering their own code improvements to our repos (which we would love to see more of!) and especially upstream commits from experts working on open source projects like Bitcoin itself. We'd like tothank each and everyone who's hard work has contributed to this progress.
As part of Reddcoin's evolution, and in order to include required security fixes, speed improvements that are long overdue, the team has up to this point incorporated the following code commits since our last v3.0.1 public release. In attempting to solve the relatively minor font display issue with MacOS Catalina, we uncovered a complicated interweaving of updates between Reddcoin Core, QT software, MacOS SDK, Bitcoin Core and related libraries and dependencies that mandated we take a holistic approach to both solve the Catalina display problem, but in doing so, prepare a more streamlined overall build and test system, allowing the team to roll out more frequent and more secure updates in the future. And also to include some badly needed fixes in the current version of Core, which we have tentatively labeled Reddcoin Core Wallet v3.1.
Note: As indicated below, v3.1 is NOT YET AVAILABLE FOR DOWNLOAD BY PUBLIC. We wil advise when it is.
The new v3.1 version should be ready for internal QA and build testing by the end of this week, with luck, and will be turned over to the public shortly thereafter once testing has proven no unexpected issues have been introduced. We know the delay has been a bit extended for our ReddHead MacOS Catalina stakers, and we hope to have them all aboard soon. We have moved with all possible speed while attempting to incorproate all the required work, testing, and ensuring security and safety for our ReddHeads.
Which leads us to: PoSV v2 activation and the supermajority on Mainnet at the time of this writing has reached 5625/9000 blocks or 62.5%. We have progressed quite well and without any reported user issues since release, but we need all of the community to participate! This activation, much like the funding mechanisms currently being debated by BCH and others, and employed by DASH, will mean not only a catalyst for Reddcoin but ensure it's future by providing funding for the dev team. As a personal plea from the team, please help us support the PoSV v2 activation by staking your RDD, no matter how large or small your amount of stake.
Every block and every RDD counts, and if you don't know how, we'll teach you! Live chat is fun as well as providing tech support you can trust from devs and community ReddHead members. Join us today in staking and online and collect some RDD "rain" from users and devs alike!
If you're holding Reddcoin and not staking, or you haven't upgraded your v2.x wallet to v3.0.1 (current release), we need you to help achieve consensus and activate PoSV v2! For details, see the pinned message here or our website or medium channel. Upgrade is simple and takes moments; if you're nervous or unsure, we're here to help live in Telegram or Discord, as well as other chat programs. See our website for links.
Look for more updates shortly as our long-anticipated Reddcoin Payment Gateway and Merchant Services API come online with point-of-sale support, as we announce the cross-crypto-project Aussie firefighter fundraiser program, as well as a comprehensive update to our development roadmap and more.
Work has restarted on ReddID and multiple initiatives are underway to begin educating and sharing information about ReddID, what it is, and how to use it, as we approach a releasable ReddID product. We enthusiastically encourage anyone interested in working to bring these efforts to life, whether writers, UX/UI experts, big data analysts, graphic artists, coders, front-end, back-end, AI, DevOps, the Reddcoin Core dev team is growing, and there's more opportunity and work than ever!
Bring your talents to a community and dev team that truly appreciates it, and share the Reddcoin Love!
And now, lots of commits. As v3.1 is not yet quite ready for public release, these commits have not been pushed publicly, but in the interests of sharing progress transparently, and including our ReddHead community in the process, see below for mind-numbing technical detail of work accomplished.
e5c143404 - - 2014-08-07 - Ross Nicoll - Changed LevelDB cursors to use scoped pointers to ensure destruction when going out of scope. *99a7dba2e - - 2014-08-15 - Cory Fields - tests: fix test-runner for osx. Closes ##4708 *8c667f1be - - 2014-08-15 - Cory Fields - build: add funcs.mk to the list of meta-depends *bcc1b2b2f - - 2014-08-15 - Cory Fields - depends: fix shasum on osx < 10.9 *54dac77d1 - - 2014-08-18 - Cory Fields - build: add option for reducing exports (v2) *6fb9611c0 - - 2014-08-16 - randy-waterhouse - build : fix CPPFLAGS for libbitcoin_cli *9958cc923 - - 2014-08-16 - randy-waterhouse - build: Add --with-utils (bitcoin-cli and bitcoin-tx, default=yes). Help string consistency tweaks. Target sanity check fix. *342aa98ea - - 2014-08-07 - Cory Fields - build: fix automake warnings about the use of INCLUDES *46db8ad51 - - 2020-02-18 - John Nash - build: add build.h to the correct target *a24de1e4c - - 2014-11-26 - Pavel Janík - Use complete path to include bitcoin-config.h. *fd8f506e5 - - 2014-08-04 - Wladimir J. van der Laan - qt: Demote ReportInvalidCertificate message to qDebug *f12aaf3b1 - - 2020-02-17 - John Nash - build: QT5 compiled with fPIC require fPIC to be enabled, fPIE is not enough *7a991b37e - - 2014-08-12 - Wladimir J. van der Laan - build: check for sys/prctl.h in the proper way *2cfa63a48 - - 2014-08-11 - Wladimir J. van der Laan - build: Add mention of --disable-wallet to bdb48 error messages *9aa580f04 - - 2014-07-23 - Cory Fields - depends: add shared dependency builder *8853d4645 - - 2014-08-08 - Philip Kaufmann - [Qt] move SubstituteFonts() above ToolTipToRichTextFilter *0c98e21db - - 2014-08-02 - Ross Nicoll - URLs containing a / after the address no longer cause parsing errors. *7baa77731 - - 2014-08-07 - ntrgn - Fixes ignored qt 4.8 codecs path on windows when configuring with --with-qt-libdir *2a3df4617 - - 2014-08-06 - Cory Fields - qt: fix unicode character display on osx when building with 10.7 sdk *71a36303d - - 2014-08-04 - Cory Fields - build: fix race in 'make deploy' for windows *077295498 - - 2014-08-04 - Cory Fields - build: Fix 'make deploy' when binaries haven't been built yet *ffdcc4d7d - - 2014-08-04 - Cory Fields - build: hook up qt translations for static osx packaging *25a7e9c90 - - 2014-08-04 - Cory Fields - build: add --with-qt-translationdir to configure for use with static qt *11cfcef37 - - 2014-08-04 - Cory Fields - build: teach macdeploy the -translations-dir argument, for use with static qt *4c4ae35b1 - - 2014-07-23 - Cory Fields - build: Find the proper xcb/pcre dependencies *942e77dd2 - - 2014-08-06 - Cory Fields - build: silence mingw fpic warning spew *e73e2b834 - - 2014-06-27 - Huang Le - Use async name resolving to improve net thread responsiveness *c88e76e8e - - 2014-07-23 - Cory Fields - build: don't let libtool insert rpath into binaries *18e14e11c - - 2014-08-05 - ntrgn - build: Fix windows configure when using --with-qt-libdir *bb92d65c4 - - 2014-07-31 - Cory Fields - test: don't let the port number exceed the legal range *62b95290a - - 2014-06-18 - Cory Fields - test: redirect comparison tool output to stdout *cefe447e9 - - 2014-07-22 - Cory Fields - gitian: remove unneeded option after last commit *9347402ca - - 2014-07-21 - Cory Fields - build: fix broken boost chrono check on some platforms *c9ed039cf - - 2014-06-03 - Cory Fields - build: fix whitespace in pkg-config variable *3bcc5ad37 - - 2014-06-03 - Cory Fields - build: allow linux and osx to build against static qt5 *01a44ba90 - - 2014-07-17 - Cory Fields - build: silence false errors during make clean *d1fbf7ba2 - - 2014-07-08 - Cory Fields - build: fix win32 static linking after libtool merge *005ae2fa4 - - 2014-07-08 - Cory Fields - build: re-add AM_LDFLAGS where it's overridden *37043076d - - 2014-07-02 - Wladimir J. van der Laan - Fix the Qt5 build after d95ba75 *f3b4bbf40 - - 2014-07-01 - Wladimir J. van der Laan - qt: Change serious messages from qDebug to qWarning *f4706f753 - - 2014-07-01 - Wladimir J. van der Laan - qt: Log messages with type>QtDebugMsg as non-debug *98e85fa1f - - 2014-06-06 - Pieter Wuille - libsecp256k1 integration *5f1f2e226 - - 2020-02-17 - John Nash - Merge branch 'switch_verification_code' into Build *1f30416c9 - - 2014-02-07 - Pieter Wuille - Also switch the (unused) verification code to low-s instead of even-s. *1c093d55e - - 2014-06-06 - Cory Fields - secp256k1: Add build-side changes for libsecp256k1 *7f3114484 - - 2014-06-06 - Cory Fields - secp256k1: add libtool as a dependency *2531f9299 - - 2020-02-17 - John Nash - Move network-time related functions to timedata.cpp/h *d003e4c57 - - 2020-02-16 - John Nash - build: fix build weirdness after 54372482. *7035f5034 - - 2020-02-16 - John Nash - Add ::OUTPUT_SIZE *2a864c4d8 - - 2014-06-09 - Cory Fields - crypto: create a separate lib for crypto functions *03a4e4c70 - - 2014-06-09 - Cory Fields - crypto: explicitly check for byte read/write functions *a78462a2a - - 2014-06-09 - Cory Fields - build: move bitcoin-config.h to its own directory *a885721c4 - - 2014-05-31 - Pieter Wuille - Extend and move all crypto tests to crypto_tests.cpp *5f308f528 - - 2014-05-03 - Pieter Wuille - Move {Read,Write}{LE,BE}{32,64} to common.h and use builtins if possible *0161cc426 - - 2014-05-01 - Pieter Wuille - Add built-in RIPEMD-160 implementation *deefc27c0 - - 2014-04-28 - Pieter Wuille - Move crypto implementations to src/crypto/ *d6a12182b - - 2014-04-28 - Pieter Wuille - Add built-in SHA-1 implementation. *c3c4f9f2e - - 2014-04-27 - Pieter Wuille - Switch miner.cpp to use sha2 instead of OpenSSL. *b6ed6def9 - - 2014-04-28 - Pieter Wuille - Remove getwork() RPC call *0a09c1c60 - - 2014-04-26 - Pieter Wuille - Switch script.cpp and hash.cpp to use sha2.cpp instead of OpenSSL. *8ed091692 - - 2014-04-20 - Pieter Wuille - Add a built-in SHA256/SHA512 implementation. *0c4c99b3f - - 2014-06-21 - Philip Kaufmann - small cleanup in src/compat .h and .cpp *ab1369745 - - 2014-06-13 - Cory Fields - sanity: hook up sanity checks *f598c67e0 - - 2014-06-13 - Cory Fields - sanity: add libc/stdlib sanity checks *b241b3e13 - - 2014-06-13 - Cory Fields - sanity: autoconf check for sys/select.h *cad980a4f - - 2019-07-03 - John Nash - build: Add a top-level forwarding target for src/ objects *f4533ee1c - - 2019-07-03 - John Nash - build: qt: split locale resources. Fixes non-deterministic distcheck *4a0e46e76 - - 2019-06-29 - John Nash - build: fix version dependency *2f61699d9 - - 2019-06-29 - John Nash - build: quit abusing AMCPPFLAGS *99b60ba49 - - 2019-06-29 - John Nash - build: avoid the use of top and abs_ dir paths *c8f673d5d - - 2019-06-29 - John Nash - build: Tidy up file generation output *5318bce57 - - 2019-06-29 - John Nash - build: nuke Makefile.include from orbit *672a25349 - - 2019-06-29 - John Nash - build: add stub makefiles for easier subdir builds *562b7c5a6 - - 2020-02-08 - John Nash - build: delete old Makefile.am's *066120079 - - 2020-02-08 - John Nash - build: Switch to non-recursive make
Whew! No wonder it's taken the dev team a while! :)
TL;DR: Trying to fix MacOS Catalina font display led to requiring all kinds of work to migrate and evolve the Reddcoin Core software with Apple, Bitcoin and QT components. Lots of work done, v3.1 public release soon. Also other exciting things and ReddID back under active dev effort.
submitted by TechAdept to reddCoin [link] [comments]

Solve the "storage, mining pool and exchange centralization", and only generate 1G data every year(only pc-miner)

The blockheader has two segments with a total length of 64 bit0 (of which blocktime is 64 bits), which strongly prevents the collapse effect of the sha256 operation in the ASIC miner, so that the mining difficulty will not increase indefinitely. The centralization for the high hashrate of the mining pool is strongly restricted. Census and prune the transactions (at most 4 outputs per transaction) whose all outputs are spent,in the block below 1300 depth in batches(i.e. clear up the input and output at the same time, and only keep the version of all-outs-spent transaction on the disk,--not serialize vin and vout). 250 for each batch, 20 block files(one file per block) will be reconstructed for each block received from other nodes, that is to say, 5000 transactions will be pruned at a time. And special mechanism is used to make the synchronization of data from malicious nodes error free. Only 1G data is increased every year. The data it running for 1000 years will be no more than 1T. Block size is 2M, and only 1g data is increased every year without SPV, which strongly prevents the storage of a large number of block data reducing the number of nodes. At the same time, 'four outputs per tx' limit the settlement of the mining pool, and strongly prevent the centralization of the mining pool. For example, the settlement is sent to 4000 miners, which requires 1000 transactions. All currencies are locked in the maturity of 300 blocks (the input can only be used as prevout after 300 blocks), which strongly prevents the frequency of trading speculation, the crash from the online exchange, and prevent the centralization of the biggest online exchange in the world.
This has achieved "absolute decentralization".
At present, the tip height is only 600, and there is no pre-mined. The RPC is stable and reliable same as bitcoin 0.10.2. No segwit but P2SH, a little change based on 0.10.2. Usage: $ /download-directory/bitcoind -addnode =47.114.58.108 (same for Ubuntu) with bitcoin.conf configuration file
Detailed introduction,original text is as follows: github-holyangel250-bitsupercoin
submitted by DangerousDetail8 to BitcoinMining [link] [comments]

FlowCards: A Declarative Framework for Development of Ergo dApps

FlowCards: A Declarative Framework for Development of Ergo dApps
Introduction
ErgoScript is the smart contract language used by the Ergo blockchain. While it has concise syntax adopted from Scala/Kotlin, it still may seem confusing at first because conceptually ErgoScript is quite different compared to conventional languages which we all know and love. This is because Ergo is a UTXO based blockchain, whereas smart contracts are traditionally associated with account based systems like Ethereum. However, Ergo's transaction model has many advantages over the account based model and with the right approach it can even be significantly easier to develop Ergo contracts than to write and debug Solidity code.
Below we will cover the key aspects of the Ergo contract model which makes it different:
Paradigm
The account model of Ethereum is imperative. This means that the typical task of sending coins from Alice to Bob requires changing the balances in storage as a series of operations. Ergo's UTXO based programming model on the other hand is declarative. ErgoScript contracts specify conditions for a transaction to be accepted by the blockchain (not changes to be made in the storage state as result of the contract execution).
Scalability
In the account model of Ethereum both storage changes and validity checks are performed on-chain during code execution. In contrast, Ergo transactions are created off-chain and only validation checks are performed on-chain thus reducing the amount of operations performed by every node on the network. In addition, due to immutability of the transaction graph, various optimization strategies are possible to improve throughput of transactions per second in the network. Light verifying nodes are also possible thus further facilitating scalability and accessibility of the network.
Shared state
The account-based model is reliant on shared mutable state which is known to lead to complex semantics (and subtle million dollar bugs) in the context of concurrent/ distributed computation. Ergo's model is based on an immutable graph of transactions. This approach, inherited from Bitcoin, plays well with the concurrent and distributed nature of blockchains and facilitates light trustless clients.
Expressive Power
Ethereum advocated execution of a turing-complete language on the blockchain. It theoretically promised unlimited potential, however in practice severe limitations came to light from excessive blockchain bloat, subtle multi-million dollar bugs, gas costs which limit contract complexity, and other such problems. Ergo on the flip side extends UTXO to enable turing-completeness while limiting the complexity of the ErgoScript language itself. The same expressive power is achieved in a different and more semantically sound way.
With the all of the above points, it should be clear that there are a lot of benefits to the model Ergo is using. In the rest of this article I will introduce you to the concept of FlowCards - a dApp developer component which allows for designing complex Ergo contracts in a declarative and visual way.

From Imperative to Declarative

In the imperative programming model of Ethereum a transaction is a sequence of operations executed by the Ethereum VM. The following Solidity function implements a transfer of tokens from sender to receiver . The transaction starts when sender calls this function on an instance of a contract and ends when the function returns.
// Sends an amount of existing coins from any caller to an address function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; balances[receiver] += amount; emit Sent(msg.sender, receiver, amount); } 
The function first checks the pre-conditions, then updates the storage (i.e. balances) and finally publishes the post-condition as the Sent event. The gas which is consumed by the transaction is sent to the miner as a reward for executing this transaction.
Unlike Ethereum, a transaction in Ergo is a data structure holding a list of input coins which it spends and a list of output coins which it creates preserving the total balances of ERGs and tokens (in which Ergo is similar to Bitcoin).
Turning back to the example above, since Ergo natively supports tokens, therefore for this specific example of sending tokens we don't need to write any code in ErgoScript. Instead we need to create the ‘send’ transaction shown in the following figure, which describes the same token transfer but declaratively.
https://preview.redd.it/sxs3kesvrsv41.png?width=1348&format=png&auto=webp&s=582382bc26912ff79114d831d937d94b6988e69f
The picture visually describes the following steps, which the network user needs to perform:
  1. Select unspent sender's boxes, containing in total tB >= amount of tokens and B >= txFee + minErg ERGs.
  2. Create an output target box which is protected by the receiver public key with minErg ERGs and amount of T tokens.
  3. Create one fee output protected by the minerFee contract with txFee ERGs.
  4. Create one change output protected by the sender public key, containing B - minErg - txFee ERGs and tB - amount of T tokens.
  5. Create a new transaction, sign it using the sender's secret key and send to the Ergo network.
What is important to understand here is that all of these steps are preformed off-chain (for example using Appkit Transaction API) by the user's application. Ergo network nodes don't need to repeat this transaction creation process, they only need to validate the already formed transaction. ErgoScript contracts are stored in the inputs of the transaction and check spending conditions. The node executes the contracts on-chain when the transaction is validated. The transaction is valid if all of the conditions are satisfied.
Thus, in Ethereum when we “send amount from sender to recipient” we are literally editing balances and updating the storage with a concrete set of commands. This happens on-chain and thus a new transaction is also created on-chain as the result of this process.
In Ergo (as in Bitcoin) transactions are created off-chain and the network nodes only verify them. The effects of the transaction on the blockchain state is that input coins (or Boxes in Ergo's parlance) are removed and output boxes are added to the UTXO set.
In the example above we don't use an ErgoScript contract but instead assume a signature check is used as the spending pre-condition. However in more complex application scenarios we of course need to use ErgoScript which is what we are going to discuss next.

From Changing State to Checking Context

In the send function example we first checked the pre-condition (require(amount <= balances[msg.sender],...) ) and then changed the state (i.e. update balances balances[msg.sender] -= amount ). This is typical in Ethereum transactions. Before we change anything we need to check if it is valid to do so.
In Ergo, as we discussed previously, the state (i.e. UTXO set of boxes) is changed implicitly when a valid transaction is included in a block. Thus we only need to check the pre-conditions before the transaction can be added to the block. This is what ErgoScript contracts do.
It is not possible to “change the state” in ErgoScript because it is a language to check pre-conditions for spending coins. ErgoScript is a purely functional language without side effects that operates on immutable data values. This means all the inputs, outputs and other transaction parameters available in a script are immutable. This, among other things, makes ErgoScript a very simple language that is easy to learn and safe to use. Similar to Bitcoin, each input box contains a script, which should return the true value in order to 1) allow spending of the box (i.e. removing from the UTXO set) and 2) adding the transaction to the block.
If we are being pedantic, it is therefore incorrect (strictly speaking) to think of ErgoScript as the language of Ergo contracts, because it is the language of propositions (logical predicates, formulas, etc.) which protect boxes from “illegal” spending. Unlike Bitcoin, in Ergo the whole transaction and a part of the current blockchain context is available to every script. Therefore each script may check which outputs are created by the transaction, their ERG and token amounts (we will use this capability in our example DEX contracts), current block number etc.
In ErgoScript you define the conditions of whether changes (i.e. coin spending) are allowed to happen in a given context. This is in contrast to programming the changes imperatively in the code of a contract.
While Ergo's transaction model unlocks a whole range of applications like (DEX, DeFi Apps, LETS, etc), designing contracts as pre-conditions for coin spending (or guarding scripts) directly is not intuitive. In the next sections we will consider a useful graphical notation to design contracts declaratively using FlowCard Diagrams, which is a visual representation of executable components (FlowCards).
FlowCards aim to radically simplify dApp development on the Ergo platform by providing a high-level declarative language, execution runtime, storage format and a graphical notation.
We will start with a high level of diagrams and go down to FlowCard specification.

FlowCard Diagrams

The idea behind FlowCard diagrams is based on the following observations: 1) An Ergo box is immutable and can only be spent in the transaction which uses it as an input. 2) We therefore can draw a flow of boxes through transactions, so that boxes flowing in to the transaction are spent and those flowing out are created and added to the UTXO. 3) A transaction from this perspective is simply a transformer of old boxes to the new ones preserving the balances of ERGs and tokens involved.
The following figure shows the main elements of the Ergo transaction we've already seen previously (now under the name of FlowCard Diagram).
https://preview.redd.it/06aqkcd1ssv41.png?width=1304&format=png&auto=webp&s=106eda730e0526919aabd5af9596b97e45b69777
There is a strictly defined meaning (semantics) behind every element of the diagram, so that the diagram is a visual representation (or a view) of the underlying executable component (called FlowCard).
The FlowCard can be used as a reusable component of an Ergo dApp to create and initiate the transaction on the Ergo blockchain. We will discuss this in the coming sections.
Now let's look at the individual pieces of the FlowCard diagram one by one.
1. Name and Parameters
Each flow card is given a name and a list of typed parameters. This is similar to a template with parameters. In the above figure we can see the Send flow card which has five parameters. The parameters are used in the specification.
2. Contract Wallet
This is a key element of the flow card. Every box has a guarding script. Often it is the script that checks a signature against a public key. This script is trivial in ErgoScript and is defined like the def pk(pubkey: Address) = { pubkey } template where pubkey is a parameter of the type Address . In the figure, the script template is applied to the parameter pk(sender) and thus a concrete wallet contract is obtained. Therefore pk(sender) and pk(receiver) yield different scripts and represent different wallets on the diagram, even though they use the same template.
Contract Wallet contains a set of all UTXO boxes which have a given script derived from the given script template using flow card parameters. For example, in the figure, the template is pk and parameter pubkey is substituted with the `sender’ flow card parameter.
3. Contract
Even though a contract is a property of a box, on the diagram we group the boxes by their contracts, therefore it looks like the boxes belong to the contracts, rather than the contracts belong to the boxes. In the example, we have three instantiated contracts pk(sender) , pk(receiver) and minerFee . Note, that pk(sender) is the instantiation of the pk template with the concrete parameter sender and minerFee is the instantiation of the pre-defined contract which protects the miner reward boxes.
4. Box name
In the diagram we can give each box a name. Besides readability of the diagram, we also use the name as a synonym of a more complex indexed access to the box in the contract. For example, change is the name of the box, which can also be used in the ErgoScript conditions instead of OUTPUTS(2) . We also use box names to associate spending conditions with the boxes.
5. Boxes in the wallet
In the diagram, we show boxes (darker rectangles) as belonging to the contract wallets (lighter rectangles). Each such box rectangle is connected with a grey transaction rectangle by either orange or green arrows or both. An output box (with an incoming green arrow) may include many lines of text where each line specifies a condition which should be checked as part of the transaction. The first line specifies the condition on the amount of ERG which should be placed in the box. Other lines may take one of the following forms:
  1. amount: TOKEN - the box should contain the given amount of the given TOKEN
  2. R == value - the box should contain the given value of the given register R
  3. boxName ? condition - the box named boxName should check condition in its script.
We discuss these conditions in the sections below.
6. Amount of ERGs in the box
Each box should store a minimum amount of ERGs. This is checked when the creating transaction is validated. In the diagram the amount of ERGs is always shown as the first line (e.g. B: ERG or B - minErg - txFee ). The value type ascription B: ERG is optional and may be used for readability. When the value is given as a formula, then this formula should be respected by the transaction which creates the box.
It is important to understand that variables like amount and txFee are not named properties of the boxes. They are parameters of the whole diagram and representing some amounts. Or put it another way, they are shared parameters between transactions (e.g. Sell Order and Swap transactions from DEX example below share the tAmt parameter). So the same name is tied to the same value throughout the diagram (this is where the tooling would help a lot). However, when it comes to on-chain validation of those values, only explicit conditions which are marked with ? are transformed to ErgoScript. At the same time, all other conditions are ensured off-chain during transaction building (for example in an application using Appkit API) and transaction validation when it is added to the blockchain.
7. Amount of T token
A box can store values of many tokens. The tokens on the diagram are named and a value variable may be associated with the token T using value: T expression. The value may be given by formula. If the formula is prefixed with a box name like boxName ? formula , then it is should also be checked in the guarding script of the boxName box. This additional specification is very convenient because 1) it allows to validate the visual design automatically, and 2) the conditions specified in the boxes of a diagram are enough to synthesize the necessary guarding scripts. (more about this below at “From Diagrams To ErgoScript Contracts”)
8. Tx Inputs
Inputs are connected to the corresponding transaction by orange arrows. An input arrow may have a label of the following forms:
  1. [email protected] - optional name with an index i.e. [email protected] or u/2 . This is a property of the target endpoint of the arrow. The name is used in conditions of related boxes and the index is the position of the corresponding box in the INPUTS collection of the transaction.
  2. !action - is a property of the source of the arrow and gives a name for an alternative spending path of the box (we will see this in DEX example)
Because of alternative spending paths, a box may have many outgoing orange arrows, in which case they should be labeled with different actions.
9. Transaction
A transaction spends input boxes and creates output boxes. The input boxes are given by the orange arrows and the labels are expected to put inputs at the right indexes in INPUTS collection. The output boxes are given by the green arrows. Each transaction should preserve a strict balance of ERG values (sum of inputs == sum of outputs) and for each token the sum of inputs >= the sum of outputs. The design diagram requires an explicit specification of the ERG and token values for all of the output boxes to avoid implicit errors and ensure better readability.
10. Tx Outputs
Outputs are connected to the corresponding transaction by green arrows. An output arrow may have a label of the following [email protected] , where an optional name is accompanied with an index i.e. [email protected] or u/2 . This is a property of the source endpoint of the arrow. The name is used in conditions of the related boxes and the index is the position of the corresponding box in the OUTPUTS collection of the transaction.

Example: Decentralized Exchange (DEX)

Now let's use the above described notation to design a FlowCard for a DEX dApp. It is simple enough yet also illustrates all of the key features of FlowCard diagrams which we've introduced in the previous section.
The dApp scenario is shown in the figure below: There are three participants (buyer, seller and DEX) of the DEX dApp and five different transaction types, which are created by participants. The buyer wants to swap ergAmt of ERGs for tAmt of TID tokens (or vice versa, the seller wants to sell TID tokens for ERGs, who sends the order first doesn't matter). Both the buyer and the seller can cancel their orders any time. The DEX off-chain matching service can find matching orders and create the Swap transaction to complete the exchange.
The following diagram fully (and formally) specifies all of the five transactions that must be created off-chain by the DEX dApp. It also specifies all of the spending conditions that should be verified on-chain.

https://preview.redd.it/piogz0v9ssv41.png?width=1614&format=png&auto=webp&s=e1b503a635ad3d138ef91e2f0c3b726e78958646
Let's discuss the FlowCard diagram and the logic of each transaction in details:
Buy Order Transaction
A buyer creates a Buy Order transaction. The transaction spends E amount of ERGs (which we will write E: ERG ) from one or more boxes in the pk(buyer) wallet. The transaction creates a bid box with ergAmt: ERG protected by the buyOrder script. The buyOrder script is synthesized from the specification (see below at “From Diagrams To ErgoScript Contracts”) either manually or automatically by a tool. Even though we don't need to define the buyOrder script explicitly during designing, at run time the bid box should contain the buyOrder script as the guarding proposition (which checks the box spending conditions), otherwise the conditions specified in the diagram will not be checked.
The change box is created to make the input and output sums of the transaction balanced. The transaction fee box is omitted because it can be added automatically by the tools. In practice, however, the designer can add the fee box explicitly to the a diagram. It covers the cases of more complex transactions (like Swap) where there are many ways to pay the transaction fee.
Cancel Buy, Cancel Sell Transactions
At any time, the buyer can cancel the order by sending CancelBuy transaction. The transaction should satisfy the guarding buyOrder contract which protects the bid box. As you can see on the diagram, both the Cancel and the Swap transactions can spend the bid box. When a box has spending alternatives (or spending paths) then each alternative is identified by a unique name prefixed with ! (!cancel and !swap for the bid box). Each alternative path has specific spending conditions. In our example, when the Cancel Buy transaction spends the bid box the ?buyer condition should be satisfied, which we read as “the signature for the buyer address should be presented in the transaction”. Therefore, only buyer can cancel the buy order. This “signature” condition is only required for the !cancel alternative spending path and not required for !swap .
Sell Order Transaction
The Sell Order transaction is similar to the BuyOrder in that it deals with tokens in addition to ERGs. The transaction spends E: ERG and T: TID tokens from seller's wallet (specified as pk(seller) contract). The two outputs are ask and change . The change is a standard box to balance transaction. The ask box keeps tAmt: TID tokens for the exchange and minErg: ERG - the minimum amount of ERGs required in every box.
Swap Transaction
This is a key transaction in the DEX dApp scenario. The transaction has several spending conditions on the input boxes and those conditions are included in the buyOrder and sellOrder scripts (which are verified when the transaction is added to the blockchain). However, on the diagram those conditions are not specified in the bid and ask boxes, they are instead defined in the output boxes of the transaction.
This is a convention for improved usability because most of the conditions relate to the properties of the output boxes. We could specify those properties in the bid box, but then we would have to use more complex expressions.
Let's consider the output created by the arrow labeled with [email protected] . This label tells us that the output is at the index 0 in the OUTPUTS collection of the transaction and that in the diagram we can refer to this box by the buyerOut name. Thus we can label both the box itself and the arrow to give the box a name.
The conditions shown in the buyerOut box have the form bid ? condition , which means they should be verified on-chain in order to spend the bid box. The conditions have the following meaning:
  • tAmt: TID requires the box to have tAmt amount of TID token
  • R4 == bid.id requires R4 register in the box to be equal to id of the bid box.
  • script == buyer requires the buyerOut box to have the script of the wallet where it is located on the diagram, i.e. pk(buyer)
Similar properties are added to the sellerOut box, which is specified to be at index 1 and the name is given to it using the label on the box itself, rather than on the arrow.
The Swap transaction spends two boxes bid and ask using the !swap spending path on both, however unlike !cancel the conditions on the path are not specified. This is where the bid ? and ask ? prefixes come into play. They are used so that the conditions listed in the buyerOut and sellerOut boxes are moved to the !swap spending path of the bid and ask boxes correspondingly.
If you look at the conditions of the output boxes, you will see that they exactly specify the swap of values between seller's and buyer's wallets. The buyer gets the necessary amount of TID token and seller gets the corresponding amount of ERGs. The Swap transaction is created when there are two matching boxes with buyOrder and sellOrder contracts.

From Diagrams To ErgoScript Contracts

What is interesting about FlowCard specifications is that we can use them to automatically generate the necessary ErgoTree scripts. With the appropriate tooling support this can be done automatically, but with the lack of thereof, it can be done manually. Thus, the FlowCard allows us to capture and visually represent all of the design choices and semantic details of an Ergo dApp.
What we are going to do next is to mechanically create the buyOrder contract from the information given in the DEX flow card.
Recall that each script is a proposition (boolean valued expression) which should evaluate to true to allow spending of the box. When we have many conditions to be met at the same time we can combine them in a logical formula using the AND binary operation, and if we have alternatives (not necessarily exclusive) we can put them into the OR operation.
The buyOrder box has the alternative spending paths !cancel and !swap . Thus the ErgoScript code should have OR operation with two arguments - one for each spending path.
/** buyOrder contract */ { val cancelCondition = {} val swapCondition = {} cancelCondition || swapCondition } 
The formula for the cancelCondition expression is given in the !cancel spending path of the buyOrder box. We can directly include it in the script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = {} cancelCondition || swapCondition } 
For the !swap spending path of the buyOrder box the conditions are specified in the buyerOut output box of the Swap transaction. If we simply include them in the swapCondition then we get a syntactically incorrect script.
/** buyOrder contract */ { val cancelCondition = { buyer } val swapCondition = { tAmt: TID && R4 == bid.id && @contract } cancelCondition || swapCondition } 
We can however translate the conditions from the diagram syntax to ErgoScript expressions using the following simple rules
  1. [email protected] ==> val buyerOut = OUTPUTS(0)
  2. tAmt: TID ==> tid._2 == tAmt where tid = buyerOut.tokens(TID)
  3. R4 == bid.id ==> R4 == SELF.id where R4 = buyerOut.R4[Coll[Byte]].get
  4. script == buyer ==> buyerOut.propositionBytes == buyer.propBytes
Note, in the diagram TID represents a token id, but ErgoScript doesn't have access to the tokens by the ids so we cannot write tokens.getByKey(TID) . For this reason, when the diagram is translated into ErgoScript, TID becomes a named constant of the index in tokens collection of the box. The concrete value of the constant is assigned when the BuyOrder transaction with the buyOrder box is created. The correspondence and consistency between the actual tokenId, the TID constant and the actual tokens of the buyerOut box is ensured by the off-chain application code, which is completely possible since all of the transactions are created by the application using FlowCard as a guiding specification. This may sound too complicated, but this is part of the translation from diagram specification to actual executable application code, most of which can be automated.
After the transformation we can obtain a correct script which checks all the required preconditions for spending the buyOrder box.
/** buyOrder contract */ def DEX(buyer: Addrss, seller: Address, TID: Int, ergAmt: Long, tAmt: Long) { val cancelCondition: SigmaProp = { buyer } // verify buyer's sig (ProveDlog) val swapCondition = OUTPUTS.size > 0 && { // securing OUTPUTS access val buyerOut = OUTPUTS(0) // from [email protected] buyerOut.tokens.size > TID && { // securing tokens access val tid = buyerOut.tokens(TID) val regR4 = buyerOut.R4[Coll[Byte]] regR4.isDefined && { // securing R4 access val R4 = regR4.get tid._2 == tAmt && // from tAmt: TID R4 == SELF.id && // from R4 == bid.id buyerOut.propositionBytes == buyer.propBytes // from script == buyer } } } cancelCondition || swapCondition } 
A similar script for the sellOrder box can be obtained using the same translation rules. With the help of the tooling the code of contracts can be mechanically generated from the diagram specification.

Conclusions

Declarative programming models have already won the battle against imperative programming in many application domains like Big Data, Stream Processing, Deep Learning, Databases, etc. Ergo is pioneering the declarative model of dApp development as a better and safer alternative to the now popular imperative model of smart contracts.
The concept of FlowCard shifts the focus from writing ErgoScript contracts to the overall flow of values (hence the name), in such a way, that ErgoScript can always be generated from them. You will never need to look at the ErgoScript code once the tooling is in place.
Here are the possible next steps for future work:
  1. Storage format for FlowCard Spec and the corresponding EIP standardized file format (Json/XML/Protobuf). This will allow various tools (Diagram Editor, Runtime, dApps etc) to create and use *.flowcard files.
  2. FlowCard Viewer, which can generate the diagrams from *.flowcard files.
  3. FlowCard Runtime, which can run *.flowcard files, create and send transactions to Ergo network.
  4. FlowCard Designer Tool, which can simplify development of complex diagrams . This will make designing and validation of Ergo contracts a pleasant experience, more like drawing rather than coding. In addition, the correctness of the whole dApp scenario can be verified and controlled by the tooling.
submitted by eleanorcwhite to btc [link] [comments]

Bitcoin Block Size: Larger or smaller blocks? Bitcoin Fundamentals: Block Size, Bitcoin Scalability, & SegWit Bitcoin block size limit concept: history of its establishment Bitcoin Dev Suggests Lower Block Size Bitcoin blocksize debate - An overview of both sides arguments

A perfect example of a Bitcoin upgrade nightmare occurred in March 2013. Bitcoin had a planned upgrade from Version 0.7 to Version 0.8. Version 0.8 increased the block size of Bitcoin. Once the update was complete, the nightmare began. Developers realized that the update made the network incompatible with the current version of Bitcoin. During a panel discussion on Bitcoin scaling at the recent State of Digital Money event in Los Angeles, the idea that a larger block size limit would lead to further centralization of bitcoin mining was debated by the four participants on the panel: Airbitz CEO Paul Puey, derivatives trader Tone Vays, Yours CEO Ryan X. Charles, and Bitcoin Core contributor Eric Lombrozo. After Bitcoin Developer Suggests Dropping Block Size To 300KB, Roger Ver Threatens To Sell His Bitcoins If The Plans Go Through. As the discussion on the halving of Bitcoin mining rewards goes on, the debate surrounding the block size of the popular token is becoming divisive. As this change has been suggested over time, it has even resulted in major hard forks, like Bitcoin Cash and Bitcoin SV. This group of power brokers wanted to double the bitcoin block size as a means to increase the network’s transaction capacity. However, an increase to the block size would have required a change to the network consensus rules, which would have split (or hard-forked) the network. Back in April, BitMEX reported that the BSV network experienced block re-organizations, pinning the blame on the large block size. On 18th April 2019, our Bitcoin Cash SV node experienced 2 block

[index] [31207] [30194] [24556] [7643] [13663] [10523] [6142] [15807] [6880] [28273]

Bitcoin Block Size: Larger or smaller blocks?

During the second half of the show, Bitcoin Developer and outspoken block size increase opponent Peter Todd joins the discussion to share his perspective on the issue, the problems he sees and why ... The bitcoin blocksize debate has been going for a while now. There is 2 factions that are discussing it. One side wants the blocksize to stay small, around 1 mb, and the other side wants the ... Size of block chain can be 6-7GB. After installing miner gets account number. In this passbook all the transactions related with bitcoins all around workd gets recorded. This video goes over the Bitcoin block size issue and the current Exodus Issue and how to export your private keys into the Bitcoin Core wallet. Make Bitcoins And Get Paid Each Day Save 3% on ... Top Bitcoin Core Dev Greg Maxwell DevCore: Must watch talk on mining, block size, and more - Duration: 55:04. The Bitcoin Foundation 19,937 views

Flag Counter