Bitcoin Forum
January 27, 2020, 10:25:14 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Warning: One or more bitcointalk.org users have reported that they believe that the creator of this topic displays some red flags which make them high-risk. (Login to see the detailed trust ratings.) While the bitcointalk.org administration does not verify such claims, you should proceed with extreme caution.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 »  All
  Print  
Author Topic: [ANN] [BSV] [Bitcoin SV] Original Satoshi Vision  (Read 3160 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (16 posts by 9 users with 9 merit deleted.)
Bitcoin SV
Member
**
Offline Offline

Activity: 158
Merit: 42


View Profile
December 23, 2019, 08:18:47 PM
Last edit: December 25, 2019, 12:37:21 PM by Bitcoin SV
Merited by MirkoIta (25), SergeyMalar (1)
 #1



“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.”
Satoshi Nakamoto

White paper
https://bitcoinsv.io/bitcoin.pdf

Hard Fork Latest Updates
https://bitcoinsv.io/genesis-hard-fork

Bitcoin SV – Blocking potential P2SH replay attack after Genesis hard fork
https://bitcoinsv.io/2019/12/23/bitcoin-sv-blocking-potential-p2sh-replay-attack-after-genesis-hard-fork

The Bitcoin SV Node team notes the recent public disclosure on Reddit by Gregory Maxwell (a.k.a. /u/nullc) from the Bitcoin Core (BTC) of a potential replay attack vector on Bitcoin SV after the “Genesis” hard fork in February 2020 which will be deprecating the P2SH (pay-to-script-hash) feature that is not part of the Bitcoin design described by Satoshi Nakamoto.

The post describes a possible theft via replay attack of P2SH (pay-to-script-hash) transactions from the BTC chain that could be executed to steal unsplit funds of BTC users on the Bitcoin SV chain. The Bitcoin SV mission is to return Bitcoin to the vision described in Satoshi’s whitepaper which uses the word “honest” no less than 15 times and we emphatically reject the notion that obvious theft of coins by miners can fall within the definition of “honest” behaviour.

 We note that Mr. Maxwell’s public disclosure in no way fits the broadly accepted definition of “responsible disclosure” and by describing in detail the steps required to exploit and potentially cause loss of funds to BTC users, we would deem it both irresponsible to BTC users and poor security practice.  Had the disclosure been made responsibly according the guidelines set out in the Bitcoin SV Responsible Disclosure Policy, it likely would have been eligible for a substantial bug bounty.  It is particularly puzzling to the BSV Node team that the disclosure was made in this public way by a BTC core developer given the users most likely put at greater risk by the disclosure are not those actively engaged with BSV, but primarily those that are BTC users who may not even be interested in BSV.

We note for the record that the Bitcoin SV Node team has previously made responsible disclosures to the Bitcoin Core and Bitcoin Cash development teams and intend to continuing to do so as part of our commitment to professionalizing Bitcoin software development.

The Bitcoin SV team had been previously aware of variations of this attack vector and did in fact have a plan in place to mitigate it, in part involving a coalition of honest miners forcibly rejecting blocks that contain obvious theft attempts in order to protect the integrity of the chain. We note that this mechanism has subtle but important differences to an explicit consensus rule although has a similar effect. However, due to this public disclosure and explicit description of the method, we believe there is now a significantly higher risk of a dishonest miner attempting to execute this theft attack with a large amount of hashpower and consequently the economic cost to honest miners of implementing the proposed mitigation method is likely to be substantially higher as well. As such the Bitcoin SV team has determined that a stronger mitigation is now required.

We note for the record that Mr. Maxwell’s post did bring to our attention some aspects of this issue that the Bitcoin SV team had not yet fully considered.  So we thank him for the technical review and shedding some new light on the matter.  

In fact, this event demonstrates that the public review process implemented by the Bitcoin SV team, in advance of finalizing the code in early January, is achieving the intended goal of improving security outcomes for the ecosystem.

Mitigation
In response, the Bitcoin SV Node team will update the “Genesis” hard fork specification by upgrading the rule rejecting the P2SH script pattern from a policy rule to a consensus rule.  That is the specific script template “OP_HASH160 <hash> OP_EQUAL” will not be allowed in new outputs and this rule will be directly implemented in the Bitcoin SV Node software.  Whilst unfortunate to restrict the usage of a particular script pattern, we note that the same effect can be achieved using variations of the script pattern e.g. “OP_SHA256 OP_RIPEMD160 <hash> OP_EQUAL”.

This change closes the attack vector and mitigates the need for honest miners to forcibly reject blocks containing theft transactions.  Whilst this could have triggered a valuable demonstration of the principle of honest miners acting punitively against dishonest miners, the public disclosure by Mr. Maxwell raises the potential cost to those miners to an unacceptable level.

Segwit script pattern
To address an additional but unrelated issue related to native Segwit transaction replay an additional measure will be taken. This will be detailed in a later post.

An update to the Genesis hard fork specification will be published shortly and the code changes included in the next beta release of Bitcoin SV.  Release notification will occur through the usual channels noted here: https://bitcoinsv.io/genesis-hard-fork/

Bug Bounty
We take this opportunity to remind the security research community of the substantial bug bounty program offered by Bitcoin SV with a maximum reward of up to $100,000 USD (payable in BSV), rivalling the largest bug bounty programs in the world offered by multinational technology giants.

We offer a top-tier bug bounty program in order to encourage further scrutiny, review and responsible disclosures from all parties.  Gregory Maxwell is of course eligible to participate so long as he adheres to principles of Responsible Disclosure in the future.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
olkah
Hero Member
*****
Offline Offline

Activity: 1176
Merit: 505



View Profile
December 24, 2019, 12:38:06 AM
 #2

Finally BSV global adoption of BSV happened
New Algo Huh
human8ty
Jr. Member
*
Offline Offline

Activity: 92
Merit: 1


View Profile
December 24, 2019, 01:36:43 AM
Last edit: January 11, 2020, 02:24:34 AM by human8ty
Merited by Bitcoin SV (1)
 #3

I am delighted with this project, which is suitable for global scale-up. Metanet will be an open gateway to a new world 🪐

Quote
in the Bitcoin SV ecosystem. The number of Bitcoin SV transactions per second (TPS) doubles each quarter. As of mid-November 2019, Bitcoin SV has processed an average of 5 TPS. With this, it has definitely surpassed the CTO (~ 3.5 TPS) and is likely to definitely surpass Ethereum, which currently processes ~ 8 TPS, in the first quarter of 2020.


Quote
BTC a core tinkered and (blocks) limited which makes it obsolete (incidentally served as an incubation test) and is technically invaded by the cancer of the economic stranglehold of Sunday traders, whales and Blockstream Rock. The objective of making the block unlimited is to allow data to be aggregated and block prices to be negotiated to boost the economy and allow the small to extract BSV and extend the decentralization of the core. The protocol remains unchanged but it will be impossible to change the code at the end. Currently since 2019 a lot of BSV transactions are weather data, tested to fill the blocks but it can be all kind of data not only weather, IoT, medical records, transport, logistics, traceability, NFT transaction, votes, mass reimbursements that's what the scaling is for to be compatible with the user mass without bottleneck.... nChain and other entities are jointly developing an external interface called Metanet to launch web 3.0 based on a specific protocol on which a multitude of applications offer different interfaces and specific functionalities, Metanet intends to unify all this within a legal and prosperous framework like a Windows but very different. It is a perspective of identity and identifiable web also offering a certain degree of confidentiality, all user actions will be time-stamped, engraved in stone in a distributed system and still decentralized in the core. It's like an inclusive big brother with a Chinese sauce who can give you a social rating, except that you are the one who control/trade all your data directly and without any intermediary. The software is in the early stages of 2020/2021 testnet, the goal is to drastically reduce the costs of operation, security, logistics of data routing, maintenance, storage and to provide everyone with a way to control the completeness of all its data produced. While taking into account the different cultural approaches and languages from all over the world (this is a keystone dear friend). As for accessibility, it would be possible to access it without the Internet, via satellite, radio or quantum teleportation channels, as with the 2019 qubit experiment. In this respect, nChain has already registered hundreds of technological patents, some of which are very innovative. The next update in February 2020 will lead to a hardfork (or more) named Genesis. Remember that Skynet is Genesis and it's no bullshit that deploying a tamper-proof time stamp (a blockchain) can be a safe way to e.g. enforce Asimov's laws on robots and humanoids transcend next century TLR (The Three Laws of Robotics) quantum PMQ1 or millions of other plural objectives and even provide a basis to get around the decoherence problem. In 2020 it is the stone age of the world that we create in our image is computer science, faster, faster, more storage, smaller, more everything and yet already overtaken by qutrits (3N) since 2008 because even if you do not know it yet it is possible to open a wallet (with standard keyseeds) in a few hours provided you write the right code for quantum exploitation, certainly it takes resources, they exist those who will tell you the opposite are very funny. Soon we will be one day just as obsolete as Bitcoin and its Satoshi as life is. In the meantime I propose to take advantage of our loved ones and also green candles because life is a beautiful experience to go through.

Do_zzze
Jr. Member
*
Offline Offline

Activity: 147
Merit: 1


View Profile
December 24, 2019, 01:39:07 AM
 #4

Where to download official client of BSV?

look the links are on the official website
https://bitcoinsv.io/services/wallets-and-exchanges/
ReD_Yaka_MoZ_
Jr. Member
*
Offline Offline

Activity: 47
Merit: 1


View Profile
December 24, 2019, 01:43:18 AM
Last edit: January 11, 2020, 06:29:50 PM by ReD_Yaka_MoZ_
 #5

Update 2020/01/11. I find this analysis very relevant:

Quote

Many BSV supporters often compare the two networks. They put BTC head to head with BSV and believe we live in a world where only one of these networks will survive. However, I don’t think that’s the case—at least, not for the foreseeable future.


Quote
@CalvinAyre on twitter say:
My prediction:  Bitcoin SV and BTC can coexist for years to come as they do not compete at all.  Anonymous tokens will slowly be banned in most major countries and the rest of the platforms will become irrelevant as they do not scale and BSV does everything better than they do.

I think a good portion of Mr. Ayre’s statement is correct; BTC and BSV don’t compete. I also think the part about anonymous tokens being banned is true, and that other blockchains are going to lose relevance—although for a different reason than the one Calvin states, but we’ll save that story for another day.

Why BTC and BSV will co-exist

Modern-day utility in BTC is that it is an alternative investment vehicle that has striking similarities to gold; for this reason, many people call BTC “digital gold.” Although Bitcoin SV also has that property (digital gold), the utility in BSV comes from it being an infrastructure protocol that can be used to create the internet of value.


Today, BTC is primarily used as an investment vehicle. Although there was a point in time when it’s primary use-case was a pseudo-anonymous payment rail, those days are over. The government has cracked down on Dark Net Markets, and users of those markets have turned away from BTC to digital currencies that give them more privacy. 

In addition, BTC’s technical limitations, such as 1MB blocks, make it difficult for developers to build businesses and programs on top of the network, so for that reason, not many are interested in building atop BTC.

So if BTC is seeing a very small amount of activity as a payment rail, and if it’s not being used as an infrastructure protocol, then what is it being used as? Many will tell you that it is being used as an alternative to gold.

BTC is similar to gold, but has many advantages; it has a finite supply, and it acts as a hedge against inflation, but it is easier to carry, is highly divisible, and is relatively liquid just like physical gold. Individuals who purchase BTC are primarily doing it for investment purposes. In other words, they are speculating on BTC and believe it will be more valuable in the future than it is today due to its similarities—and advantages—to gold among many other reasons that they might have.

Internet of value

And then we have the internet of value, which at the moment, can only come to fruition by using BSV in your stack. BSV does everything that BTC was supposed to do since it is not restricted by technical limitations. This gives companies the ability to create businesses and applications that empower consumers. Several companies are using BSV to build applications and platforms that give consumers ownership of the data they create online, the ability to monetize that data, censorship resistance, and increased transparency.

Why both will survive

BTC and BSV will survive for at least two reasons:

1. they serve different purposes, and
2. they capture different audiences.

BTC attracts the majority of the individuals who are interested in an alternative investment vehicle. At the same time, BSV captures the lion’s share of developers who would like to build a market-disrupting business. Although BSV has all of the same properties of BTC  (without the technical limitations), we cannot overlook that BTC was first to market. I say that to say this, people—especially newcomers—are going to be more familiar with the item that hit the market first before they become familiar with the alternatives that followed.

That is why we continue to see the individuals interested in an alternative investment gravitate toward BTC before they even consider that BSV is a viable option. And why highly technical individuals who have been a part of the cryptocurrency communities and markets for quite some time gravitate toward BSV.

Final thoughts

At the end of the day, both BTC and BSV are going to be around for many years to come. In all honesty, the two don’t compete, and they captivate different audiences. One is primarily being used as an alternative investment vehicle. The other is being used to create the companies and programs that could ultimately disrupt many modern internet applications as we know it, bringing us closer to a world with an internet of value that empowers the end user.

It is easy to get caught up in a dispute, even an echo-chamber, regarding why only one of these blockchain networks will survive. But when you talk to the average person, especially a no coiner who is interested in jumping into the crypto-markets, they are going to have no idea what someone means when they say that only one coin will survive. While BSV is considered the original Bitcoin now that BTC forked off taking its ticker symbol deviating from Satoshi’s whitepaper to create its own unique protocol, both blockchains will exist for some time since neither compete head to head anymore.
Source : https://coingeek.com/a-tale-of-two-bitcoin/

 



What is BSV Genesis update ?

Passionate by Crypto world: BSV - CLOAK - CROWN and other technologies
human8ty
Jr. Member
*
Offline Offline

Activity: 92
Merit: 1


View Profile
December 24, 2019, 01:52:17 AM
 #6

What is BSV Genesis update ?

Check on https://bitcoinsv.io/vision/  and  https://bitcoinsv.io/genesis-hard-fork/

Quote
Four fundamental pillars form the basis of Bitcoin SV’s roadmap to create the one blockchain for the world: stability, scalability, security, and safe instant transactions (a.k.a 0-confirmation).

“The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling.” – Satoshi Nakamoto (April 2009)

1 – Stability
Businesses, especially the biggest enterprises, require stability before they will operate on a technology platform. Repeated, unnecessary, and unproven changes to the Bitcoin protocol can be detrimental to the economic incentive structure and security of the blockchain. They can also cause significant uncertainties for large scale businesses that need to plan years in advance and commit significant resources before deciding to build applications and projects on Bitcoin SV.

The Bitcoin SV vision is to provide assured stability with only a limited and well known set of changes planned to restore the Bitcoin protocol to its original design, and enable innovation to occur on top of a stable base protocol.

Part of this is restoring the Satoshi op_codes to enable businesses and development teams around the world to create the many solutions possible on the BSV blockchain, such as smart contracts, tokenisation, atomic swaps, and many more.

2 – Scalability
In order for Bitcoin SV to truly act as a global money platform, it is necessary to demonstrate that the platform is ready to process transaction volume at the required scale. The Bitcoin SV roadmap is primarily focussed on delivering capacity increases, through bigger default or miner configurable block sizes and performance improvements. Out of the nine test environments in use by the project, the SV Gigablock Testnet (SV-GBTN) is specifically dedicated to identifying bottlenecks and performance measurement of proposed changes. The SV-GBTN is running on a continuous cycle of performance tests and the results of those are for public consumption so that miners and other industry participants will be able to make informed scaling decisions.

By enabling massive scaling, Bitcoin SV will pave the way for the BSV blockchain to support significantly higher transaction volumes and more transaction fees for miners. This is important for miners to maintain profitability as the block reward will halve again in the year 2020 (reducing from 12 BSV to 6.25 BSV for each block), and halve again in later years.

Massive scaling is also important to convince enterprises to use BSV for their blockchain applications – which will require big blocks and large throughput capacity.

3 – Security
Bitcoin SV will be a global currency. To enable such a future, we need to be prepared to ensure a level of security commensurate with a global money system. To do this, the Bitcoin SV project has focused on rigorous Quality Assurance for mining node software.

This is achieved by implementing a rigid set of test phases with full traceability throughout the test pipeline, to assure users that changes pass through a formal and rigorous validation process before they are accepted. In this respect, Bitcoin SV aspires to levels of Quality Assurance exemplified by mission critical industries such as aerospace, medicine and national security.

First, the team will use best practice change management processes and engage external QA expertise from other security-sensitive industries to monitor and audit its QA processes.

Second, the project will engage the services of an industry-leading blockchain security audit firm.

Third, the project will offer a lucrative bug bounty program matching the likes of Google and Microsoft to motivate and mobilize security researchers around the world to find and responsibly report security vulnerabilities. The team has engaged expert service providers in the field to develop an industry best practice “Responsible Disclosure Program.”

4 – Safe instant transactions (a.k.a. 0-conf)
Instant transactions are key to unlocking the brick and mortar merchant market for Bitcoin SV payments. Security improvements can be made to better secure instant transactions for the future, and the Bitcoin SV roadmap treats safe instant transactions as a key priority.

Moore details check BSV Github https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md

Quote
Genesis Upgrade Specification
Version: 2019-12-19

Authors: nChain Ltd

Introduction
Definitions
Upgrade Activation Mechanism
UTXO Height Rule Determination
Changes to the Bitcoin Specification
Block Consensus Rules
Block Size Consensus Rule
Number of CheckSig Operations per MB of Block Space
Transaction Consensus Rules
Maximum Transaction Size
Maximum Number of CheckSig Operations per Transaction
Signature Hashing Algorithm
nLockTime & nSequence
Script Language Rules
Data Types
Formal Grammar for Bitcoin Script
Validity of Script Consensus Rule
PUSHDATA Only in Unlocking Script Consensus Rule
Disabled Operations Consensus Rule
Script Element Size Consensus Rule
Stack Size Consensus Rule
Script Size Consensus Rule
Numeric Value Size Consensus Rule
Number of Public Keys per Multisig Consensus Rule
Number of Non-Push Operations Per Script Consensus Rule
Stack Memory Usage Consensus Rule
Sunset P2SH
OP_RETURN Functionality
Sunset OP_CHECKLOCKTIMEVERIFY & OP_CHECKSEQUENCEVERIFY
Standard Local Policies
Standard Local Transaction Policies
Maximum Acceptable Transaction Size Policy
Transaction Evaluation Timeout
Standard Local Script Language Policies
Numeric Value Length
Stack Memory Usage Policy
Standard Local P2P Network Policies
Propagation of non-Standard Transactions
Notes
Introduction
This is the specification of the Genesis Upgrade. It defines the upgrade activation mechanism, the changes to the Bitcoin Specification and the Consensus Rules, as well as the Standard Local Policies that are recommended for client implementations.

This document is a specification. It is not a guide and it does not describe implementation specifics or emergent behaviour of the system.

Definitions
The Bitcoin Rules are the precise rules which define Bitcoin. These include rules such as: the sum of the value of the inputs of a transaction must be greater than or equal to the sum of the values of the outputs, and the block subsidy schedule. These are the foundational rules of Bitcoin, irrespective of implementation.

The Consensus Rules are additional rules that have been reached by general agreement and are necessary to implement the Bitcoin Specification in software. They are needed because software has limitations and agreements are needed in order to facilitate integration of the software. Some Consensus Rules are configurable in the software, some are not. An example of a non-configurable Consensus Rule is that the version of a transaction must fit in a signed 32-bit integer. An example of a configurable Consensus Rule, after Genesis activation, is the maximum accepted block size.

Local Policies are additional controls that are implemented in software and may place additional restrictions on the transactions and blocks that the software will propagate to other systems and, for transactions, confirm in blocks. Policies are “local”, they apply to the instance of software that is running, they do not apply to the validation of blocks, or the transactions within a block. A block accepted from another miner may contain transactions that do not conform to local policy.

Standard Policies are common local policies that are used by client software. They are defined as a Standard to facilitate common application across independent software implementations but it is important to note that it is not required that software implement or adhere to these policies.

Throughout this specification the following words are used with specific meanings:

valid - a transaction or block is valid if it follows the Bitcoin and Consensus rules.
invalid - a transaction or block is invalid if it does not follow either the Bitcoin or Consensus rules.
rejected - a transaction or block may be rejected by an implementation due to a Policy. The implementation may not have determined whether the transaction or block was valid or invalid.
Throughout this specification the metric system is used. One KB is one kilobyte which is 1,000 bytes.

Upgrade Activation Mechanism
The Genesis Upgrade will activate at the block heights defined in the table below.

Mainnet   
620,538

Testnet   
1,344,302

Scaling Test Network   
14,896

Regtest   
10,000

The upgraded Bitcoin Rules, Consensus Rules, and Policies become active in the block that is mined at this height.

UTXO Height Rule Determination
The Genesis Upgrade introduces the “UTXO Height” mechanism for determining the Bitcoin Rules, Consensus Rules, and Policies that are to be applied to a transaction. The purpose of this mechanism is to maintain compatibility for UTXO’s that were created under the previous version of the Bitcoin Rules and Consensus Rules.

Every output of a transaction is evaluated under the rules that are in effect for the block in which the transaction is being confirmed. If a transaction is confirmed in a block that has a height which is greater or equal to the Genesis activation height, then the outputs of that transaction must comply with the Genesis Upgrade. If a transaction is confirmed in a block that has a height which is less than the Genesis activation height, then the outputs of that transaction must comply with the rules prior to the Genesis Upgrade.

Every input of a transaction is evaluated under either the rules prior to the Genesis Upgrade, or the Genesis Upgrade rules, depending on whether the UTXO that is being spent by the input was, or will be, confirmed prior to the Genesis activation height or after the Genesis activation height. If the transaction which contains the UTXO that is being spent was, or will be, confirmed in a block before the Genesis activation height then the input script and the output script for the UTXO being spent by that input are evaluated according to rules prior to the Genesis Upgrade. If the transaction which contains the UTXO that is being spent was, or will be, confirmed in a block with a height greater than or equal to the Genesis activation height, then the input script and the output script for the UTXO being spent by that input are evaluated according to the Genesis Upgrade.

Other characteristics of the transaction, such as the maximum number of sigops, are evaluated according to the rules that are in effect for the block in which the transaction is being confirmed.

It is worth noting that, after Genesis activation, a single transaction may spend inputs from before Genesis activation and after Genesis activation, in which case each input is evaluated under the rules that are applicable to that input based upon the block height that the transaction referenced by that input was confirmed.

Changes to the Bitcoin Specification
Block Consensus Rules
These consensus rules apply to blocks that are produced after Genesis activation.

Block Size Consensus Rule
The size of a block is the size in bytes of the serialized form of the block, including the block header and all of the transactions confirmed by the block[^1].

The consensus rule that restricts the maximum size of a block to a specific number of bytes has been converted into a configurable consensus rule. The default value of the maximum acceptable size of a block is unlimited.

Miners are expected to reach consensus on this value and configure it manually.

Number of CheckSig Operations per MB of Block Space
The consensus rule that limits the number of checksig operations per megabyte of block space has been removed.

Transaction Consensus Rules
These consensus rules apply to transactions that are confirmed in blocks after Genesis activation.

Maximum Transaction Size
The size of a transaction is the size in bytes of the serialized form of the transaction[^2].

The maximum size of a transaction is 1GB (1,000,000,000 bytes). This limitation is expected to be lifted in the future.

Maximum Number of CheckSig Operations per Transaction
The consensus rule that limits the number of checksig operations per transaction has been removed.

Signature Hashing Algorithm
The signature hashing algorithm for UTXO’s created after the Genesis Upgrade remains the same as it was prior to the Genesis Upgrade. This is the signature hashing algorithm that was introduced on the Bitcoin Cash blockchain during the BTC/BCH split on the 1st August 2017. The signature hashing algorithm is described in requirement 6-2 of the specification.

After the Genesis activation, the original signature hashing algorithm, which is still in use on the BTC blockchain, is valid for outputs created before the Genesis activation.

nLockTime & nSequence
After Genesis activation, the functionality of the nLockTime field of a transaction and the nSequence fields of transaction inputs revert to their original purpose. The rules defined here only apply to transactions that are confirmed after Genesis activation.

The nSequence fields of every transaction input and the nLockTime field of the transaction collectively determine the “finality” of a transaction. If a transaction is “non-final” then it can not be valid but it can become “final” at a later time. If a transaction is “final” then it can be valid.

If the value of nSequence of a transaction input is 0xFFFFFFFF then that input is a “final input”.
If the value of nSequence of a transaction input is not 0xFFFFFFFF then that input is a “non-final input”.
If all of the inputs of a transaction are “final inputs” then the transaction is “final”, irrespective of the value of the nLockTime field.
If one or more of the inputs of a transaction are “non-final inputs” then:
If the value of the transactions nLockTime field is less than 500,000,000 then the field represents a block height.
If the height of the block in which the transaction is being confirmed is greater or equal to the value of this field, then the transaction is “final”.
Otherwise the transaction is “non-final”
If the value of the transactions nLockTime field is greater or equal to 500,000,000 then the field represents a UNIX epoch timestamp.
If the MTP of the last 11 blocks is greater or equal to the value of this field, then the transaction is “final”.
Otherwise, the transaction is “non-final”.
A “final” transaction may be confirmed in a block following the “first-seen” rule.

A new transaction must replace a prior “non-final” transaction if it has the same inputs in the same order and every sequence number for every input in the new transaction is not less than the sequence number for the corresponding input in the prior transaction and the sequence number of at least one input in the new transaction is greater than the sequence number for the corresponding input in the prior transaction.

If a new transaction is detected which does not fulfill all of these requirements then it must be rejected.

If a new transaction is detected which has inputs that conflict with the inputs of a “non-final” transaction, but which are not identical to the inputs of the “non-final” transaction, then the “non-final” transaction is the “first seen” transaction and takes priority over the new transaction.

Script Language Rules
Bitcoin Script is the programming language that is used to lock and unlock transaction outputs. This section contains changes to the Script Language Rules.

The rules defined here apply to locking and unlocking scripts for transactions outputs that are created after the Genesis activation. The previous rules apply to transaction outputs created prior to Genesis activation.

Data Types
All data items in Bitcoin Script are a byte sequence. Some operations interpret their parameters as numeric or boolean values and require the item to fulfill the requirements of those types. Some operations produce items on the stack which are valid numeric or boolean values.

A byte sequence has a length and a value. The length of the byte sequence must be an integer greater or equal to zero and less than or equal to 2^32-1 (UINT32_MAX).

The byte sequence of length zero is called the “null value”.

Any data item can be interpreted as a boolean value. If the data item consists entirely of bytes with value zero, or the data item is the null value, then the boolean value of the item is false. Otherwise, the boolean value of the item is true.

A data item can be interpreted as a numeric value. The numeric value is encoded in a byte sequence using little-endian notation. The byte sequence of length zero (the null value) is the standard representation for the numeric value zero. There is a Consensus Rule on the maximum size of a numeric value that is defined below.

Formal Grammar for Bitcoin Script
A formal grammar has been defined for Bitcoin Script. This section of the document defines that grammar but it does not describe how this definition is applied. The application of the grammar definition is described in further parts of this document.

This grammar is fully described by the following BNF grammar:

 ::[/s]= any sequence of bytes
It’s worth highlighting the following features of this formal grammar:

The complete script consists of two sections, the unlocking script and the locking script. The locking script is included in the transaction output that is being spent, the unlocking script is included in the transaction input that is spending the output.
The unlocking script can only contain constants. This requirement is part of Validity of Script Consensus Rule, defined later.
A branching operator (OP_IF or OP_NOTIF) must have a matching OP_ENDIF.
An OP_ELSE can only be included between a branching operator and OP_ENDIF pair. There can only be at most one OP_ELSE between a branching operator and an OP_ENDIF.
OP_RETURN may appear at any location in a valid script. The functionality of OP_RETURN has been restored and is defined later in the section OP_RETURN Functionality. Grammatically, any bytes after an OP_RETURN that is not in a branch block are not evaluated and there are no grammatical requirements for those bytes.
Note that disabled operations are included in this grammar. A disabled operation is grammatically correct but will produce a failure if executed.
Validity of Script Consensus Rule
The locking and unlocking scripts for every input of a transaction must be grammatically valid, as defined by the formal grammar above.

Note that this includes the requirement that unlocking scripts only contain PUSHDATA operations.

Also note that the scripts must be grammatically valid when they are spent. It is not required that the output scripts of a transaction are grammatically valid although it is highly recommended that client software implement this restriction as a policy.

PUSHDATA Only in Unlocking Script Consensus Rule
After Genesis activation, the unlocking scripts used in transaction inputs may only contain PUSHDATA operations, as defined by the formal grammar above.

In contrast to all the other updates in this section, this consensus rule is activated for all inputs of transactions that are, or will be, confirmed in a block after Genesis activation, regardless of the height of the UTXO being spent.

This rule is a subset of the Validity of Script Consensus Rule defined above but is included separately because the activation conditions are different.

Disabled Operations Consensus Rule
The following operations are disabled: OP_2MUL, OP_2DIV, OP_VERIF, OP_VERNOTIF.

Although these operations are grammatically correct and can appear in valid Script, their execution will cause script failure and therefore transaction invalidity. If they are present in un-executed script, the script execution may succeed.

It is very strongly recommended that these operations not be used at all until they are activated.

Script Element Size Consensus Rule
The consensus rule that limits the maximum size of a script element has been removed.

The functionality previously provided by this consensus rule is now covered by the Stack Memory Usage Consensus Rule.

Stack Size Consensus Rule
The consensus rule that limits the combined number of elements that can be placed on the stack, and the altstack, has been removed.

The functionality previously provided by this consensus rule is now covered by the Stack Memory Usage Consensus Rule.

Script Size Consensus Rule
The consensus rule that limits the maximum size of a script has been removed.

The functionality previously provided by this consensus rule is now covered by the Maximum Transaction Size Consensus Rule and the Stack Memory Usage Consensus Rule.

Numeric Value Size Consensus Rule
For a byte sequence to validly represent a numeric value, the length of the byte sequence must be less than or equal to 750,000 bytes. A byte sequence that is larger than this is a valid byte sequence but is not a valid numeric value.

Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).

Number of Public Keys per Multisig Consensus Rule
The consensus rule that limits the number of public keys per multisig has been changed to be 2^31-1 (INT32_MAX).

Number of Non-Push Operations Per Script Consensus Rule
The consensus rule that limits the number of non-push operations per script has been removed.

The functionality previously provided by this consensus rule is now covered by the Stack Memory Usage Consensus Rule while other capabilities manage the cost of execution.

Stack Memory Usage Consensus Rule
The stack memory usage consensus rule limits the amount of memory that can be used on the stacks. This rule is evaluated against the sum of the memory used by the stack and the memory used by the altstack.

If the execution of the unlocking and locking script for an input uses more stack memory than defined in this rule, then the transaction is invalid.

The memory usage of a stack is calculated using a specific formula, so that it can be coordinated across software implementations. The formula for calculating the memory usage of a stack is:

usage = sum of (for each element: 32 + size in bytes of element)

where "size in bytes of element" is the size in bytes of the element when serialized in the Bitcoin Serialization Format.

This is a configurable consensus rule, with a default value that is formally unlimited but will in practice depend on the capabilities of the system that is evaluating the script.

Miners are expected to reach consensus on this value and configure it manually.

Sunset P2SH
Pay to script hash (P2SH) is a capability that was added to Bitcoin in 2012 by BIP13. It assigns a special meaning to a specific output script template. If the specific script template is present in the script of an output that is being spent by an input then it is treated in a different way, rather than being executed normally.

This feature is being removed by the Genesis Upgrade. The P2SH script template will not be treated “specially” for outputs but will be evaluated normally.

OP_RETURN Functionality
The functionality of the OP_RETURN operation is being restored. OP_RETURN will cause termination of the script and the validity of the script is determined by the value of the top item on the stack.

Sunset OP_CHECKLOCKTIMEVERIFY & OP_CHECKSEQUENCEVERIFY
OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY are operations that were introduced by BIP0065 and BIP0112.

These operations revert to NOP’s, which have no effect.

However, most implementations have a local policy which rejects scripts that contain “upgradeable NOPs”, including these, and will reject transactions containing these operations.

Standard Local Policies
Policies are settings that are configured by software operators. These settings are generally required by software implementations. It is expected that as implementations of the software mature that these settings will be adjusted.

Policies control which transactions the software will propagate across the P2P network or include in a block. However, policies are not Bitcoin Rules or Consensus Rules and are not used to determine the validity of blocks or the transactions confirmed by a block.

Four new standard policies have been defined as part of the Genesis Upgrade and one prior policy has been changed. These policies are listed below. It must be noted that this is not an exhaustive list of all standard policies, many of the policies that were standard before the Genesis Upgrade have been retained.

Standard Local Transaction Policies
Maximum Acceptable Transaction Size Policy
The maximum acceptable transaction size is a standard policy that configures the largest transactions that the software will propagate across the P2P network or include in a block.

The value of this configuration item must be less than or equal to the value of the Maximum Transaction Size Consensus Rule or it will have no effect

The default value for this policy setting is 10MB (10,000,000 bytes).

Transaction Evaluation Timeout
The transaction evaluation timeout is a standard policy that defines the maximum amount of time that the software will allow for the evaluation of a transaction before terminating the evaluation and rejecting the transaction. This setting is always defined with a time unit and the default value is 1 second.

This policy applies to transactions that are received by the software and its processes for determining whether the transaction should be propagated across the P2P network or included in a block. The policy does not apply to the evaluation of transactions in a confirmed block.

Note that:

if the evaluation of a transaction is terminated due to exceeding the timeout limit then the software has not determined whether the transaction is valid or invalid, it has merely decided not to make that determination;
the time taken to evaluate a transaction by a particular system will vary based on the software used, the resources available, and other dynamic factors such as the load on the system. It is not an exact measurement.
Standard Local Script Language Policies
Script Language Policies apply to the execution of script.

It must be noted that there are existing policies regarding the representation of numeric values in byte sequences, in particular the minimal encoding policy. These policies have not been changed as part of the Genesis Upgrade and are not documented here.

Numeric Value Length
The length of numeric value policy defines the maximum length of a byte sequence to be considered a valid numeric value. The default value for this policy is 250,000 bytes.

Transactions which contain script that consume numeric values that are larger than this policy setting will be rejected; they will not be propagated across the P2P network or included in a block.

Stack Memory Usage Policy
The stack memory usage policy limits the amount of memory that can be used on the stacks. This policy is evaluated against the sum of the memory used by the stack and the memory used by the altstack.

If the execution of the unlocking and locking script for an input uses more stack memory than defined in this policy, then the transaction is rejected.

The memory usage of a stack is calculated using the same formula described in the Stack Memory Usage Consensus Rule (above).

The default value for this policy is 100MB (100,000,000 bytes). The value of this policy must be less than or equal to the value of the Stack Memory Usage Consensus Rule.

Standard Local P2P Network Policies
Propagation of non-Standard Transactions
The local policy on the Propagation of non-standard transactions controls whether the software will propagate non-standard transactions to other peers on the P2P network.

Before Genesis Activation, the default setting for this policy is that non-standard transactions will not be propagated across the P2P Network.

After Genesis Activation, the default setting for this policy is that non-standard transactions will be propagated across the P2P Network.

Note that even though non-standard transactions will be propagated across the P2P Network after Genesis activation, other policies such as the Maximum Acceptable Transaction Size Policy remain in effect.

Pipasol
Newbie
*
Offline Offline

Activity: 15
Merit: 1


View Profile
December 24, 2019, 01:57:52 AM
Merited by Bitcoin SV (1)
 #7

I've just come across your BSV post and I must say it's very interesting, thanks for sharing. What is force of BSV ?
human8ty
Jr. Member
*
Offline Offline

Activity: 92
Merit: 1


View Profile
December 24, 2019, 01:58:33 AM
 #8

Let us look at the technology at the service of people. Computer science is in its infancy, we are only at the beginning. This powerful technology will be very different in a few generations, let us imagine in three hundred years what it will be possible to achieve with dematerialization? perhaps teleport water from Earth to Mars? In the Futur, people may talk about a quantum computer dating back to the Stone Age. In any case, the Blockchain digital environment can be like a time stamping gateway up to and beyond this period. Remember the Floppy air as the floppy disk, see the compression evolution, a Turing computer take more than 15 square meters, today miniaturization is another world, the same goes for what the Blockchain offers you, a gateway to a time-stamped executive system, which can be confidential, or even anonymous decoding with a specific code. All modern industries can join it to allow an event to be time-stamped, to make it material, indelible, engraved in digital stone. Whether it is a contract between several unlockable parties, a sentence, a good, the origin of a dna or even and the whole history of the steps to produce a cappuccino, images, movies and now betting games and video games, IoT encrypted communication environment, or publish your cd books in your space... the blockchain is compatible in everything since it is one of the founding pillars and witness of the birth of the web.3.8 among other things, allows to exchange goods materialized by NFT "addressed" to a specific and unique "thing", you, your property right etc... You can remain in control of your data at any time, it belongs to you in the dematerialization transcribed of any data in the Block of the Chain, redundant, indelible, unforgeable. For a company the interest is to be able to benefit from a distributed system, unified and accessible everywhere at all times, your operating station can be the blockchain system like Metanet from nChain which also allows to propose several hundred applications, at the moment (future) of a kind of Revolutive Android I.A. system in much more evolved, secure, indelible and accessible everywhere. Let's see what's in store for us this coming year, even though we've already started to take another step towards Blockchain BSV evolution.

ReD_Yaka_MoZ_
Jr. Member
*
Offline Offline

Activity: 47
Merit: 1


View Profile
December 24, 2019, 02:02:22 AM
Last edit: December 24, 2019, 02:35:50 AM by ReD_Yaka_MoZ_
 #9



Thanks for links @Human8ty


I've just come across your BSV post and I must say it's very interesting, thanks for sharing. What is force of BSV ?


Bitcoin Satoshi Vision (BSV) is the only Bitcoin implementation that respects the original Bitcoin design, protocol and vision as expressed by its creator Satoshi Nakamoto. Squire supports the BSV roadmap because it is the only project to enable massive block chain scaling by dramatically increasing the size of Bitcoin blocks so that the blocks can hold many more transactions and data and thus generate more transaction costs for the miners and more contours for the cryptography industry. Why massive block chain scaling is important for the entire interdependent Bitcoin ecosystem. Craig S. Wright, who sits on Squire's Strategic Advisory Board, has been granted U.S. copyright, as author under the pseudonym Satoshi Nakamoto, for the original Bitcoin white paper and most of the original Bitcoin code.

About the Bitcoin Association
The Bitcoin Association is the leading global organization for the Bitcoin industry. It brings together merchants, exchanges, application developers, companies, miners and others in the Bitcoin ecosystem to advance the growth of the Bitcoin business. The Bitcoin Association supports Bitcoin SV (BSV) as the original Bitcoin with a stable protocol and an evolving roadmap to become the new global financing and enterprise block chain. The Bitcoin Association seeks to create a regulatory-compliant ecosystem that encourages lawful behavior while enabling innovation in cryptography.


Passionate by Crypto world: BSV - CLOAK - CROWN and other technologies
Pipasol
Newbie
*
Offline Offline

Activity: 15
Merit: 1


View Profile
December 24, 2019, 02:06:53 AM
 #10

Where is the list of applications developed for BSV?
Do_zzze
Jr. Member
*
Offline Offline

Activity: 147
Merit: 1


View Profile
December 24, 2019, 02:13:32 AM
 #11

Where is the list of applications developed for BSV?


Here is a list of more than +357 projects (at this day) developed for the BSV ecosystem / environment and this is just the beginning. You can see that there is no unemployment Cool

https://ibb.co/T14yhd9


Pipasol
Newbie
*
Offline Offline

Activity: 15
Merit: 1


View Profile
December 24, 2019, 02:14:48 AM
 #12

Where is the list of applications developed for BSV?


Here is a list of more than +357 projects (at this day) developed for the BSV ecosystem / environment and this is just the beginning. You can see that there is no unemployment Cool

https://ibb.co/T14yhd9






WoOw thank you very much!
ReD_Yaka_MoZ_
Jr. Member
*
Offline Offline

Activity: 47
Merit: 1


View Profile
December 24, 2019, 02:18:17 AM
 #13

Let us look at the technology at the service of people. Computer science is in its infancy, we are only at the beginning. This powerful technology will be very different in a few generations, let us imagine in three hundred years what it will be possible to achieve with dematerialization? perhaps teleport water from Earth to Mars? In the Futur, people may talk about a quantum computer dating back to the Stone Age. In any case, the Blockchain digital environment can be like a time stamping gateway up to and beyond this period. Remember the Floppy air as the floppy disk, see the compression evolution, a Turing computer take more than 15 square meters, today miniaturization is another world, the same goes for what the Blockchain offers you, a gateway to a time-stamped executive system, which can be confidential, or even anonymous decoding with a specific code. All modern industries can join it to allow an event to be time-stamped, to make it material, indelible, engraved in digital stone. Whether it is a contract between several unlockable parties, a sentence, a good, the origin of a dna or even and the whole history of the steps to produce a cappuccino, images, movies and now betting games and video games, IoT encrypted communication environment, or publish your cd books in your space... the blockchain is compatible in everything since it is one of the founding pillars and witness of the birth of the web.3.8 among other things, allows to exchange goods materialized by NFT "addressed" to a specific and unique "thing", you, your property right etc... You can remain in control of your data at any time, it belongs to you in the dematerialization transcribed of any data in the Block of the Chain, redundant, indelible, unforgeable. For a company the interest is to be able to benefit from a distributed system, unified and accessible everywhere at all times, your operating station can be the blockchain system like Metanet from nChain which also allows to propose several hundred applications, at the moment (future) of a kind of Revolutive Android I.A. system in much more evolved, secure, indelible and accessible everywhere. Let's see what's in store for us this coming year, even though we've already started to take another step towards Blockchain BSV evolution.




Your vision is very relevant, seems futuristic and enthusiastic, the metanet protocol of nChain and BSV seems compatible with what you describe of the future.

Passionate by Crypto world: BSV - CLOAK - CROWN and other technologies
human8ty
Jr. Member
*
Offline Offline

Activity: 92
Merit: 1


View Profile
December 24, 2019, 02:19:22 AM
Last edit: December 24, 2019, 03:48:05 AM by human8ty
 #14

Your vision is very relevant, seems futuristic and enthusiastic, the metanet protocol of nChain and BSV seems compatible with what you describe of the future.

YES. More than
Quote
you could know Lowest unit cost drives innovation, further strengthening Bitcoin SV's lead Bitcoin SV emphasis on daisy-chaining (i.e. factory scaling) through massive blocks allows its unit cost (transmission costs) to decrease more rapidly. They call this relationship the experience curve: the more experience a company has in producing a particular product, the lower its costs. Bruce Henderson, the founder of the OCG, said the following: Costs generally drop by 20-30% in real terms every time the accumulated experience doubles. -

Market-leading unit costs enable unprecedented use cases / innovations that further increase the quantity of units produced (i.e. transactions on a particular blockchain), further improving unit costs through economies of scale. Bitcoin SV is now visibly reaping the benefits of this virtuous circle.
AyouthR
Newbie
*
Offline Offline

Activity: 24
Merit: 0


View Profile
December 24, 2019, 02:24:32 AM
 #15

... allows to exchange goods materialized by NFT "addressed" to a specific and unique "thing", you, your property right etc... You can remain in control of your data at any time, it belongs to you in the dematerialization transcribed of any data in the Block of the Chain, redundant, indelible, unforgeable......



I get on the BSV moving train and I wonder... As I read The above EU directive - the NFT  project would also be affected in the ability to transfer say gaming assets from one environment to the other. Did you read paragraph 53 - that is insane
They want to integrate all the national registers.

The direktivet States that ingame assets are not covered Unless they are tradeable outside the games ecosystem
Trading with any virtuel asset or art or providing a Wallet are subjects under the directive
Yes  I know these integrations should not be a surprice - its just too invasive to the still existing national States and the privacy of the citizens of those States

By Wallet  they does not just mean mobile apps. But I guess we are all just testers
Do_zzze
Jr. Member
*
Offline Offline

Activity: 147
Merit: 1


View Profile
December 24, 2019, 02:33:00 AM
 #16



Google's patent library confirms that nChain (BSV) obtained the patent for the smart contracts imposed by Blockchain.

While nChain has a total of 826 patents filed, 1,450 pending and approximately 200 granted,
https://www.youtube.com/watch?v=ZBbN2dy_uWg&feature=youtu.be


suchpool
Newbie
*
Offline Offline

Activity: 2
Merit: 1


View Profile
December 24, 2019, 02:44:11 AM
Merited by Bitcoin SV (1)
 #17

What is BSV Genesis update ?


This makes me very enthusiastic that BSV can steer the world towards new horizons. It's a matter of mass adoption and simple understanding.


Quote
Source https://coingeek.com/genesis-is-coming-bitcoin-sv-node-publishes-full-tech-specs-for-february-hard-fork/

The Genesis upgrade will introduce new capabilities in the form of scaling, and restore (or remove) parts of the original Bitcoin protocol that were controversially altered in the years since 2009. This will enable a new world of Metanet-based applications, tokenization, smart contracts, more instant confirmations, and time-locked transactions.

That 2GB block limit BSV implemented in its July 2019 “Quasar” upgrade was just an entree. In keeping with Satoshi’s vision of massive on-chain scaling, Genesis will remove default block size limits completely. Miners will now have the power to set their own block size limits—or have none at all.

The original functionality of nLockTime and nSequence will be restored, after they were repurposed by BTC Core developers. This allows, among other things, someone to send a Bitcoin transaction that will not be written to the blockchain until a certain time—a form of will or trust that could execute years into the future. This is only possible on a stable protocol that can’t be changed.

Bitcoin’s Script language will see its grammar formalized and the original function of OP_RETURN will return, making developers’ jobs easier. Additionally, Script’s numeric type will change from 32-bit numbers to “big numbers.” The release says this “will dramatically increase the mathematical capabilities of the Bitcoin Script language”, allowing even more advanced functionality.

Non-standard and complex transactions (eg: anything other than payments or plain data transactions) will now be available to everyone via relay across the peer-to-peer network (P2P Relay). These previously required direct contact and negotiation with a miner to complete.

New pay-to-script hash (P2SH) transactions will no longer be permitted post-Genesis, although previous transactions sent under this rule will remain valid. This will encourage better privacy practices and create a more honest record of events.

After February 4, 2020, Bitcoin will be more powerful, more consistent, and ready to start building a new global economy. And no-one will be able to alter it—“not even God,” according to Dr. Craig Wright. That’s the kind of stability Bitcoin was always meant to have.
Do_zzze
Jr. Member
*
Offline Offline

Activity: 147
Merit: 1


View Profile
December 24, 2019, 02:51:34 AM
 #18

Quote
from = https://coingeek.com/_unwriters-tools-explained-practical-use-cases-reviewed/

_unwriter has been going HAM since the beginning of the New Year, releasing a new tool to enable folks to build on top of Bitcoin SV seemingly every day.

While most people paying attention can clearly see that he is contributing and is paving the way for great things to be built, perhaps some with a limited technical background are having trouble keeping up. I am fairly technical myself and I am having a hard time keeping up!

On occasion I find myself still having to go back an re-read how this stuff works, so I decided to write a post explaining what all these tools are at a high-level and some practical use cases that some have already proposed and some that perhaps no one else has thought of yet.

BitDB – BitDB is a database that structures the transactions in the blockchain in a readable, formatted way. We no longer have to write redundant code to fetch data from a transaction. This tool was released before the fork, but one must understand what this is in order to grasp how the other tools work.

Genesis, Babel, Chronos and Meta

While these seem mysterious and complex with their cryptic names, each one of these is simply a subset implementation of a BitDB.

Genesis – an BSV exclusive BitDB. It only uses the legacy address format and is optimized for performance based on the previous stress tests.

Babel – another subset of BitDB, is a database optimized for users to query arbitrary data written in OP_RETURN to the chain. Since it’s focus is only on the arbitrary data stored in the chain, therefore less, querying it will be much faster.

Use case: Babel should be used for applications that only need access to the data, files or protocols stored in the blockchain, not necessarily the scripts or other details of a transaction.

Chronos – another subset of BitDB, this database is used to track timestamps of transactions, with the caveat that this database only tracks those transactions over the previous, rolling 24-hour period.

This means that transactions sent two days ago are not in the Chronos database. Why?

If we think of Babel, we know that since the database contains less data querying it is much faster. Chronos should be very fast as well since only transactions are stored from the previous 24 hours!

Use case: Since Chronos stores each transaction with a timestamp chronologically, this database can be used as a single source of truth in terms of keeping track of timing of transactions. Users do not have to rely on inconsistencies from other nodes, their node or miners. Therefore developers have an incentive to use Chronos for their applications rather than (god forbid) their own ‘full node’.

Meta – Yet another subset of BitDB, this database contains only block attributes, ex. Block height, difficulty, timestamps, etc. all the way back to the first block mined. Since this one stores even less data than Babel and Chronos, it is the fastest BitDB instance.

Use cases:

– Leverage the Difficulty field of the block metadata to add AI features to your video game application, for example the Difficulty of the Bitcoin SV network rising would actually increase the difficulty of your video game!
– Use the timing of the next block mined or block height to determine an increase of attributes of video game character, or age of some digital character (credit to @itisbitcoin).

Now we can explore how the tools interact with each other.

Bitsocket – This tool was also released prior to the fork, it is a mechanism for listening for different types of transactions based on your own custom query, then doing some function that you implement in code.

Which other tools does it use?

This tool is used along with BitDB, meaning it can be used with each of Genesis, Babel, Chronos, and Meta.

Use cases:

– Listen to a single one of your Bitcoin addresses, (ex. the next Bitcoin address dynamically leveraging Handcash) and once a transaction is received, send an email to yourself.
– When customer pays to a Bitcoin address, but still in an unconfirmed state, send an order confirmation email to the customer. Once that transaction has a certain number of confirmations (ex. 6) send another notification to your ERP system or yourself indicating the order is eligible to be picked/shipped.

Bitpipe – Server side application that can take Bitcoin transactions requests formatted in JSON, then broadcast them to the network. This tool is probably my favorite.

The JSON tells Bitpipe how to send the transaction, meaning that the request is only a request, not a Bitcoin transaction. The owner of the Bitpipe pays for the transactions, meaning the transactions initiated in the requests are free to that party.

The request can tell Bitpipe to send 2000 satoshis to address B, or to send some encrypted data to address C – or do both in one request.

Custom filtering can be added to your instance of Bitpipe such that you only broadcast certain transactions, meaning if someone sends a random request structured in a way you do not expect, you can simply reject or ignore it.

Personally I am excited about this as it no longer requires developers to write the redundant input/output managing and transaction signing logic in their applications in order to send Bitcoin.

Any application, any programming language is trivially capable of making HTTP requests in a JSON format, enabling almost any external app to quickly interact with the Bitcoin SV blockchain.

With this, we have a method of external applications being capable of interacting with Bitcoin, without actually needing to own Bitcoin.


$apagut ✋💵 Alex Agut
@apagut
Don't ask companies "use the blockchain" or "just use Bitcoin"

Give them ready made products that are no different to their current tools. People won't start learning what the hell is an OP_RETURN or what's a satoshi.

Ready made. Running on BSV.

128
4:03 PM - Jan 31, 2019
Twitter Ads info and privacy
41 people are talking about this
This tool enables exactly what Alex is talking about in his tweet, we can on-board companies by just telling them to use a standard HTTP requests to a Bitpipe node with a specified JSON document/protocol in order to leverage the powerful properties of Bitcoin.

Use cases:

– Make deal with external application entity to process an X number of a certain type of transactions per month through your Bitpipe node. For example, the 3rd party can pay you $100/month in fiat, while you broadcast their transactions for a fraction of the cost and taking the profit.
– EDI transmision, an ERP system sends an HTTP request with details of 850 purchase order in OP_RETURN to a Bitpipe instance, which broadcasts the transaction to the receiver’s address. ERP does not have to manage private keys or keep track of Bitcoin.

Bitchat – This tool is more simple, it is a real-time chat application on the blockchain. Users send chat message and since it leverages Bitpipe, the transactions are free as long as it is funded.

Which other tools does it use?

BitDB, BitSocket, BitPipe

Bitcom – Bitcom is a tool you can use to create your own space, protocol or database in the blockchain. The idea is that a Bitcoin receive address generated from your private key represents uniqueness, and since it is derived from your key it proves ownership.

Using OP_RETURN, you would send a transaction containing:

OP_RETURN <yourBitcoinAddress> <your data or protocol>

Use cases:

– Leverage encryption to store your own database on-chain, where lookups are easily filterable (on your address), eliminating the need (thus reducing costs) to run a MongoDB or SQL instance for your application
– Create your own video game protocol, where commands are prefixed with your Bitcoin address, and the commands represent some state change of their character in the environment of the game

B: Protocol created by _unwriter to store and reference arbitrary data on the Bitcoin blockchain.

Which other tools does it use?

Bitcom

Use case:

– This is so bad-ass it speaks for itself.
– Create a directory of ownership of files, pictures or audio that can be referenced in your application. For example, assign files that could represent a character or set of attributes (RPG?!) to a user based on their own generated Bitcoin address.

OP_Return <yourInputAddress> <usersBitcoinAddress> <JSONDocumentAttributes>

Datapay – Leverages the bsv javascript library maintained by Ryan X. Charles, this is a library that lets you broadcast a transaction with minimal code written. You can send Bitcoin, write data or both with ease. Great place to start here for beginners looking to get into Bitcoin development.

ButtonPage – Web page where users can generate a dynamic money button on the fly, and can share the URL with others. Using the moneybutton documentation, users can easily tinker with the fields to create a custom money button that pays themselves, their friends or multiple people with any amount of Bitcoin.

This URL can also be generated in code, so that an application could generate a money button, then share with a user interacting with their application.

Use case – On an e-commerce site, generate a money button URL where users can pay the invoice (order number in OP_RETURN) for their order of goods online. This money button could be configured with multiple outputs such that the merchant and suppliers are paid at the moment the user swipes to pay for their order.

The possibilities of development on Bitcoin SV are so great with the creation of these tools and are a demonstration of what can be done with a locked down protocol.

By creating these tools, _unwriter is signaling to all of us his intent to build. He/She/They are putting pressure on us all of us by taking away the excuse to build by providing these tools that streamline development, enable scalable applications, and create the robust eco-system needed to sustain the network and security model going forward.

Let me know what you think, what can be improved in this article and what other use cases you can think of that are possible with these tools!

The original post can be found at https://www.yours.org/content/_unwriter-s-tools-explained--practical-use-cases-reviewed-93d7bff2fef8



It is clear that the perspectives go beyond the simple classical crypto, I hope that the community will be able to grasp the importance and subtlety of what is being built with BSV.

ReD_Yaka_MoZ_
Jr. Member
*
Offline Offline

Activity: 47
Merit: 1


View Profile
December 24, 2019, 02:55:42 AM
 #19

The remittance industry has grown significantly over the last decade and will probably continue to expand in the years to come, nChain and its BSV has a bright future ahead of it provided the world learns what BSV is all about with simple tools that even grandma can easily use in 3 clicks.

Passionate by Crypto world: BSV - CLOAK - CROWN and other technologies
human8ty
Jr. Member
*
Offline Offline

Activity: 92
Merit: 1


View Profile
December 24, 2019, 02:58:20 AM
 #20

The remittance industry has grown significantly over the last decade and will probably continue to expand in the years to come, nChain and its BSV has a bright future ahead of it provided the world learns what BSV is all about with simple tools that even grandma can easily use in 3 clicks.


Yes it's a fact also the distribution network is paramount! you can have the idea of the century but if the software is not translated or worse badly distributed then everything you build can be thrown into oblivion and then copied and improved by other entities or countries. BSV is no exception to the rules.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!